Техническое задание может составить заказчик или исполнитель — зависит от бюджета проекта и наличия в команде аналитиков. Если решили составлять техзадание на разработку веб-сервиса своими силами, выясните, какие пункты в него должны входить. Как можно конкретнее объясните команде, какой продукт хотите получить в итоге.

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

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

Составление технического задания включает в себя несколько обязательных этапов. Чтобы не упустить важные моменты, воспользуйтесь схемой:

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

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

Избегайте слов «красиво», «быстро», «просто» и других подобных оценок — они не несут в себе конкретного смысла и могут быть поняты множеством разных способов. Замените их конкретикой:

• «сервис должен быть выполнен в фирменной цветовой гамме и ориентирован на женскую аудиторию 25 – 35 лет»;
• «главная страница сайта должна загружаться не более, чем за 5 секунд»;
• «кнопка целевого действия должна выделяться на экране цветом и размером, чтобы пользователю не пришлось искать».

Не бойтесь написать больше: в техническом задании это может принести пользу.

Проследите, чтобы все понятия были четко и однозначно описаны. Это касается как заказчика, так и исполнителя: техническое задание должно быть понятно обеим сторонам. Раскройте термины, которые характерны для вашей сферы деятельности. Попросите разработчиков сделать то же самое с понятиями, новыми для вас.

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