Планирование загрузки открывают, когда проект регулярно обещает больше, чем команда реально может потянуть. На словах всё выглядит достижимым, но в реальности возникает постоянный перегруз, скрытая очередь, просрочки и ощущение, что команда всё время догоняет сама себя.
Что это за подход
Capacity planning полезен как рамка соотнесения объёма работы с реальной пропускной способностью команды. Для PM это способ делать обещания и приоритеты, опираясь не только на желание и давление, но и на ограничения среды.
Когда он нужен
- команда перегружена или часто не попадает в обещанный объём;
- несколько потоков конкурируют за один и тот же ресурс;
- важно заранее видеть price of commitment;
- PM нужно защищать проект от системного overcommitment.
Когда он не нужен
- если работа слишком мала по масштабу для отдельного capacity-контура;
- если capacity planning превращается в фиктивную математику без связи с реальной командой;
- если его используют как замену приоритизации.
Что из него реально применимо для PM
- переводить ограничения команды в управленческий язык;
- балансировать объём между потоками;
- снижать избыточные обещания;
- поддерживать более честное planning и status expectations.
Какие артефакты, ритуалы и правила важны
- понятная модель доступной ёмкости;
- учёт встреч, поддержки, срочного входящего и отсутствий;
- регулярный пересмотр capacity assumptions;
- связь с prioritization и planning.
Какие ошибки чаще всего делают при внедрении
- считают capacity по идеальной, а не реальной доступности;
- игнорируют переключение контекста и support load;
- сводят capacity к одной цифре без понимания состава работы;
- используют расчёт, но не меняют обещания и приоритеты.
Чем можно заменить или упростить
- лёгкой weekly check of load;
- таблицами загрузки, если пока нужен инструментальный, а не методологический слой;
- верхнеуровневой оценкой команды по потокам.