Change request в разработке: как работают изменения scope

Change request - это согласованный запрос на изменение проекта: объема работ, сроков, бюджета, критериев результата или состава поставки. Он нужен не для бюрократии, а для управляемости: участники видят, что именно меняется, почему это важно, как изменение влияет на проект и кто принял решение.

Не каждое уточнение является change request. Но новое требование, расширение scope или изменение уже согласованного результата должно проходить через отдельное решение.

Change request нужен, когда запрос выходит за рамки уже согласованного объема.

Типовые ситуации:

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

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

Не каждый вопрос или комментарий заказчика должен превращаться в change request.

Обычно change request не нужен, если:

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

Главный вопрос простой: меняется ли обещанный результат или объем работ. Если да, нужен отдельный разбор.

В проектах часто смешивают три разные ситуации.

Исправление - это доведение результата до согласованного критерия. Например, кнопка должна сохранять заявку, но не сохраняет.

Уточнение - это детализация уже согласованного поведения. Например, нужно уточнить текст статуса или порядок сортировки в таблице.

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

Change request обычно нужен для нового требования или существенного изменения согласованного поведения.

Перед решением по change request нужно понять несколько вещей:

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

Иногда правильное решение - не принимать изменение сразу, а добавить его в backlog будущих работ. Это нормально, если текущий этап должен завершиться в согласованных границах.

• Считать любое уточнение платным изменением.
• Считать любое новое пожелание частью текущего бюджета.
• Запускать работу до оценки влияния.
• Не фиксировать, кто принял решение.
• Смешивать дефекты, уточнения и новые требования.
• Не обновлять план, если change request принят.
• Копить изменения устно и вспоминать о них на приемке.

В MVP личного кабинета согласован сценарий: дилер создает заявку, менеджер видит ее в очереди и меняет статус.

Во время разработки появляется запрос: добавить автоматическое согласование заявки с финансовым отделом, если сумма больше порога.

Это не просто уточнение. Появляется новая роль, новое правило, дополнительные статусы и, возможно, новая интеграция. Такой запрос нужно оформить как change request: описать изменение, оценить влияние, решить, включать его в текущий этап или вынести в следующий релиз.

Чем change request отличается от дефекта?

Дефект - это несоответствие согласованному результату. Change request - это изменение самого согласованного результата или объема работ.

Нужно ли оформлять маленькие изменения?

Если изменение не влияет на сроки, бюджет и критерии результата, достаточно зафиксировать его в задаче или backlog. Если влияние есть, нужен отдельный разбор.

Кто принимает решение по change request?

Решение должен принимать человек или группа, которые отвечают за scope, бюджет и приоритеты проекта. Это стоит назвать заранее.

Что делать, если изменение срочное?

Срочность не отменяет оценки влияния. Можно быстро принять решение, но все равно нужно зафиксировать, что меняется и на что это влияет.

Как change request связан с backlog?

Backlog хранит возможные работы и идеи. Change request нужен, когда часть backlog предлагается включить в текущий согласованный объем или изменить уже согласованный результат.

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