Техническое задание на разработку сайта: как составить правильно и зачем оно нужно

Техническое задание на разработку сайта — документ, который большинство заказчиков считают необязательной формальностью. До первого конфликта с исполнителем. После него мнение меняется кардинально: без ТЗ нет чётких критериев «готово», нет защиты от переделок за ваш счёт и нет рычага влияния, если что-то пошло не так.

В этой статье разберём, что такое техническое задание, зачем оно нужно обеим сторонам, из каких разделов состоит и как составить его самостоятельно — даже без технического опыта.

Что такое техническое задание на разработку сайта

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

ТЗ — не просто список пожеланий. Это юридически значимый документ, который прикладывается к договору и становится основой для оценки результата. Если исполнитель не сделал то, что прописано в ТЗ — он нарушил договор. Если заказчик требует то, чего в ТЗ нет — это дополнительная работа за отдельную плату.

«Техническое задание защищает обе стороны. Заказчика — от того, что получит не то. Разработчика — от бесконечных правок за те же деньги.»

Чем ТЗ отличается от брифа

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

Бриф отвечает на вопрос «что нужно сделать в общих чертах». ТЗ отвечает на вопрос «как именно это должно быть сделано и по каким критериям принимается».

Зачем нужно техническое задание

Для заказчика

• Фиксирует договорённости — то, что обсудили устно, становится документом
• Защищает бюджет — правки в рамках ТЗ бесплатны, всё сверх — по дополнительному соглашению
• Даёт критерии приёмки — вы точно знаете, что должно быть на сайте, и можете проверить
• Помогает сравнивать предложения — с одним ТЗ вы получаете сопоставимые сметы от разных студий

Для исполнителя

• Снимает неопределённость — понятно, что делать и в каком объёме
• Защищает от «а я думал, это само собой разумеется»
• Позволяет точно оценить сроки и стоимость
• Упрощает управление проектом внутри команды

Что происходит без ТЗ

Работа «на словах» — прямой путь к конфликту. Типичный сценарий: заказчик говорит «сделайте как у конкурента», разработчик делает «как понял», результат не совпадает с ожиданиями. Без ТЗ невозможно доказать, кто прав.

По оценкам проектных менеджеров, 60–70% конфликтов между заказчиками и исполнителями в веб-разработке возникают именно из-за отсутствия или расплывчатости технического задания.

Кто составляет техническое задание

Есть три варианта:

Исполнитель составляет ТЗ — наиболее распространённая практика. Менеджер проекта проводит интервью с заказчиком, изучает задачу и формирует документ. Плюс: профессиональный подход. Минус: риск, что исполнитель «заточит» ТЗ под то, что ему удобно делать.

Заказчик составляет ТЗ — хорошо работает, если у заказчика есть технический специалист или опыт в разработке. Плюс: точное отражение потребностей. Минус: часто содержит пробелы в технической части.

Совместная работа — оптимальный вариант. Заказчик описывает бизнес-логику и цели, исполнитель переводит это в технические требования. Итоговый документ согласовывается и подписывается обеими сторонами.

Независимо от того, кто пишет ТЗ, — подписывает его всегда заказчик. Убедитесь, что понимаете каждый пункт перед подписанием.

Структура технического задания на разработку сайта

Универсального стандарта не существует, но грамотное ТЗ всегда включает следующие разделы.

1. Общая информация о проекте

Вводный раздел, который даёт контекст всей команде:

• Название проекта и заказчика
• Краткое описание бизнеса и сферы деятельности
• Цель создания сайта — конкретная и измеримая
• Целевая аудитория — кто будет пользоваться сайтом
• Конкуренты — 3–5 примеров с комментариями «нравится / не нравится»
• Референсы — сайты, которые нравятся по стилю или структуре

Этот раздел часто недооценивают, но именно он задаёт вектор всей дальнейшей работы. Разработчик, который понимает бизнес заказчика, делает другие решения, чем тот, кто не понимает.

2. Структура сайта

