Когда я слы�?у о техническом задании на разработку веб-сайта, я внутренне улыбаюсь – еще один продукт, устарев�?ий уже в момент выхода. Это первая проблема всех технических заданий – предположение, что вне�?няя среда не меняется.

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

Вторая проблема хоро�?о известна и отражена в древней мудрости: чтобы задать правильный вопрос, надо знать половину ответа. В ситуации, когда каждый новый сайт вы разрабатываете с использованием только что появив�?ихся технологий (новые модули, новая версия собственного движка, новая версия базы данных), – фактически вы каждый раз многое делаете заново. Это значительно осложняет процесс разработки, потому что вы не знаете, как будете это разрабатывать.

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

Третья проблема классическая – заказчик не всегда точно знает, чего он хочет. �? когда подходит срок сдачи проекта, вы слы�?ите, что вот здесь хоро�?о бы подправить, вот здесь изменить, а вот здесь добавить. Частично эту проблему ре�?ает моделирование конечного продукта, но, повторюсь, ли�?ь частично.

Это называется "работа с требованиями заказчика", читаем и запоминаем. � абота с требованиями заказчика действительно неприятный процесс и требует морального напряжения, но такова уж на�?а тяжелая доля. Почему-то никого не удивляет, что добавление в ма�?ину электростеклоподъемника стоит денег. Почему это должно удивлять в случае с сайтом? Тут нам очень поможет ТЗ, которое как раз описывает пожелания заказчика на старте проекта и содержит его (закачика) согласие, в виде подписи и печати. Фиксируйте пожелания заказчика, оценивайте их. Согласуйте описание пожеланий и оценку с клиентом. Если стоимость доработки невысока и не выводит проект за рамки бюджета – вы можете это сделать, как "подарок" заказчику, в противном случае – нужна соответствующая компенсация ва�?их _дополнительных_ работ. (кстати, PMP не рекомендует вносить "бесплатные" доработки и называет это Gold Plating) Далее в статье перечисляются очень слабо-применимые, при коммерческой разработке сайтов, методики, типа XP, подход притянут за у�?и. Почему, я подробнее напи�?у несколько позже. Продолжим:

�? все же нам нужно чем-то заменить отсутствие формального технического задания, – ведь мы должны сделать то, что требуется заказчику.

�?менно в Техническом Задании изложено то, чего хочет Заказчик. Отсутствие технического задания позволит Заказчику _бесконечно_ требовать доработок, а проект этот никогда не завер�?иться. Хотя где-то я видел и такой подход, когда проект превращался в процесс. Напоминаю, что это мой взгляд на проблему, в контексте _коммерческой_ разработки. Описанный автором подход тоже может работать, но я хотел бы увидеть также и описание бизнес-модели компании, которая бы обеспечивала гарантированную безубыточную деятельность при таком подходе. Это может быть работа по схеме Time-and-material, но найдите мне российского клиента который согласится на такую схему…