☀Объяснение:

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

Что такое процесс управления изменениями (Change Request)?
Это формальная процедура, которая состоит из шагов:

Запрос на изменение (Change Request, CR) – любой стейкхолдер заполняет форму: описывает изменение, обоснование (почему это важно), ожидаемую бизнес-ценность.

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

Рассмотрение на Change Control Board (CCB) – встреча с участием заказчика, продукт-оунера, технического лида. Принимается решение: принять, отклонить, отложить. Если принимается, то определяется, за счёт каких задач это будет сделано (вытеснение других задач, сдвиг сроков).
Коммуникация – решение доводится до всей команды, обновляются требования и бэклог.
Реализация – изменение попадает в разработку уже с понятным приоритетом.

Почему остальные варианты не решают проблему?
A (фиксировать в протоколе) – полезно, но не даёт оценки трудозатрат и приоритизации. Команда всё равно вынуждена реагировать на каждое изменение «по факту».
C (еженедельный пересмотр приоритетов) – хорошая практика, но без формального CR изменения могут быть неполными, неоценёнными или незадокументированными.
D (матрица трассируемости) – помогает понять, какие артефакты связаны с требованием, но не управляет потоком изменений.

Реальный кейс из практики:
В одном проекте по разработке CRM для сети салонов связи изменения поступали ежедневно. Аналитик просто передавал их в бэклог, команда хваталась за то, что «горело». В результате через месяц половина фич была недоделана, а релиз сдвинулся на три недели. Ввели Change Request Board из трёх человек (заказчик, аналитик, тимлид). Заказчик заполнял CR-форму (описание, ценность). На ежедневной 15-минутной встрече оценивали влияние. Если оценка превышала 8 часов, вопрос выносили на еженедельное заседание. Через месяц количество несогласованных правок сократилось на 80%, а команда стала прогнозировать сроки.

Что должен зафиксировать аналитик:
В регламенте проекта: «Любое изменение требований после утверждения бэклога оформляется через Change Request и проходит оценку».
Форма CR должна содержать поля: автор, описание, обоснование (ожидаемый эффект), приоритет для бизнеса.
Порог принятия: например, изменения до 4 часов может утвердить PO, более 4 часов – CCB.

Вывод: Управление изменениями – это не бюрократия, а способ сохранить предсказуемость разработки и снизить хаос. Аналитик выступает не врагом изменений, а их фильтром и координатором.