Проект без технического задания — это договор на словах. Заказчик представляет одно, разработчик делает другое. В итоге три раунда правок, споры на сдаче и деньги, потраченные на доработки, которых можно было избежать. ТЗ — документ, который защищает обе стороны и делает разработку предсказуемой.
Что такое ТЗ на сайт
Техническое задание (ТЗ) на разработку сайта — это документ, который регламентирует технические, функциональные и контентные составляющие будущего проекта. В нём фиксируется всё:
- какой движок использовать,
- как должна выглядеть главная страница,
- какие функции нужны в личном кабинете,
- какой должна быть скорость загрузки,
- как выглядит мобильная версия.
Чем детальнее проработано ТЗ — тем выше шанс, что заказчик получит именно то, что хотел, а исполнитель сделает работу в срок без бесконечных доработок. ТЗ — не договор, это приложение к договору. Два разных документа с разными функциями.
Зачем нужно техническое задание
Пользу от ТЗ получают обе стороны — и заказчик, и исполнитель. Это не просто формальность.
| Для заказчика | Для исполнителя |
|---|---|
| Позволяет узнать предварительную стоимость разработки | Ускоряет разработку — не нужно угадывать намерения клиента |
| Ускоряет согласование базовых вопросов | Даёт чёткое понимание главной задачи и объёма работ |
| Собирает все пожелания в одном документе | Страхует от выполнения несогласованных задач |
| Позволяет сверять промежуточные этапы с планом | Формирует базис для будущего развития проекта |
| Защищает при приёмке — факты зафиксированы | Защищает от претензий — есть что показать клиенту |
Практический пример: если при сдаче проекта заказчику не понравилась выбранная 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, а потом выясняется, что в компании нет специалистов по этому стеку и некому сайт поддерживать.
- Нет критериев приёмки. Без конкретных метрик сдача проекта превращается в субъективную дискуссию о том, хорошо ли «в целом» сделана работа.
- ТЗ не обновляется при изменении требований. Требования в процессе разработки меняются — это нормально. Ненормально, когда изменения обсуждаются устно и не фиксируются в документе. Итог — конфликт на приёмке.
Комментарии скоро откроются. А пока — пишите нам в Telegram-канал.