Загрузка команды и управление ресурсами проекта

Сроки в проекте срываются не потому, что люди ленятся, а потому что одному человеку на одну неделю назначили работы на полторы. Управление загрузкой команды — это умение видеть, кто и насколько занят, до того как дедлайн уже горит. В этой статье разберём, что считать загрузкой, как находить перегрузку и узкие места и почему ресурсы важно смотреть прямо рядом с планом, а не в отдельной таблице.

Что такое загрузка команды и зачем её считать

Загрузка — это отношение запланированной на человека работы к его доступному времени за период. Если у разработчика 40 рабочих часов в неделю, а на него повешено задач на 52 часа, его загрузка 130 процентов — это перегрузка. Если на 16 часов, то 40 процентов — недозагрузка.

Оба перекоса вредны. Перегруженный человек становится узким местом: его задачи задерживают всех, кто от них зависит, он выгорает и ошибается. Недозагруженный простаивает или работа, которую он мог бы взять, лежит у соседа в перегрузе. Управление ресурсами — это постоянное выравнивание: распределить работу так, чтобы никто не был ни в дыму, ни без дела.

Важная оговорка: 100 процентов загрузки — это не цель, а потолок. Закладывать каждого под завязку нельзя — встречи, код-ревью, починка инцидентов, переключение контекста съедают время. Здоровый ориентир — 70–80 процентов планируемой загрузки, остальное буфер на реальность.

Как планировать загрузку по задачам и срокам

Чтобы загрузка считалась, а не угадывалась, нужны три вещи на каждой задаче: исполнитель, оценка трудоёмкости и сроки. Без оценки задача «весит» ноль и невидима для планирования — поэтому начинать стоит с дисциплины оценок (см. оценку задач в разработке и story points).

Дальше работа размазывается по календарю между датой старта и дедлайном. Задача на 16 часов, растянутая на две недели, даёт примерно 1,6 часа в день — это совсем другая нагрузка, чем те же 16 часов, втиснутые в два дня. Поэтому загрузка считается по дням и неделям, а не «всего по проекту».

Если человек работает на нескольких проектах, его доступное время делится между ними. Частая ошибка — планировать каждый проект так, будто сотрудник отдан ему целиком. Сложите загрузку по всем проектам, и вы увидите реальную картину. Учитывайте отпуска и больничные: неделя отпуска — это минус доступное время, и задачи на неё планировать нельзя.

Перегрузка, узкие места и недозагрузка: как находить

Самый наглядный инструмент — тепловая карта загрузки: строки это люди, столбцы дни или недели, цвет ячейки показывает занятость. Зелёное — норма, жёлтое — близко к потолку, красное — перегруз. За пару секунд видно, у кого и когда завал.

На что смотреть:

• Красные полосы у конкретного человека — кандидат на разгрузку прямо сейчас.
• Один человек в красном, рядом синий простой — классический повод перекинуть задачу.
• Узкое место по роли — например, единственный тестировщик или единственный, кто знает платёжный модуль. Тут поможет не перенос задач, а распределение знаний и связи задач с Git, чтобы видеть, через кого реально идёт код.
• Хроническая недозагрузка — сигнал, что человек либо берёт мелочёвку мимо трекера, либо его недогружают и он скучает.

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

Выравнивание загрузки: что можно сделать

Когда перекос найден, есть несколько рычагов — от самого дешёвого к дорогому:

• Перераспределить исполнителей. Перекинуть задачу с перегруженного на свободного, если у того есть нужные навыки.
• Сдвинуть сроки внутри буфера. Задачи не на критическом пути часто имеют запас (slack) — их можно подвинуть, не трогая дедлайн проекта (подробнее в зависимостях задач).
• Уменьшить объём. Договориться с заказчиком о приоритетах — что-то в этот спринт, что-то в следующий.
• Добавить людей. Самый медленный путь: новичку нужно время на вход, и закон Брукса напоминает, что поздно добавленные люди сначала замедляют проект.

Выравнивание — не разовая акция, а ритм. Удобно проверять загрузку на планировании спринта и сверяться на ежедневном стендапе, когда всплывают неожиданные блокеры. И помните про скорость команды: брать в спринт больше, чем команда стабильно закрывает по velocity, — это запрограммированная перегрузка.

Почему загрузку важно видеть рядом с планом

Главная беда классического ресурс-менеджмента в том, что загрузка живёт в отдельной таблице, а план проекта — в другом месте. Любое изменение в задачах (сдвинули срок, переназначили исполнителя, добавили работу) делает табличку устаревшей за час. Руководитель смотрит на красивые цифры, которые уже не соответствуют реальности.

Корректно — когда загрузка считается из тех же задач, что лежат на диаграмме Ганта и на канбан-доске. Передвинули задачу — тепловая карта пересчиталась. Переназначили — увидели, как разгрузился один и нагрузился другой. Тогда планирование сроков и планирование людей становятся одним действием, а не двумя.

Именно так это устроено в TeamVector: загрузка и ресурсы команды считаются прямо из задач проекта, рядом с Гантом, критическим путём и бюджетом, с разбивкой план/факт по дням. Видно не только кто перегружен, но и почему — какие задачи и зависимости это создают. Это часть среды для команд разработки с self-hosted или облачным размещением; ранние команды заходят бесплатно по программе Founding Teams.

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