Вам нужен разработчик. Независимо от того, являетесь ли вы новым основателем с интересной идеей или опытным директором по маркетингу, который хочет сделать что-то новое в своей компании, вы знаете, что вам нужен разработчик, но понятия не имеете, как они это делают что они делают.

Не волнуйтесь, вы в хорошей компании.

Черная магия… Алхимия…. Вуду… процесс заставить компьютер что-то делать редко понимается. Все, что знает клиент, - это то, что ему нужно что-то построить, а для этого нужно, чтобы разработчик творил чудеса. Часто эта неуверенность приводит к некоторому запугиванию и, следовательно, к недоверию.

Если вы работали с компанией-разработчиком в прошлом, то это чувство может быть еще сильнее, если этот опыт не удастся. Обычно это бывает разных вкусов:

  • «Мой разработчик перестал отвечать на электронные письма после того, как я внес крупный промежуточный платеж, и у меня остался проект, который выполнен на 80%».
  • «Моя команда разработчиков отключилась на шесть месяцев и вышла с чем-то совершенно отличным от того, что я имел в виду».
  • «Мой разработчик все еще здесь! Каждый месяц я получаю счет за все больше и больше часов за вещи, за которые, как мне казалось, я уже заплатил! »

Все эти ситуации заставят кого-нибудь с осторожностью относиться к работе с кодировщиками. Развитие часто сравнивают с хирургией. Вы знаете, что это необходимо, и вы знаете, что это должно помочь, но вы не хотите терпеть боль.

Так как же найти фирму по развитию, которая развеет эти страхи? Как вы можете чувствовать себя комфортно и быть ответственным, даже если вы не совсем понимаете, чем занимается команда?

Ответ заключается в том, чтобы найти разработчика, который основывается на прозрачности. Моя цель в этой серии статей - помочь любому, кто ищет команду разработчиков, найти фирму, которой можно доверять и с которой можно установить долгие и продуктивные отношения.

Поиск прозрачного разработчика начинается в самом начале любого проекта: с предложения. Это первый результат, который любая фирма предоставляет своему клиенту, поэтому он является хорошим индикатором того, как будет работать с ними.

Вы хотите знать, что работаете с солидной и достойной компанией-разработчиком. Чтобы выбрать подходящий для вас, поищите эти вещи в их предложениях.

Ясность

Предложение - это основа проекта. Он определяет спецификации (или спецификации) того, что делается, сколько это стоит и когда будет закончено.

Если и когда произойдет разногласие или недоразумение, то обе стороны будут ссылаться на спецификацию, чтобы попытаться решить эту проблему. Если язык написан не так, чтобы быть кристально ясным для обеих сторон, они оба будут интерпретировать его по-разному.

Следствие нечеткого языка часто проявляется так:

Клиент: если клиент думает, что разработчик не выполняет свою работу и не выполняет то, что они видят как требования, тогда он может начать злиться, и ему станет труднее работать.

Разработчик: с другой стороны, если разработчик чувствует, что клиент использует свое понимание спецификации, чтобы бесплатно выполнить дополнительную работу, он может обидеться и в некоторых случаях дела могут не работать наилучшим образом.

В любом случае проект может очень быстро выйти из строя, и это часто заканчивается недовольством одной или обеих сторон. Этого можно избежать с помощью некоторой ясности.

Ключи к четкому предложению

  • Оценка должна быть простой, точной и показывать твердое понимание того, что такое успешная доставка. Хорошим признаком того, что разработчик пытается сосредоточить внимание и на понятности, является либеральное использование маркированных списков вместо длинных, плавных абзацев.
  • В четком предложении следует как можно больше избегать технического жаргона и цветистых словечек. По необходимости они будут, но хорошая оценка написана для 8-го класса, а не для профессора колледжа.
  • Всегда должен быть раздел предположений. Здесь разработчик объясняет предположения, которые они делают, чтобы сделать оценку. Это могут быть такие вещи, как то, можно ли будет использовать веб-приложение на телефоне, технический стек, который разработчик хочет использовать, или кто управляет различными серверами. Если есть разногласия по этим вопросам, самое время их обсудить, а не тогда, когда команда продвигается к производству.

Фиксированная цена

Это горячая кнопка для многих разработчиков, но если цель состоит в том, чтобы быть более прозрачным и открытым для клиентов, то нет лучшего способа начать отношения, чем показать им, сколько именно что-то будет стоить, до первой строчки кода написано.

По самой своей природе почасовые или «временные и материальные» проекты устанавливают состязательные отношения. Независимо от того, как долго они работали вместе, клиент никогда не будет уверен, что разработчик немного затягивает juuuust на лишний час тут и там. Предложения с фиксированной оплатой сразу решают эту проблему.

Исключения из правила

