Техническое задание часто превращают в каталог пожеланий: современный дизайн, удобное меню, быстрая загрузка, интеграция с CRM. Все пункты звучат разумно, но стороны могут понимать их по-разному. Хорошее ТЗ нужно прежде всего для того, чтобы договориться о поведении сайта, границах проекта и способе приёмки.
Начните со сценариев, а не со списка экранов
Опишите, кто приходит на сайт и что должен сделать. Например: посетитель выбирает услугу, проверяет ограничения, отправляет запрос и получает подтверждение. Менеджер видит обращение в CRM с источником и выбранным направлением. Редактор меняет цену без обращения к разработчику.
Сценарий сразу обнаруживает пропуски. Если заявка отправлена, но почта недоступна, что увидит человек? Если файл слишком большой, как сайт объяснит ошибку? Если сотрудник удалит категорию, что произойдёт с её адресом? В разработке сайта такие вопросы лучше решить до программирования, когда изменения ещё относительно недороги.
Зафиксируйте структуру и содержание
Для каждого типа страницы укажите назначение, обязательные блоки и источник данных. Типов обычно меньше, чем страниц: услуга, статья, карточка товара, список, контакты. Это позволяет согласовать общие правила, а не описывать вручную каждый похожий экран.
Отдельно распределите ответственность за тексты, фотографии, цены, документы и перенос старых материалов. Формулировка «наполнение сайта» без количества и состава почти неизбежно создаёт спор. Если контент ещё не готов, согласуйте образцы и ограничения, чтобы макет не зависел от идеальных коротких заголовков.
Опишите интеграции через данные и ошибки
«Подключить CRM» недостаточно. Нужны перечень полей, направление передачи, момент запуска обмена и поведение при сбое. Для формы уточняют, как предотвращаются дубли при повторном нажатии, где сохраняется копия и кто получает уведомление о проблеме.
Для обмена каталогом важны источник истины для цены и остатка, частота обновления, сопоставление товаров и журнал ошибок. Не обязательно перегружать основной документ техническими деталями: их можно вынести в приложение, сохранив проверяемые сценарии в ТЗ.
Превратите пожелания в критерии приёмки
- Вместо «удобно на телефоне» — основные сценарии проходят на согласованных размерах экрана без горизонтальной прокрутки и перекрытия кнопок.
- Вместо «редактируемый сайт» — редактор меняет конкретные поля и видит результат после сохранения.
- Вместо «SEO готовность» — управляемые заголовки и описания, постоянные адреса, правила перенаправлений, корректные коды ответов.
- Вместо «надёжная форма» — обращение сохраняется, передаётся по согласованному каналу и показывает пользователю понятный результат.
Визуальные критерии тоже нуждаются в согласовании. Дизайн сайта оценивают по утверждённым макетам и состояниям компонентов, а не по личному впечатлению от одного скриншота в конце проекта.
Оставьте механизм изменения требований
Во время работы появляются новые идеи. Это нормально, если понятно, как они влияют на сроки и стоимость. Для каждого изменения фиксируйте описание, причину, оценку и решение: включить сейчас, заменить другую задачу или отложить.
ТЗ не должно запрещать развитие проекта. Его задача — сделать изменения видимыми. После согласования у обеих сторон должен остаться одинаковый ответ на три вопроса: что создаём, чего в текущем этапе нет и как доказываем готовность. Чем яснее эти ответы, тем меньше энергии уйдёт на споры о формулировках.