Большинство проектов по разработке сайтов проваливается не из-за плохих программистов, а из-за плохого технического задания.

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

Поисковая статистика говорит сама за себя: тысячи руководителей и маркетологов каждый месяц ищут, как написать техническое задание на разработку сайта. И причина проста — от качества этого документа зависит 80% результата. Хорошее ТЗ экономит деньги, время и нервы обеих сторон.

Что такое ТЗ на разработку сайта и почему без него нельзя

Техническое задание — это документ, который фиксирует требования к будущему сайту: его цели, структуру, функционал, дизайн, контент и критерии приёмки. Юридически ТЗ часто является приложением к договору, а значит — защищает и заказчика, и подрядчика.

+40%
в среднем растёт бюджет проекта без детального ТЗ из-за правок и доработок
×2
возрастает срок разработки, если требования выясняются «по ходу дела»
70%
споров между заказчиком и студией возникают из-за непрописанных требований

Структура идеального технического задания: 10 обязательных разделов

Не существует единого ГОСТа на ТЗ для сайтов, но практика выработала устойчивую структуру. Кликните на раздел, чтобы раскрыть его содержание:

1. Общие сведения о проекте ▾
О чём компания, для чего нужен сайт, какую бизнес-задачу он решает. Пример: «интернет-магазин для продажи детской одежды с доставкой по Казахстану, цель — выйти на онлайн-продажи 3 млн тг в месяц за полгода».
2. Целевая аудитория ▾
Портрет посетителя: возраст, география, устройства, мотивация, боли. От этого зависят дизайн, структура и тексты. «Сайт для всех» — красный флаг плохого ТЗ.
3. Анализ конкурентов и референсы ▾
3–5 сайтов, которые нравятся, и 2–3, которые не нравятся, с пояснением «что именно». Это избавляет дизайнера от гадания на кофейной гуще.
4. Структура сайта (карта страниц) ▾
Иерархическое дерево всех разделов и страниц с указанием их назначения. Главная, каталог, карточка товара, блог, контакты — каждая страница должна быть перечислена.
5. Функциональные требования ▾
Самый важный раздел. Каждая функция описывается по принципу «действие → результат»: форма обратной связи отправляет данные на e-mail и в CRM; корзина пересчитывает стоимость при изменении количества; фильтр работает без перезагрузки страницы.
6. Требования к дизайну ▾
Фирменный стиль (или его отсутствие), цвета, шрифты, настроение, запреты. Не «сделайте красиво», а «минимализм, много «воздуха», акцентный цвет — красный, без стоковых фото handshake'ов».
7. Технические требования ▾
CMS или фреймворк, хостинг, адаптивность (breakpoints), скорость загрузки (например, PageSpeed от 70 баллов на мобильных), совместимость с браузерами, SSL, интеграции с CRM, платёжными системами, 1С.
8. Контент ▾
Кто и когда предоставляет тексты, фото, видео. Требования к SEO: мета-теги, заголовки, человекопонятные URL. Классическая ошибка — предполагать, что контент «сам появится».
9. Этапы, сроки и порядок приёмки ▾
Разбивка на этапы (прототип → дизайн → вёрстка → программирование → наполнение → тестирование) с дедлайнами. Критерии приёмки: чек-лист, по которому проверяется готовность, и порядок внесения правок (например, 2 итерации включены).
10. Что не входит в проект ▾
Раздел, который спасает от 90% конфликтов. Прямо укажите: продвижение, настройка рекламы, ведение соцсетей, наполнение сверх N страниц — оплачиваются отдельно.

Размытое формулирование против конкретного

Главный принцип ТЗ: каждое требование должно быть проверяемым. Сравните сами:

❌ Так писать нельзя ✅ Так писать нужно
«Сайт должен быть быстрым» «Время полной загрузки страниц — до 3 секунд при 3G, PageSpeed Insights — не ниже 70 баллов на мобильных»
«Удобная админка» «Менеджер должен иметь возможность без программиста добавить товар, изменить цену и отредактировать SEO-теги»
«Современный дизайн» «Дизайн в стиле референсов №1 и №3: светлый фон, крупная типографика, фирменный красный #D80621 как акцентный»
«Интеграция с CRM» «Заявки с форм автоматически передаются в amoCRM по API в воронку "Сайт" с указанием UTM-меток»

Сколько внимания занимает каждый этап в ТЗ

Опыт показывает: чем детальнее прописан функционал, тем меньше сюрпризов в конце. Вот как должен распределяться объём документа:

Функциональные требования~30%
Структура и страницы~20%
Технические требования~15%
Дизайн и референсы~15%
Контент и SEO~10%
Этапы, приёмка, ограничения~10%

Чек-лист перед передачей ТЗ подрядчику

✓ Каждое требование можно проверить «да/нет» без субъективной оценки
✓ Перечислены все страницы и весь функционал — ничего «по умолчанию»
✓ Есть раздел «что не входит в проект» и порядок внесения правок
✓ Прописаны критерии приёмки и количество итераций доработок
✓ ТЗ показано хотя бы одному человеку «не из темы» — если он понял, что нужно сделать, подрядчик поймёт тоже
✓ Документ приложен к договору и подписан обеими сторонами
Ключевая мысль

Час, потраченный на техническое задание, экономит дни на правках и недели переписки. Правило простое: не бывает слишком подробного ТЗ — бывает ТЗ, в котором подрядчик вынужден додумывать за заказчика. А додуманное никогда не совпадает с ожидаемым.

Конкретные, измеримые и проверяемые формулировки превращают ТЗ из формальности в инструмент управления проектом — и именно тогда сайт получается именно таким, каким его задумывали.