🔀 Scope creep и управление изменениями

Заказал ремонт ванной, по ходу попросил «заодно» переложить плитку в коридоре. Хороший прораб не скажет «нет», он скажет «это плюс неделя и плюс 80 тысяч, делаем?»

Как это работает

1. Изменение приходит от кого угодно: заказчик, команда, руководство
2. Менеджер записывает его: что меняется и зачем
3. Команда оценивает влияние на срок, бюджет, риски и другие задачи
4. Решение принимает спонсор или заказчик, видя цену
5. Принятое изменение попадает в план и скоуп, отклонённое остаётся в журнале

В Agile это проще: изменение идёт в бэклог, продакт ставит приоритет, и что-то другое из спринта уходит ниже. Но принцип тот же: добавил одно, убери или сдвинь другое

Откуда растёт скоуп

• Размытые границы в уставе: нет раздела «не входит»
• Прямые просьбы к разработчикам мимо менеджера
• Золочение — команда сама делает больше, чем просили
• Уточнение требований по ходу: это нормально, но должно быть оценено

Пример из жизни

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

Важно запомнить

• Не «нет», а «вот цена»: изменение с оценкой и вариантами