Команда разрабатывает согласование заявок на закупку. По исходному требованию заявки дороже 500 000 ₽ подтверждает финансовый директор.

Backend уже реализовал часть логики, frontend начал экран согласования, QA подготовил проверки.

Анализ влияния изменений — одна из задач бизнес‑аналитика в ИТ, особенно когда новые требования появляются уже в процессе разработки.

В этот момент заказчик добавляет:

• от 100 000 ₽ заявку должен сначала согласовать руководитель подразделения;

• от 500 000 ₽ после него ещё и финансовый директор;

• а после отказа автор может исправить заявку и отправить повторно.

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

Разберём этот кейс и соберём оценку, с которой можно обсуждать включение изменения в релиз.

Кейс учебный. Допустим, система ещё не запущена, суммы указаны в рублях с НДС, а исходная постановка разрешала заявки до 500 000 ₽ включительно без ручного согласования. После отказа заявка закрывалась. В реальном проекте эти условия нужно проверить.

1. Зафиксировать, что именно меняется

Начать удобно с отдельной записи об изменении:

• инициатор;

• причина;

• дата;

• ссылка на действующее требование;

• предлагаемая редакция.

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

IIBA выделяет оценку изменения и согласование требований в отдельные задачи. Сообщение заказчика ещё не означает, что команда приняла новый объём работ. IIBA, Assess Requirement and Design Changes.

Запишем разницу в поведении:

Границу 500 000 ₽ подтверждаем отдельно: «дороже» и «от» задают разные условия. Пока неясно, намеренно ли заказчик изменил порог, заменять > на >= рано.

Следом выясняем причину и срок: какую проблему решает новый маршрут и допустим ли запуск по прежнему правилу.

1. Если согласование руководителя обязательно по новому регламенту, выпуск старого варианта может потерять смысл.

2. Если это пожелание, можно обсуждать поэтапное внедрение. Основание и владельца решения указываем в записи изменения.

NASA рекомендует сравнивать влияние изменения с последствиями его отклонения.

В нашем случае учитываем стоимость доработки и риск запуска без контроля руководителя. NASA Systems Engineering Handbook, Requirements Management.

2. Пройти от правила к тем частям системы, которые от него зависят

Impact analysis, или анализ влияния изменения, начинается с зависимостей: где используется порог суммы, кто принимает решение и кто получает результат?

Начинаем со ссылок на схему процесса, задачи, API и проверки.

Для этого полезна трассировка требований: отслеживание связей от исходной потребности до реализованного решения. IIBA прямо связывает её с контролем изменений. IIBA, Tracing Requirements and Designs.

Если готовой трассировки нет, восстанавливаем связи с разработчиками и QA.

Записываем основание каждой зависимости: документ, участок реализации или договорённость.

Пометка «API затронуто» без объяснения почти бесполезна.

Первый проход даст такую таблицу. Это предварительная оценка: влияние на реализацию ещё нужно подтвердить.

Последствие для бизнеса и способ реализации нужно разделять

Два этапа не обязательно означают два новых статуса: можно хранить WAITING_APPROVAL и текущий этап отдельно.

Существующий API тоже может уже работать с конкретным заданием на согласование. Необходимость изменения контракта ещё нужно проверить.

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

3. Разобрать сценарии, которые появились из‑за изменения

Возьмём заявку на 700 000 ₽. Руководитель одобрил её, финансовый директор отказал.

Автор уменьшил сумму до 450 000 ₽ и отправил повторно. Достаточно ли старого одобрения руководителя?

• Если да, он фактически отвечает за содержание, которого мог не видеть.

• Если нет, нужно явно указать, что повторная отправка создаёт новую попытку согласования, а предыдущие решения сохраняются только в истории.

Для кейса выберем второй вариант: повторная отправка запускает маршрут заново по новой сумме, прежние решения сохраняются в истории. Во время согласования редактирование запрещено. Эти правила нужно согласовать с владельцем процесса.

Теперь у руководителя осталась вкладка с предыдущей попыткой. Заявка уже отклонена, исправлена и отправлена заново. Старая кнопка не должна одобрить новую версию. Фиксируем требование: решение относится к определённой версии и попытке согласования; устаревшее действие их не меняет. Способ проверки команда выберет при проектировании.

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

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

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

В нашем кейсе рабочих заявок ещё нет, миграция бизнес‑данных не требуется. При работающем пилоте пришлось бы решить, завершать заявки по старым правилам или переводить на новые. У заявки на 700 000 ₽, ожидающей финансового директора, при переводе появится пропущенный первый этап.

