Почему план на полгода вперёд — самый дорогой способ ошибиться?
Три команды делают один продукт. В январе руководитель расписал релиз до июня: кто что делает в каждом спринте. К марту команда платежей упёрлась в интеграцию с банком, команда витрины ждёт их API, а мобильщики уже сделали экраны под старый контракт. План есть — а работает только бесконечное пересогласование.
Майк Кон в «Agile: оценка и планирование проектов» предлагает «скользящий опережающий план» (rolling lookahead): детально расписывать работу лишь на ближайшие 1–2 итерации, а дальше держать только приоритеты и ориентиры. Выглядит как лень, но это метод: чем дальше горизонт, тем шире конус неопределённости, и детали, придуманные в январе, к марту стоят дороже, чем их отсутствие. Кон вообще советует опираться на фактическую скорость команды, а не на прогнозы — а измерить её можно только после пары итераций.
Кен Швабер в «Софт за 30 дней» доводит мысль до цифр: планирование до первой итерации занимает около 20% времени от привычного каскадного, а детальные требования формируются «точно в срок» — прямо перед итерацией, с учётом того, что показала предыдущая.
Дэвид Андерсон в «Канбан» добавляет неудобное уточнение: узкое место в системе постоянно переезжает. Расшили одно — ограничение всплыло в другом месте. Жёсткий долгосрочный план фиксирует картину бутылочных горлышек на момент составления, а через два месяца она уже другая.
💡 Короткий горизонт детализации — не отказ от планирования, а признание, что самая точная информация о проекте появляется в процессе. Цель планируйте далеко, шаги — близко.
❓ На сколько спринтов вперёд у вас реально расписаны задачи — и сколько из этого потом переделывается?
📚 Источники: Майк Кон — «Agile: оценка и планирование проектов», Кен Швабер — «Софт за 30 дней», Дэвид Андерсон — «Канбан. Альтернативный путь в Agile»