Полный список страниц и разделов в виде иерархии. Например:

Главная
├── О компании
│   ├── История
│   └── Команда
├── Услуги
│   ├── Услуга 1
│   ├── Услуга 2
│   └── Услуга 3
├── Портфолио
├── Блог
│   └── Статья (шаблон)
└── Контакты

Для каждой страницы укажите: назначение, основные блоки, целевое действие посетителя.

3. Функциональные требования

Самый объёмный и важный раздел. Здесь описывается всё, что сайт должен уметь делать:

Формы и заявки:

• какие формы нужны и на каких страницах
• какие поля обязательны
• куда приходят заявки — email, CRM, мессенджер
• нужна ли автоматическая нотификация пользователю

Каталог и фильтры (для магазинов и каталогов):

• структура категорий
• атрибуты товаров и фильтры
• логика сортировки
• отображение — список или плитка

Личный кабинет:

• регистрация и авторизация (email, телефон, соцсети)
• что видит пользователь в кабинете
• история заказов, сохранённые данные, настройки

Интеграции:

• CRM-система (AmoCRM, Битрикс24, HubSpot)
• платёжные системы (ЮKassa, Tinkoff Pay, СБП)
• логистика (СДЭК, Почта России)
• системы аналитики (Яндекс.Метрика, Google Analytics)
• сторонние сервисы (онлайн-чат, обратный звонок, карты)

Административная панель:

• какие разделы нужно редактировать без разработчика
• кто будет администратором и каков уровень технической подготовки
• нужны ли разные роли пользователей

4. Требования к дизайну

Этот раздел помогает дизайнеру работать в нужном направлении, а не угадывать вкус заказчика:

• Фирменные цвета (HEX-коды, если есть брендбук)
• Типографика — шрифты, если есть предпочтения
• Стиль — минимализм, корпоративный, яркий, технологичный
• Референсы с конкретными комментариями: «нравится сетка», «нравится цветовая схема», «нравится анимация кнопок»
• Что категорически не нравится
• Наличие фирменного стиля — есть ли логотип, брендбук, гайдлайны

Требования к адаптивности:

• перечень разрешений, под которые нужна адаптация (как минимум: мобильный 375px, планшет 768px, десктоп 1280px+)
• приоритет: mobile first или desktop first

5. Технические требования

Раздел для технической команды:

Технологический стек:

• CMS (WordPress, 1С-Битрикс, собственная разработка, headless)
• язык программирования бэкенда (PHP, Python, Node.js)
• фронтенд-фреймворк (React, Vue, Nuxt, Next.js)
• база данных (MySQL, PostgreSQL, MongoDB)

Хостинг и сервер:

• требования к хостингу или предпочтения
• ожидаемая нагрузка — сколько посетителей в день/месяц
• нужен ли CDN для ускорения загрузки

Безопасность:

• SSL-сертификат (обязательно)
• защита от SQL-инъекций и XSS
• двухфакторная аутентификация для администраторов
• регулярное резервное копирование

Производительность:

• целевые показатели PageSpeed Insights (рекомендуется 70+ для мобильных)
• максимальное время загрузки главной страницы

6. SEO-требования

Этот раздел часто вообще отсутствует в ТЗ — и это большая ошибка. Разработка сайта с SEO в основе обходится значительно дешевле, чем доработка под SEO после запуска.

Базовые SEO-требования в ТЗ:

• ЧПУ (человекопонятные URL) для всех страниц
• возможность редактировать title, description, H1 для каждой страницы
• правильная структура заголовков H1–H6
• микроразметка Schema.org (хотя бы Organization, BreadcrumbList, FAQ)
• автогенерация sitemap.xml
• настройка robots.txt
• канонические URL для избежания дублей
• оптимизация изображений (сжатие, форматы WebP, атрибуты alt)
• страница 404 с навигацией

7. Требования к контенту

Кто отвечает за наполнение сайта текстами, фото и видео — заказчик или исполнитель? Это должно быть зафиксировано явно, иначе сайт зависнет перед запуском.

