Почему красивое ТЗ может быть бесполезным
Большая языковая модель легко создаёт документ с десятками разделов. Но объём не означает определённость. Если исходный бриф не содержит ролей, правил, исключений и ограничений, ИИ заполнит пробелы правдоподобными предположениями. Команда получит ложную точность, а спор проявится уже во время разработки.
Хорошее ТЗ уменьшает пространство разных трактовок. Оно не обязано предсказывать каждую техническую деталь, но должно объяснять ценность, границы, поведение и способ проверки результата.
Роль ИИ: интервьюер, редактор и критик
Владелец продукта подтверждает факты и приоритеты, дизайнер - пользовательский путь, разработчик - реализуемость, безопасность и зависимости, тестировщик - проверяемость. ИИ не заменяет эти роли.
Паспорт требования: откуда оно появилось
У каждого существенного требования должен быть источник. Это помогает разрешить конфликт и понять, что можно изменить.
| Тип | Пример | Кто подтверждает |
|---|---|---|
| Факт | Платёжный провайдер присылает webhook | Документация или владелец интеграции |
| Бизнес-решение | Возврат доступен 14 дней | Владелец продукта и юрист |
| Гипотеза | Пользователю нужна регистрация по телефону | Исследование или эксперимент |
| Ограничение | Использовать существующую CRM | Архитектор или заказчик |
| Вопрос | Что делать при повторном webhook | Назначенный владелец и срок |
Предположение модели всегда остаётся вопросом или гипотезой, пока человек или первичный источник его не подтвердил.
Бриф до написания ТЗ
- Какую проблему и для кого решает проект.
- Как процесс работает сейчас и где возникает потеря.
- Какой измеримый результат нужен бизнесу.
- Какие роли взаимодействуют с системой.
- Какие данные поступают и откуда.
- Какие системы и подрядчики участвуют.
- Какие правила уже утверждены.
- Какие сроки, бюджет и технологии ограничивают решение.
- Что точно не входит в первую версию.
- Кто принимает решения и результат.
Промпт-интервью для сбора требований
Ты - бизнес-аналитик. Помоги собрать требования, но не придумывай ответы. Контекст: [идея и текущий процесс] Цель: [бизнес-результат] Участники: [роли] Ограничения: [известное] Проведи интервью блоками: пользователи; текущий сценарий; данные; бизнес-правила; исключения; интеграции; безопасность; доступность; метрики; границы первой версии. Задавай до 5 вопросов за один раунд. После каждого раунда обновляй реестр: - подтверждённые факты; - принятые решения; - гипотезы; - открытые вопросы с владельцем; - противоречия. Не заполняй пробелы общепринятой практикой без маркировки.
Цель и метрика результата
«Сделать личный кабинет» - описание объекта, а не цель. Цель связывает проблему с измеримым изменением: например, клиент самостоятельно получает документ, а поддержка видит меньше обращений определённого типа.
Разделяйте бизнес-метрику и продуктовую. Снижение обращений зависит не только от интерфейса; доля успешных самостоятельных скачиваний ближе к поведению продукта. Для метрики укажите источник, исходное значение, период, сегмент и допустимые побочные эффекты.
Границы: in scope и out of scope
Большинство конфликтов рождается не в описанном, а в подразумеваемом. Явно запишите, какие роли, платформы, интеграции, языки, типы данных и исключения входят в релиз.
Проведи аудит границ проекта. Вход: [цель, сценарии и ограничения]. Составь таблицу: объект | входит в релиз | не входит | требует решения | причина | владелец. Проверь роли, web/mobile, браузеры, языки, страны, платежи, уведомления, админку, аналитику, миграцию, импорт/экспорт, интеграции, поддержку и эксплуатацию. Не переноси спорные пункты в «не входит» автоматически. Сформулируй вопрос и влияние на оценку.
User story: пользователь, цель и ценность
Atlassian описывает распространённый формат: «Как [пользователь], я хочу [цель], чтобы [ценность]». История удерживает внимание на результате, но не заменяет бизнес-правила, макеты и критерии приёмки.
| Слабая история | Почему | Улучшение |
|---|---|---|
| Как пользователь, хочу кнопку | Неясны роль и ценность | Назвать роль и результат |
| Как система, хочу PostgreSQL | Это решение реализации | Вынести в ограничение архитектуры |
| Как админ, хочу управлять всем | Нет границ полномочий | Разделить по операциям и объектам |
| Как клиент, хочу быстро | Непроверяемое слово | Задать действие и порог времени |
Карта пользовательского пути
Отдельные истории могут быть правильными, но не складываться в целый путь. Для каждого ключевого сценария опишите триггер, предварительные условия, шаги, результат, ошибки и продолжение.
- Как человек понимает, что функция существует.
- Какие права и данные нужны до старта.
- Что является первым действием.
- Что система проверяет и где сообщает ошибку.
- Как пользователь видит успешный результат.
- Можно ли отменить, повторить или исправить действие.
- Что получают другие роли и внешние системы.
- Где остаётся журнал и как работает поддержка.
Критерии приёмки: условия, а не инструкция реализации
Критерии приёмки определяют условия, при которых история или инкремент считаются выполненными. Они должны быть ясными, измеримыми и проверяемыми. Не подменяйте наблюдаемый результат внутренней реализацией без архитектурной причины.
- Связан с одной историей или бизнес-правилом.
- Описывает наблюдаемое поведение.
- Имеет конкретные входные условия.
- Содержит ожидаемый результат.
- Не использует «удобно», «быстро», «корректно» без метрики.
- Покрывает права доступа.
- Учитывает ошибку и восстановление.
- Может быть проверен до сдачи.
Given - When - Then на практическом примере
В Gherkin Given задаёт известное начальное состояние, When - событие, Then - наблюдаемый результат. Cucumber рекомендует держать пример выразительным и не перегружать его деталями интерфейса.
История: Как клиент, я хочу скачать оплаченный счёт, чтобы передать его бухгалтерии. Сценарий: доступ к своему счёту Дано клиент вошёл в аккаунт И счёт принадлежит этому клиенту Когда клиент запрашивает PDF Тогда система отдаёт файл с номером и суммой счёта И событие скачивания появляется в журнале Сценарий: попытка доступа к чужому счёту Дано клиент вошёл в аккаунт И счёт принадлежит другой организации Когда клиент запрашивает PDF Тогда система не раскрывает файл и его реквизиты И возвращает согласованный безопасный ответ И фиксирует отказ в журнале безопасности
Промпт для генерации критериев и негативных сценариев
На основе подтверждённой user story и бизнес-правил предложи критерии приёмки. История: [текст] Правила: [список] Роли и права: [матрица] Сначала перечисли отсутствующие данные. Затем создай сценарии Given - When - Then: основной, пустое состояние, неверный ввод, отсутствие прав, повторная операция, конкурентное изменение, недоступная интеграция и восстановление. Каждый Then должен быть наблюдаемым и проверяемым. Не придумывай текст ошибок, сроки и бизнес-правила - помечай «требует решения». Отдельно предложи нефункциональные проверки, не смешивая их с поведением.
Нефункциональные требования с метрикой
«Сайт должен быть быстрым и безопасным» невозможно принять. Требование задаёт объект измерения, условия, инструмент или метод и порог.
| Область | Что определить | Неопределённая формулировка |
|---|---|---|
| Производительность | Операция, нагрузка, перцентиль, среда, порог | Страница открывается быстро |
| Надёжность | SLO, окно, исключения, восстановление | Всегда доступно |
| Безопасность | Уровень контроля и проверяемые требования | Защищено от хакеров |
| Доступность | Версия WCAG, уровень и область | Доступно всем |
| Совместимость | Браузеры, версии, устройства | Работает везде |
| Хранение | Срок, регион, удаление, резервные копии | Данные хранятся безопасно |
Безопасность и доступность в ТЗ
OWASP ASVS предоставляет открытый набор проверяемых требований безопасности веб-приложений и может использоваться при разработке и закупке. Выбирайте применимые требования и версию, а не вставляйте название стандарта без области и проверки.
Для web-интерфейсов W3C WCAG 2.2 задаёт рекомендации доступности. В ТЗ укажите целевой уровень, страницы и компоненты, исключения, способ тестирования и ответственность. Соответствие стандарту не отменяет тесты с реальными пользователями и локальные правовые требования.
Данные и интеграции
- Источник истины для каждой сущности.
- Поля, форматы, обязательность и справочники.
- Кто создаёт, читает, меняет и удаляет данные.
- Основание, согласие и срок хранения персональных данных.
- Идентификаторы и правила дедупликации.
- API, авторизация, лимиты и версии интеграций.
- Повторные запросы, идемпотентность и порядок событий.
- Таймауты, retry, очередь ошибок и ручное восстановление.
- Миграция, сверка полноты и план отката.
- Журналы без лишних секретов и персональных данных.
Макеты и состояния интерфейса
Один идеальный экран не описывает продукт. Для формы нужны пустое состояние, заполнение, валидация, загрузка, успех, частичный успех, ошибка, повтор, отсутствие прав и истёкшая сессия. Для списка - отсутствие данных, пагинация, фильтры, сортировка и большие значения.
ТЗ не обязано дублировать каждый пиксель макета. Свяжите требование, story, экран и критерии устойчивыми идентификаторами. Укажите, что является источником истины при конфликте текста и дизайна.
Definition of Done и приёмка проекта
Acceptance criteria относятся к конкретной истории. Definition of Done - общий стандарт качества для всех работ команды: код проверен, тесты пройдены, документация обновлена, мониторинг настроен, миграция проверена. Не смешивайте эти уровни.
Составь протокол приёмки релиза на основе ТЗ. Для каждого требования укажи: ID | сценарий проверки | тестовые данные | ожидаемый результат | доказательство | ответственный | статус. Отдельные разделы: функциональные истории; безопасность; доступность; производительность; интеграции; миграция; аналитика; мониторинг; резервное копирование; откат; документация и обучение. Не отмечай пункт выполненным по факту наличия функции. Требуй воспроизводимое доказательство или явно согласованное исключение.
Как оценивать проект по ТЗ
Точная стоимость при открытых интеграциях и правилах - иллюзия. До оценки разделите подтверждённый объём, опции, неизвестное и рисковые исследования. Команда должна указать предположения, а заказчик - подтвердить их.
- Декомпозировать по пользовательским сценариям, а не экранам.
- Выделить внешние зависимости и ожидание доступов.
- Провести spike для технически неизвестного.
- Отдельно оценить данные, миграцию, безопасность и эксплуатацию.
- Зафиксировать, что меняет стоимость и срок.
- Определить процесс change request после утверждения границ.
Структура полного технического задания
# Техническое задание 1. Паспорт документа: версия, дата, владельцы, статус. 2. Контекст, проблема, цель и метрики. 3. Термины и источники требований. 4. Пользователи, роли и права. 5. Текущий и целевой процессы. 6. Границы: входит / не входит. 7. Пользовательские сценарии и user stories. 8. Бизнес-правила и таблицы решений. 9. Критерии приёмки и негативные сценарии. 10. Данные, модель, хранение и удаление. 11. Интеграции, ошибки и восстановление. 12. Нефункциональные требования. 13. Безопасность и приватность. 14. Доступность и совместимость. 15. Аналитика, логи и мониторинг. 16. Миграция, запуск и откат. 17. Документация и эксплуатация. 18. Зависимости, риски и открытые вопросы. 19. Протокол приёмки и Definition of Done. 20. История решений и изменений.
Финальный чек-лист перед передачей разработчику
- Цель связана с измеримым результатом.
- Роли и права определены.
- Термины используются однозначно.
- Границы первой версии явны.
- Факты отделены от гипотез ИИ.
- Основные и негативные сценарии описаны.
- Критерии приёмки наблюдаемы.
- Нефункциональные требования имеют метрику и порог.
- Данные, интеграции и восстановление разобраны.
- Безопасность и доступность имеют проверяемую область.
- Миграция, мониторинг и откат включены.
- У открытых вопросов есть владельцы и сроки.
- История изменений сохраняется.
- Разработчик, тестировщик и заказчик провели совместный разбор.
ТЗ готово не тогда, когда нейросеть дописала последний раздел, а когда команда одинаково понимает результат и умеет доказать его готовность.