Студийные истории #5. Техническое задание на разработку сайта. Когда нет — хотят, когда есть — не хотят.

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

Пример, для большего понимания:
Задача: Сделай форму обратной связи. Поля: ФИО, e-mail, сообщение — обязательные; телефон, компания — не обязательные.
Недочет в выполнении: поле e-mail не проверяется на корректность e-mail (т.е. можно было без @ вводить).
Замечание: А почему поле не проверяется на корректность? Надо исправить.
Ответ: Исправлять не буду. Никто об этом не говорил.

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

Когда технического задания нет — его хотят. Когда оно есть — его не хотят.

Почему так получилось? А дело в том, что до тех.заданий всегда можно было свалить на меня некорректную постановку задачи. С наличием ТЗ это сделать в разы сложнее.

Но попытки были:

  • это в тех.задании описано не ясно, я не понял, потому сделал как я посчитал нужным — за такое были выговоры и переделки;
  • то, что тут написано я понял так, потому и сделал, как я понял — садились разбирать ТЗ вместе с начальством, я выигрывал где-то 9 из 10 случаев, опять же переделки;
  • то, что тут написано сделать нереально — садились с разработчиками, и я разжевывал алгоритм, иногда присоединялось начальство. Если начальство раньше понимало алгоритм, то разработчики получали по шее;
  • меня отвлекли, и я не заметил эту строчку — это стандартная отмашка для растягивания времени, когда сделать все к сроку не успевали.

Для меня было очень плохо, когда:

  • очевидную мелочь не вписывал в ТЗ — делать ее отказывались, сроки срывали, я получал по шее;
  • необходимо было изменить ТЗ, т.к. у клиента тоже что-то изменилось — это было просто скандально; понять, что мир меняется, никто не хотел, часто приходилось привлекать начальство;
  • разработчики уточняли детали устно, а потом ссылались на устный разговор как хотели — тут полезно все документировать хотя бы в виде e-mail (об этом дальше);
  • особый вид ошибок в ТЗ (ИМХО) — это, когда я не правильно понимал клиента и действительно неправильно ставил задачу, тут ТЗ работало против меня на все 100%, но это хоть было заслуженно и не было так обидно.

Не смотря на все это, были и приятные моменты — сайты делались вовремя и с надлежащим качеством.

Выводы:
а) техническое задание — это хорошо:

  • если вы умеете его писать;
  • если разработчики умеют его читать;
  • если нет проблем с внесением изменений (к сожалению не все понимают, что условия диктуются бизнесом).

б) техническое задание — это плохо:

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

Почему же от ТЗ потом отказались? Об этом я расскажу потом. В реальности это произошло через месяцев шесть.

Реальные кейсы роста продаж
и повышения конверсии!

Узнайте как другие увеличивают продажи на 10%, 30%, 50% или даже в 2 раза!

100% без спама!