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

Теперь длинное объяснение.

Что такое ТЗ? Это документ, в котором бизнес-требования описаны техническим языком. Упоминаются протоколы, стандарты, меры безопасности. Четко описаны процессы обмена данными.

Когда программист просит ТЗ, он не понимает, что требует невозможного. У заказчика не может быть правильно составленного технического документа. Все, что у него есть – это обрывки идей будущего бизнеса.

Задача программиста – помочь оформить бизнес-идеи в техническую форму. Заказчик не может сделать это сам. Он не знает разницу между HTTP и HTTPS, GET и POST, и чем стандартная авторизация отличается от OAuth 2.0.

Если программист отказывается составлять ТЗ, это значит, он не разработчик, а кодер, фрилансер, которому можно доверить только самую примитивную работу.

Заказчик с готовым ТЗ это редкость. Если есть готовое ТЗ, скорее всего, над ним уже работал технический специалист. Зачем тогда уходить к другому? Или найти помошника через того, кто составлял ТЗ.

Поэтому первая фаза встречи программиста и заказчика – это много-много вопросов. Исполнитель имеет право брать за это деньги, если гарантирует, что на выходе получится ТЗ, максимально полно отражающее бизнес-требования.

Программисты-неведжы думают, что заказчику составить ТЗ будет легко. Предлагаю обмен ролями: пусть заказчик напишет ТЗ, а программист – бизнес-план проекта на будущий год. Затем каждая сторона оценит результаты другой.

Описанное выше можно изобразить на графике. Вот как протекает сотрудничество во времени. Программист думает:

|ТЗ       |код       |код        |код     |код      |код         |готово
>------------------------------------------------------------------------>
                                 время

На самом деле:

|вопросы    |вопросы   |вопросы   |ТЗ     |код    |код   |код     |готово
>------------------------------------------------------------------------>
                                 время

Когда основные вопросы решены и ТЗ составлено, настает время решать, стоит ли работать над проектом. Возможно, начальные идеи выродятся во что-то другое.

А вот что будет, если следовать первому графику.

ТЗ – это документ. Однако, напрасно программист думает, что ТЗ как золотой щит спасет от всех разногласий. Помимо проекта, который описан в ТЗ, есть еще одна его версия, которая живет в голове заказчика.

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

  • Заказчик: Форма авторизации как-то не очень…
  • Программист: Все сделано по техзаданию.
  • Заказчик: Да, но нет авторизации через соцсети.
  • Программист: Этого не было в ТЗ.
  • Заказчик: Не было, потому что сейчас это везде, я думал, вы догадаетесь.
  • Программист: Вы не отразили это техзадании.
  • Заказчик: Что вы все с техзаданием! У нас будет меньше пользователей!
  • Программист (мысленно): Вот мудак, не знает, что хочет.
  • Заказчик (думает): Послал же бог дурака. Только по бумажке работает, мозга ноль.

И так до следующей встречи. С новым заказчиком и исполнителем. Драмы и плач на форумах.

Выводы

Хороший исполнитель не берется за проект пока досконально не изучит предмет. Он долго задает вопросы. Техническое задание фиксирует итог совместных исследований. ТЗ максимально точно соответствует ожиданиям заказчика. Документ не поможет, если реализация не оправдала надежд.