Изменение требований: Change Request и Impact Analysis

Требования меняются почти всегда: меняется бизнес, появляются новые данные, находятся неточности. Проблема не в самом изменении, а в том, что его вносят на ходу без оценки последствий: работа остаётся прежней по объёму, но уходит в неожиданные места.

Кейс: «просто добавить причину отмены»

Владелец «Узелка» просит добавить при отмене заказа одно поле: покупатель выбирает причину отмены. На словах это пара минут. На деле нужно новое поле на экране, новое поле в API, новая колонка в базе, изменённые письма, новые тесты и обновлённые документы. Если взять это в работу «на ходу», вторая команда узнает об изменении на тестах, когда они падают.

Дальше разберём, как строить такой разговор: с запросом, оценкой и решением.

Уточнение или изменение

Не каждая правка требует запроса. Различие такое:

Уточнение - требование становится яснее, а то, что уже обещано и принято, не меняется. Пример: заменили «быстро» на «не дольше двух секунд» по уже согласованному смыслу.
Изменение - меняется то, на что уже согласились: поведение, объём, срок или стоимость. Пример: появилось новое поле причины отмены.

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

Рисунок 1. Уточнение или изменение

Запрос на изменение

Запрос на изменение (Change Request) - это карточка, в которой изменение описано так, чтобы по ней можно было принять решение. Минимальный состав:

Номер и автор: по нему запрос можно найти и знать, кто его подал.
Что меняем: было и стало.
Зачем: причина изменения, иначе нельзя взвесить пользу.
Срочность: обычная или надо сделать раньше.
Влияние: результат анализа, о котором ниже.
Решение: принять, отклонить или отложить, кто решил и когда.

Рисунок 2. Карточка запроса на изменение: номер, суть, причина, срочность, влияние и решение

Impact Analysis: что ещё затронет изменение

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

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

Интерфейс. Новое поле на экране, макет и тексты ошибок.
API. Новое поле в запросе и ответе, обратная совместимость для старых клиентов.
База данных. Новая колонка и значение для старых заказов.
Письма и документы. Текст письма об отмене, описание в требованиях и инструкциях поддержки.
Тесты. Новые проверки и правка старых.
Пользователи. Что увидит покупатель и как ему об этом сообщат.

Рисунок 3. Одно изменение и шесть областей, на которые оно влияет

После областей считают трудоёмкость, срок и риск: нужны ли работы по старым заказам, сдвинет ли изменение релиз. Чтобы не искать затронутое вручную, требования связывают с макетами, API и тестами: это называется трассировкой (статья 02-22). Трассировка значительно ускоряет поиск затронутых элементов.

Как принимается решение

Результаты анализа отдают тому, кто решает. В крупных проектах это совет по изменениям (CCB), в небольших владелец продукта. Решений три: принять, отклонить, отложить. Пропуск анализа не уменьшает объём работы, но превращает его в сюрприз.

Рисунок 4. Три решения и одна запись

Решение записывают в запросе и в журнале решений (статья 08-04): так через месяц видно, почему поле появилось или не появилось. После принятия решения обновляют всё, что найдено анализом: требования, макет, описание API, тесты.

Рисунок 5. Четыре шага: запрос, анализ, решение, обновление

Где это встречается в работе

Просьба «просто добавить поле» после согласования макета (статья 02-15).
Изменение бизнес-правила, например срока возврата (статья 02-11).
Изменение контракта API и влияние на старых клиентов.
Миграция данных при добавлении нового обязательного поля.
Планирование релиза, когда изменение приходит в середине спринта.

Итог

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

Что дальше

Дальше разберём трассировку требований (статья 02-22), которая делает анализ влияния быстрее, и журнал решений (статья 08-04).