Стратегия и планирование
Техническое задание на разработку сайта: структура ТЗ и пример
Разбираем, какие разделы нужны в ТЗ, что можно подготовить до старта и как превратить идею в понятный объем работ.
Коротко
Техническое задание на разработку сайта фиксирует не только страницы, но и бизнес-цель, аудиторию, пользовательские сценарии, контент, интеграции и критерии готовности. Для первого разговора достаточно брифа, примеров и описания результата. Полное ТЗ обычно собирают вместе с командой на этапе discovery, чтобы не зафиксировать предположения как обязательные функции.
Зачем нужно техническое задание на разработку сайта
Техническое задание нужно не для того, чтобы заполнить документ на десятки страниц. Его задача - убрать разные трактовки: какой результат должен принести сайт, кто им пользуется, что должен сделать посетитель и какие функции обязательны в первом релизе. Без этой рамки фраза «нужен современный сайт» превращается в бесконечные правки, а смета - в предположение.
Хорошее ТЗ связывает бизнес-задачу и интерфейс. Например, производственной компании нужно не «пять страниц», а получение заявок на расчет, понятное объяснение сложной услуги и передача обращения в CRM. Для интернет-магазина важен другой результат: посетитель находит товар, видит актуальные условия, оплачивает заказ и получает уведомление. У каждого сценария свои экраны, поля, ошибки и интеграции.
Если сайта еще нет, начните с короткого брифа: продукт, аудитория, главная цель, список услуг или товаров, текущий способ обработки заявок, желаемый срок и ссылки на референсы. Если сайт уже работает, добавьте данные аналитики, вопросы клиентов и список проблем. Это дает разработке больше пользы, чем попытка самостоятельно придумать техническую архитектуру.
Что подготовить к первой встрече
Не нужно приносить идеальное ТЗ. Чтобы предметно обсудить сайт, команде достаточно увидеть контекст и ограничения. Чем раньше они станут известны, тем быстрее получится предложить реалистичный первый этап и не заложить в макеты недоступную функцию.
- ссылку на текущий сайт, презентацию, таблицу или описание существующего процесса;
- главную цель: обращение, продажа, запись, расчет, самообслуживание или внутренняя операция;
- кто принимает решение и какие вопросы он обычно задает до покупки;
- перечень обязательных материалов: услуги, товары, документы, цены, кейсы, фото;
- что нельзя менять: бренд, домен, текущую CRM, учетную систему, юридические ограничения;
- желаемый срок и причину, почему запуск важен именно к этой дате;
- примеры, в которых важны не цвета, а конкретная логика или подача.
Такой набор помогает отделить факты от пожеланий. Дальше команда задает уточняющие вопросы и превращает вводные в структуру, сценарии, технические риски и план согласований.
Структура ТЗ на разработку сайта
| Раздел | Что фиксируем | Зачем это нужно |
|---|---|---|
| Цель | Каким измеримым действием должен закончиться визит | Помогает не спорить о второстепенных блоках |
| Аудитория | Кто принимает решение и что для него важно | Влияет на язык, структуру и доказательства |
| Сценарии | Путь от первого экрана до заявки, заказа или действия | Определяет набор экранов и состояний |
| Контент | Тексты, фото, документы, товары, кейсы и ответственность за них | Не дает дизайну ждать материалы в последний момент |
| Функции | Формы, каталог, кабинет, роли, уведомления, поиск | Делает оценку прозрачной |
| Интеграции | CRM, платежи, доставка, аналитика, внешние базы | Позволяет проверить API и границы ответственности |
| Приемка | Как проверяем готовность этапа и что считается релизом | Снижает риск субъективных правок |
Структура не должна быть одинаковой для всех проектов. Лендингу часто достаточно цели, аудитории, карты блоков, формы и аналитики. Для личного кабинета или CRM добавляются роли, права, статусы, импорт данных, журнал действий и сценарии ошибок. Если продукт связан с продажами, отдельно описывают путь обращения после отправки формы: кто получает уведомление, где хранится лид и что видит менеджер.
Как описывать страницы
Вместо формулировки «страница услуг» полезнее написать: «пользователь выбирает направление, видит состав работы, срок и ориентир по бюджету, затем оставляет запрос или переходит в каталог». Это сразу задает смысл блока, нужные CTA и данные. Количество экранов появляется как следствие сценария, а не как случайное число в смете.
Как зафиксировать функции и интеграции
Функция описывается действием пользователя и результатом системы. Например: «посетитель оставляет номер телефона, видит подтверждение, заявка приходит менеджеру и сохраняется в CRM с источником рекламы». Такое описание показывает, что форма - это не только поле и кнопка. Нужно предусмотреть валидацию, защиту от спама, страницу успеха, передачу UTM-меток, уведомление и проверку доставки.
- входные данные: что вводит пользователь и какие поля обязательны;
- состояния: загрузка, пустой результат, ошибка, успешное действие;
- роли: кто видит, редактирует, подтверждает или удаляет данные;
- источник данных: вручную, через API, импортом или из существующей системы;
- интеграции: событие запуска, формат данных, ошибки и ответственный сервис;
- безопасность: какие данные чувствительны и где они не должны появляться;
- аналитика: какие действия и цели должны быть измеримы после запуска.
Платежи, доставка и CRM нельзя оставлять строчкой «подключить». Для них заранее проверяют документацию, учетные данные, тестовую среду, вебхуки и сценарии отказа. Отдельный разбор есть в материале об интеграции платежных систем на сайт. Если интеграция нестандартная, ее оценка должна быть самостоятельной частью плана, а не обещанием «подключить по ходу».
Пример ТЗ для лендинга
Для лендинга нет необходимости рисовать корпоративную энциклопедию. Достаточно зафиксировать одну воронку и доказательства, которые помогают человеку принять решение. Ниже минимальная структура, с которой можно начинать оценку.
- Цель и оффер.Например: получать заявки на расчет услуги от компаний определенного сегмента. Указать, что получает клиент и почему обращается именно сейчас.
- Первый экран.Заголовок, короткое объяснение, основное действие и доказательство доверия: кейс, срок, сертификат или понятный процесс.
- Структура аргументов.Проблема, решение, состав услуги, процесс, кейсы, ответы на возражения и финальная форма.
- Форма заявки.Поля, согласие на обработку данных, сообщение об успехе, уведомление и передача источника обращения.
- Запуск и измерение.Домен, базовая SEO-разметка, настройка целей и проверка страницы на мобильных устройствах.
Если лендинг должен проверять спрос, оставьте только обязательные блоки и один главный CTA. Не переносите в него каталог, личный кабинет и редкие функции, которые не нужны для первого обращения. Более подробно состав первого релиза и диапазоны бюджета разобраны в статье о стоимости создания сайта.
Пять ошибок, которые делают ТЗ бесполезным
Описывать интерфейс без цели
Фразы вроде «сделать современно», «как у конкурента» или «добавить анимацию» сами по себе не дают критерия решения. У каждой идеи должен быть контекст: какую проблему пользователя она снимает, какое действие помогает совершить и как поймем, что решение работает. Тогда дизайн и разработка могут предложить лучший способ реализации, а не просто копировать пример.
Перечислять страницы вместо сценариев
Список «главная, услуги, контакты» не объясняет поведение сайта. В ТЗ должна быть видна цепочка: пользователь пришел с рекламы, понял предложение, сравнил варианты, оставил контакты, получил подтверждение, а менеджер увидел заявку с источником. Такой сценарий сразу показывает, какие данные, состояния и интеграции действительно нужны.
Не фиксировать исключения
Полезное ТЗ содержит не только то, что входит, но и то, что пока не делаем: подготовку большого фотобанка, многоязычность, сложный кабинет, интеграцию с редкой учетной системой или регулярное SEO-продвижение. Это не «мелкий шрифт», а защита планирования. Исключения можно оценить отдельным этапом, когда они становятся приоритетом.
Согласовать макет, но не приемку
До запуска стоит договориться, как проверяется функциональность: на каких устройствах, с какими браузерами, куда приходит тестовая заявка, кто принимает контент и кто дает доступы. Тогда команда не обнаружит в день релиза, что форма не должна принимать заявки ночью или что домен принадлежит другому сотруднику.
Если каждое решение можно связать с целью, сценарием и критерием готовности, документ перестает быть бюрократией и становится инструментом управления проектом.
Как согласовать объем без бюрократии
До разработки полезно согласовать не только документ, но и порядок решений. Сначала команда показывает структуру и сценарии, затем - прототип или дизайн ключевых экранов, после - рабочую версию на тестовом адресе. На каждом этапе должен быть понятный вопрос для клиента: «это решает задачу?», «все обязательные состояния учтены?», «можно переходить к следующей стадии?».
Изменения не запрещают, но делают управляемыми. Если новая функция влияет на сроки, дизайн или интеграции, ее добавляют в отдельный следующий релиз либо пересчитывают до начала работы. Такой подход сохраняет прозрачность для обеих сторон и позволяет не жертвовать качеством ключевого сценария.
Рабочее ТЗ - это карта решений: что делаем, для кого, как проверяем результат и где заканчивается первый релиз.
FAQ
Частые вопросы
01Можно ли начать разработку сайта без ТЗ?
Да. Для старта достаточно короткого брифа, цели, примеров и описания текущего процесса. Затем команда проводит discovery, собирает структуру, сценарии и границы MVP. Полное ТЗ становится результатом этого этапа, а не барьером для первой встречи.
02Кто должен составлять техническое задание?
Бизнес отвечает за цель, правила работы, исходные данные и приоритеты. Команда разработки помогает превратить их в понятные сценарии, интерфейсы, технические требования и план запуска. Одностороннее ТЗ без обсуждения обычно фиксирует лишь предположения.
03Сколько страниц должно быть в ТЗ?
Количество страниц не определяет качество. Для лендинга может хватить нескольких согласованных разделов и прототипа. Для CRM или web-приложения важнее описать роли, статусы, данные, ошибки и интеграции, даже если документ становится объемнее.
04Нужно ли отдельно описывать мобильную версию?
Да, нужно зафиксировать адаптивный сценарий и критичные отличия: порядок блоков, меню, формы, таблицы, фильтры и касания. Мобильная версия не должна появляться в конце как уменьшенная копия desktop-макета.
05Что делать, если требования изменились во время разработки?
Зафиксировать изменение и оценить его влияние на сроки, бюджет и уже принятые решения. Затем выбрать: заменить менее приоритетную функцию, перенести идею в следующий релиз или обновить план до начала работ.
Источники и документация
Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.
Обсудить проект
Соберем понятный план до старта разработки
Пришлите идею, старый сайт или список задач. Поможем выделить первый результат, обязательные функции и границы проекта.