Как подготовить ТЗ на разработку сайта: требования, интеграции и приёмка

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

Плохое ТЗ перечисляет экраны: «главная, каталог, карточка, контакты». Хорошее объясняет, кто и зачем использует продукт, откуда приходят данные, что происходит в исключительных ситуациях и по каким признакам функция считается готовой.

Стандарт ISO/IEC/IEEE 29148 рассматривает requirements engineering как процесс выявления, анализа, проверки, документирования и управления требованиями на всём жизненном цикле. Для бизнеса ключевой вывод прост: требования не «пишутся один раз», а уточняются и трассируются от цели до реализации и теста.

1. Контекст и бизнес-цель

Начните не с цветовой палитры, а с причины проекта:

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

Формулировка «сделать современный сайт» непроверяема. Формулировка «увеличить долю заявок с мобильных устройств и дать маркетингу возможность самостоятельно создавать посадочные» задаёт направление архитектуре и приёмке.

2. Заинтересованные стороны и ответственность

Перечислите роли:

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

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

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

Описывайте не страницы, а задачи.

Пример сценария:

> Менеджер снабжения выбирает оборудование для ресторана, фильтрует товары по категории и бренду, добавляет позиции в подборку, отправляет запрос на расчёт и получает копию на email. Менеджер продаж видит источник, состав заявки и UTM-метки в CRM.

У сценария должны быть:

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

Для интернет-магазина отдельно описывают гостя, покупателя, менеджера, редактора каталога и администратора. Для B2B могут понадобиться роли закупщика, согласующего и финансового контролёра.

4. Функциональные требования

Каждое требование должно быть атомарным и проверяемым.

Плохо: «На сайте должен быть удобный поиск». Лучше: «Поиск находит товар по названию, артикулу и бренду; опечатка в одном символе не должна приводить к пустой выдаче; ответ для 95-го перцентиля — не более 700 мс при 100 одновременных пользователях».

Структура требования:

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

Приоритет удобно задавать по MoSCoW: Must, Should, Could, Won’t for now. Важно не превратить Must в список из 100% функций — иначе приоритизации нет.

5. Данные и интеграции

Это самый частый источник недооценки. Для каждой интеграции нужно зафиксировать:

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

Пример: остаток товара приходит из трёх складских систем. Недостаточно написать «синхронизировать остатки». Нужно определить приоритет источников, единицу измерения, резерв, статус «в пути», частоту пересчёта и поведение при недоступности одного API.

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

Именно они определяют качество эксплуатации.

Производительность

• ожидаемая аудитория и пики;
• время ответа API;
• максимальный вес первого экрана;
• целевые Core Web Vitals;
• допустимое время построения отчёта.

Надёжность

• целевая доступность;
• резервное копирование;
• RPO — сколько данных можно потерять;
• RTO — как быстро восстановиться;
• поведение при отказе внешнего сервиса.

Безопасность

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

OWASP ASVS можно использовать как основу проверяемых требований к безопасности веб-приложения. Для обычного корпоративного сайта набор будет меньше, для личного кабинета и платёжного контура — существенно шире.

Доступность

WCAG 2.2 рекомендует текстовые альтернативы, управление с клавиатуры, различимый контраст, видимый фокус, понятные ошибки и доступную аутентификацию. Даже если формальная сертификация не требуется, эти правила повышают общую удобность.

7. SEO-требования

SEO нельзя добавлять после разработки одной строкой «поставить метатеги». Зафиксируйте:

• редактируемые title, description, H1;
• человекопонятные URL;
• canonical;
• robots.txt и sitemap.xml;
• Open Graph;
• редиректы при миграции;
• шаблоны для фильтров и пагинации;
• хлебные крошки;
• schema.org;
• серверную доступность основного контента;
• alt и размеры изображений;
• карту старых и новых URL.

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

8. Аналитика как часть требований

Список событий создают до разработки:

События должны быть согласованы с CRM, чтобы аналитика не заканчивалась на отправке формы.

9. Контент и миграция

Укажите:

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

Для большого сайта полезна пробная миграция 3–5% данных. Она показывает качество исходников и реальные исключения до того, как ошибка масштабируется.

10. Критерии приёмки

Фраза «всё работает» создаёт конфликт. Приёмка должна быть воспроизводимой.

Формат Given–When–Then:

> Дано: товар доступен на двух складах. > Когда: пользователь добавляет количество, превышающее остаток первого склада. > Тогда: система рассчитывает суммарную доступность, показывает реальный срок и не разрешает заказать больше общего остатка.

Для каждого Must-требования нужен тест. Для ключевого сценария — end-to-end тест от входа до результата в CRM или учётной системе.

11. Управление изменениями

Проект почти всегда уточняется. Нужно заранее определить:

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

Это не бюрократия, а защита от ситуации, когда десять «маленьких правок» меняют архитектуру и срок.

Минимальный шаблон ТЗ

1. Цели и KPI.
2. Границы проекта.
3. Термины.
4. Пользователи и роли.
5. Сценарии.
6. Функциональные требования.
7. Данные и интеграции.
8. Производительность и надёжность.
9. Безопасность и персональные данные.
10. SEO и аналитика.
11. Контент и миграция.
12. Поддерживаемые устройства.
13. Критерии приёмки.
14. План запуска и отката.
15. Поддержка и права.

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

Пример требования к API

Вместо «интегрировать CRM» можно зафиксировать контракт:

• после успешной отправки формы backend создаёт лид не позднее чем за 10 секунд;
• повтор с тем же submission_id не создаёт дубль;
• при ответе CRM 429 или 5xx выполняются повторные попытки с увеличивающимся интервалом;
• после исчерпания попыток заявка сохраняется в очереди, а ответственному отправляется уведомление;
• в логах нет телефона и email в открытом виде;
• frontend получает нейтральное подтверждение, не раскрывающее внутреннюю ошибку;
• тест подтверждает доставку заявки после временного отказа CRM.

Такое требование связывает бизнес-риск потери лида с техническим поведением и проверкой.

План запуска и отката

ТЗ должно отвечать, что произойдёт в день релиза:

1. кто принимает решение о запуске;
2. когда замораживается контент;
3. как создаётся резервная копия;
4. как переключается домен;
5. кто проверяет формы, оплату и аналитику;
6. какие метрики наблюдаются первые часы;
7. при каких ошибках выполняется откат;
8. как возвращается предыдущая версия;
9. кто информирует пользователей и поддержку.

Для SEO-миграции в этот план входят карта 301-редиректов, проверка canonical, robots, sitemap и сохранение аналитических идентификаторов.

Как не превратить ТЗ в мёртвый документ

Храните требования рядом с backlog и решениями. После изменения прототипа обновляйте связанное требование и тест. Крупные решения фиксируйте в коротком журнале: дата, контекст, варианты, выбор и последствия. Тогда через полгода команда понимает не только что сделано, но и почему.