Большинство конфликтов в проектах происходит не из-за плохой работы, а из-за разных ожиданий. Заказчик считал, что «интеграция с CRM» включает настройку воронок. Подрядчик имел в виду передачу заявки. Оба правы — в документе этого не было.
Техническое задание не обязано быть на сто страниц. Оно обязано снимать двусмысленность.
Что должно быть в ТЗ
Цель проекта — на человеческом языке
Не «создать современный сайт», а «получать не менее 30 заявок в месяц из органического поиска по услугам монтажа». Цель определяет решения: под такую формулировку нужна структура под запросы, а не красивая обложка.
Целевая аудитория и сценарии
Кто приходит на сайт, что он хочет узнать, что должен сделать. Достаточно двух-трёх типовых сценариев — они сразу показывают, каких страниц не хватает.
Структура сайта
Список всех страниц с вложенностью. Здесь же — какие страницы типовые (карточка услуги, статья), а какие уникальные. Именно этот раздел чаще всего расходится с реальностью, если его не проработать заранее.
Функциональные требования
По каждому нетривиальному блоку — что он делает и как ведёт себя в крайних случаях. Пример плохой формулировки: «форма обратной связи». Хорошей: «форма с полями имя, телефон, услуга; телефон обязателен и валидируется; после отправки — редирект на страницу благодарности; заявка уходит на почту и в Telegram-чат».
Требования к контенту
Кто пишет тексты, кто даёт фото, кто наполняет каталог и в какие сроки. Пропущенный пункт — самая частая причина срыва дедлайна: разработка готова, наполнять нечем.
Технические требования
- какие браузеры и устройства поддерживаем
- целевые показатели скорости (например, PageSpeed 90+ на мобильных)
- требования к доступности и SEO-базе: ЧПУ, микроразметка, sitemap
- где размещается сайт, кому принадлежат домен и хостинг
Критерии приёмки
Самый важный и самый пропускаемый раздел. Как именно вы поймёте, что работа сделана? Проверяемые критерии выглядят так: все формы отправляются и приходят на указанную почту; на iPhone SE ни один блок не выходит за экран; PageSpeed Insights показывает не ниже 90 на четырёх ключевых страницах.
Чего в ТЗ быть не должно
- Оценочных прилагательных. «Современный», «стильный», «удобный» — непроверяемо. Вместо этого — референсы: три сайта, которые нравятся, и объяснение чем.
- Технических решений вместо задач. Не «сделать на WordPress», а «редактор должен уметь добавлять статьи без разработчика». Выбор инструмента — зона ответственности подрядчика.
- Всего сразу. Если список функций занимает пять страниц, разбейте на этапы. Первый релиз должен уместиться в разумный срок.
Если писать ТЗ некому
Нормальная ситуация. Тогда документ пишет подрядчик — по результатам брифа и нескольких созвонов, а вы его согласовываете. Это платная работа, но она окупается: вы получаете документ, который можно показать любой другой команде, если что-то пойдёт не так.
Признак хорошего подрядчика — он задаёт неудобные вопросы на этапе ТЗ, а не соглашается со всем и вспоминает про сложности в середине проекта.
