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

«Обычное» техническое задание

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

Проблема решается короткими итерациями и постоянными переговорами с клиентом, плюс частыми демонстрациями. При это очень важно быстро сдавать проект/этап, фиксировать сдачу и переходить к следующей итерации. Остальное не работает.

Альтернативное техническое задание

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

• полностью описывает результат работ
• максимально простое и понятное
• наглядно
• кратко
• измеримо в деньгах
• интерактивно

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

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

У клиента вообще не должно возникать желания докапываться к формулировкам в техническом задании на интернет-магазин, а должно быть ощущение, «что все идет по плану» и все именно так, как и должно быть. Этому способствуют короткие двухнедельные итерации, на которые есть четкие зафиксированные требования, которые понятны как менеджеру проекта, так и заказчику.
Люди быстрее понимают картинки и наглядное представление — поэтому прототипы намного эффективнее. Однако описать технические аспекты и механику работы web-приложений на прототипах до конца нельзя, поэтому текстовые ТЗ,  постановки и диаграммы так же нужны. Это не обязательно должны быть отдельные документы. Иногда достаточно презентации в PowerPoint, иногда — даже просто комментариев к прототипу.

Итерации должны быть короткие, иначе, если результат итерации не зафиксирован — накопленные сведения забываются, и ни команда, ни заказчик через пару месяцев уже не вспомнит, на какой фазе был заброшен проект, и что именно с ним теперь делать. «Перезапустить» такой проект — очень сложно и дорого. Длинные и толстые технические задания нужны в случае, если планируется вести разработку другой командой.

Если риск не очень большой, можно делать общее короткое тех.задание на проект с фиксацией списка требований и делать ТЗ на конкретную итерацию. Это добавляет гибкости в процессе работы, но такой подход не очень любят программисты. Разработка прототипа и ТЗ к нему обычно съедает 12% бюджета проекта.
В маленьких проектах проблема в разработке хорошего технического задания еще и в том, что его нужно готовить до того, как будет готов договор, но есть риск, что договор в итоге не будет подписан.

Что еще можно оптимизировать при разработке ТЗ:

1. Не забываем указать роли пользователей и доступные для каждого типа пользователей действия.
2. Структура сайта — расписываем какие разделы и подразделы сайт включает. Описываем страницы. Если схему страницы нарисовать проще, чем расписать какой блок где находится — рисуем. Если страница простая — ограничиваемся текстовым описанием.
3. Если ваше ТЗ включает раздел про дизайн, не надо там переписывать бриф. Достаточно качественно заполнить бриф вместе с заказчиком и сделать отсылку к нему, включив в договор отдельным приложением. В техническом же задании фиксируем только формальные требования к дизайну, количеству итераций, и порядок работ по нему. Иногда выгодно к ТЗ приложить скетч — схематичный набросок, в котором грубо прорисованы основные идеи концепции, без детализации и цвета .
4. Если используется коробочная CMS, не изобретаем велосипед — указываем редакцию, даем ссылку на ее описание на официальном сайте и перечисляем какие модули из включенных в данную редакцию настраиваем для сайта.

Вообще, средств прототипирования довольно много. В крайнем случае можно нарисовать прототип от руки на бумаге или сделать в одном из обычных офисных приложений. Мне приходилось видеть прототипы сделанные и в Word, и в Excell и в Power Point. Но гораздо удобнее использовать специальное программное обеспечение. При разработке прототипов мы пользуемся Axure Pro или Evolus Pencil. Также популярны Visio и InDesign.