Проверка шага: бизнес, разработчик и QA одинаково описывают исход этих сценариев. Иначе они будут оценивать разную реализацию.

4. Сопоставить новое поведение с уже выполненной работой

Допустим, команда обнаружила: обработчик одобрения всегда переводит заявку в APPROVED, экран показывает одного согласующего, тесты ожидают завершения процесса после одного решения финансового директора.

Обработчик нужно изменить: первое одобрение заявки на 700 000 ₽ не завершает процесс. Экран должен показывать этап и историю. Тесты маршрута пересматриваем, проверки обязательных полей сохраняем, если правила заполнения прежние. Незавершённую задачу на уведомление уточняем, пока она не закрепила старое поведение.

В переделку входят не только код, но и требования, дизайн, тесты, пользовательская документация. Эти категории перечисляет и руководство NASA. NASA Software Engineering Handbook, анализ последствий изменений.

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

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

«Мы почти дописали» не делает старый маршрут подходящим для запуска.

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

5. Собрать оценку, по которой можно принять решение

Дополняем таблицу причиной, вопросами, оценками команды и вариантами действий. Получается Change Impact Assessment, запись об оценке последствий. Её можно хранить в связанной задаче.

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

Теперь обсуждаем варианты:

• включить всё и пересмотреть план;

• разделить на этапы, например отложить повторную отправку, согласовав временный порядок работы после отказа;

• отложить изменение, если старый маршрут допустим.

Альтернатива вроде ручного согласования тоже требует владельца, срока действия и оценки рисков.

Оценки сопровождаем условиями: например, запуск без рабочих заявок и делегирования согласования. Открытым вопросам назначаем ответственных и сроки ответа. Решение о приоритетах принимает уполномоченный участник процесса.

В Scrum изменения внутри спринта не запрещены: объём можно уточнять и пересогласовывать с Product Owner, сохраняя качество и не ставя под угрозу цель спринта.

Разработчики и Product Owner проверяют совместимость нового маршрута с этой целью. Если она утратила актуальность, отменить спринт вправе Product Owner. Scrum Guide, The Sprint.

1. Фиксируем вариант, основание, согласовавшего и целевой релиз.

2. Обновляем затронутые требования, задачи, процесс, контракты и проверки.

3. Сохраняем историю, явно отмечая действующую версию.

6. Проверить, что оценку можно передавать команде

Перед передачей полезно повторно пройти несколько контрольных примеров.

При выбранных и подтверждённых правилах заявка на 99 999,99 ₽ проходит без ручного согласования, на 100 000 ₽ требует руководителя, а на 500 000 ₽ требует обоих участников по очереди. Первое одобрение крупной заявки не завершает процесс.

Повторная отправка запускает новую попытку, а старый или повторный запрос не может продвинуть её дальше.

Это проверка постановки, не реализации. Для каждого примера должны находиться правило, задача и критерий приёмки; для незакрытого вопроса — владелец и заблокированная часть оценки.

Умеете находить зависимости между требованиями и оценивать последствия изменений? Проверить свои знания и увидеть, какие темы стоит подтянуть, можно с помощью короткого вступительного теста по бизнес‑анализу в ИТ.

На следующем запросе можно использовать такой порядок:

1. Сохранить исходную версию и описать разницу в поведении, включая границы условий.

2. Уточнить причину, срок изменения и последствия отказа от него.

3. Найти зависимости и отделить подтверждённое влияние от предположений.

4. Разобрать новые сценарии, повторы, конфликтующие действия и переход со старых правил.

5. Сопоставить требования с выполненной работой и получить оценки команды.

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

7. Обновить связанные материалы и проверить их на одних и тех же примерах.

Для нескольких систем с независимыми релизами, договорными обязательствами или требованиями безопасности этой записи может быть недостаточно: понадобятся дополнительные согласования и план перехода.

Для локального изменения она даёт основу решения: что переделываем, что сохраняем и на каких условиях берёмся за новый объём.

Новое требование может сорвать сроки разработки. Но как понять, оправдано ли изменение для бизнеса и что придётся переделать?

На бесплатных открытых уроках разберём, как связывать изменения с бизнес‑целями, оценивать результат через метрики и управлять требованиями:

• 15 октября в 20:00. «Цели и метрики как одно целое». Записаться

• 22 октября в 20:00. «Управление изменениями требований». Записаться

Полный список вебинаров октября собрали в дайджесте.