ТЗ на разработку сайта или портала: полная структура с шаблонными разделами

1. Паспорт проекта: контекст, цель и границы

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

Границы проекта так же важны, как цели. Если в релиз не входит мобильное приложение, сложная админка, интеграция с 1С, миграция старого архива или личный кабинет, это нужно написать явно. Иначе участники будут держать разные ожидания в голове, а спор возникнет уже на этапе приёмки. Хорошая формулировка границ защищает обе стороны: заказчик понимает, что получает, подрядчик понимает, что обязан реализовать, а будущие изменения можно оценивать как change request.

• Шаблон: Проект создаётся для того, чтобы... Основная бизнес-метрика после запуска...
• Шаблон: В первый релиз входит... В первый релиз не входит...
• Шаблон: Критические даты и зависимости: маркетинговая кампания, договор, выставка, миграция, сезонность.
• Шаблон: Ответственные лица: владелец продукта, представитель бизнеса, технический контакт, принимающая сторона.

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

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

Раздел про аудиторию нужен не для маркетинговых портретов ради красивого документа. Он помогает принимать продуктовые решения. Покупатель, технический специалист, бухгалтер, HR, партнёр, дилер, администратор и руководитель используют сайт по-разному. Им нужны разные аргументы, разная глубина информации, разные формы и разные права доступа. Если это не описать, интерфейс начнёт обслуживать усреднённого пользователя, которого в реальности нет.

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

• Шаблон персоны: роль, цель, сценарий, устройство, уровень знаний, частые вопросы, барьеры, критерий успеха.
• Для портала добавьте внутренние роли: пользователь, менеджер, администратор, бухгалтер, поддержка, супер-админ.
• Опишите различия между новым посетителем, повторным пользователем и авторизованным клиентом.
• Укажите, какие сценарии должны быть удобны на мобильном устройстве, а какие допустимы только на desktop.

3. User stories и пользовательские сценарии

User story — это короткое описание потребности: как пользователь в определённой роли, я хочу выполнить действие, чтобы получить результат. В ТЗ stories нужны не ради agile-терминологии, а чтобы связать интерфейс с реальным поведением. Страница услуги существует не просто для отображения текста, а чтобы посетитель понял предложение, увидел доказательства, сравнил варианты, снял возражения и отправил заявку. Личный кабинет существует не просто для авторизации, а чтобы пользователь видел статусы, документы, оплаты и мог выполнить действие без звонка менеджеру.

Для каждого ключевого сценария полезно описать вход, шаги, данные, развилки, ошибки, уведомления и итог. Например: пользователь отправляет заявку на расчёт. Вход — страница услуги или статья. Шаги — открывает форму, вводит контакты, выбирает услугу, прикрепляет файл, принимает политику, отправляет. Система валидирует поля, создаёт лид в CRM, отправляет письмо пользователю, уведомляет менеджера, пишет событие в аналитику. Ошибки — неверный email, недоступная CRM, слишком большой файл, антиспам.

Если сценарий нельзя пройти словами от входа до результата, его рано отдавать в дизайн и разработку.

4. Структура страниц и контентная модель

Раздел со страницами должен описывать не только карту сайта, но и типы шаблонов. Например: главная, услуга, кейс, статья, категория блога, страница отрасли, FAQ, контакты, политика, 404, личный кабинет, профиль, список заявок, карточка заявки, админка. Для каждого шаблона важно указать назначение, основные блоки, обязательные и опциональные поля, SEO-поля, медиа, состояния и связи с другими сущностями. Тогда команда проектирует систему, а не набор отдельных экранов.

Контентная модель особенно важна для сайтов, которые будут развиваться. Если услуги, кейсы, статьи и FAQ связаны между собой, это нужно заложить в ТЗ. Услуга может иметь связанные кейсы, статьи и вопросы. Кейс может иметь отрасль, стек, метрики и ссылку на услугу. Статья может ссылаться на услуги и другие материалы. Такая модель помогает SEO, навигации, редакционному процессу и будущей админке. Без неё каждая новая страница собирается вручную и быстро становится источником дублей.

• Шаблон страницы: цель, аудитория, блоки, данные, CTA, SEO, аналитика, состояния, права редактирования.
• Для каждого блока укажите, является он обязательным, опциональным или условным.
• Опишите правила изображений: размеры, форматы, alt, кадрирование, заглушки и источники.
• Сразу включите служебные страницы: 404, 500, поиск, пустые состояния, политика конфиденциальности, cookies.

