Как составить техническое задание на разработку сайта в 2026 году: структура, примеры и типичные ошибки
Коротко: Техническое задание на разработку сайта — документ, в котором описаны цели, функционал, структура, дизайн-требования и технический стек. Минимальный объём ТЗ для лендинга — 3–5 страниц, для интернет-магазина — 15–30 страниц, для веб-приложения — 40–80 страниц. Без ТЗ или с размытым ТЗ 68% проектов выходят за бюджет по данным исследований рынка разработки 2024–2025 гг.
Зачем вообще нужно ТЗ и что будет без него?
Техническое задание — это контракт между заказчиком и разработчиком на уровне смыслов. Оно фиксирует, что именно будет сделано, в каком виде, в какие сроки и по каким критериям принимается работа. Без ТЗ каждая сторона понимает «сайт как у конкурентов» по-своему: заказчик видит анимации, личный кабинет и интеграцию с CRM, разработчик — пять страниц на шаблоне.
Последствия работы без ТЗ конкретны: перерасход бюджета в среднем на 35–60%, срыв сроков в 2–3 раза, конфликты при приёмке и судебные споры. По данным опросов российских студий веб-разработки 2025 года, 72% проблемных проектов начинались без формализованного ТЗ или с документом в 1–2 страницы.
Кто должен составлять ТЗ: заказчик или разработчик?
Идеальная схема — совместная работа: заказчик формулирует бизнес-цели и требования к результату, разработчик или аналитик переводит их в технические спецификации. На практике существуют три модели:
- Заказчик пишет сам — подходит, если в команде есть технический директор или продакт. Риск: терминологические ошибки и пропущенные технические детали.
- Разработчик пишет по брифу — студии часто включают составление ТЗ в предпроектную аналитику стоимостью 30 000–150 000 ₽. Риск: студия закладывает удобные ей технологии.
- Независимый аналитик — нейтральная сторона, стоимость 50 000–200 000 ₽. Оптимально для проектов бюджетом от 1 млн ₽.
Для проектов до 300 000 ₽ достаточно брифа на 2–3 страницы плюс прототип экранов. Для проектов от 500 000 ₽ полноценное ТЗ обязательно — иначе вы рискуете потерять больше, чем сэкономили на аналитике.
Структура ТЗ: что должно быть в каждом разделе?
Универсальная структура технического задания на сайт включает 8 обязательных разделов. Ниже — каждый раздел с пояснением, что именно в него вносить.
1. Общая информация о проекте
Название проекта, компания-заказчик, контактные лица, цель проекта (одно предложение: «Увеличить онлайн-продажи кровельных материалов в Москве и МО»), целевая аудитория, конкуренты для ориентира, бюджет и срок. Этот раздел — 1 страница, но он задаёт контекст для всего остального.
2. Типология и структура сайта
Тип сайта (лендинг, корпоративный, интернет-магазин, веб-приложение), карта сайта с перечнем всех страниц и разделов, иерархия разделов. Карту сайта удобно оформлять в виде схемы (Figma, Miro) или нумерованного списка. Пример: «1. Главная → 1.1 Баннер → 1.2 Блок преимуществ → 1.3 Каталог (6 категорий) → 1.4 Форма заявки».
3. Функциональные требования
Самый объёмный раздел. Для каждой функции: название, описание поведения, роли пользователей (гость / зарегистрированный / администратор), граничные условия. Пример: «Фильтрация каталога — пользователь может фильтровать товары по цене (ползунок), категории (чекбоксы), наличию (тоггл). Фильтры применяются без перезагрузки страницы. При отсутствии результатов — сообщение и кнопка сброса фильтров».
4. Нефункциональные требования
Производительность (время загрузки страниц — до 2 секунд на 4G), SEO-требования (ЧПУ, мета-теги, sitemap.xml), безопасность (HTTPS, защита от XSS и SQL-инъекций, политика паролей), доступность (WCAG 2.1 уровень AA), мультиязычность, адаптивность (мобильный, планшет, десктоп).
5. Дизайн-требования
Наличие брендбука или гайдлайна, референсы (3–5 сайтов, которые нравятся и почему), референсы «как не надо», цветовая палитра, шрифты, требования к фотоконтенту. Если дизайн разрабатывается в рамках проекта — описать количество уникальных экранов и количество итераций правок.
6. Технический стек и интеграции
Предпочтительные технологии (или отсутствие предпочтений), CMS или фреймворк, хостинг и сервер, интеграции с внешними сервисами (CRM, 1С, платёжные шлюзы, службы доставки, аналитика). Для каждой интеграции: тип (API, виджет, iframe), наличие документации, ответственная сторона за предоставление доступов.
7. Контент
Кто предоставляет тексты, фото, видео — заказчик или подрядчик. Сроки предоставления контента. Требования к текстам (объём, ключевые слова, тон). Если контент делает подрядчик — количество страниц и стоимость.
8. Критерии приёмки и порядок сдачи
Этапы сдачи (дизайн-макеты → вёрстка → бэкенд → тестирование → запуск), формат демонстрации (тестовый сервер, стейджинг), кто принимает работу со стороны заказчика, срок на проверку каждого этапа (обычно 3–5 рабочих дней), порядок фиксации правок (баг-трекер или Google Docs).
Сколько стоит составить ТЗ и сколько времени это занимает?
| Тип проекта | Объём ТЗ | Стоимость аналитики | Срок подготовки |
|---|---|---|---|
| Лендинг / промо-сайт | 3–5 страниц | 0–15 000 ₽ (часто бесплатно) | 1–3 дня |
| Корпоративный сайт | 8–15 страниц | 15 000–50 000 ₽ | 3–7 дней |
| Интернет-магазин | 15–30 страниц | 30 000–100 000 ₽ | 7–14 дней |
| Веб-приложение / SaaS | 40–80 страниц | 80 000–250 000 ₽ | 14–30 дней |
| Мобильное приложение | 30–60 страниц | 60 000–200 000 ₽ | 10–21 день |
Стоимость аналитики и составления ТЗ — это инвестиция, которая окупается. Проект с чётким ТЗ в среднем обходится на 25–40% дешевле аналогичного проекта без ТЗ за счёт отсутствия переработок и споров о скоупе.
Сравнение: проект с ТЗ vs проект без ТЗ
| Параметр | С ТЗ | Без ТЗ |
|---|---|---|
| Точность оценки бюджета | ±10–15% | ±50–100% |
| Срыв сроков | 20% проектов | 65% проектов |
| Количество итераций правок | 2–3 раунда | 6–12 раундов |
| Конфликты при приёмке | Редко (есть критерии) | Часто (субъективная оценка) |
| Стоимость доработок после запуска | 10–20% от бюджета | 40–80% от бюджета |
| Возможность сменить подрядчика | Легко (документация есть) | Сложно (знания только у исполнителя) |
7 типичных ошибок в ТЗ, которые убивают проект
Ошибка 1: «Сайт как у конкурента X»
Ссылка на чужой сайт без расшифровки — не требование. Разработчик не знает, что именно вам нравится: дизайн, структура, скорость загрузки или конкретная функция. Всегда указывайте: «Хочу как у X — имею в виду вот эту конкретную функцию фильтрации».
Ошибка 2: Отсутствие приоритетов
Если в ТЗ 40 функций без расстановки приоритетов, разработчик не знает, чем пожертвовать при нехватке времени. Используйте систему MoSCoW: Must have / Should have / Could have / Won't have. Это позволяет запустить MVP вовремя и добавить остальное позже.
Ошибка 3: Игнорирование мобильной версии
В 2026 году 58–65% трафика на большинство сайтов приходит с мобильных устройств. Если в ТЗ написано «адаптивный дизайн» без деталей — разработчик сделает минимум. Опишите поведение каждого ключевого блока на мобильном отдельно.
Ошибка 4: Не описаны роли и права доступа
Для сайтов с личным кабинетом, CMS или мультивендорных площадок отсутствие матрицы ролей — гарантия переработок. Кто может редактировать товары? Кто видит финансовую статистику? Кто модерирует отзывы? Каждая роль — отдельный сценарий.
Ошибка 5: Размытые формулировки
«Быстрый сайт», «красивый дизайн», «удобная навигация» — не требования. Быстрый — это LCP до 2,5 секунды по Core Web Vitals. Красивый — соответствие прилагаемому брендбуку. Удобная навигация — меню не глубже 2 уровней, поиск на каждой странице. Переводите субъективное в измеримое.
Ошибка 6: Не описан контент
Кто пишет тексты, кто делает фото, когда это будет готово — если этого нет в ТЗ, проект встанет на этапе наполнения. Задержка контента со стороны заказчика — причина №1 срыва сроков по данным российских студий разработки.
Ошибка 7: Нет раздела о поддержке после запуска
Что происходит после сдачи проекта? Гарантийный период (обычно 1–3 месяца), кто исправляет баги, как передаются доступы, есть ли документация для администратора. Без этого раздела заказчик оказывается в зависимости от подрядчика навсегда.
Инструменты для создания ТЗ в 2026 году
Для составления ТЗ и сопутствующей документации используют следующие инструменты:
- Notion / Confluence — текстовые разделы, таблицы, комментирование. Бесплатно для небольших команд.
- Figma — прототипы экранов, пользовательские сценарии, карта сайта. Стандарт индустрии в 2026 году.
- Miro / FigJam — диаграммы, карта сайта, пользовательские пути (user journey).
- Google Docs — простейший вариант для малых проектов, удобен для совместного редактирования.
- Jira / YouTrack — для декомпозиции ТЗ на задачи и отслеживания в ходе разработки.
Оптимальная связка для большинства проектов: Notion (текст ТЗ) + Figma (прототипы) + Google Sheets (матрица требований с приоритетами MoSCoW).
Шаблон минимального ТЗ для лендинга: что включить за 1 день
Если бюджет небольшой и времени мало, вот минимальный набор для лендинга, который позволит получить адекватную оценку от разработчика:
- Цель страницы (одно предложение) и целевое действие (звонок / заявка / покупка)
- Целевая аудитория (3–5 характеристик: кто, откуда, какая боль)
- Структура блоков (перечень секций в порядке сверху вниз)
- Обязательные элементы (форма, калькулятор, видео, карта, счётчик)
- Референсы (2–3 ссылки с комментарием «нравится вот это»)
- Брендбук или хотя бы логотип + корпоративные цвета
- Кто предоставляет тексты и фото, в какой срок
- Интеграции (CRM, Яндекс.Метрика, пиксели рекламных систем)
- Срок запуска и бюджет
Такой документ на 2–3 страницы даёт разработчику достаточно информации для точной оценки и защищает заказчика от «это не входило в задачу».
FAQ: частые вопросы о техническом задании на сайт
Часто задаваемые вопросы
Обязательно ли составлять ТЗ для небольшого сайта?
Для лендинга достаточно брифа на 2–3 страницы с описанием цели, структуры блоков, референсов и интеграций. Полноценное ТЗ обязательно для проектов от 300 000 ₽ — интернет-магазинов, корпоративных сайтов и веб-приложений.
Сколько стоит составить техническое задание на сайт?
Стоимость зависит от типа проекта: для лендинга — 0–15 000 ₽ (часто бесплатно в рамках предпроектного анализа), для корпоративного сайта — 15 000–50 000 ₽, для интернет-магазина — 30 000–100 000 ₽, для веб-приложения — 80 000–250 000 ₽.
Кто должен писать ТЗ — заказчик или разработчик?
Оптимально — совместная работа: заказчик формулирует бизнес-цели, разработчик или аналитик переводит их в технические требования. Для проектов до 300 000 ₽ ТЗ обычно пишет студия по брифу заказчика. Для проектов от 1 млн ₽ рекомендуется привлечь независимого аналитика.
Что будет, если начать разработку без ТЗ?
По данным опросов российских студий 2025 года, 72% проблемных проектов начинались без ТЗ. Последствия: перерасход бюджета на 35–60%, срыв сроков в 2–3 раза, конфликты при приёмке. Стоимость доработок после запуска без ТЗ составляет 40–80% от исходного бюджета.
Сколько страниц должно быть в ТЗ?
Зависит от сложности проекта: лендинг — 3–5 страниц, корпоративный сайт — 8–15 страниц, интернет-магазин — 15–30 страниц, веб-приложение или SaaS — 40–80 страниц, мобильное приложение — 30–60 страниц.
Какие инструменты использовать для написания ТЗ в 2026 году?
Оптимальная связка: Notion или Google Docs для текста ТЗ, Figma для прототипов экранов и карты сайта, Google Sheets для матрицы требований с приоритетами MoSCoW. Для крупных проектов — Confluence для документации и Jira для декомпозиции на задачи.
Что такое метод MoSCoW в ТЗ и зачем он нужен?
MoSCoW — метод расстановки приоритетов для требований: Must have (обязательно), Should have (желательно), Could have (можно добавить), Won't have (не в этой версии). Позволяет запустить MVP вовремя, не жертвуя ключевым функционалом, и добавить остальное в следующих итерациях.