Независимо от того, насколько прозрачным пытается быть разработчик, бывают случаи, когда просто неразумно или даже невозможно перейти на фиксированную плату. В первую очередь это касается ситуаций с некоторой долей неопределенности. Вот несколько примеров:

  • Новый (или старый) API, который необходимо интегрировать в проект. Если проект требует интеграции с известным API, таким как Stripe или Twilio, тогда опытный разработчик знает, сколько времени потребуется на интеграцию с это и оценить это не проблема. Однако, если проект находится немного в стороне от левого поля и должен работать с API, который использует 10-страничный PDF-файл в качестве «технической документации», или основан на технологиях 1992 года, тогда просто невозможно узнать заранее. время, насколько уродливой может стать эта интеграция.
  • Экспериментальные или новейшие технологии, которые могут понадобиться проекту. Если в проекте используются технологии, которые не поддерживаются сообществом (Stack Overflow, блоги и т. д.), то на создание проекта уходит больше времени, потому что команда сама по себе. В таких ситуациях очень сложно установить фиксированную плату.
  • В проекте просто есть что-то, с чем разработчик не знаком, и необходимо провести исследование. Это немного мягко, но ни один разработчик не работал со всеми технологиями, и это не делает их плохой командой для работы. Если вам нужен мастер в Power BI для работы вашего проекта, наймите мастера, но вы можете сэкономить немного денег, если будете работать с разработчиком, способным и увлеченным изучением чего-то нового. В этой ситуации небольшой исследовательский проект может иметь большое значение.

Ключевым моментом здесь является то, что даже если требуется исследование, цель не в том, чтобы выполнять всю работу ежечасно. Вместо этого разработчик должен выделить достаточно времени, чтобы провести необходимое исследование и построить прототипы, которые ему нужны, чтобы чувствовать себя уверенно с технологией, и они могут оценить эту часть с фиксированной оплатой.

Сфера

Теперь для того, чтобы ценообразование с фиксированной оплатой работало, необходимо, чтобы обе стороны играли честно. Принимая участие в обязательстве с фиксированной оплатой, команда разработчиков фактически просто пожимает руки, говоря: «Я торжественно клянусь выполнить эту работу за XX.XX долларов без каких-либо уловок или скрытых затрат».

Клиентская сторона этого соглашения известна как сфера действия. Здесь клиент плюет в руки и говорит: «Если и когда я передумаю, что хочу построить, я понимаю, что и стоимость, и сроки изменятся, чтобы отразить эти дополнительные требования».

Это может быть сложно, потому что даже самый опытный клиент часто предполагает, что он платит фиксированную плату за концепцию, которая у них в голове, а не за то, что изложено в спец. Если они говорят команде разработчиков создать что-то, а затем решают, что это им не нравится, часто предполагается, что доработка включена в первоначальную стоимость.

Разработчик, с другой стороны, считает, что они создают функции A, B и C, которые запрашивает клиент. Если клиенту по какой-то причине нужна функция D, то это изменение объема. На этом этапе разработчик будет ожидать больше денег и, возможно, больше времени для завершения проекта.

Предложение должно сделать это совершенно ясным. Хорошая оценка будет иметь раздел, в котором точно описывается, как будут осуществляться изменения объема. Таким образом не возникает путаницы, и все понимают, каковы ожидания.

Сроки

При приверженности прозрачности сроки имеют большое значение. Проблема в том, что как только разработчик вводит жесткую дату, клиент будет сдерживать ее и может рассердиться, если ее пропустят, даже по самым веским причинам.

Баланс для прозрачности и «пространства для маневра», который часто требуется проектам, заключается в том, чтобы выделить несколько недель, а не одну дату. Таким образом, разработчик по-прежнему открыт и открыт, но у него еще есть немного места, если / когда что-то займет больше времени, чем ожидалось.

Примечание. Хотя это не связано конкретно с предложением, когда дело доходит до сроков, важно обсудить с командой график отпусков и праздничные дни. Когда дело касается дедлайнов, большинство клиентов забывают о праздниках. Обязательно говорите с командой перед каждым этапом о том, как отпуск / праздники могут повлиять на результат.

Есть несколько замечательных магазинов для разработчиков. К сожалению, есть также много плохих парней, которые используют практику обфускации и ловкости рук, чтобы получать больше денег, срывать сроки или выполнять некачественную работу. Качество и ясность предложения очень помогут вам определить, с каким типом вы имеете дело.

Прозрачность означает другой тип разработчика: того, кого клиенты ищут, а не «заканчивают». Что еще более важно, прозрачность является надежным показателем фирмы, с которой большинство клиентов предпочли бы иметь длительные отношения. Освещение процесса предложения - это первый шаг на этом пути, и ваша компания по развитию сочтет, что это стоит сделать.