Как написать техническое задание на сайт в 2026 году: шаблон, структура и типичные ошибки
Коротко: Техническое задание (ТЗ) на сайт — это документ от 5 до 40 страниц, в котором описаны цели, функциональность, дизайн, интеграции и критерии приёмки. Правильно составленное ТЗ сокращает количество правок в 2–3 раза, фиксирует объём работ и защищает заказчика от ситуации «мы так не договаривались». Составить базовое ТЗ можно самостоятельно за 3–8 часов, используя готовую структуру.
Зачем нужно ТЗ и что будет без него?
Большинство конфликтов между заказчиками и разработчиками возникают не из-за плохого кода, а из-за разных ожиданий. Заказчик думал, что «корзина» — это стандартная функция, которая входит в стоимость. Разработчик считал, что корзина с мультивалютностью, промокодами и сохранением на 30 дней — это отдельный модуль. Итог: спор, доплата или переделка.
ТЗ решает эту проблему: всё, что зафиксировано в документе, входит в стоимость. Всё, чего нет — оплачивается отдельно. Это работает в обе стороны: защищает заказчика от «мы так не делаем» и защищает разработчика от бесконечных бесплатных доработок.
Проекты без ТЗ, как правило, выходят за бюджет и сроки. По нашему опыту работы с заказными проектами, отсутствие чёткой документации — причина большинства конфликтов на финальном этапе сдачи работ.
Чем ТЗ отличается от брифа и технической спецификации?
Бриф — это маркетинговый документ: кто целевая аудитория, какие цели у сайта, какой стиль нравится. Бриф заполняет заказчик, обычно на 1–3 страницы. ТЗ — технический документ: что именно должно быть реализовано, как это должно работать, какие интеграции нужны. ТЗ пишет разработчик или аналитик на основе брифа. Техническая спецификация — это более детальный документ для крупных проектов, где каждый экран и каждый API-метод описан отдельно. Для малого и среднего бизнеса достаточно ТЗ.
| Документ | Кто пишет | Объём | Когда нужен |
|---|---|---|---|
| Бриф | Заказчик | 1–3 страницы | До начала работы с подрядчиком |
| ТЗ (базовое) | Разработчик / заказчик | 5–15 страниц | Лендинги, корпоративные сайты |
| ТЗ (полное) | Аналитик / тимлид | 15–40 страниц | Интернет-магазины, веб-приложения |
| Техническая спецификация | Системный аналитик | 40–200+ страниц | Крупные платформы, SaaS-продукты |
Структура ТЗ на сайт: что должно быть в каждом разделе
1. Общая информация о проекте
Этот раздел отвечает на вопрос «зачем делается сайт». Укажите: название компании и проекта, цель сайта (продажи, лидогенерация, имидж, сервис), целевую аудиторию (кто будет пользоваться сайтом), конкурентов и референсы (сайты, которые нравятся), язык и регион (русский, английский, мультиязычность). Без этого раздела дизайнер не поймёт, для кого делать интерфейс, а разработчик — какую логику закладывать.
2. Структура сайта (карта страниц)
Перечислите все страницы и разделы. Для корпоративного сайта это обычно 5–15 страниц: главная, о компании, услуги (и подстраницы по каждой), портфолио, блог, контакты. Для интернет-магазина — каталог, карточка товара, корзина, оформление заказа, личный кабинет, страницы статусов. Карту страниц удобно оформить в виде дерева или таблицы. Это самый важный раздел для оценки стоимости: каждая уникальная страница — это отдельная работа по дизайну и вёрстке.
3. Функциональные требования
Описывайте функции конкретно, избегая абстракций. Не «удобная корзина», а «корзина с возможностью изменить количество товара, применить промокод, выбрать способ доставки из 3 вариантов и сохранить содержимое на 7 дней для авторизованных пользователей». Каждую функцию описывайте по схеме: что делает пользователь → что происходит в системе → что видит пользователь в результате.
4. Требования к дизайну
Укажите: наличие брендбука или гайдлайнов, референсы (ссылки на понравившиеся сайты), цветовую палитру, шрифты, стиль (минимализм, корпоративный, яркий), количество уникальных макетов страниц, требования к адаптивности (мобильная версия обязательна в 2026 году), анимации и интерактивность.
5. Технические требования
Этот раздел часто пропускают — и зря. Укажите: CMS или фреймворк (WordPress, 1С-Битрикс, Next.js, собственная разработка), хостинг и сервер (или требования к ним), требования к скорости загрузки (например, LCP не более 2,5 секунды), поддерживаемые браузеры и устройства, требования к безопасности (SSL, защита от SQL-инъекций, резервное копирование), требования к SEO (ЧПУ, мета-теги, карта сайта, robots.txt).
6. Интеграции
Перечислите все внешние системы, с которыми должен работать сайт: CRM (amoCRM, Битрикс24), платёжные системы (ЮKassa, Тинькофф, СБП), системы аналитики (Яндекс.Метрика, счётчики), 1С или другие учётные системы, сервисы email-рассылок, чат-боты и виджеты. Каждая интеграция — это отдельная задача со своей стоимостью и сроками. Если не указать интеграцию в ТЗ, разработчик включит её в смету как дополнительную работу.
7. Административная панель
Опишите, что должен уметь делать администратор сайта без помощи разработчика: добавлять/редактировать/удалять страницы, управлять каталогом и ценами, просматривать заказы и заявки, управлять пользователями, настраивать SEO-параметры страниц. Чем подробнее описана панель управления, тем меньше вопросов возникнет при разработке.
8. Критерии приёмки
Это раздел, который чаще всего отсутствует в ТЗ, — и именно из-за этого возникают споры при сдаче проекта. Укажите: как будет проводиться тестирование, какие браузеры и устройства нужно проверить, какие показатели скорости считаются приемлемыми, что происходит с найденными багами (сроки исправления), как долго длится гарантийный период.
| Тип проекта | Объём ТЗ | Стоимость составления ТЗ | Срок составления |
|---|---|---|---|
| Лендинг (1 страница) | 3–5 страниц | Бесплатно (входит в разработку) или 5 000–15 000 ₽ | 1–3 дня |
| Корпоративный сайт (5–15 стр.) | 10–20 страниц | 10 000–30 000 ₽ | 3–7 дней |
| Интернет-магазин (до 1000 товаров) | 20–40 страниц | 30 000–80 000 ₽ | 7–14 дней |
| Веб-приложение / платформа | 40–150+ страниц | 80 000–300 000 ₽ | 14–45 дней |
Кто должен писать ТЗ: заказчик или разработчик?
Оптимальная схема: заказчик заполняет бриф и формулирует бизнес-требования («хочу, чтобы клиент мог оформить заказ за 3 клика»), а разработчик или аналитик переводит их в технические требования и пишет ТЗ. Заказчик согласовывает и подписывает. Такой подход работает лучше всего: заказчик не погружается в технические детали, которые ему незнакомы, а разработчик не угадывает бизнес-логику.
Если разработчик отказывается составлять ТЗ или говорит «мы работаем без ТЗ, всё обсудим в процессе» — это красный флаг. Работа без ТЗ выгодна только исполнителю: он всегда может сказать, что «это не входило в объём».
Типичные ошибки при составлении ТЗ
Ошибка 1: Абстрактные формулировки
«Современный дизайн», «удобная навигация», «быстрый сайт» — это не требования, это пожелания. Разработчик интерпретирует их по-своему. Замените абстракции на конкретику: «скорость загрузки главной страницы не более 3 секунд на мобильном устройстве», «навигационное меню содержит не более 7 пунктов первого уровня».
Ошибка 2: Пропуск очевидных функций
Заказчики часто не указывают то, что кажется им само собой разумеющимся: форму обратной связи, страницу 404, политику конфиденциальности, мобильную версию, фавикон. Разработчик может посчитать это дополнительной работой. Правило: если функция нужна — она должна быть в ТЗ, даже если кажется очевидной.
Ошибка 3: Отсутствие описания ролей пользователей
Для сайтов с личным кабинетом, интернет-магазинов и платформ критично описать роли: незарегистрированный посетитель, зарегистрированный пользователь, менеджер, администратор. У каждой роли — свои права и интерфейс. Если роли не описаны, разработчик сделает минимальный вариант или уточнит уже в процессе — с потерей времени.
Ошибка 4: ТЗ пишется один раз и не обновляется
В процессе разработки требования меняются. Это нормально. Но изменения должны фиксироваться в ТЗ через дополнительные соглашения. Устные договорённости «добавь вот эту кнопку» без фиксации — источник конфликтов. Любое изменение объёма работ должно быть оформлено письменно.
Ошибка 5: Нет раздела «что не входит в объём»
Опытные разработчики добавляют в ТЗ раздел с явным перечислением того, что не делается в рамках проекта: наполнение контентом, написание текстов, фотосъёмка, настройка рекламы, интеграция с конкретной системой. Это снимает вопросы «а почему это не сделано?» при сдаче.
Шаблон ТЗ: минимальная структура для старта
Если вы хотите составить базовое ТЗ самостоятельно, используйте эту структуру:
- Общие сведения: название проекта, компания, контактное лицо, дата
- Цели и задачи: зачем нужен сайт, какой результат ожидается
- Целевая аудитория: кто будет пользоваться сайтом
- Структура (карта страниц): список всех страниц и разделов
- Функциональные требования: что умеет делать сайт (по каждой странице)
- Дизайн: референсы, брендбук, требования к адаптивности
- Технические требования: CMS, хостинг, браузеры, скорость
- Интеграции: список внешних систем
- Административная панель: что умеет делать администратор
- Сроки и этапы: когда что должно быть готово
- Критерии приёмки: как понять, что работа выполнена
- Что не входит в объём: явный список исключений
Сколько стоит разработка с ТЗ и без: сравнение
| Параметр | С ТЗ | Без ТЗ |
|---|---|---|
| Точность оценки стоимости | ±10–15% | ±40–80% |
| Количество правок после сдачи | Минимальное (в рамках ТЗ) | Высокое (спорные зоны) |
| Риск конфликта при сдаче | Низкий | Высокий |
| Возможность сменить разработчика | Легко (документация есть) | Сложно (всё в голове у исполнителя) |
| Срок разработки | Предсказуемый | Часто затягивается |
| Дополнительные расходы на доработки | Как правило, минимальные | Нередко 20–50% сверх бюджета |
Когда ТЗ можно не писать?
Есть случаи, когда полноценное ТЗ избыточно: лендинг по готовому шаблону, простой сайт-визитка на 3–5 страниц без сложной функциональности, прототип или MVP для быстрой проверки гипотезы. В этих случаях достаточно детального брифа и чёткого описания объёма работ в договоре. Но даже для простых проектов рекомендуется зафиксировать список страниц, функции и критерии приёмки — хотя бы в виде одностраничного документа.
Часто задаваемые вопросы
Кто должен писать ТЗ на сайт — заказчик или разработчик?
Оптимально: заказчик формулирует бизнес-требования и заполняет бриф, разработчик или аналитик переводит их в техническое задание. Заказчик согласовывает и подписывает. Если разработчик отказывается составлять ТЗ — это красный флаг.
Сколько стоит составление ТЗ на сайт?
Для лендинга ТЗ часто входит в стоимость разработки или стоит 5 000–15 000 ₽. Для корпоративного сайта — 10 000–30 000 ₽. Для интернет-магазина — 30 000–80 000 ₽. Для веб-приложения — от 80 000 до 300 000 ₽ и выше.
Можно ли работать без ТЗ?
Для простых проектов (лендинг, сайт-визитка) достаточно детального брифа и описания объёма в договоре. Для интернет-магазина и веб-приложения работа без ТЗ — серьёзный риск: по нашему опыту, именно отсутствие документации становится причиной большинства конфликтов при сдаче проекта.
Что обязательно должно быть в ТЗ на сайт?
Обязательные разделы: цели и задачи сайта, структура (карта страниц), функциональные требования по каждой странице, требования к дизайну, технические требования (CMS, хостинг, скорость), список интеграций, описание административной панели, критерии приёмки и явный список того, что не входит в объём.
Чем ТЗ отличается от брифа?
Бриф — маркетинговый документ (цели, аудитория, референсы), заполняется заказчиком, объём 1–3 страницы. ТЗ — технический документ (что именно реализуется, как работает, какие интеграции), пишется разработчиком на основе брифа, объём 5–40 страниц в зависимости от сложности проекта.
Как описывать функции в ТЗ, чтобы не было споров?
Описывайте каждую функцию по схеме: что делает пользователь → что происходит в системе → что видит пользователь в результате. Избегайте абстракций: не 'удобная корзина', а 'корзина с возможностью изменить количество, применить промокод и сохранить содержимое на 7 дней для авторизованных пользователей'.
Что делать, если требования изменились после подписания ТЗ?
Любые изменения объёма работ должны фиксироваться в дополнительном соглашении к договору. Устные договорённости 'добавь вот эту кнопку' без письменной фиксации — источник конфликтов. Изменение ТЗ, как правило, влечёт пересмотр сроков и стоимости.