Sharing my mind…

Андрей Бородийчук

Техзадание

Итак, мы пришли к выводу, что для выполнения некоего проекта нам нужно техзадание.

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

Техзадание нужно написать самому. Включить его в смету, в накладные расходы, неважно. Но написать его надо самому — для себя же. У нас уже есть информация от клиента о проекте. Отлично — надо спроектировать результат в техзадании. Открываем Google Documents, создаем там текстовый файл, расшариваем его с клиентом и начнаем там писать то, что впоследствии будет перенесено в код. Можно прямо в терминах MVC — чтобы проще было реализовывать.

Важно. Гугл-документ клиент прочитает и поймет, в отличии от UML-диаграммы, которая всё-же рассчитана на бездушных программистов.

Итак, модель User. Пара слов для клиента о том, что юзер — это зарегистрированный пользователь нашего сайта. Список свойств. Настоящее имя, — возникает логичный вопрос, как же хранить имя, которое моет состоять из собственно имён-фамилий, а также отчеств, титулов и прочей аттрибутики? Логично будет задать этот вопрос клиенту. Ставим там комментарий (Ctrl-Alt-M) и задаём в нём вопрос, отом, какие у клиента требования к имени, и как нам следует поступать с ним и сопровождающими его аттрибутами? Дальше, свойства. Удаление юзера. Ещё один вопрос, а что нам делать со всем тем, что юзер наплодил за время своего существования? Удалить, разлинковать, либо оставить. пометив что тот юзер уже удалён? Ещё один комментарий, и ещё один вопрос в нём.

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

В процессе получения информации очень помогает вопрос: «Как вы это будете тестировать при приёмке?». Желательно полученную методику также занести в ТЗ. Затем — контрольная точка. Говорим клиенту: «Этим ТЗ мы будем отбиватья от вас, если вы захотите внести изменения в проект. Точно всё ок?». И если всё ок, то ТЗ экспортируется в PDF и формально согласовывается с клиентом. Уровень формальности зависит от клиента, — можно и просто по почте послать, а иногда следует распечатать и скрепить подписями, печатями или даже кровью (нужное подчеркнуть).

В чем плюсы такго подхода к составлению ТЗ?

  1. Сразу же отсеиваютя неадекватные клиенты.
  2. Мы, в результате, таки, получаем ТЗ к проекту.
  3. Мы делаем полный «проход» проекта, выявляем в нём все сомнительные места, логические неувязки, получаем к ним разъснения, и согласовываем решения с клиентом.
  4. Нам проще объяснить почему та или иная идея усложнит реализацию.
  5. ТЗ написано нами и защищает прежде всего наши интересы. Разумеется, клиент проследит, чтобы там были все затребованные им фичи, но все эти фичи уже будут описаны и проработаны нами.

Из недостатков — на это уходит время, которое, впрочем, окупится сэкономленными нервами.