Проект без технического задания — это договор на словах. Заказчик представляет одно, разработчик делает другое. В итоге три раунда правок, споры на сдаче и деньги, потраченные на доработки, которых можно было избежать. ТЗ — документ, который защищает обе стороны и делает разработку предсказуемой.
Что такое ТЗ на сайт
Техническое задание (ТЗ) на разработку сайта — это документ, который регламентирует технические, функциональные и контентные составляющие будущего проекта. В нём фиксируется всё:
- какой движок использовать,
- как должна выглядеть главная страница,
- какие функции нужны в личном кабинете,
- какой должна быть скорость загрузки,
- как выглядит мобильная версия.
Чем детальнее проработано ТЗ — тем выше шанс, что заказчик получит именно то, что хотел, а исполнитель сделает работу в срок без бесконечных доработок. ТЗ — не договор, это приложение к договору. Два разных документа с разными функциями.
Зачем нужно техническое задание
Пользу от ТЗ получают обе стороны — и заказчик, и исполнитель. Это не просто формальность.
Для заказчика Для исполнителя Позволяет узнать предварительную стоимость разработки Ускоряет разработку — не нужно угадывать намерения клиента Ускоряет согласование базовых вопросов Даёт чёткое понимание главной задачи и объёма работ Собирает все пожелания в одном документе Страхует от выполнения несогласованных задач Позволяет сверять промежуточные этапы с планом Формирует базис для будущего развития проекта Защищает при приёмке — факты зафиксированы Защищает от претензий — есть что показать клиенту
Практический пример: если при сдаче проекта заказчику не понравилась выбранная CMS — исполнитель открывает ТЗ и показывает пункт, где эта CMS согласована и подписана. Спор закрыт без эмоций.
Кто составляет ТЗ
В идеале — совместно: заказчик описывает задачи бизнеса, исполнитель переводит их в технические требования. На практике чаще всего ТЗ составляет исполнитель (агентство или фрилансер) и отдаёт заказчику на согласование, подробно объясняя каждый пункт.
Заказчик помогает исполнителю, если заранее заполняет бриф — короткий опросник о компании:
- отрасль,
- целевая аудитория,
- специфика продаж,
- основные каналы привлечения клиентов.
Это позволяет разработчику понять контекст бизнеса и сделать сайт под конкретного клиента, а не «сайт вообще».
Важная практика, которую часто игнорируют: вести Change Log — журнал изменений в ТЗ. Дата, версия документа, что изменилось, кем согласовано. Это снижает количество конфликтов на приёмке, когда выясняется, что в процессе разработки требования менялись несколько раз, но никто ничего не фиксировал.
Сроки разработки в зависимости от типа проекта
Тип проекта Примерный срок Особенности Лендинг на готовом шаблоне 1–2 недели Минимальный функционал, быстрый запуск Корпоративный сайт или визитка на шаблоне 2–4 недели Несколько страниц, стандартные блоки Сайт с индивидуальным дизайном 4–8 недель Проектирование + дизайн + вёрстка Интернет-магазин 6–12 недель Каталог, корзина, оплата, интеграции Сложный веб-сервис или портал 3–6 месяцев и более Личные кабинеты, API, нестандартный функционал
Основные разделы ТЗ на разработку сайта
1. Общая информация о проекте
- Название проекта, заказчик, исполнитель, версия документа, дата.
- Описание целей сайта — для чего он создаётся, какую бизнес-задачу решает.
- Целевая аудитория — кто будет пользователем сайта, их технические возможности и ожидания.
Этот раздел кажется формальным, но именно из него вытекают все остальные требования: непонятно для кого сайт — непонятно что делать.
2. Выбор движка (CMS)
В ТЗ фиксируется, на какой платформе будет работать сайт. Варианты: CMS (WordPress, Drupal, OpenCart, 1С-Битрикс), SaaS-конструктор (Tilda, Wix), кастомный движок или фреймворк.
Три вопроса, которые помогают выбрать правильный движок:
- Кто будет администрировать сайт — профессиональный разработчик или сотрудник заказчика без технических знаний?
- Публиковать контент?
- Обслуживать сайт и делать обновления?
Если в штате нет разработчиков — лучше выбрать коробочную CMS. SaaS-сервисы подходят для простых сайтов с ограниченным функционалом.
3. Структура сайта
Перечень страниц и разделов с описанием их содержания и назначения. Иерархия страниц — главная, разделы, подразделы. Навигационная схема. Этот раздел часто оформляется в виде майнд-карты или древовидной таблицы, где сразу видно всю архитектуру сайта.
4. Требования к дизайну
Ссылки на сайты-референсы — что нравится по стилю. Фирменные цвета, шрифты, логотип (если есть). Требования к адаптивности: какие разрешения экрана должны поддерживаться, на каком устройстве сайт должен работать в первую очередь. В 2025 году мобильный трафик превышает десктопный у большинства сайтов — mobile first не опция, а необходимость.
5. Функциональные требования
Список всех функций, которые должны работать на сайте. Для каждой функции — описание поведения. Например: форма заявки должна отправлять данные на email и в CRM, после отправки показывать страницу «Спасибо», все поля валидировать на клиенте до отправки. Чем конкретнее — тем меньше разночтений.
6. Требования к SEO и технической оптимизации
Это раздел, который часто пропускают — и потом исправляют уже на работающем сайте. В ТЗ стоит зафиксировать: возможность редактировать title и description для каждой страницы, наличие ЧПУ (человекопонятных URL), автоматическую генерацию sitemap.xml, корректный robots.txt, скорость загрузки по метрикам Core Web Vitals.
7. Критерии приёмки
Самый важный раздел с точки зрения защиты обеих сторон. Конкретные измеримые показатели, по которым проект считается выполненным.
Требование Норма Как проверить LCP (скорость загрузки основного контента) ≤ 2,5 сек PageSpeed Insights CLS (стабильность верстки) ≤ 0,1 PageSpeed Insights Индексируемость страниц ≥ 95% целевых страниц Google Search Console / Яндекс.Вебмастер Коды ответов 200 для страниц, 301/302 для редиректов Выборочная проверка URL Sitemap.xml и robots.txt Доступны, не блокируют важные разделы Проверка по прямому URL Формы и события аналитики Работают, фиксируются в счётчике Тестовые заявки, журнал аналитики
ТЗ для разных типов сайтов
ТЗ для лендинга
Лендинг — простейший случай, но и здесь важно зафиксировать структуру блоков в правильном порядке, призывы к действию и их расположение, целевые действия (форма, звонок, чат), требования к загрузке и адаптивности. Особое внимание — конверсионным элементам: кнопкам, формам, офферу. Лендинг создаётся для одного действия, и каждый элемент должен вести к нему.
Для корпоративного сайта
Сложнее — больше страниц, больше типов контента. Здесь важно прописать структуру каждого раздела, логику навигации, требования к новостному разделу или блогу, интеграции с CRM или почтой. Отдельно — требования к административной панели: кто и что может редактировать, нужны ли разные уровни доступа.
ТЗ для интернет-магазина
Самое сложное ТЗ — много функциональных требований. Обязательные блоки: каталог с фильтрами, карточка товара, корзина и оформление заказа, личный кабинет покупателя, интеграция с платёжными системами, интеграция с 1С или складским ПО, система скидок и промокодов. Каждый из этих блоков требует детального описания поведения — что происходит при каждом действии пользователя.
Топ-7 ошибок при составлении ТЗ
- Расплывчатые формулировки — «современный дизайн», «удобная навигация», «быстрый сайт». Это не требования, это пожелания. Каждое утверждение должно быть измеримым: не «быстрый», а «LCP не более 2,5 секунд».
- Нет описания целевой аудитории. Без понимания кто пользователь — невозможно правильно выбрать структуру, функционал и дизайн.
- Пропущен раздел о правах и доступах. Кто может редактировать тексты, добавлять новые товары? Кто имеет доступ к аналитике? Это важно и для разработки, и для безопасности.
- Нет требований к SEO. Если не прописать возможность редактировать метатеги, ЧПУ и карту сайта на этапе ТЗ — потом это будет дорогостоящей доработкой.
- Не согласован стек технологий. Разработчик делает на PHP/Laravel, а потом выясняется, что в компании нет специалистов по этому стеку и некому сайт поддерживать.
- Нет критериев приёмки. Без конкретных метрик сдача проекта превращается в субъективную дискуссию о том, хорошо ли «в целом» сделана работа.
- ТЗ не обновляется при изменении требований. Требования в процессе разработки меняются — это нормально. Ненормально, когда изменения обсуждаются устно и не фиксируются в документе. Итог — конфликт на приёмке.