Как написать ТЗ и критерии приёмки, чтобы не спорить в конце проекта

Начните с результата, а не технологии

Вместо «разработать систему с микросервисной архитектурой и AI»:

Менеджер обрабатывает входящую заявку из формы и Telegram в одной очереди, не создаёт дубликат при повторной отправке и видит источник обращения. Руководитель измеряет время до первого ответа.

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

Минимальная структура рабочего ТЗ

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

Как процесс работает сейчас, что не устраивает, кто владелец, какой baseline и какой результат нужен.

2. Scope и out of scope

Что входит в первую поставку и чего там сознательно нет. Out of scope защищает обе стороны лучше, чем фраза «и другие функции по необходимости».

3. Пользователи и роли

Не просто «администратор» и «пользователь», а разрешённые ресурсы и действия. Для каждого сценария укажите, от чьего имени он выполняется.

4. Сценарии

Триггер, предусловия, основной поток, исключения, итоговое состояние. GOV.UK предлагает user story как короткую формулировку потребности пользователя, но сама story не заменяет acceptance criteria.

5. Данные

Источник, владелец, формат, качество, сроки хранения, миграция, удаление и права. Для AI — какие данные разрешено передавать модели и использовать в eval.

6. Интеграции

API, версия, sandbox, лимиты, аутентификация, timeout, retry, idempotency и поведение при недоступности.

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

Доступность, latency, объём, безопасность, accessibility, аудит, backup, RTO/RPO, поддерживаемые браузеры и устройства.

8. Приёмка и эксплуатация

Тестовые данные, среда, ответственные, доказательства, Definition of Done, обучение, документация, гарантия и SLA.

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

Как писать acceptance criteria

Критерий должен давать наблюдаемый pass/fail.

Плохо:

Система быстро отправляет уведомление и корректно обрабатывает ошибки.

Лучше:

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

В хорошем критерии есть условие, действие, измеримый результат и поведение при сбое. Указанные 60 секунд и сохранение в очереди — пример требований для согласования, а не описание каждого проекта CENTURY.

Не забудьте негативные критерии

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

• Пользователь роли A не видит записи роли B.
• Файл запрещённого типа не попадает в рабочее хранилище.
• Повтор платежного callback не меняет баланс дважды.
• Агент не отправляет письмо без подтверждения.
• RAG не использует документ после отзыва права.
• Ошибка API не раскрывает stack trace и секрет.

Definition of Done шире acceptance criteria

Acceptance criteria относятся к конкретной функции. Definition of Done — общий gate для любого элемента: review, тесты, документация, security checks, deployability, monitoring и отсутствие известных критических дефектов.

В DoD можно включить:

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

Важно разделять доказательства: локальные тесты, CI, staging, deployment и live-проверка — разные этапы. Один не подменяет другой.

Как принимать AI-функцию

Фраза «ответ должен быть точным» не проверяется. Нужен versioned eval-набор:

• реальные типы задач;
• ожидаемые источники;
• допустимый отказ;
• запрещённые tool calls;
• роли пользователей;
• rubrics качества;
• бюджеты latency и стоимости.

Общий score не должен компенсировать утечку права или критическое действие. Такие ошибки — отдельный blocker.

Изменения — часть ТЗ

Требования изменятся. Зафиксируйте процесс:

1. кто предлагает изменение;
2. как оценивается влияние на срок, цену и риски;
3. кто принимает решение;
4. какая версия требований становится активной;
5. что происходит с уже выполненной работой.

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

Гарантия, поддержка и развитие

Разделите три понятия до подписания акта.

Гарантия: исправление поведения, которое не соответствует утверждённым требованиям и критериям.

Поддержка: реакция на инциденты, мониторинг, восстановление и согласованные операционные работы по SLA.

Развитие: новые сценарии и изменение требований.

В SLA укажите часы, каналы, уровни критичности, время реакции/восстановления, исключения, эскалацию и отчётность. Не обещайте 24/7, если дежурной команды нет.

Приёмочный пакет

К финалу этапа заказчик получает не только интерфейс:

• ссылку на версию требований;
• release notes;
• результаты acceptance и security checks;
• известные ограничения;
• инструкции запуска и rollback;
• схему данных и интеграций;
• доступы в согласованных владельцах;
• monitoring/support runbook;
• экспорт или миграционный пакет, если он входит в этап.

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

Последняя проверка перед стартом

Дайте ТЗ человеку, который не участвовал во встречах, и попросите ответить:

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

Если ответы приходится восстанавливать из переписки, ТЗ ещё не готово. Исправить это до разработки дешевле, чем в последнюю неделю проекта.