Хорошее ТЗ экономит 20–40% бюджета и сроков. Плохое ТЗ — это правки на каждом этапе и взаимные претензии. Разберём, как составить документ, по которому подрядчик и заказчик понимают одно и то же.
Что должно быть в ТЗ
Минимально необходимый набор разделов:
- Цель проекта — какую бизнес-задачу решает. Не «нужен сайт», а «увеличить заявки с органики на 30% за 6 месяцев».
- Целевая аудитория — кто пользуется, какие у них устройства, сценарии.
- Функциональные требования — что система делает: список модулей и фич с приоритетами (must / should / could).
- Нефункциональные требования — производительность, безопасность, доступность, языки, законодательство (152-ФЗ).
- Интеграции — список систем (CRM, 1С, ЮKassa, GA4) с типами обмена и владельцами API.
- Контент и SEO — кто готовит тексты, какие страницы каноничны, плановая семантика.
- Дизайн — референсы, гайдлайн, требования к адаптиву.
- Инфраструктура — где хостится, кто администрирует, какие требования по бэкапам.
- Этапы и сроки — milestones с критериями приёмки.
- Поддержка после релиза — SLA, формат запросов, оплата.
Уровни детализации
ТЗ бывает трёх уровней:
- Концепция (5–15 страниц) — что и зачем. Подходит для оценки и выбора подрядчика.
- Функциональное ТЗ (20–60 страниц) — все экраны, состояния, валидации. Подходит для фиксации скоупа и старта работ.
- Техническое ТЗ (50+ страниц) — API-контракты, схемы БД, диаграммы. Нужен для крупных проектов и тендеров.
Малому бизнесу обычно достаточно концепции + функционального ТЗ. Техническая часть пишется уже подрядчиком в процессе и согласуется итеративно.
Типовые ошибки
- Слова без определений: «современный дизайн», «быстрый сайт». Замените на конкретику: «LCP < 2 с на p75», «hero-секция в стиле референсов 1, 2, 3».
- Отсутствие приоритетов: всё must-have. Через 3 недели окажется, что времени мало, а резать нечего.
- Размытые границы интеграций: «синхронизировать с 1С». Уточните: какие сущности, в какую сторону, по какому событию, как часто, кто инициирует.
- Игнор нефункциональных требований: фронт сделан, упёрлись в Core Web Vitals — переделывать архитектуру.
- Нет критериев приёмки: фича «готова», когда формально работает, но кто-то считает, что «не так». Опишите Definition of Done для каждого этапа.
Кто пишет ТЗ
Идеально — продакт со стороны заказчика и архитектор/системный аналитик со стороны подрядчика, в паре. На малых проектах роль аналитика выполняет сам разработчик. В этом случае ТЗ собирается в 2–3 итерации:
- Заказчик пишет концепцию своими словами.
- Подрядчик задаёт 30–80 уточняющих вопросов.
- Совместно собирается функциональное ТЗ, фиксируется сметой.
Шаблон оглавления
1. О проекте и целях
2. Аудитория и сценарии
3. Карта сайта / список экранов
4. Функциональные требования (по разделам)
5. Нефункциональные требования
6. Интеграции
7. Контент и SEO
8. Дизайн
9. Технические требования и стек
10. Хостинг и эксплуатация
11. Этапы, сроки, приёмка
12. Поддержка после релиза
13. Приложения (вайрфреймы, схемы данных, примеры API)
Что в сухом остатке
Хорошее ТЗ — это документ, по которому два разных подрядчика дадут смету в пределах 15% друг от друга. Если расхождение больше — в ТЗ дыры. Не экономьте время на проработке: каждый день в ТЗ экономит неделю в разработке.
Частые вопросы
Что должно быть в техническом задании на сайт?
Минимальный набор из десяти разделов: цель проекта в цифрах (а не «нужен сайт»), целевая аудитория и сценарии, функциональные требования с приоритетами по системе must/should/could, нефункциональные требования (производительность, безопасность, доступность, 152-ФЗ), интеграции с типами обмена и владельцами API, контент и SEO, дизайн с референсами, инфраструктура и хостинг, этапы со сроками и критериями приёмки, поддержка после релиза. Без любого из них в проекте появятся дыры.
Сколько страниц должно быть в ТЗ на сайт?
Зависит от уровня детализации. Концепция — 5–15 страниц, нужна для оценки и выбора подрядчика. Функциональное ТЗ — 20–60 страниц с описанием экранов, состояний и валидаций; нужно для фиксации скоупа и старта работ. Техническое ТЗ — от 50 страниц с API-контрактами, схемами БД и диаграммами; нужно для крупных проектов и тендеров. Малому бизнесу обычно достаточно концепции и функционального ТЗ, техническую часть подрядчик допишет итеративно.
Кто должен писать ТЗ на разработку сайта?
В идеале — продакт-менеджер со стороны заказчика и архитектор или системный аналитик со стороны подрядчика, в паре. На малых проектах роль аналитика берёт на себя сам разработчик. Типовая схема: 1) заказчик пишет концепцию своими словами; 2) подрядчик задаёт 30–80 уточняющих вопросов; 3) совместно собирается функциональное ТЗ и фиксируется сметой. Это занимает 2–3 итерации и 1–2 недели.
Какие типовые ошибки в ТЗ ломают проект?
Пять характерных дыр: слова без определений вроде «современный дизайн» и «быстрый сайт» — заменяйте на цифры (LCP меньше 2 секунд, конкретные референсы). Отсутствие приоритетов — всё «must have» и резать нечего, когда время поджимает. Размытые интеграции «синхронизировать с 1С» без указания сущностей, направления и событий. Игнор нефункциональных требований — упёрлись в Core Web Vitals после релиза, переделывать архитектуру. Нет критериев приёмки — фича «готова», но кто-то считает, что «не так».
Зачем вообще нужно ТЗ на сайт, если есть дизайн?
Дизайн отвечает на вопрос «как выглядит», ТЗ — на вопросы «что делает», «при каких условиях», «как интегрируется», «что считается готовым». Подрядчик без ТЗ будет считать смету по картинкам и неминуемо упрётся в неучтённые состояния, валидации, права доступа, фоновые задачи. Хорошее ТЗ снижает разброс смет от разных подрядчиков до 15% — и это надёжный способ проверить, что вас не обсчитывают.
Сколько времени занимает написание ТЗ?
Концепция — 3–7 рабочих дней с участием продакта и пары встреч с командой. Функциональное ТЗ — от 2 до 4 недель в зависимости от сложности проекта. Техническое ТЗ — обычно делается параллельно с разработкой первого спринта, потому что его невозможно написать без приземления на стек. Каждый день в ТЗ экономит неделю в разработке — это статистически проверенное соотношение.