Как составлять ТЗ для разработки сайта

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

Проблема здесь не в плохой коммуникации как таковой. Проблема в том, что сайт — это не одна страница и не один экран. Это структура, сценарии, контент, роли, интеграции, требования к скорости, безопасности, админке, формам, аналитике и приемке. Если это не зафиксировано заранее, проект почти неизбежно начинает расползаться.

 

Что такое хорошее ТЗ на сайт на практике

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

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

Последний пункт недооценивают чаще всего. Но именно он спасает бюджет и сроки. Пока границы не описаны, любая новая идея звучит как «небольшое уточнение». А в реальности это может быть новый шаблон страницы, отдельный сценарий, доработка админки, новая интеграция, дополнительная роль или новый кусок аналитики.

 

Зачем ТЗ нужно бизнесу, а не только подрядчику

ТЗ закрывает сразу несколько бизнес-рисков.

• Риск разного понимания результата. Пока требования не зафиксированы, каждый участник проекта достраивает картину у себя в голове. Заказчик думает об одном, дизайнер о другом, разработка о третьем. На выходе это превращается в дорогую синхронизацию через переделки.
  
  
• Риск неточной оценки. Невозможно честно посчитать сроки и стоимость, если не определены типы страниц, структура, интеграции, роли, сценарии и критерии приемки.
  
  
• Риск конфликта на приемке. Если не описано, что именно должно быть реализовано, финальная приемка превращается в спор вкусов и ожиданий. В исходном тексте правильно подмечено, что ТЗ удобно использовать как проверочный чек-лист и как юридическую опору при разногласиях.
  
  
• Риск зависимости от конкретного исполнителя. Когда проект существует только в переписке, звонках и устных договоренностях, смена команды становится болезненной. Нормально собранное ТЗ делает проект переносимым. Новая команда хотя бы понимает, что уже было согласовано и что именно требуется сделать.
  
  

 

Где проекты чаще всего ломаются без ТЗ

Есть 5 типовых точек сбоя.

1. Формулировки слишком общие

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

Нормальное ТЗ переводит такие вещи в измеримые критерии. Не «быстрая загрузка», а время ответа. Не «удобный каталог», а список фильтров, логика сортировки и сценарий выбора. Не «красивый первый экран», а конкретный состав блока, акценты, тип контента и ограничения.

2. Не описаны сценарии, только страницы

Это одна из самых частых ошибок. Команда описывает структуру сайта и забывает, что сайт — это не только набор экранов, но и действия пользователя.

Например:

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

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

3. Не зафиксированы интеграции

Многие сайты сегодня — это уже не витрина, а узел в общей цифровой схеме бизнеса. Формы идут в CRM. Заказы — в ERP. Авторизация — через внешний сервис. Контент тянется из других источников. Аналитика отправляется в несколько систем сразу.

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

4. Не разведены функциональные и нефункциональные требования

Функциональные требования отвечают на вопрос «что сайт делает». Нефункциональные — «как именно он должен это делать». Например:

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

Если этот слой не описан, сайт можно формально сделать, но он будет плохо работать в реальной эксплуатации.

5. Не описаны критерии приемки

Самый частый финальный конфликт звучит так: «Мы думали, это будет работать иначе». Это почти всегда следствие слабой приемки на бумаге.

У каждого важного блока должны быть проверяемые критерии:

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

 

Кто должен делать ТЗ

Правильный ответ — не только заказчик и не только подрядчик.

ТЗ почти никогда не получается качественным, если его делает одна сторона в одиночку.

Заказчик знает бизнес-задачу, ограничения, внутренние процессы, аудиторию, контент, юридические нюансы и смысл проекта. Подрядчик знает, как перевести это в архитектуру сайта, структуру, логику, сценарии, интеграции и технические ограничения.

Поэтому рабочая модель обычно такая:

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

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

 

Каким должно быть сильное ТЗ

Есть простое правило: чем меньше в документе субъективности, тем он сильнее.

 

 

ТЗ должно быть:

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

Отметим 2 сильных принципа: не допускать двусмысленности и сопровождать документ понятным глоссарием. Это действительно базовые вещи. Без них ТЗ быстро превращается в формальный текст, который никто одинаково не понимает.

«Нормальное ТЗ нужно, чтобы через 3 месяца у бизнеса, разработки и менеджмента был один и тот же ответ на вопрос, что именно мы делаем и как поймем, что сделали это правильно», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Подведем итоги

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

Поэтому зрелый подход здесь простой. Не спрашивать, нужно ли нам ТЗ вообще. Спрашивать надо другое: насколько подробно нужно зафиксировать требования, чтобы не платить потом за переделку того, что можно было договорить до старта.