Проект близок к релизу, а ключевой стейкхолдер приносит существенное новое требование. Как поступите?
Короткий ответ
- Не говорить сразу ни «да», ни «нет»
- Понять причину: что изменилось и какова срочность
- Оценить влияние на сроки, риски и тестирование
- Подготовить варианты: в релиз, следующим релизом, частично
- Урезанный вариант часто закрывает срочную часть потребности
- Решение принимает владелец релиза с полной картиной
- Зафиксировать решение и обновить план
Позднее требование не принимается и не отвергается с ходу: аналитик выясняет причину, оценивает влияние, готовит варианты с ценой каждого и выносит решение владельцу релиза.
Как сказать вслух
пример ответаЯ не отвечаю сразу ни да, ни нет. Сначала выясняю, почему требование появилось именно сейчас и что будет, если выпустить релиз без него — иногда за срочностью стоит реальное изменение, например в законе, а иногда просто «вспомнили». Потом с командой оцениваю влияние: сроки, риски, что придётся перетестировать. Готовлю варианты: сдвинуть релиз, выпустить как есть и доделать следующим, или сделать урезанную версию, закрывающую самое срочное. Решение с полной картиной принимает владелец релиза, итог фиксируем.
Подробный ответ
Основной ответ
Позднее изменение — управленческая ситуация, а не повод для героизма или глухой обороны. Первый шаг — причина и цена отсрочки: изменение регуляторики с датой вступления — это одно, «увидел у конкурента» — другое; вопрос «что случится, если это выйдет через месяц после релиза» быстро проясняет реальную срочность. Второй — честная оценка влияния с командой: трудоёмкость, затронутые компоненты, объём регрессионного тестирования, риски дестабилизации релиза — именно сжатое тестирование чаще всего и ломает поздние добавления. Третий — варианты для решения: включить и сдвинуть релиз; выпустить по плану, требование — в ближайший следующий; реализовать минимальный кусок, закрывающий срочную часть (например, ручной обходной процесс вместо автоматизации). Решение принимает владелец релиза или спонсор, видя цену каждого варианта. Итог фиксируется, план и бэклог обновляются. Системно частые поздние изменения — сигнал проблемы в процессе выявления требований, её стоит разобрать на ретроспективе.
Ключевые моменты
- Цена отсрочки. Вопрос «что будет, если выпустить без этого» отделяет настоящую срочность от эмоциональной.
- Риск регрессии. Поздние изменения опасны не столько разработкой, сколько сжатым тестированием и дестабилизацией релиза.
- Варианты вместо да/нет. Сдвиг релиза, перенос в следующий, минимальная версия — решение выбирается из оценённых альтернатив.
- Сигнал процессу. Регулярные поздние требования от одного стейкхолдера — повод чинить процесс выявления, а не геройствовать перед каждым релизом.
Практический контекст
Классика поведенческого интервью для senior-аналитика: проверяется умение держать рамку под давлением статусного стейкхолдера. Интервьюер ждёт историю по STAR с конкретным исходом и смотрит, не прогибается ли кандидат автоматически и не прячется ли за формальное «заявка в следующий релиз» при настоящей срочности. Упоминание риска регрессии и урезанного варианта отличает опытного кандидата.
Частые ошибки
- Соглашаются «впихнуть» из-за статуса стейкхолдера без оценки влияния
- Отказывают формальной процедурой, не разобравшись в реальной срочности
- Забывают про стоимость регрессионного тестирования при оценке изменения