Техническое задание на сайт — это документ, в котором заказчик фиксирует, что именно должно быть сделано, как это проверить и по каким критериям работа будет принята. Если его нет или оно написано общими словами, подрядчик достраивает недостающее сам, а заказчик на приёмке обнаруживает, что имелось в виду другое. Ниже — структура документа, примеры формулировок и ошибки, из-за которых сроки и бюджет расходятся с ожиданиями.
Что такое ТЗ на сайт и чем оно отличается от брифа
Бриф отвечает на вопросы «зачем» и «для кого»: чем занимается компания, кто клиенты, какие задачи решает сайт. ТЗ отвечает на вопросы «что именно» и «как проверить»: какие страницы, какие функции, какие интеграции, при каких условиях работа считается выполненной.
Готовит документ обычно заказчик, но подрядчик помогает его формализовать: задаёт уточняющие вопросы, предлагает структуру, оценивает риски. Объём не должен быть самоцелью. Для корпоративного B2B-сайта хватает 10–20 страниц, если каждое требование можно проверить.
Из каких разделов состоит ТЗ
Рабочая структура технического задания на сайт выглядит так:
- Общие сведения. Компания, продукты, рынок, текущий сайт и его проблемы.
- Цели и метрики. Что сайт должен давать бизнесу и как это измерять.
- Аудитория и сценарии. Кто приходит на сайт и что хочет сделать.
- Структура сайта. Карта разделов и описание каждой страницы.
- Функциональные требования. Формы, каталог, поиск, личный кабинет, калькуляторы.
- Дизайн и UX. Стилистика, брендбук, адаптивность, анимации.
- Технические требования. CMS, скорость, безопасность, SEO-база, аналитика.
- Контент. Кто и когда готовит тексты, фото, видео, документы.
- Интеграции. CRM, телефония, почта, ERP, платёжные системы.
- Этапы, сроки и приёмка. Что сдаётся на каждом шаге и по каким критериям.
Если у вас уже есть брендбук, список конкурентных сайтов-референсов или выгрузка аналитики, оформите это как приложения. Так основной текст остаётся читаемым.
Цели, аудитория и сценарии: основа документа
Цель сайта в ТЗ должна быть измеримой. Формулировка «современный сайт, который привлекает клиентов» ничего не говорит исполнителю. Лучше так: «Сайт должен принимать заявки на расчёт стоимости от технических специалистов и закупщиков; каждая заявка фиксируется в CRM с указанием источника и страницы».
Дальше опишите роли посетителей. В B2B это обычно лицо, принимающее решение, технический эксперт и закупщик. У каждого свой вопрос: первому нужны выгоды и риски, второму — характеристики и документация, третьему — условия поставки и цены.
Затем переведите роли в сценарии. Пример: «Технический директор приходит из поиска на страницу оборудования, сравнивает модели, скачивает каталог в PDF и оставляет заявку на консультацию». Из таких сценариев подрядчик выводит структуру страниц и расстановку кнопок, а не придумывает их из общих соображений.
Как описывать структуру и функциональность
Структура сайта
Начните с карты сайта: разделы, подразделы, связи между ними. Для каждой страницы укажите назначение, обязательные блоки, главное целевое действие и источник контента: готовый текст, нужно написать, нужно собрать у экспертов.
Отдельно отметьте шаблонные и уникальные страницы. Десять карточек продуктов на одном шаблоне и три посадочные страницы с индивидуальной вёрсткой — это разный объём работы, и оценка должна это учитывать.
Функциональные требования
Описывайте функцию через действие пользователя и результат. Формат «Пользователь может… система делает…» лучше любых абстрактных определений, потому что его можно проверить на тестовой версии.
| Размытая формулировка | Проверяемая формулировка |
|---|---|
| Удобный каталог с фильтрами | Пользователь может отфильтровать каталог по типу оборудования, мощности и отрасли; результат обновляется без перезагрузки страницы; выбранные фильтры отражаются в адресе страницы |
| Форма обратной связи | Форма содержит поля «Имя», «Телефон», «Email», «Комментарий»; после отправки пользователь видит сообщение об успехе, менеджер получает письмо, данные попадают в CRM |
| Быстрый сайт | Основные страницы загружаются на мобильном устройстве не дольше 3 секунд при стандартном 4G-соединении; проверка выполняется заранее согласованным инструментом |
| Простая админка | Контент-менеджер без навыков программирования может создать новость, изменить текст на странице и загрузить документ |
Правило простое: если к требованию нельзя придумать тест, оно сформулировано неточно. Переписывайте, пока тест не появится.
Технические и нефункциональные требования
Нефункциональные требования заказчики чаще всего пропускают, а потом спорят о них на приёмке. Зафиксируйте заранее:
- Платформа. Какая CMS или фреймворк, кто владеет исходным кодом, можно ли сменить подрядчика без переписывания сайта.
- Адаптивность. Какие разрешения и браузеры поддерживаются, включая мобильные.
- Скорость. Целевые значения и инструмент, которым они проверяются.
- Безопасность. HTTPS, разграничение прав в админке, резервное копирование, защита форм от спама.
- SEO-основа. Читаемые адреса, управляемые заголовки и описания, карта сайта, файл robots, редиректы со старых адресов, микроразметка.
- Аналитика. Счётчики, цели, события для форм и скачиваний, передача источника заявки в CRM.
- Хостинг и доступы. Где размещается сайт, на кого оформлены домен и аккаунты.
- Персональные данные. Согласия в формах, политика обработки, размещение данных в соответствии с законодательством.
Если сайт переезжает со старого, опишите миграцию: что переносится, что переписывается, как сохраняются позиции в поиске.
Контент, приёмка и ответственность сторон
Контент — главный источник задержек. В ТЗ должно быть прописано, кто готовит тексты и материалы, в какие сроки и в каком формате передаёт. Добавьте условие: если материалы не поступили к дате, срок проекта сдвигается на то же количество дней.
Раздел о приёмке описывает порядок проверки. Укажите, что результат сдаётся на тестовой площадке, сколько рабочих дней у заказчика на проверку, сколько кругов правок включено в стоимость и что считается дефектом, а что — новой задачей. Дефект — это несоответствие ТЗ. Новая функция, которой в ТЗ не было, оценивается и оплачивается отдельно.
Закрепите и гарантийный период: в течение какого времени подрядчик бесплатно исправляет ошибки, найденные после запуска, и в какие сроки отвечает на обращения.
Частые ошибки заказчика при составлении ТЗ
- Описывать решения вместо задач. «Сделать слайдер на главной» вместо «показать три ключевых направления и привести к целевому действию». Подрядчик лишается возможности предложить лучшее решение.
- Использовать оценочные слова. «Современный», «удобный», «интуитивный», «быстрый» не проверяются. Заменяйте их критериями.
- Не указывать цели и метрики. Без них невозможно оценить результат и приоритизировать функции.
- Забывать про интеграции. Связка с CRM, телефонией и почтой часто выясняется в середине проекта и меняет оценку.
- Не определять контент. Сайт готов, а наполнить его нечем, и запуск откладывается.
- Писать ТЗ в одиночку. Маркетинг, продажи, ИТ и юристы видят сайт по-разному. Требования стоит согласовать до отправки подрядчику.
- Считать ТЗ неизменным. Документ можно обновлять, но каждое изменение должно проходить через согласование с пересмотром срока и стоимости.
- Не прописывать права и передачу. Не указано, кто владеет кодом, дизайном, доступами и документацией, — возникает зависимость от исполнителя.
Как проверить ТЗ перед отправкой подрядчику
Дайте документ коллеге, который не участвовал в проекте, и попросите пересказать, что будет создано. Если пересказ отличается от вашего представления, в тексте есть пробелы.
Затем пройдите по чек-листу:
- У каждой цели есть метрика или признак достижения.
- Для каждой страницы определено главное действие посетителя.
- Для каждой функции есть сценарий проверки.
- Перечислены все интеграции и внешние системы.
- Указан ответственный за контент и сроки его передачи.
- Описаны порядок приёмки, число кругов правок и гарантия.
- Закреплены права на код, дизайн и доступы.
- Документ согласован маркетингом, продажами и ИТ.
Хорошо, если подрядчик задаёт вопросы по ТЗ до оценки. Это признак того, что он читает документ, а не просто выставляет цену.
Итог
Хорошее техническое задание на сайт не обязано быть объёмным, но обязано быть проверяемым: цели измеримы, сценарии описаны, функции формулируются через действия, а приёмка опирается на критерии, а не на ощущения. Вложив несколько дней в подготовку, вы сокращаете число споров, переделок и скрытых доплат. Начните с целей и сценариев, добавьте структуру и нефункциональные требования, договоритесь о контенте и приёмке — и у подрядчика будет понятная рамка, а у вас — инструмент контроля.
Читайте также
Частые вопросы
-
Чем техническое задание на сайт отличается от брифа?
Бриф описывает бизнес, аудиторию и задачи, а ТЗ — конкретные требования к результату: страницы, функции, интеграции и критерии приёмки. Бриф помогает подрядчику понять контекст, ТЗ позволяет проверить работу.
-
Кто должен писать ТЗ: заказчик или подрядчик?
Содержание требований определяет заказчик, потому что только он знает свои цели и процессы. Подрядчик помогает с формализацией: задаёт вопросы, предлагает структуру и оценивает технические риски.
-
Сколько страниц должно быть в ТЗ на корпоративный сайт?
Для B2B-сайта обычно достаточно 10–20 страниц плюс приложения с брендбуком, картой сайта и референсами. Важнее не объём, а то, что каждое требование можно проверить.
-
Что делать, если требования изменились после начала работ?
Зафиксировать изменение письменно, оценить влияние на срок и стоимость и согласовать обе стороны. Так ТЗ остаётся актуальным документом, а не источником споров.
