Техническое задание на сайт: что включить заказчику
Техническое задание должно уменьшать количество разных трактовок, а не превращаться в сотню страниц формальностей. Хорошее ТЗ описывает, что должен уметь продукт и как проверить результат.
Опишите контекст и границы проекта
Исполнитель должен понимать бизнес-задачу и то, что не входит в первую версию. Контекст помогает принимать разумные решения там, где документ не описывает каждый пиксель.
- цели, аудитории и показатели успеха
- обязательные разделы и исключённые функции
- ограничения по срокам, бюджету, бренду и технологиям
Практический ориентир: отдельно укажите предположения, которые ещё нужно проверить, чтобы не выдавать их за требования.
Фиксируйте сценарии и данные
Функцию лучше описывать через действия и результат. Вместо «сделать форму» укажите поля, проверки, получателя, сообщение об успехе и способ хранения согласия.
- роли пользователей и последовательность действий
- поля, статусы, ошибки и уведомления
- источники данных и правила обмена с CRM или учётной системой
Практический ориентир: для сложного модуля приложите схему процесса и примеры реальных данных.
Добавьте критерии качества и приёмки
Требования к устройствам, скорости и SEO должны быть измеримыми и соотноситься с проектом. Слишком общие обещания создают спор, а нереалистичные показатели — лишнюю стоимость.
- поддерживаемые браузеры и диапазоны экранов
- метаданные, URL, sitemap, редиректы и микроразметка
- порядок тестирования, передачи замечаний и фиксации готовности
Практический ориентир: привяжите критерии к согласованным сценариям и условиям теста.
Минимальная структура ТЗ
- цели и аудитории
- карта сайта и сценарии
- описание функций и данных
- требования к контенту и дизайну
- тесты, приёмка и передача доступов
Частые вопросы
Кто должен писать ТЗ?
Заказчик предоставляет знания о бизнесе, а исполнитель превращает их в проектные и технические требования. Совместная работа над ТЗ обычно надёжнее.
Можно ли менять ТЗ после старта?
Да, через управляемый процесс изменений с оценкой влияния на стоимость и срок.
Нужны ли макеты в ТЗ?
Макеты и прототипы могут быть приложениями. ТЗ должно описывать поведение, чтобы визуальный файл не был единственным источником требований.