Документ нужен, чтобы люди одинаково поняли изменение и через полгода могли вспомнить, почему решили именно так. Объём документа подбирают под проект: стартапу хватит страницы в Confluence, банку для регулятора нужен полный комплект.
Vision and Scope
Документ видения и границ, обычно первый. Отвечает на вопросы:
- какая проблема или возможность, почему сейчас;
- бизнес-цели и метрики успеха;
- кто стейкхолдеры и пользователи;
- что входит в объём, что явно не входит;
- ключевые ограничения, допущения, риски.
Короткий, на 3-7 страниц. Его утверждает спонсор, и дальше на него ссылаются при спорах о границах.
BRD
Business Requirements Document, документ бизнес-требований. Типичная структура:
- Введение и цель документа.
- Бизнес-контекст и проблема.
- Бизнес-цели (SMART) и метрики.
- Объём: в рамках и вне рамок.
- Стейкхолдеры.
- Текущий процесс (AS-IS) и целевой (TO-BE).
- Бизнес-требования и требования стейкхолдеров.
- Бизнес-правила.
- Нефункциональные ожидания бизнеса (доступность, объёмы, сроки обработки).
- Допущения, ограничения, зависимости, риски.
- Глоссарий.
- Лист согласования и история изменений.
BRD отличается от SRS (спецификации требований к ПО): BRD про «что нужно бизнесу», SRS про «что делает система». SRS обычно пишет системный аналитик.
Глоссарий
Словарь терминов проекта. Звучит скучно, но спасает: в одной компании «клиент» у продаж это компания, у поддержки это человек, у биллинга это лицевой счёт. Для каждого термина: определение, синонимы, чем не является, пример. Глоссарий начинают с первой встречи.
В agile-командах
Вместо толстого BRD: Vision, карта историй (user story map), эпики и истории в бэклоге с критериями приёмки, живая wiki с моделями процессов и решениями. Документации меньше, но она не исчезает: решения и границы всё равно нужно зафиксировать.
Журнал решений и допущений
Записывайте решения: что решили, почему, кто, когда, какие альтернативы отвергли. Через полгода это единственный способ ответить на вопрос «а почему так сделали?». Допущения («считаем, что 80% клиентов пользуются приложением») тоже фиксируют и проверяют.
Управление изменениями требований
Требования меняются, это нормально. Плохо, когда они меняются незаметно.
- Запрос на изменение: кто, что, зачем.
- Анализ влияния: какие требования, процессы, сроки, бюджет затронуты. Здесь помогает трассировка.
- Решение: принимает владелец объёма (спонсор, комитет изменений, владелец продукта).
- Обновление документов и базовой версии требований.
- Информирование всех затронутых.
Базовая линия (baseline) это утверждённая версия требований, от которой считают изменения.
Хороший документ
- Написан для читателя: руководителю резюме на первой странице, разработчику детали.
- Однозначные формулировки, термины из глоссария.
- Схемы вместо длинных абзацев о процессе.
- Версия, статус, история изменений.
- Ссылки, а не копии: одно место правды.
Частые ошибки
- Документ ради документа, который никто не читает.
- Нет раздела «вне рамок», и спор о границах в конце проекта.
- Термины без глоссария.
- Изменения в письмах и чатах, а документ устарел.
- Решения без причин.
Что спросят на собесе
- Какие документы вы писали, их структура.
- Чем BRD отличается от SRS и Vision.
- Зачем глоссарий.
- Как управлять изменениями требований.
- Как документируете в agile-команде.