ТЗ на корпоративный сайт: требования, по которым можно принять работу

ТЗ — договорённость о результате и границах

Техническое задание помогает заказчику и команде одинаково понимать, что делает корпоративный сайт, кому он нужен и как проверить готовность. Список «главная, услуги, контакты» не отвечает на вопросы о контенте, заявках, ролях, интеграциях и поддержке после запуска. Поэтому два подрядчика могут назвать разные сроки и стоимость, формально отвечая на одну и ту же заявку.

Эта статья — о требованиях и критериях приёмки для оценки проекта. Она отличается от плана разработки корпоративного сайта и статьи о структуре: здесь акцент на достаточном брифе, открытых допущениях, границах и проверяемых формулировках. Нельзя требовать фиксированную смету при неясном составе работ и одновременно считать все изменения включёнными.

Мини-шаблон требования к одному сценарию

Эту структуру можно перенести в бриф или таблицу требований без превращения документа в сотню страниц.

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

Какие исходные данные нужны заказчику

Не пытайтесь заранее придумать каждый экран. Сначала сформулируйте бизнес-задачу, аудитории и обязательные ограничения.

• Опишите, чем занимается компания, какие услуги приоритетны и какие действия посетитель должен выполнить: выбрать направление, сравнить компетенции, оставить заявку, найти документ или связаться с поддержкой.
• Назовите целевые группы и их вопросы. Покупатель, партнёр, кандидат и действующий клиент могут искать разный контент; это влияет на навигацию и права доступа.
• Соберите доступные материалы: тексты, фотографии, фирменный стиль, документы, кейсы, юридические сведения, существующие URL и статистику. Для отсутствующего контента укажите, кто его готовит и утверждает.
• Перечислите системы, с которыми сайт должен работать: CRM, аналитика, рассылка, поиск, авторизация, каталог. Для каждой связи уточните владельца API и доступ к тестовой среде.
• Запишите ограничения: домен, хостинг, требования к данным, языковые версии, редакторские роли, доступность, сроки согласований и ответственных за приёмку.

Структура ТЗ, пригодная для оценки и приёмки

Каждый раздел должен либо влиять на объём работ, либо позволять проверить результат.

• Зафиксируйте цели и измеримые сценарии: например, посетитель из выбранной отрасли находит подходящую услугу и отправляет запрос; заявка приходит в назначенный канал с источником и подтверждением отправителю.
• Опишите состав страниц и типы шаблонов отдельно. Десять услуг на одном шаблоне и десять уникальных лендингов — разные проекты. Укажите правила создания новых страниц в CMS.
• Перечислите функциональность: навигация, поиск, формы, загрузки, языки, фильтры, роли редакторов и интеграции. Для каждого пункта определите входные данные, результат и поведение при ошибке.
• Добавьте требования к контенту и SEO: миграция старых URL, метаданные, канонические адреса, карта сайта, микроразметка по фактическому содержимому, внутренние ссылки. Не обещайте позиции поисковой выдачи как критерий технической приёмки.
• Опишите нефункциональные требования через проверяемый способ: мобильные размеры, доступность ключевых сценариев, резервное копирование, права доступа, мониторинг, восстановление после сбоя. Числовые пороги согласуйте под конкретную инфраструктуру и нагрузку.
• Разделите этапы: исследование, прототип, дизайн, разработка, наполнение, тестирование, миграция, запуск, гарантийные исправления и поддержка. Для каждого укажите решение о приёмке и ответственного.
• Создайте таблицу критериев для критических задач. Например: «форма с обязательными полями отклоняет некорректный адрес, сохраняет корректное обращение один раз, отправляет подтверждение и показывает понятное состояние ошибки при недоступности CRM».
• Отдельно запишите исключения и порядок изменений. Если новые разделы или интеграции появятся после согласования, укажите, кто оценивает влияние на срок и бюджет.

Как контролировать подготовку и реализацию

ТЗ полезно, если снижает число неизвестных и делает решения прозрачными.

• Доля критических сценариев с согласованными критериями приёмки и назначенным владельцем решения.
• Число открытых зависимостей: контент, доступы, внешние API и юридические согласования.
• Количество изменений объёма после утверждения и причины: новая потребность или пропущенное исходное требование.
• Доля дефектов критического пути, найденных до запуска и после публикации.

Формулировки, которые дорого обходятся

Слова «удобно» и «как у конкурента» не объясняют, что именно нужно проверить.

• Называть срок и бюджет до выбора числа уникальных шаблонов, интеграций и объёма подготовки контента.
• Писать «быстрый сайт» без условий измерения, целевых страниц, устройства и допустимых исключений.
• Не назначать ответственного за тексты, юридические согласования и доступы, а затем считать их отсутствие задержкой разработки.
• Оставлять интеграцию словом «CRM» без описания полей, сценариев отказа, владельца системы и проверки доставки заявки.

С чего начать обсуждение проекта

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

Хорошее ТЗ не запрещает менять решение по мере обучения. Оно делает изменение осознанным: видно, что именно пересмотрено, как это влияет на сроки и по каким условиям работа будет принята.

Пример строки из ТЗ

Раздел «Услуги» использует один утверждённый шаблон; редактор может добавить услугу с названием, лидом, преимуществами, вопросами и CTA без изменения кода. Посетитель с клавиатуры достигает формы и получает понятное подтверждение. Заявка содержит slug услуги и попадает в CRM один раз даже при повторном нажатии. Критерий приёмки: пройти сценарий на согласованных устройствах, проверить повтор и отказ CRM, а не просто увидеть макет страницы.