Capacity management без героизма

Когда использовать

Этот материал нужен, когда команда все чаще отвечает “сделаем”, но фактически живет в перегрузе: задачи застревают, review копится, срочные просьбы ломают план, а разговор о capacity сводится к вопросу “кто еще может потерпеть”.

Capacity management в работе тимлида - это не учет каждой минуты. Это способ сделать ограничение команды видимым до того, как оно превратится в героизм, выгорание или срыв ожиданий.

Главный принцип

Capacity - это не сумма календарных часов людей.

Реальная способность команды поставлять результат зависит от:

• незавершенной работы;
• переключений;
• скрытой поддержки;
• ожидания решений и review;
• внешних зависимостей;
• навыковых узких мест;
• качества постановки задач;
• запаса внимания на риск и изменение условий.

Если учитывать только доступные часы, команда почти всегда выглядит свободнее, чем есть на самом деле.

Что считать нагрузкой

В capacity-разговор должны попадать не только задачи из спринта.

Если часть работы невидима, команда начинает планировать поверх нее.

1. Посмотреть на WIP

Первый вопрос:

Сколько работы сейчас уже начато, но еще не дало результат?

Проверьте:

• задачи в разработке;
• задачи на review;
• задачи на приемке;
• задачи, которые ждут решения;
• незакрытые дефекты;
• ручные обходы и поддержка;
• обещания, которые уже даны внешним участникам.

Большой WIP часто выглядит как высокая занятость, но снижает способность заканчивать работу. Если команда начинает все, но мало завершает, capacity уже занята очередями.

2. Отделить загрузку от пропускной способности

Загруженный человек не равен полезному потоку.

Признаки, что загрузка стала ловушкой:

• каждый занят, но результат не движется;
• review ждет конкретного человека;
• решения возвращаются к тимлиду;
• разработчики переключаются между несколькими незавершенными задачами;
• срочные просьбы не записываются как работа;
• команда компенсирует неясность личным усилием.

Разговор о capacity должен начинаться не с “кто свободен”, а с “где сейчас ограничение потока”.

3. Найти скрытую работу

Скрытая работа особенно опасна, потому что она не спорит за место в плане.

Соберите за неделю:

• сколько было срочных вопросов;
• сколько задач потребовало повторного уточнения;
• сколько времени ушло на поддержку;
• где были блокировки из-за внешней стороны;
• какие решения принимались вне видимого места;
• где люди возвращались к старым задачам после “почти готово”.

Цель не в точном тайм-трекинге. Цель - показать, что план уже конкурирует с работой, которую никто не назвал.

4. Проверить навыковые узкие места

Capacity команды может упираться не в количество людей, а в конкретный навык или право принимать решение.

Примеры:

• только один человек понимает интеграционный контур;
• только один человек может принять архитектурный trade-off;
• только тимлид умеет говорить с внешней стороной;
• только один QA знает риск регрессии;
• только один разработчик может быстро сделать review.

Это не повод срочно “размазать” ответственность. Это повод решить, что делать:

• оставить узкое место явным на время;
• передать часть контекста;
• снизить WIP рядом с узким местом;
• пересобрать порядок задач;
• выделить обучение как работу, а не как свободное время.

5. Использовать capacity в приоритизации

Capacity нужна не для отчета. Она должна менять выбор.

Перед добавлением новой задачи спросите:

• что нужно остановить или не начинать;
• какой текущий результат сдвинется;
• какое решение или review станет узким местом;
• кто будет владельцем до результата;
• что произойдет с поддержкой и срочными вопросами;
• какой риск мы принимаем, если все равно добавляем работу.

Если новая задача не меняет план, хотя capacity уже занята, значит план не отражает реальную работу.

6. Как говорить без давления на людей

Плохой capacity-разговор звучит так:

Кто сможет взять еще?

Лучше:

Где у нас сейчас ограничение потока,
что уже начато,
что нужно закончить,
и что мы сознательно не берем в работу?

Так разговор уходит от личной выносливости к системе работы. Это не снимает ответственность с людей, но защищает команду от привычки закрывать системный перегруз личным усилием.

Copy-paste проверка capacity

Период:
Какой цикл или окно планируем.

Видимая работа:
Какие задачи уже в потоке.

Скрытая работа:
Поддержка, review, приемка, внешние вопросы, найм, onboarding, one-on-one.

Ограничение:
Где поток упирается сейчас: человек, навык, решение, внешняя сторона, качество входа.

Новый кандидат:
Что хотят добавить.

Цена добавления:
Что нужно остановить, отложить или сузить.

Риск:
Что станет хуже, если добавить без изменения плана.

Решение:
Берем / проверяем сначала / откладываем / не делаем.

Пересмотр:
Когда смотрим, стало ли ограничение меньше.

Что фиксировать как решение

Capacity-решение стоит записать, если:

• команда откладывает важную задачу из-за ограничения;
• выбирает короткую проверку вместо полной реализации;
• снимает часть scope;
• останавливает старт задачи до готовности;
• выделяет время на поддержку, обучение или снижение WIP;
• принимает риск, что часть работы не попадет в ближайший период.

В записи решения важно назвать не только “что делаем”, но и “что не делаем”. Иначе capacity снова станет невидимой.

Антипаттерны

Стоит насторожиться, если:

• capacity считается только по календарю людей;
• незапланированная работа не влияет на план;
• каждый человек загружен, но задачи долго ждут review или решения;
• команда берет новую работу без выбора, что остановить;
• обучение и передача контекста считаются личной инициативой, а не задачей;
• срочность используется как способ обойти приоритизацию;
• перегруз объясняется слабостью людей, а не устройством потока.

Capacity management без героизма помогает говорить не “потерпим еще”, а “вот наше реальное ограничение, вот выбор, вот цена следующей задачи”.