Как составить ТЗ на разработку сайта

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

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

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

Преимущества разработки по ТЗ:

• Четкая формулировка цели. В процессе согласования проясняются задачи проекта, требования к структуре, функционалу и технической части.
• Быстрая реализация. Исполнитель заранее понимает, что именно нужно сделать, — меньше уточняющих вопросов и вероятность правок по итогам первого релиза.
• Простая смена подрядчика. При необходимости ТЗ позволит быстро подключить нового специалиста без длительного погружения.
• Прозрачные критерии приемки. Готовый сайт можно сверить с чек-листом требований. ТЗ помогает урегулировать спорные моменты — при необходимости и в судебном порядке.

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

Кто составляет ТЗ на разработку сайта

Обычно ТЗ подготавливает исполнитель перед подписанием договора: он задает вопросы, предлагает варианты архитектуры и стилистики.

Что важно со стороны заказчика:

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

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

Правила составления технического задания.

Хорошее ТЗ — краткое и однозначное. Главная ошибка — субъективные определения («современный», «красивый», «удобный»), которые каждый понимает по‑своему. Нужны измеримые и проверяемые параметры.

Примеры удачных и неудачных формулировок:

• Неправильно: «Сайт должен выдерживать большой трафик». Правильно: «Сайт стабильно работает при одновременной нагрузке 55 000 пользователей».
• Неправильно: «Страницы должны быстро открываться». Правильно: «Время загрузки — не более 2 секунд».
• Неправильно: «У статей должно быть хорошее превью». Правильно: «Превью статьи — первый абзац текста».
• Неправильно: «Статьи должны быть уникальными». Правильно: «Уникальность материалов — от 90% по text.ru».

Структура шаблона

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

Базовая структура:

• Цели и задачи проекта.
• Сведения о компании.
• Описание целевой аудитории.
• Словарь терминов, используемых в документе.
• Технические требования (CMS, хостинг, стек, безопасность и пр.).
• Детализированная структура меню.
• Прототипы страниц с описанием элементов.
• Пользовательские сценарии.
• Перечень контента к релизу.
• Требования к веб-дизайну.

Единого «универсального» образца ТЗ не существует. Опирайтесь на шаблон, но адаптируйте формулировки под свой бизнес.

Шаблон технического задания (для редактирования): ссылка Пример заполненного ТЗ: ссылка

Вводная информация.

Команда должна понимать назначение сайта и задачи, которые он решает. В начале указывают цель запуска, ключевые функции, кратко описывают деятельность компании, продукты/услуги и портрет клиента.

Словарь терминов.

Документ читают не только технические специалисты — поэтому важно расшифровать термины, чтобы исключить разночтения (включая юридические споры).

Примеры:

• CMS — система управления содержимым, позволяющая создавать и редактировать сайт без программирования.
• Сценарии — пошаговые маршруты действий пользователя.
• Фильтры — параметры для сортировки товаров/материалов/страниц.
• Контент — тексты, изображения, видео, интерактивные блоки и другие форматы.

Техническая часть

В разделе фиксируют:

• выбранную CMS;
• требования к хостингу;
• целевые показатели скорости загрузки;
• отказоустойчивость и допуски по нагрузке (одновременные пользователи);
• требования к информационной безопасности. Обязательно прописывают кроссбраузерность и адаптивность: корректная работа в популярных браузерах и на устройствах с разными диагоналями.

Структура меню.

Если у заказчика нет финального видения, исполнитель предлагает структуру, исходя из задач, ассортимента и логики контента. Совместно согласуют страницы и настройки фильтров. Для наглядности архитектуру удобно представить ментальной картой или блок-схемой. После релиза разделы можно дополнять и редактировать через CMS.

Прототипы страниц.

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

Пользовательские сценарии

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

Базовый формат:

• цель пользователя;
• его действие;
• изменение на странице;
• ожидаемый результат. Пример: Клиент хочет «обратный звонок» (цель). Нажимает зеленую кнопку с иконкой трубки (действие). Открывается форма с полем телефона и кнопкой «Заказать звонок» (изменение). Пользователю очевидно, что делать дальше (результат).

Контент.

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

Веб-дизайн.

Раздел фиксирует требования к UX/UI и визуалу: шрифты, цветовая палитра, размеры и формат изображений, принципы обработки фото, правила для иконок и иллюстраций, а также элементы, не влияющие напрямую на функциональность, но формирующие идентику.

Особенности ТЗ для разных типов сайтов

• Лендинг/визитка. Документ компактнее: нет сложной структуры меню и фильтров, но обязателен прототип главного экрана и описание сценариев.
• Корпоративный сайт. Подходит полная схема ТЗ. Дизайн обязан соответствовать брендбуку: фирменные цвета, шрифты, правила логотипа и т. д. Если брендбука нет, разумно сначала его разработать — иначе возможен редизайн с дополнительными затратами.

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