Разница между подрядчиком и партнёром редко видна на презентации. Оба могут представить безупречное предложение, разумные сроки и убедительное портфолио. Разница проявляется через полгода после запуска, когда что-то нужно изменить, в части системы, к которой никто не притрагивался с момента передачи, всплывает ошибка, или сам бизнес перерос предположения, на которых строилась первоначальная система. Подрядчик поставил то, что было указано, и считает отношения завершёнными. Партнёр ожидал этого момента и строил систему с расчётом на него.
На что нацелен подрядчик
Мотивация подрядчика — эффективно закрыть текущий контракт: соответствовать техзаданию, уложиться в срок, сдать результат, перейти к следующему клиенту. Это не нечестность — это просто иные отношения, чем те, что на самом деле нужны большинству бизнесов от технологий, потому что техзадание, написанное до того, как система существует, никогда не является последним словом о том, что она должна делать. Подрядчик рассматривает отклонения от этого задания как расширение объёма работ, которое выставляется отдельным счётом. Партнёр рассматривает их как нормальный, ожидаемый процесс создания чего-то, что работает в реальном бизнесе, а не только на бумаге.
Вопросы, которые вскрывают разницу до подписания чего-либо
«Что происходит после запуска?» Ответ подрядчика обычно — пакет поддержки с почасовой или потикетной оплатой. Ответ партнёра обычно включает, что он ожидает изменить в первые три месяца, потому что он уже думает о системе как о чём-то развивающемся, а не как о том, что поставляется и на этом заканчивается.
«Кто ещё получит доступ к этому после запуска?» Этот вопрос показывает, планирует ли компания передать реальное владение — учётные данные, исходный код, документацию — или намерена остаться единственной стороной, способной трогать систему. Уклончивый ответ здесь стоит воспринимать всерьёз как предупреждение, а не как формальность, которую можно уладить позже.
«Что бы вы сделали иначе, если бы бриф был ошибочным?» У партнёра есть ответ, потому что он уже спорил с частями брифа, которые не выдерживали критики, вместо того чтобы построить точно то, что попросили, и оставить клиенту обнаружить разрыв позже. Ответ подрядчика здесь часто сводится к тому, что он построил всё по техзаданию, что звучит ответственно, а обычно таким не является.
«Можете показать отношения с клиентом, продлившиеся дольше первого проекта?» Список клиентов подрядчика в основном состоит из разовых проектов. Список клиентов партнёра включает бизнесы, которые продолжают работать с ним спустя годы, и это более сильный сигнал, чем любой отдельный проект в портфолио.
Почему это важнее для малого бизнеса
Крупное предприятие может позволить себе нанять подрядчика для узкой, хорошо описанной задачи и вести отношения внутри компании силами своей технической команды. Малый бизнес обычно не может — у него нет внутренней экспертизы, чтобы заметить плохое техзадание до того, как его реализуют, или чтобы управлять развитием системы без внешней помощи. Для бизнеса в таком положении сами технологические отношения — часть того, за что платят, а не формальность вокруг сданного кода, и это одна из причин, почему процесс, на котором строится проект, важен не меньше, чем само создаваемое программное обеспечение — хорошо выстроенные отношения поглощают неожиданности так же, как хорошо описанный процесс. Наша команда разработки устроена так, чтобы продолжать работать с клиентами после передачи проекта именно потому, что как раз в этот момент обычно и становятся ясны реальные требования к системе.
