Когда я пришел в компанию, технические задания на разработку сайта никто не писал. Точнее писали его крайне редко и для очень больших проектов и как приложение к договору, когда клиент очень настаивал. Спустя несколько месяц работы, я пришел к тому, что техническое задание делать надо. В этом у меня была достаточно острая потребность, т.к. понимать на словах меня упорно не хотели. Надо было разжевать и положить в рот.
Пример, для большего понимания:
Задача: Сделай форму обратной связи. Поля: ФИО, e-mail, сообщение — обязательные; телефон, компания — не обязательные.
Недочет в выполнении: поле e-mail не проверяется на корректность e-mail (т.е. можно было без @ вводить).
Замечание: А почему поле не проверяется на корректность? Надо исправить.
Ответ: Исправлять не буду. Никто об этом не говорил.
Таких мелочей было много. Раз за разом они повторялись. Необходимо было ТЗ. Тех. задания я писал и до этого, особой сложности в написании не было. Но в итоге получилось не то, что ожидали.
Когда технического задания нет — его хотят. Когда оно есть — его не хотят.
Почему так получилось? А дело в том, что до тех.заданий всегда можно было свалить на меня некорректную постановку задачи. С наличием ТЗ это сделать в разы сложнее.
Но попытки были:
- это в тех.задании описано не ясно, я не понял, потому сделал как я посчитал нужным — за такое были выговоры и переделки;
- то, что тут написано я понял так, потому и сделал, как я понял — садились разбирать ТЗ вместе с начальством, я выигрывал где-то 9 из 10 случаев, опять же переделки;
- то, что тут написано сделать нереально — садились с разработчиками, и я разжевывал алгоритм, иногда присоединялось начальство. Если начальство раньше понимало алгоритм, то разработчики получали по шее;
- меня отвлекли, и я не заметил эту строчку — это стандартная отмашка для растягивания времени, когда сделать все к сроку не успевали.
Для меня было очень плохо, когда:
- очевидную мелочь не вписывал в ТЗ — делать ее отказывались, сроки срывали, я получал по шее;
- необходимо было изменить ТЗ, т.к. у клиента тоже что-то изменилось — это было просто скандально; понять, что мир меняется, никто не хотел, часто приходилось привлекать начальство;
- разработчики уточняли детали устно, а потом ссылались на устный разговор как хотели — тут полезно все документировать хотя бы в виде e-mail (об этом дальше);
- особый вид ошибок в ТЗ (ИМХО) — это, когда я не правильно понимал клиента и действительно неправильно ставил задачу, тут ТЗ работало против меня на все 100%, но это хоть было заслуженно и не было так обидно.
Не смотря на все это, были и приятные моменты — сайты делались вовремя и с надлежащим качеством.
Выводы:
а) техническое задание — это хорошо:
- если вы умеете его писать;
- если разработчики умеют его читать;
- если нет проблем с внесением изменений (к сожалению не все понимают, что условия диктуются бизнесом).
б) техническое задание — это плохо:
- если это формальность, что бы оградить себя от человеческого фактора разработчиков;
- если в ТЗ никто не смотрит: оно часто меняется, все привыкли уточнять устно, каждое утро Вы заново ставите задачи и приоритеты.
Почему же от ТЗ потом отказались? Об этом я расскажу потом. В реальности это произошло через месяцев шесть.
