Change request и управление изменениями scope
Изменения неизбежны — хаос нет
В любом IT-проекте появляются новые пожелания: "добавьте отчёт", "переделайте интеграцию", "регулятор потребовал поле". Agile как раз допускает смену приоритетов. Проблема начинается, когда объём растёт тихо — в чатах, на демо, "пока вы тут" — а срок и бюджет остаются прежними. Это scope creep (незаметное расширение объёма).
Change management — набор правил, как обрабатывать запросы "сделайте ещё вот это" прозрачно: оценка влияния, решение PO или заказчика, при необходимости формальный change request (CR). В production критичных систем добавляется CAB (Change Advisory Board) — согласование релизов.
Договорённость — это формализованное взаимное обязательство между участниками проектной деятельности, устанавливающее конкретные условия выполнения задач, распределения ресурсов и ожидаемых результатов. Данный механизм обеспечивает синхронизацию ожиданий заказчика и исполнителя, создаёт надёжную основу для последующей реализации проектных инициатив и гарантирует однозначность трактовки утверждённых параметров.
ТЗ — это исходный проектный документ, фиксирующий функциональные и нефункциональные требования к разрабатываемой системе, архитектурные ограничения, критерии приёмки и условия поставки. Документ устанавливает чёткие границы ожидаемого результата, определяет технические параметры реализации и служит юридическим основанием для планирования работ, оценки трудозатрат и проведения итоговой приёмки продукта заказчиком.
Change request — это формализованный запрос на внесение модификаций в утверждённую проектную документацию, архитектуру или рабочий план, содержащий описание предлагаемых изменений, обоснование целесообразности, оценку рисков и расчёт необходимого ресурсного обеспечения. Документ проходит установленный процесс согласования, обеспечивая контролируемое внесение корректировок в текущий ход работ и сохранение целостности проектной документации.
Управление изменениями — это систематический процесс идентификации, документирования, оценки влияния и утверждения корректировок в проектном плане, архитектуре или требованиях. Данный механизм обеспечивает контролируемое внедрение модификаций через регламентированные процедуры согласования, сохраняет баланс между гибкостью реализации и соблюдением утверждённых контрактов, бюджетных ограничений и временных рамок.
CAB (Change Advisory Board) — это коллегиальный орган, состоящий из представителей технических команд, бизнес-заказчиков и руководителей проектов, осуществляющий экспертизу предлагаемых изменений перед их утверждением. Совет анализирует технические риски, оценивает влияние на производственные системы, проверяет соответствие изменений бизнес-целям и принимает окончательное решение о включении корректировок в рабочий план.
Смежные разделы: договор, методология, инциденты, трекер.
Услышали "срочно добавьте" — вежливо просите тикет или CR и оценку влияния. Не начинайте без приоритета PO. Это не саботаж, а защита срока и вашего сна.
Play ITЗагрузка интерактивного демо…
Срочность — это параметр классификации запроса или инцидента, определяющий требуемую скорость реакции исполнителей и приоритет обработки задачи в контексте бизнес-процессов. Данный атрибут устанавливает порядок очереди на выполнение, влияет на распределение инженерных ресурсов и определяет допустимые сроки восстановления работоспособности или внедрения корректировок в соответствии с установленными соглашениями об уровне обслуживания.
Оценка влияния — это аналитическая процедура определения последствий предлагаемых изменений для архитектуры системы, смежных компонентов, производственной среды, бюджета и графика реализации работ. Процедура выявляет затронутые модули, оценивает необходимый объём дополнительных тестирований, прогнозирует риски возникновения регрессий и формирует количественные показатели требуемых ресурсов для принятия обоснованного решения об утверждении запроса.
Фиксация — это процесс документального закрепления утверждённых требований, архитектурных решений, конфигураций или результатов согласования в официальной проектной документации. Данный этап обеспечивает создание стабильной точки отсчёта, гарантирует однозначную интерпретацию условий выполнения работ всеми участниками проекта и формирует надёжный базис для последующего контроля соответствия утверждённым параметрам.
Scope и scope creep
Scope и scope creep — это совокупность утверждённых требований, задач и результатов, определяющих границы проекта, а также постепенное расширение этих границ вследствие последовательного добавления новых функциональных ожиданий при сохранении исходных бюджетных и временных рамок. Исходные границы фиксируются в базовой конфигурации проекта, обеспечивая предсказуемость выполнения работ, тогда как расширение функциональности требует пересмотра контрактных условий и перераспределения ресурсов для сохранения качества конечного продукта.
Scope (объём работ) — что входит в проект, релиз или спринт по договорённости (договор, backlog, ТЗ, цель спринта).
Scope creep — когда объём растёт, а сроки, бюджет и capacity команды не пересмотрены.
Типичные признаки:
- просьба "добавьте кнопку" в личном чате без тикета;
- ТЗ раздувается, дедлайн тот же;
- разработчик узнаёт о новом требовании только на демо;
- "это же мелочь" повторяется десять раз в неделю;
- в аутсорсе заказчик считает, что всё входит в fixed price.
Лечение: каждое изменение — в трекер; крупное — change request с явным trade-off (что снимаем из scope).
| Здоровый признак | Scope creep |
|---|---|
| Новое = что-то сняли или сдвинули срок | Новое = "втиснем" |
| PO сказал "да" или "нет" письменно | "Все согласны" в чате |
| Влияние на срок оценили | "Должно быстро" |
Backlog — это приоритизированный перечень задач, требований, дефектов и технических улучшений, предназначенных для реализации в рамках текущего или последующих этапов разработки. Список содержит детализированные описания элементов работ, критерии приёмки и оценку сложности, обеспечивая прозрачное планирование итераций и позволяя команде последовательно обрабатывать задачи в порядке убывания бизнес-ценности.
Change request — что это
Change request (CR) — заявка на изменение scope, срока, стоимости или рисков проекта. Форма зависит от организации (Jira issue type, Word-форма, портал заказчика), суть одна: зафиксировать разницу между планом и новым желанием.
Минимальные поля CR
| Поле | Содержание |
|---|---|
| ID и дата | Уникальный номер, автор |
| Описание | Что хотят иначе, чем в текущем плане |
| Обоснование | Бизнес-цель, метрика, регламент, письмо регулятора |
| Влияние | Срок (+N дней), стоимость (+часы/руб), риски, архитектура |
| Альтернативы | Отложить, урезать, заменить другой фичей, MVP |
| Решение | Принято / отклонено / отложено / частично |
| Утверждающий | PO, спонсор, заказчик |
Fixed price и T&M
Fixed price — это модель ценообразования, при которой стоимость выполнения всего объёма работ определяется заранее и фиксируется в договоре до начала активной фазы реализации проекта. Данный формат предусматривает ограничение бюджета, перенос рисков превышения сметных расходов на исполнителя и требует детальной проработки технического задания на этапе планирования для обеспечения точной трактовки конечного результата.
T&M — это модель взаимодействия, основанная на оплате фактически затраченного рабочего времени специалистов и стоимости использованных материальных или программных ресурсов. Данный подход обеспечивает гибкость в корректировке требований на протяжении жизненного цикла проекта, позволяет оперативно адаптировать план работ к изменяющимся бизнес-условиям и предполагает регулярную финансовую отчётность по затраченным часам и приобретённым лицензиям.
- При fixed price CR часто ведёт к допсоглашению к договору и пересмотру срока/суммы.
- При T&M (time and material) — переприоритизация backlog с фиксацией прогноза часов и уведомлением заказчика.
- В продукте без внешнего заказчика CR может быть лёгким (эпик + комментарий PO), но trade-off всё равно явный.
Trade-off — это стратегическое решение о сознательной замене одного из параметров проекта оптимизацией другого показателя в условиях ограниченных ресурсов или противоречивых требований. Механизм обеспечивает поиск оптимального баланса между качеством, стоимостью и сроками реализации, позволяя руководству принимать взвешенные архитектурные и управленческие решения для сохранения жизнеспособности проекта при возникновении критических ограничений.
Workflow change request
Workflow change request — это регламентированная последовательность этапов обработки запроса на изменение, включающая регистрацию запроса, первичную экспертизу, техническую оценку влияния, согласование с заинтересованными сторонами, утверждение уполномоченным органом, планирование реализации и контроль исполнения. Данная последовательность гарантирует прозрачность процесса принятия решений, обеспечивает аудит всех этапов согласования и поддерживает санкционированное внесение корректировок в производственную среду.
Изменения в Agile-процессе
Изменения в Agile-процессе — это механизм адаптации требований и планов разработки в рамках итеративной методологии, предусматривающий регулярный пересмотр приоритетов задач на границах спринтов или во время планирующих сессий. Процедура позволяет команде оперативно реагировать на новые рыночные условия, корректировать функциональные ожидания заказчика с сохранением целостности текущего итеративного цикла и поддержанием высокой скорости доставки рабочего программного продукта.
Agile — это итеративная методология управления проектами, основанная на принципах гибкого планирования, регулярной поставки рабочего продукта, непрерывного взаимодействия с заказчиком и адаптации к изменяющимся требованиям. Методология предусматривает разделение разработки на короткие временные интервалы, распределение ответственности внутри самоорганизующейся команды и приоритизацию рабочего функционала над избыточной документацией для обеспечения быстрой реакции на рыночные изменения.
Agile не значит "меняем всё без последствий". Значит — меняем прозрачно и часто.
- Запрос → тикет типа "Change" или комментарий к эпику с меткой
scope-change. - BA / SA оценивают влияние; при неясности — spike на 1–2 дня.
- PO/PM меняет приоритет backlog; при нехватке capacity — снимает другую работу (называет вслух).
- В Scrum — пересмотр Sprint Goal, а не тихое дописывание задач в середине спринта (спринт).
- В Kanban — новый элемент в очереди и пересмотр WIP, не "ещё одна карточка без лимита".
Если в середине спринта прилетело изменение — PO решает: продолжаем цель, сужаем scope спринта или прерываем. Scrum Master помогает процессу, не подменяет PO.
CAB — совет по изменениям в production
CAB (Change Advisory Board) — формальное согласование изменений в production в банках, госсекторе, критичной инфраструктуре, телекоме.
Обычно фиксируют:
- окно обслуживания (maintenance window);
- чек-лист (тесты на stage, rollback, дежурный on-call);
- уровни изменений — стандартное, срочное, экстренное (emergency);
- связь с severity при инциденте.
Окно обслуживания (maintenance window) — это заранее согласованный временной интервал, выделенный для проведения технических работ, обновления систем, применения патчей или внедрения утверждённых изменений в производственной среде. Данный период снижает влияние технических процедур на пользовательскую активность, обеспечивает безопасное выполнение рискованных операций под контролем инженерных команд и гарантирует наличие ресурсов для оперативного восстановления сервисов при возникновении технических сбоев.
CAB не должен блокировать каждый мелкий hotfix месяцами. Зрелые организации вводят tier:
| Tier | Пример | Согласование |
|---|---|---|
| Standard | Плановый релиз в окно вс | Полный CAB |
| Expedited | Срочный патч вне окна | Укороченный CAB |
| Emergency | P1, восстановление prod | Post-facto документирование |
Разработчик в банке должен знать tier до ночного деплоя, а не узнавать от отказа в тикете.
Пример — госсектор
Релиз портала услуг — заявка в Service Desk, протокол CAB, окно в воскресенье 02:00–06:00, дежурная бригада, rollback по чек-листу. Изменение ТЗ по новому полю от ведомства — отдельный CR к контракту, не "впихнуть в воскресный релиз" без оценки.
Service Desk — это единая точка взаимодействия пользователей с технической поддержкой, обеспечивающая регистрацию, классификацию, маршрутизацию и контроль исполнения запросов на обслуживание и инцидентов. Служба выполняет функции коммуникационного хаба, гарантирует соблюдение установленных сроков реакции, предоставляет пользователям актуальную информацию о статусе обработки обращений и поддерживает базу знаний для оперативного решения типовых технических проблем.
Примеры по контекстам
Продуктовая компания
PM получает данные: 40% пользователей бросают корзину на шаге доставки. PO вытаскивает эпик "упростить доставку" вместо "новый раздел блога" в этом квартале. Формальный CR не нужен — достаточно решения PO в backlog с комментарием trade-off. Если затронута архитектура (новый складской API) — ADR.
Аутсорс, fixed price
Заказчик просит интеграцию с 1С в том же релизе, что и личный кабинет. PM исполнителя оформляет CR: +6 недель, +N рублей, риск сдвига приёмки. Заказчик подписывает допсоглашение или отказывается. Разработчик не начинает 1С до статуса "принято".
Внутренний IT
Бизнес подаёт заявку через ITSM. Владелец услуги (PO внутреннего продукта) ранжирует с портфелем. CR — при смене SLA или бюджета департамента.
Роль BA и SA в change request
| Роль | Вклад в CR |
|---|---|
| BA | Уточнение требований, дельта к ТЗ/AC, влияние на процессы |
| SA | Техническое влияние, интеграции, NFR, оценка риска |
| PO/заказчик | Решение принять / отклонить, что снять из scope |
| PM | Срок, бюджет, коммуникация со стейкхолдерами |
| Юрист (аутсорс) | Допсоглашение при fixed price |
Без оценки влияния CR — просто пожелание. Spike допустим для "не знаем, сколько стоит ЕСИА".
Роль разработчика при "срочной просьбе"
- Предложить оформить CR или тикет и оценить влияние (хотя бы порядок: дни/недели).
- Не начинать работу без приоритета PO.
- Эскалировать к PM, если давление обходит процесс.
- При изменении prod — следовать CAB/runbook, не "задеплою с ноутбука".
- Фиксировать устные "да" в комментарии к тикету — защита для всех.
Связь с инцидентами и релизами
- Emergency change после P1 — отдельный поток CAB, post-facto отчёт.
- Плановый релиз с новым scope без CR при fixed price — юридический и репутационный риск.
- Postmortem может породить CR на техдолг (мониторинг, тесты).
Антипаттерны change management
| Антипаттерн | Последствие |
|---|---|
| "Устное OK" директора | Спор на приёмке |
| CR без оценки | Недоверие заказчика |
| PO не в курсе | Scope creep в спринте |
| CAB на каждый hotfix P1 | MTTR растёт |
| Нет CAB на критичный prod | Аварии от непротестированного |
| Все CR принимаются | Ничего не успевают |
Минимальный регламент для маленькой команды
Даже без CAB и юристов:
- Один трекер, метка
change. - PO комментирует trade-off в эпике.
- Крупное (> N дней) — короткая форма CR в wiki.
- Релиз в prod — чек-лист rollback (доставка).
Пример формы change request
# CR-2025-014: Интеграция с ЕСИА
## Описание
Вход через ЕСИА вместо логина по email в личном кабинете.
## Обоснование
Требование заказчика-госоргана, п. 4.2 ТЗ v1.3.
## Влияние
- Срок: +4 недели к этапу 2
- Стоимость: +320 ч по ставке T&M
- Риски: зависимость от тестового контура ЕСИА
- Архитектура: новый ADR-0018 (OAuth2/OIDC)
## Альтернативы
1. MVP без ЕСИА в этапе 2 — отклонено заказчиком
2. Только для госсегмента пользователей — частично принято
## Решение
Принято 2025-06-10, подпись куратора Иванова И.И.
## Trade-off
Снято из этапа 2: экспорт отчётов в Excel.
Baseline scope и версии ТЗ
Baseline scope — это утверждённая версия проектных требований и границ работ, зафиксированная в документации на момент начала активной фазы реализации и служащая эталоном для оценки любых последующих корректировок. Данный базовый конфигурационный набор определяет исходные условия выполнения контракта, устанавливает критерии сравнения текущего состояния проекта с первоначальным планом и формирует основу для расчёта отклонений по бюджету, срокам и функциональному покрытию.
Baseline — снимок согласованного объёма на дату (ТЗ v1.0, backlog release 2.0). Любая дельта сравнивается с baseline в CR. В госпроектах версия ТЗ в протоколе — юридическая опора. В продукте baseline — релизная тема в трекере.
Переговоры с заказчиком при CR
- Факты — оценка BA/SA, не "нам кажется долго".
- Варианты — полный scope / MVP / отложить / доплата.
- Последствия отказа — что не получит заказчик (не угроза, а прозрачность).
- Письменное решение — протокол, email, статус в портале.
PM исполнителя не обещает срок устно на демо без оценки — классический источник scope creep.
Change board на уровне портфеля
В крупных организациях CR смотрит change board (не путать с CAB): приоритет между проектами, бюджет, зависимости. PO одного продукта готовит CR; board решает, вытесняет ли запрос другой инициативу. Разработчик видит результат как сдвиг приоритета в backlog.
Scope creep в цифрах
Признаки для ретро:
- velocity упала при "том же" scope спринта;
- % задач без связи с целью спринта вырос;
- закрытых CR за квартал — 0, а ТЗ выросло на 40%;
- T&M часы +30% при неизменном roadmap.
PO и PM разбирают причины — часто обход процесса, а не лень команды.
CAB — чек-лист заявки на релиз
- Версия и changelog
- Тесты на stage пройдены
- Rollback проверен
- On-call назначен
- Окно обслуживания согласовано
- Связанные CR и ADR
- Коммуникация поддержке и пользователям
Emergency tier — укороченный список + post-facto отчёт за 24 ч.
Продукт без формального CR
Достаточно прозрачного trade-off в эпике:
"Добавили оплату СБП. Сняли: редизайн профиля (эпик PRO-441) → Q3."
Kanban policies могут требовать комментарий PO при любом Expedite из-за стейкхолдера.
Регресс scope после инцидента
После P1 заказчик или бизнес может просить "ещё страховки". Оформляйте как CR или эпик техдолга с оценкой — не бесплатное дополнение к "исправлению вины". Postmortem action items уже в backlog; дублировать без приоритета PO нельзя.
Типы договора и изменения
| Модель | Как меняется scope |
|---|---|
| Fixed price | CR → допсоглашение → новая сумма/срок |
| T&M | CR или письмо → прогноз часов → приоритет PO |
| Retainer | Ежемесячный лимит часов, CR при превышении |
| Внутренний продукт | Trade-off в backlog, бюджет департамента |
| Гос контракт | Допсоглашение, экспертиза, протокол |
Разработчик знает модель — иначе непонятно, почему PM требует подпись на "мелочи".
Протокол изменения в середине спринта
- Запрос зафиксирован (тикет / CR).
- PO созывает короткое совещание (15–30 мин): цель спринта ещё актуальна?
- Варианты: сузить scope спринта; прервать спринт; отклонить до следующего.
- Решение PO в комментарии к спринту — видно на Daily.
- Scrum Master следит за процессом, не за содержанием приоритета.
Release train и заморозка scope
В release train (поезд релизов) за N дней до даты — freeze: только баги и CR с tier emergency. Новые фичи — в следующий поезд. PO и PM коммуницируют freeze заранее; обход freeze — формальный CR с риском сдвига поезда для всех команд.
Документирование устного согласия
Если PO сказал "да" на созвоне:
- BA или PM пишет протокол в тикет в тот же день;
- перечисляет trade-off;
- PO подтверждает реакцией в тикете.
Для заказчика в аутсорсе — email или портал, не только созвон.
Метрики change management
| Метрика | Назначение |
|---|---|
| Количество CR / квартал | Объём изменений |
| % CR принятых | Реалистичность запросов |
| Среднее время согласования CR | Узкое место |
| Scope creep hours (T&M) | Часы вне baseline |
| Релизы без rollback-плана | Риск CAB |
Ретро раз в квартал с PM и PO.
Словарь управления изменениями
| Термин | Определение |
|---|---|
| Scope | Согласованный объём работ |
| Scope creep | Рост объёма без пересмотра срока и бюджета |
| Change request | Формальная заявка на изменение |
| CAB | Совет по согласованию prod-изменений |
| Baseline | Зафиксированный scope на дату |
| Trade-off | Явный обмен — что снимаем |
| Freeze | Заморозка scope перед релизом |
| Emergency change | Срочное изменение при P1 |
| Допсоглашение | Юридическое изменение контракта |
| Spike | Краткое исследование для оценки CR |