Scope creep — это когда требования расширяются незаметно, а сроки и ресурсы почему‑то должны остаться прежними. Формально «ничего страшного», по факту — проект превращается в бесконечный ремонт дороги, где асфальт кладут прямо под колесами.
Как понять, что «скоуп поплыл»
Скоуп обычно «плывет» не с громкого “давайте всё переделаем”, а с тихих «а можно еще маленькую кнопку».
Проверьте себя: если совпало хотя бы 3 пункта — вы уже в зоне риска.
- Новые задачи «асайнятся» в спринт/план без пересборки приоритетов и без разговора “что выкидываем”.
- В обсуждениях звучит «это же уточнение», но появляется новая работа, новые проверки, новые сценарии.
- Команда чаще спорит про формулировки и “а что значит готово”, чем делает поставку.
- У фич нет четких acceptance criteria, поэтому «почти готово» длится неделями.
Почему «просто добавьте в бэклог» не спасает
Бэклог без правил изменения — это склад. На складе удобно хранить хотелки, но он не отвечает на вопрос «что делаем сейчас» и «что отменяем ради нового».
Вторая ловушка — прикрываться Agile: гибкость ≠ отсутствие change-control. Если изменения не проходят оценку влияния (сроки/риски/ресурсы) и не фиксируются, это не Agile, а неконтролируемая очередь.
Инструменты, которые реально работают
Здесь цель не «задушить инициативу», а сделать изменения управляемыми и честными для всех.
1) Мини-Change Request на 1 страницу
Не надо бюрократии и комитета на 12 человек — нужен один формат, который одинаково понимают бизнес и команда.
В change request фиксируются:
- Что меняем и зачем (бизнес-обоснование).
- Импакт: что это делает со сроками/командой/рисками.
- Trade-off: что двигаем или выкидываем, чтобы влезть.
- Кто дает сайнофф (чтобы потом не было «я такого не говорил»).
2) «Нет» без «нет»: 5 рабочих формулировок
Люди злятся не на отказ, а на расплывчатость и внезапные последствия.
- «Ок, могу взять — что из текущего снимаем, чтобы влезть в срок?»
- «Давайте оценим импакт: это +Х дней/недель, устраивает такой сдвиг?»
- «Это похоже на отдельный change request: зафиксируем и вынесем на решение сегодня до 18:00».
- «В текущий релиз не влезает, но могу поставить в следующий — при условии, что это будет в Must».
- «Сделаем облегченный вариант: минимальная ценность сейчас, остальное — потом. Принимается?»
3) Приоритизация MoSCoW, чтобы прекратить “всё срочно”
MoSCoW — простой способ разложить хотелки на Must/Should/Could/Won’t и заставить стейкхолдеров выбирать, а не “просить всё”.
Полезное правило из DSDM: Must‑требования не должны занимать больше ~60% усилий, иначе предсказуемость разваливается.
4) Acceptance criteria + Definition of Done (DoD)
Acceptance criteria ставят границы конкретной фичи: что именно считается выполненным, по каким условиям принимаем.
DoD описывает общий стандарт качества команды (тесты, ревью, документация и т.д.), чтобы «готово» не означало «ну вроде работает у меня».
Неочевидный инсайт: команда не против контроля — команда против хаоса
Миф: «если всё фиксировать, скорость умрет». На практике скорость умирает от переделок, двусмысленности и “мы договорились устно”.
Когда у вас есть легкий change request, понятные acceptance criteria и честный trade-off, команда воспринимает это как защиту — от бесконечных правок и от выгорания.
Где этому учатся
Управление требованиями — это не “талант переговорщика”, а навык: как проводить импакт‑анализ, оформлять change request, ставить рамки через acceptance criteria и защищать приоритеты без конфликта.
Если руководитель растет в Project/Product, этот навык быстро окупается: меньше хаоса, выше предсказуемость, сильнее доверие стейкхолдеров.
Что сделать на следующей неделе
- Введите единый шаблон change request на 1 страницу и правило: «нет CR — нет работы».
- На планировании всегда задавайте вопрос: «Что снимаем ради нового?»
- Для топ‑фич пропишите acceptance criteria и согласуйте их до разработки.
Подписывайтесь на Телеграм‑канал — там можно забрать шаблон change request и готовые фразы для переговоров. Напишите в комментариях: кто чаще всего раздувает скоуп у вас — бизнес, продажи или “мы сами придумали”?