Загрузка команды разработки — это баланс между объёмом задач и реальной ёмкостью людей: если держать среднюю утилизацию 70–85% и планировать с поправкой на контекст‑свитч и поддержку, риск выгорания резко падает, а предсказуемость растёт; ключевой риск — мерить «занятость» вместо пропускной способности и загнать команду в вечный аврал.

Почему Руководитель проекта обычно «не угадывает» загрузку команды разработки

Самая частая трагикомедия: план строится от идеальных часов. 8 часов в день, минус обед, плюс мотивация — и вот вам «40 часов в неделю на разработчика». Потом внезапно выясняется, что у людей созвоны, ревью, инциденты, уточнения, онбординг, отпуск, болезнь и просто жизнь. И это не «помехи». Это и есть работа.

Вторая ошибка — путать две сущности: utilization (насколько человек занят) и throughput (сколько команда реально поставляет в прод за период). Первая метрика легко украшает отчёт, но плохо предсказывает сроки. Вторая — скучная, но честная.

Что именно измерять: не «часы», а ёмкость и поток

1) Командная ёмкость (capacity): сколько работы можно взять без самоубийства

Ёмкость — это не сумма рабочих часов. Это «сколько полезной работы команда переварит», учитывая неизбежные накладные расходы. Для РП удобна простая модель: считаем доступные часы и вводим коэффициенты на реальность.

• Номинал: 8×5 = 40 ч/нед на человека.
• Минус отсутствие: отпуска/больничные/конференции (планируйте хотя бы 10–15% по году).
• Минус операционка: встречи, синки, ревью, коммуникации (обычно 15–30%).
• Минус поддержка/инциденты: если есть дежурства — ещё 5–20%.
• Минус контекст‑свитч: параллельные проекты и «ещё одна срочная задачка» могут съесть 10–25%.

Практический вывод: если вы планируете загрузку «под 100%», вы на самом деле планируете переработки. Точка. А потом удивляетесь, почему качество падает, а сроки не сходятся.

Подводный камень: пытаться компенсировать «накладные» урезанием встреч без изменения процесса. Если у вас хаос требований, встречи — не причина, а симптом.

2) Пропускная способность (throughput): сколько задач реально доезжает до Done

Самая полезная метрика для РП: сколько элементов работы команда закрывает за неделю/спринт в вашем фактическом процессе (с тестированием, ревью, деплоем). В Scrum это часто velocity (в сторипойнтах), в Kanban — throughput (по штукам). Важно одно: считать по факту, а не по ожиданиям.

Практический вывод: прогноз делается от исторических данных (медиана за 6–8 недель), а не от «мне кажется, мы ускоримся».

Подводный камень: гнаться за ростом velocity. Команда быстро найдёт способ «рисовать» цифры. РП останется с красивым графиком и тем же сроком релиза.

Быстрая модель оценки загрузки (которую можно внедрить за неделю)

Шаг 1. Посчитайте реальную командную ёмкость на неделю

Инструкция для РП: если после честного вычитания у вас остаётся 60% — это не «команда ленивая», а «у вас нормальная реальность».

Шаг 2. Выберите целевую утилизацию

Чтобы снизить риск выгорания и повысить предсказуемость, держите плановую утилизацию 70–85% от полезной ёмкости. Остальное — буфер под неизвестное, поддержку, эксперименты, обучение, форс‑мажоры.

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

Шаг 3. Ограничьте WIP и параллельность

Самый дешёвый способ разгрузить команду без найма — меньше задач одновременно. РП часто думает: «если все заняты на 120%, то мы быстрее». На практике вы получаете медленнее поставку и больше хвостов.

1. Согласуйте WIP‑лимиты по ключевым стадиям (Dev / Review / QA).
2. Определите правило: новая задача в работу — только если освобождается слот.
3. Если «горит», сначала разгружаем поток (режем WIP), потом добавляем людей.

Подводный камень: добавлять задачи «почти готовые» параллельно «чуть-чуть». Этот «чуть-чуть» и съедает недели.

Как РП снижает риск выгорания: практики, которые работают (и не звучат как медитация)

Красные флаги перегруза (их видно в данных)

• Рост времени цикла (cycle time) при той же команде и похожих задачах.
• Увеличение доли багфиксов/инцидентов после релизов.
• Падение качества: «потом поправим» становится стилем.
• Постоянные «срочно» и деградация планирования: спринт превращается в чат.
• Люди уходят в тишину: меньше инициативы, больше формального выполнения.

Антивыгорание через управление ожиданиями (а не героизм)

У РП есть два рычага: объём и срок. Если оба «не обсуждаются», вы только выбираете, где будет ломаться: у команды или у продукта. И угадайте, что дешевле чинить.

Коммерческие факторы (скрытая цена перегруза, которую никто не закладывает)

Перегруз почти всегда дороже, чем кажется. Он маскируется под «мы просто сейчас поднажмём». Реальная стоимость вылезает позже:

• Текучка: уход 1 сильного инженера — это месяцы потери скорости (поиск, найм, онбординг, провал знаний).
• Техдолг: ускорились на неделю — платите квартал рефакторингом.
• Срыв доверия: бизнес привыкает, что «всё можно срочно», и вы теряете управление.

Если хочется ROI‑аргумент: стабильный поток поставки почти всегда дешевле, чем героические рывки. Рывки красивы в презентации. В P&L — нет.

Экспертный вердикт и инструмент: чек‑лист РП «Не сжечь команду»

• Я считаю ёмкость от реальности? (операционка, поддержка, параллельность учтены цифрами, а не надеждой)
• Плановая утилизация ≤ 85%? Если выше — это не план, а ставка на переработки.
• Есть WIP‑лимиты? Если нет — у вас официально разрешён хаос.
• Срочные задачи имеют квоту? Иначе «срочно» съест roadmap.
• Прогноз от истории, а не от желаний? Медиана throughput за 6–8 недель — ваш друг.
• Ретро приводит к изменениям? Если ретро «просто поговорили» — вы платите временем за иллюзию процесса.

Частые вопросы