ТЗ на сайт: как подготовить техническое задание, чтобы разработка не стала хаосом

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

Главные требования к ТЗ

• Однозначность формулировок: одно требование - один ожидаемый результат, без "удобно", "быстро", "красиво" без критериев.
• Проверяемость: у каждого важного пункта есть критерий приемки и способ проверки.
• Приоритизация: Must/Should/Could (или аналог), чтобы понимать, что обязательно для релиза.
• Границы: что точно НЕ входит в работу и что будет отдельной задачей/этапом.
• Ответственные: кто дает исходные данные, кто согласует, кто принимает результат.
• Единый артефакт: ссылки на макеты/прототипы/контент хранятся и версионируются рядом с ТЗ.

Цели проекта и критерии успешности

Кому подходит: если вы хотите составить ТЗ на сайт так, чтобы подрядчик мог оценить объем работ, а команда - принимать результат по понятным правилам.

Когда не стоит писать детальное ТЗ: если вы не определили тип продукта и бизнес-модель, нет владельца решения (кто финально утверждает), или вы заведомо идете в исследования/прототипирование (в этом случае начните с короткого брифа + гипотез и плана discovery).

• Что сделать: сформулировать 1-3 цели (зачем сайт создается) и 3-7 измеримых критериев успеха.
• Как проверить: у каждой цели есть метрика/событие/отчет и период контроля; формулировка не допускает двойного толкования.
• Кто отвечает: владелец продукта/маркетинг - за цели; аналитик/PM - за метрики и фиксацию в документе.

Аудитория, сценарии использования и пользовательские пути

Этот блок задает "контекст принятия решений": что пользователь хочет сделать и как он доходит до результата.

• Что понадобится:
  • Доступы к аналитике (например, веб-аналитика/CRM), если они есть, либо выгрузки обезличенных данных.
  • Материалы от бизнеса: офферы, сегменты, карта продуктов/услуг, ограничения по юр. требованиям (если применимо).
  • Примеры конкурентов/референсов и список "нравится/не нравится" с пояснениями.
  • Контент-инвентарь: что уже готово (тексты, фото, видео, документы) и что нужно создать.
• Что сделать: описать 2-5 ключевых сегментов и для каждого - 1-3 сценария (задачи пользователя) и целевое действие на сайте.
• Как проверить: по каждому сценарию есть понятный "старт" (откуда пришел) и "финиш" (что считается успехом), а также исключения (что делать при ошибке/нет данных).
• Кто отвечает: маркетинг/продакт - за сегменты и ценность; UX/аналитик - за пути и события; заказчик - за финальное согласование.

Функциональные требования: приоритеты и границы

Ниже - безопасная структура, по которой удобно собирать требования, оценивать и принимать работу. Если нужен ориентир, приложите в документ "пример ТЗ на сайт" в виде 1-2 заполненных карточек функций и используйте их как эталон оформления.

Мини‑чек‑лист подготовки перед описанием функций

• Соберите единый список "страницы/разделы/сущности" (например: товары, статьи, заявки, пользователи).
• Определите роли и права доступа (гость, пользователь, администратор, контент‑менеджер).
• Зафиксируйте словарь терминов (как называете сущности и статусы).
• Определите релизы: что идет в первый запуск, что - позже.
• Уточните зависимости: какие интеграции критичны, какие можно отложить.

1. Разбейте сайт на функции и оформите "карточки требований". Для каждой функции задайте: описание, пользовательскую ценность, ограничения и зависимости. Сразу фиксируйте, где функция находится (страница/блок) и какие данные использует.
   • Приоритет: Must/Should/Could.
   • Критерии приемки: проверяемые условия (что должно получиться на экране/в админке/в данных).
   • Пример поведения: короткий сценарий "если..., то..." (включая ошибки).
2. Опишите пользовательские и административные сценарии отдельно. Пользовательские сценарии - про действия на витрине, административные - про управление контентом, правами, заявками, справочниками. Так вы не забудете админку и редакторские процессы.
   • Приоритет: отдельно для витрины и админки (они часто расходятся).
   • Критерии приемки: роли, права, аудит действий (если нужно), корректность статусов.
   • Пример поведения: "контент‑менеджер сохраняет черновик, публикация доступна только редактору".
3. Установите границы: что не делаем и что делаем позже. Зафиксируйте исключения: какие поля/фильтры/варианты не поддерживаются, какие разделы будут заглушками. Это напрямую влияет на оценку и снижает риск "а давайте еще чуть‑чуть".
   • Приоритет: "вне объема" (Out of scope) и "после релиза 1".
   • Критерии приемки: в релизе нет скрытых ожиданий; все "хочу потом" вынесено в бэклог.
   • Пример поведения: "в релизе 1 нет личного кабинета; вместо него - форма заявки и письмо на почту".
4. Опишите данные и валидации. Какие поля обязательны, какие форматы допустимы, какие сообщения об ошибках показывать. Это особенно важно для форм, фильтров, корзины, заявок и интеграций.
   • Приоритет: Must для критических полей/форм.
   • Критерии приемки: валидация на клиенте и/или сервере, понятные ошибки, сохранность данных.
   • Пример поведения: "если email некорректен, поле подсвечивается и форма не отправляется".