5. Модель данных: сущности, поля и статусы

Для портала, личного кабинета или сайта с админкой ТЗ должно описывать сущности. Сущность — это объект, с которым работает система: пользователь, организация, заявка, заказ, счёт, платёж, документ, тариф, услуга, статья, кейс, уведомление, тикет. Для каждой сущности нужны поля, типы данных, обязательность, уникальность, связи, статусы, история изменений и правила удаления. Это основа backend, API, админки, прав доступа и тестирования.

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

Модель данных — это место, где бизнес-процесс становится инженерной системой. Чем яснее она описана, тем меньше переделок в backend и админке.

6. API и интеграции: контракты до разработки

Если сайт должен отправлять заявки в CRM, создавать счета, принимать платежи, синхронизировать товары, получать статусы из ERP или отправлять документы, интеграции должны быть отдельным разделом ТЗ. Нельзя писать просто подключить CRM. Нужно указать систему, владельца, окружения, метод обмена, формат данных, частоту, авторизацию, обработку ошибок, ретраи, idempotency, логирование, тестовые аккаунты и ответственных за внешнюю сторону. Интеграции чаще всего ломают сроки, когда зависят от неопределённого API или недоступной команды партнёра.

API-контракт должен быть понятен обеим сторонам. Для каждого endpoint или webhook опишите назначение, метод, URL, авторизацию, request, response, коды ошибок, ограничения, таймауты и пример данных. Если API ещё не существует, ТЗ должно зафиксировать, кто его проектирует и в каком формате согласуется контракт. Для критичных операций — платежи, документы, статусы заказов — обязательно описывайте повторную отправку, защиту от дублей и сценарий восстановления после сбоя.

• Шаблон интеграции: система, владелец, цель, данные, направление обмена, частота, авторизация, ошибки, тестовый стенд.
• Шаблон API: endpoint, method, auth, request schema, response schema, status codes, limits, examples.
• Для webhook укажите подпись, секреты, повторную доставку, дедупликацию и максимальное время обработки.
• Для файлового обмена укажите формат, кодировку, расписание, место хранения, архив и обработку битых файлов.

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

Нефункциональные требования описывают не то, что система делает, а как хорошо она это делает. Для сайта это скорость загрузки, адаптивность, доступность, SEO-готовность, стабильность форм, устойчивость к ошибкам внешних систем, резервное копирование, мониторинг, поддерживаемость и требования к окружениям. Если NFR не зафиксированы, они всплывают в виде субъективных претензий: сайт медленный, форма иногда не работает, админка неудобная, на мобильном плохо, непонятно как откатить релиз.

Формулировки должны быть проверяемыми. Вместо сайт должен быстро загружаться напишите: ключевые публичные страницы должны проходить согласованные пороги Lighthouse или Core Web Vitals на mobile; изображения оптимизируются; критичные сценарии работают при недоступности CRM с сохранением заявки в очереди; production имеет мониторинг 5xx; резервные копии создаются ежедневно; админка поддерживает последние версии основных браузеров. Проверяемость превращает ожидания в критерии приёмки.

• Performance: пороги LCP, CLS, INP или Lighthouse для главной, услуги, статьи и формы.
• Accessibility: клавиатурная навигация, контраст, alt, focus states, корректные labels для форм.
• Reliability: uptime, мониторинг ошибок, резервные копии, откат релиза, обработка недоступных интеграций.
• Maintainability: документация, структура проекта, правила окружений, переменные, инструкция релиза.

NFR лучше согласовать до дизайна и разработки. Иначе качество станет предметом вкуса, а не инженерной проверки.

8. Безопасность и персональные данные

Безопасность в ТЗ нужна даже для обычного корпоративного сайта, если на нём есть формы, cookies, аналитика, файлы, админка или интеграции. Минимально нужно описать, какие персональные данные собираются, зачем, где хранятся, кто имеет доступ, как пользователь даёт согласие, как данные передаются в CRM или почту, сколько хранятся и как удаляются. Для портала добавляются роли, права, журнал действий, требования к паролям, сессиям, двухфакторной аутентификации, защита API и ограничения по IP или устройствам.