Укажите:

• какие разделы наполняет студия, какие — заказчик
• требования к текстам (объём, стиль, наличие ключевых слов)
• источники изображений (собственные фото, стоки, иллюстрации)
• нужна ли обработка фотографий

8. Сроки и этапы

График работ с конкретными датами:

Фиксируйте не только сроки исполнителя, но и сроки обратной связи от заказчика. Задержка согласования со стороны заказчика — главная причина срыва дедлайнов.

9. Критерии приёмки

Список конкретных условий, при выполнении которых работа считается завершённой:

• все страницы из структуры созданы и наполнены
• все функции из раздела функциональных требований работают
• сайт корректно отображается на указанных разрешениях и браузерах
• PageSpeed не ниже оговорённых значений
• все формы работают и письма доставляются
• подключены системы аналитики
• переданы все доступы и исходники

Типичные ошибки в техническом задании

Расплывчатые формулировки. «Современный дизайн», «удобная навигация», «быстрая загрузка» — это не требования, это пожелания. Хорошее ТЗ оперирует конкретикой: «время загрузки главной страницы не более 2 секунд», «PageSpeed не ниже 75».

Отсутствие структуры сайта. Без полного списка страниц невозможно точно оценить объём работы — ни сроки, ни стоимость.

Игнорирование мобильной версии. «Адаптивный дизайн» в ТЗ без указания конкретных разрешений и приоритетов — почти ничего.

Нет раздела про SEO. Разработчик не SEO-специалист. Если SEO-требования не прописаны — они не будут выполнены.

ТЗ не обновляется в процессе. Если в ходе работы появляются новые требования — их нужно фиксировать в дополнительном соглашении, а не обсуждать устно.

«Хорошее ТЗ — это когда незнакомый разработчик может взять документ, прочитать его и понять, что именно нужно сделать без единого звонка заказчику.»

Шаблон структуры ТЗ для скачивания

Если вы составляете ТЗ самостоятельно, используйте следующую структуру как основу:

1. Общая информация (описание бизнеса, цель, аудитория, конкуренты)
2. Структура сайта (иерархия страниц)
3. Функциональные требования (формы, каталог, кабинет, интеграции)
4. Требования к дизайну (стиль, цвета, адаптивность)
5. Технические требования (стек, хостинг, безопасность, скорость)
6. SEO-требования (URL, мета-теги, разметка, карта сайта)
7. Требования к контенту (кто наполняет, что нужно)
8. Сроки и этапы (таблица с датами)
9. Критерии приёмки (конкретный чек-лист)
10. Порядок внесения изменений (как оформляются правки сверх ТЗ)

Как согласовать ТЗ с исполнителем

После составления чернового варианта ТЗ проведите совместную встречу с командой разработки. Пройдитесь по каждому разделу и убедитесь, что понимание совпадает.

Хорошие вопросы для согласования:

• Есть ли в ТЗ что-то, что вы понимаете иначе, чем мы?
• Что из описанного технически невозможно или нецелесообразно?
• Какие риски вы видите в текущих требованиях?
• Что не указано в ТЗ, но, по вашему опыту, точно понадобится?

Только после того, как обе стороны подтвердили понимание документа — подписывайте его и начинайте работу.

Итог

Техническое задание на разработку сайта — не бюрократия и не лишняя трата времени. Это инструмент, который экономит деньги, защищает интересы обеих сторон и делает итоговый результат предсказуемым.

Потратьте 1–2 дня на составление нормального ТЗ — и сэкономьте недели переделок и споров. Требуйте ТЗ от любого исполнителя, будь то крупная студия или фрилансер. Если исполнитель отказывается работать с ТЗ — это один из главных красных флагов при выборе подрядчика.

Источники

• ГОСТ 34.602-89 — Техническое задание на создание автоматизированной системы
• Яндекс — рекомендации по SEO-оптимизации сайтов
• Google — Core Web Vitals
• Schema.org — словарь микроразметки
• W3C — стандарты веб-разработки