5. Привяжите каждую функцию к способу приемки. Определите, что считается "сделано": демо на стенде, чек по критериям, автотесты (если договорились), подтверждение со стороны бизнеса.
   • Приоритет: Must для функций релиза 1.
   • Критерии приемки: список проверок, ответственный принимающий, формат фиксации замечаний.
   • Пример поведения: "функция принята, когда пройден чек‑лист и замечания закрыты/перенесены в бэклог".

Нефункциональные требования: производительность, безопасность, поддержка

• Производительность: определите, какие страницы/операции критичны, и как именно вы меряете "быстро" (метрика/метод проверки/окружение).
• Надежность: опишите ожидания по отказоустойчивости и восстановлению (резервные копии, план отката релиза).
• Безопасность: роли и права, защита админки, требования к паролям/сессиям, обработка персональных данных (если применимо).
• Логи и мониторинг: что логировать (ошибки, важные события), кто имеет доступ, как быстро реагировать.
• Совместимость: поддерживаемые браузеры/устройства, требования к адаптиву.
• SEO и индексация: правила генерации мета‑данных, robots/sitemap, каноникал, редиректы (если есть перенос).
• Доступность: базовые требования к контрастности, фокусу, управлению с клавиатуры (если важно для проекта).
• Поддержка и развитие: кто обновляет CMS/зависимости, как оформляются задачи, какие среды нужны (dev/stage/prod).

Информационная архитектура: страницы, блоки и навигация

• Смешивают "страницу" и "блок": в итоге непонятно, что переиспользуется, а что уникально.
• Не фиксируют состояния: пустые списки, 404, нет результатов поиска, ошибка отправки формы.
• Не описывают правила навигации: активные пункты меню, хлебные крошки, логика подменю и футера.
• Забывают про контент‑модель: какие типы материалов есть (новость/статья/кейc), чем отличаются поля и шаблоны.
• Нет единого правила для URL и вложенности: потом сложно делать редиректы и поддерживать структуру.
• Не определяют, какие блоки редактируются из админки и какие поля нужны редактору.
• Указывают "как на макете", но не фиксируют поведение: сортировки, пагинацию, фильтры, поиск.
• Не согласуют, где какие CTA и куда ведут: конверсионные пути расползаются по сайту.

Технические ограничения, интеграции и план релизов

Выберите формат реализации и фиксации требований исходя из зрелости процесса и рисков. Если вы планируете заказать техническое задание на сайт у подрядчика, заранее договоритесь о формате артефактов (документ, backlog, прототипы) и о том, что считается "согласовано".

1. Единый документ ТЗ + приложения (прототипы/макеты) - уместно, когда объем средний/большой и много согласующих. Хорошо работает для тендера и фиксированной оценки; важно вести версии и протокол изменений.
2. ТЗ как backlog в трекере (user stories + acceptance criteria) - уместно при итеративной разработке и частых изменениях. Требует дисциплины: единые шаблоны карточек, приоритизация, Definition of Done.
3. Discovery → короткое ТЗ на релиз 1 → развитие - уместно, когда есть неопределенность в продукте или интеграциях. Снижает риск ошибиться с архитектурой, но требует времени на исследование и быстрые согласования.
4. Фикс‑прайс на релиз 1 + time&materials на доработки - уместно, когда важен прогнозируемый запуск, но вы ожидаете изменения после первых данных. Здесь особенно критично явно прописать границы и порядок change requests, иначе "разработка сайта по ТЗ цена" будет постоянно спорной на каждом уточнении.

• Что сделать: перечислить интеграции (CRM, платежи, рассылки, каталоги, SSO), форматы обмена, владельцев доступов, тестовые ключи и окружения.
• Как проверить: на каждый внешний сервис есть сценарий проверки, обработка ошибок и правило деградации (что делает сайт, если сервис недоступен).
• Кто отвечает: заказчик - за доступы и контакты вендоров; разработка - за реализацию и логи; PM - за план релизов и контроль зависимостей.

Типичные дилеммы при составлении ТЗ и готовые решения

Нужно ли ТЗ, если есть макеты?

Да: макеты редко фиксируют правила данных, ошибки, права, интеграции и критерии приемки. Минимум - добавьте к макетам текстовые acceptance criteria на ключевые функции.

Как не утонуть в деталях и все же не потерять важное?

Детализируйте только Must‑функции релиза 1 и все интеграции/формы. Остальное оформляйте как backlog с приоритетами и явной пометкой "после запуска".

Кто должен писать ТЗ - бизнес или разработчик?

Бизнес фиксирует цели, правила и ограничения; разработчик помогает формализовать требования, выявить дырки и предложить реалистичную архитектуру. Лучший вариант - совместная сессия + единый владелец документа (PM/аналитик).

Что делать, если требования меняются каждую неделю?

Введите версионирование и процедуру change request: что меняем, почему, как влияет на сроки/объем, кто утверждает. Для изменчивых частей используйте backlog вместо "заморозки" всего документа.

Как согласовывать приемку, чтобы не спорить "сделано/не сделано"?

Для каждой Must‑функции заранее запишите критерии приемки и примеры поведения, включая негативные сценарии. Приемку ведите по чек‑листу и фиксируйте решения в комментариях к версии ТЗ/задачам.

Можно ли оценить сроки и бюджет только по верхнеуровневому описанию?

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