ТЗ не обязано быть полноценной моделью угроз, но должно зафиксировать базовые ожидания: HTTPS, secure cookies, защита от CSRF для мутаций, rate limiting для форм и API, валидация файлов, ограничение размеров загрузки, хранение секретов вне репозитория, отсутствие персональных данных в логах, резервное копирование, разграничение доступов и регулярные обновления зависимостей. Если проект связан с оплатами или чувствительными данными, добавьте аудит безопасности или отдельный security review перед релизом.

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

9. SEO, аналитика и измерение результата

SEO-раздел ТЗ должен появляться до разработки шаблонов. Укажите индексируемые типы страниц, правила URL, canonical, robots.txt, sitemap.xml, hreflang для локалей, schema.org, open graph, хлебные крошки, требования к заголовкам, шаблонам title и description, редиректам и миграции старых URL. Для сайта с блогом или услугами добавьте правила внутренней перелинковки и обязательные поля контента. Для портала отдельно опишите, какие закрытые страницы не должны индексироваться.

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

• SEO-шаблон: URL, title, description, H1, canonical, robots, schema.org, breadcrumbs, open graph, alt.
• Миграция: инвентаризация старых URL, карта 301, проверка staging, контроль индексации после релиза.
• Аналитика: список событий, параметры, цели, воронки, доступы, тестирование и правила именования.
• Отчётность: какие метрики смотрим через неделю, месяц и квартал после запуска.

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

10. Админка, контент и операционные процессы

Если контент будет обновляться регулярно, ТЗ должно описывать не только публичную часть, но и процесс управления. Кто создаёт статьи, кто публикует услуги, кто редактирует SEO-поля, кто загружает изображения, кто видит заявки, кто меняет статусы, кто экспортирует отчёты. Для простого сайта это может быть data-driven подход или headless CMS. Для портала нужна полноценная админка с ролями, фильтрами, поиском, логами и безопасным редактированием.

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

• Шаблон админки: роли, разделы, CRUD-действия, фильтры, поиск, импорт, экспорт, история изменений.
• Шаблон контента: владелец, источник, статус готовности, локали, медиа, юридическая проверка.
• Для публикации добавьте статусы: черновик, на проверке, опубликовано, архив, требует перевода.
• Для заявок добавьте операционные правила: кто получает, как быстро отвечает, где меняется статус.

11. Приёмка, тестирование и Definition of Done

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

Definition of Done полезно разделить на уровни: задача, страница, сценарий, релиз. Задача готова, если код реализован, проверен, задокументирован при необходимости и не ломает тесты. Страница готова, если есть контент, адаптив, SEO, состояния и аналитика. Сценарий готов, если проходит happy path и альтернативные потоки. Релиз готов, если staging принят, миграции выполнены, мониторинг включён, есть план отката и ответственные на окно запуска.

• Шаблон критерия: Дано... Когда... Тогда... Проверяется на... Принимает...
• Список тестов: функциональные, адаптив, кроссбраузер, формы, интеграции, безопасность, SEO, аналитика.
• Блокеры релиза: неработающая форма, потеря заявки, ошибка оплаты, открытая админка, noindex на production.
• После релиза: smoke-тест, проверка логов, аналитики, Search Console, заявок и уведомлений.

Приёмка без критериев почти всегда превращается в субъективное ощущение готовности. Критерии делают запуск спокойнее для всех участников.

12. Как использовать этот шаблон на практике

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

Лучший формат работы — начать с черновика, пройти его вместе с бизнесом, дизайнером, tech lead, SEO-специалистом и ответственным за эксплуатацию, затем отметить неизвестные места. Неизвестность не делает ТЗ плохим, если она явно выделена. Например: API CRM требует уточнения, контент по английской версии будет готов после дизайна, требования к SLA согласуются перед релизом. Такие пометки честнее, чем фиктивная точность. После discovery документ можно обновить и использовать как основу договора, backlog и тест-плана.

• Для лендинга: цель, аудитория, структура, контент, формы, SEO, аналитика, адаптив, приёмка.
• Для корпоративного сайта: добавьте шаблоны страниц, контентную модель, миграцию, роли редакторов и поддержку.
• Для портала: добавьте user stories, данные, статусы, API, интеграции, безопасность, NFR и SLA.
• Для тендера: используйте ТЗ как основу RFP, чтобы подрядчики оценивали один и тот же объём.

Enginx.ru может подготовить ТЗ как отдельный discovery-этап или собрать его вместе с дизайном и разработкой: так проект стартует с понятными границами, рисками и критериями результата.