Техническое задание на создание сайта превращает пожелания заказчика в проверяемые требования: какие страницы и функции нужны, кто готовит материалы, как принимается работа и что остаётся за границами проекта. Ниже — структура документа, примеры формулировок и готовый шаблон, который можно заполнить перед обращением к подрядчику.
ТЗ, бриф и договор: в чём разница
| Документ | Главная задача | Что в нём фиксируют |
|---|---|---|
| Бриф | Собрать исходные данные | Бизнес, аудитория, продукт, пожелания, ориентиры, ограничения |
| Техническое задание | Описать проверяемый результат | Состав страниц, функции, контент, интеграции, требования и критерии приёмки |
| Договор | Закрепить обязательства сторон | Предмет, стоимость, порядок оплаты, сроки, права, ответственность и порядок изменений |
Документы связаны, но не заменяют друг друга. Бриф помогает подрядчику понять задачу и подготовить проект решения. ТЗ становится приложением к договору или отдельным согласованным документом. Договор определяет юридические условия, которых в ТЗ может не быть.
Что подготовить до составления ТЗ
Начните не с перечня технологий, а с бизнес-контекста. Подрядчику понадобятся:
- описание компании, продукта и географии работы;
- цели сайта и действия, которые должен совершать посетитель;
- сегменты аудитории, их задачи и возражения;
- перечень услуг или товаров и приоритетные направления;
- существующая аналитика, CRM, формы, каталог и другие системы;
- обязательные юридические документы и требования к персональным данным;
- владельцы контента и люди, которые принимают решения;
- ориентиры по срокам и бюджету, если они известны.
Если части информации нет, это не повод придумывать. В ТЗ можно отдельно записать: «решение определяется после интервью», «состав интеграции уточняется после доступа к API» или «контент готовит подрядчик после согласования структуры».
Структура технического задания на разработку сайта
1. Общая информация и цели
Укажите название проекта, владельца, контактных лиц и причину запуска. Цель должна быть связана с бизнесом: получать квалифицированные заявки, принимать заказы, сокращать нагрузку на менеджеров, показывать каталог партнёрам или поддерживать клиентов.
Хорошая формулировка: «Создать сайт для привлечения заявок на проектирование промышленных систем. Основное целевое действие — отправка брифа; дополнительное — запрос консультации по телефону».
2. Аудитория и пользовательские сценарии
Не ограничивайтесь демографией. Опишите ситуацию человека, его вопрос, нужное доказательство и следующий шаг. Например: инженер проверяет совместимость решения, директор оценивает сроки и риски, закупщик запрашивает документы и условия.
3. Границы проекта
Зафиксируйте, что входит и не входит в работу. Например, дизайн и разработка входят, а фотосъёмка, перевод и наполнение каталога более чем 100 товарами оцениваются отдельно. Этот раздел предотвращает конфликт ожиданий лучше длинного списка пожеланий.
4. Структура страниц
Составьте карту сайта: главная, разделы услуг, карточки, кейсы, блог, о компании, контакты, юридические страницы. Для каждой страницы укажите цель и ключевой сценарий. Если структура будет уточняться после SEO-исследования, так и запишите.
5. Функциональные требования
Каждую функцию описывайте через пользователя, действие, данные и результат. Вместо «нужен калькулятор» — «пользователь выбирает тип объекта и площадь, получает ориентировочный диапазон, оставляет контакт; параметры и заявка передаются в CRM».
6. Контент и ответственность сторон
Составьте таблицу материалов: тексты, фото, видео, логотип, реквизиты, сертификаты, переводы. Для каждого пункта назначьте владельца, формат и дату передачи. Укажите, кто согласует факты и кто имеет право финального решения.
7. Дизайн и адаптивность
Опишите брендовые ограничения, аудиторию, характер интерфейса и примеры полезных решений. Фраза «сделать современно» непроверяема. Лучше: «использовать действующий фирменный стиль; обеспечить чтение таблиц на мобильных устройствах; ключевые действия доступны с клавиатуры; макеты согласуются для трёх контрольных ширин».
8. CMS, интеграции и права доступа
Укажите, какие данные редактор должен менять самостоятельно. Для интеграций перечислите системы, направление обмена, обязательные поля, частоту синхронизации, владельца доступа и поведение при ошибке. Не выбирайте CMS только потому, что её название знакомо: сначала опишите редакционные задачи.
9. SEO, аналитика, скорость и безопасность
- человеко-понятные URL и возможность редактировать Title и Description;
- один логический H1, корректная иерархия заголовков и canonical;
- XML-карта сайта, robots.txt и правила для служебных страниц;
- редиректы со старых URL при редизайне;
- события аналитики для форм, звонков и ключевых действий;
- HTTPS, резервное копирование, роли пользователей и обновления;
- согласованные проверки производительности и доступности.
Требование «100 баллов во всех тестах» обычно некорректно: оценка зависит от страницы, устройства, сети и сторонних скриптов. Зафиксируйте измеряемые условия проверки и допустимые исключения.
10. Этапы и приёмка
Разделите проект на исследование, прототип, дизайн, разработку, наполнение, тестирование и запуск. Для этапа запишите результат, формат согласования и срок обратной связи. Приёмка должна проверять согласованные функции, контент, адаптивность, формы, аналитику, ошибки и передачу доступов.
Пример технического задания: фрагмент
Плохие и хорошие формулировки
| Плохо | Лучше |
|---|---|
| Сайт должен быть современным | Использовать утверждённые шрифты и цвета; макеты главной, услуги и статьи согласовать до разработки |
| Удобная форма | Форма содержит имя, телефон и задачу; ошибки объясняются рядом с полем; после отправки показывается подтверждение |
| Быстрая загрузка | Проверять согласованные шаблоны на мобильном профиле; отдельно фиксировать влияние внешних виджетов |
| Интеграция с CRM | Создавать лид с контактами, страницей, UTM и выбранной услугой; описать повторную отправку при ошибке |
| Хорошее SEO | Редактируемые метаданные, canonical, sitemap, редиректы, семантическая структура и события аналитики |
| Работает во всех браузерах | Проверить актуальные версии Chrome, Safari, Firefox и Edge, а также iOS и Android в согласованном диапазоне |
| Защитить сайт | HTTPS, ограниченные роли, резервные копии, обновления и журналирование критичных действий |
Что не нужно фиксировать слишком жёстко
ТЗ не должно превращаться в попытку спроектировать решение без специалиста. Оставьте подрядчику свободу выбора там, где важен результат: точный набор плагинов, внутреннюю структуру компонентов, технический способ кэширования или визуальные детали ещё не согласованного макета. Жёстко фиксируйте ограничения, данные, безопасность, пользовательский результат и критерий проверки.
Чек-лист перед отправкой подрядчику
- Понятна бизнес-цель и основное действие пользователя.
- Названы аудитории и ключевые сценарии.
- Есть карта страниц или правило её подготовки.
- Для функций описаны входные данные и результат.
- Назначены владельцы текстов, изображений и согласований.
- Перечислены интеграции и доступы.
- Определены правила SEO, аналитики и редиректов.
- Зафиксированы требования к мобильной версии и доступности.
- Понятно, что не входит в проект.
- Для каждого этапа есть критерий приёмки.
- Описан порядок изменений после утверждения.
- ТЗ не противоречит договору и смете.
Скачать образец ТЗ
Мы подготовили редактируемый шаблон с подсказками, полями для заполнения и финальным чек-листом. Удалите ненужные разделы, добавьте особенности проекта и передайте документ подрядчику для уточнения оценки.
Скачать шаблон технического задания →
Частые вопросы
Кто должен составлять ТЗ?
Заказчик предоставляет бизнес-данные и ограничения, а подрядчик помогает превратить их в технически проверяемые требования. Для сложного проекта совместная подготовка надёжнее документа, написанного одной стороной.
Можно ли начать без ТЗ?
Можно начать исследование, интервью или прототипирование. Но переходить к оценке сложной разработки без зафиксированного объёма рискованно: стороны будут по-разному понимать результат.
Чем ТЗ отличается от прототипа?
ТЗ описывает требования и критерии, а прототип показывает структуру экранов и сценариев. Они дополняют друг друга: часть решений удобнее согласовать визуально.
Нужно ли включать SEO?
Да, если сайт должен получать поисковый трафик или сохраняет адреса старого ресурса. Минимум — архитектура, метаданные, индексирование, редиректы, аналитика и требования к шаблонам контента.
Следующий шаг
Если документ уже заполнен, отправьте его вместе с примерами и доступной аналитикой через бриф на проект. Если исходные требования ещё нужно собрать, команда разработки сайтов для бизнеса поможет провести интервью, спроектировать структуру и подготовить согласуемое ТЗ.
