История про Capacity команды: как нам помог этот показатель
– рассказывает Светлана, PM
Контекст
5+ лет мы развиваем приложение для работы с товарами, проект растёт – на прод поставляются новые фичи. Мы ежемесячно не успевали выполнять 100% из запланированного пула. «Как так получилось, что мы опять одну фичу не допилили?» Так мы и пришли к капасити.

Капасити (capacity) – показатель максимальной ёмкости чего-либо. Например, в IT капасити можно применить в контексте ресурсов: штат, техника и т.д.

Внедряем
🔹 Подсчёты
Для подсчета капасити мы ориентируемся не на 8, а на 6 часов: 2 часа закладываем на допустимые риски.
По нашему опыту, у сотрудника уровня Middle+/Senior с опытом работы 3–5 лет отдача по проекту будет на уровне 100% (1). Все остальные специалисты уступают по процентовке, но в нашей команде были специалисты только с высоким грейдом.
Также важно не забыть ограничения в работе, в которые входят отпускные и больничные дни.
Например, у нас в команде 2 аналитика: Lead и Middle+. Их капасити для спринта (10 дней):
(Lead+Middle+)*количество рабочих дней=(0.7+1)*10=17
Оценивая загрузку с помощью капасити в человеко-днях, можно оценить любую команду на любой срок. Мы можем понять, в каком направлении и насколько у нас недостаточная загрузка по команде, и рассмотреть варианты перекинуть специалиста в другую команду или добавить в бэклог спринта ещё одну фичу. Фичи приходят на оценку тоже в человеко-днях.

🔹 Результаты
▪️ Производительность команды стабильна и составляет свыше 90% от плана работ на спринт.
▪️ С учётом ограничений мы формируем полноценную загрузку команды по всем направлениям, к минимуму сводим простой сотрудников в спринте.
▪️ Внедрение капасити добавило дополнительную ценность для заказчика в виде прозрачности загрузки.

В нашем случае весь процесс внедрения занял 4 месяца. На это повлияло в большей степени то, что спринт на проекте длится в течение одного месяца, в команде около 20 человек: по 3–4 человека от каждого направления.
Для небольших команд – например, по 10 специалистов – для внедрения этого подхода будет достаточно и 1–2 спринтов, продолжительностью 2 недели. Это позволит понять, насколько он удовлетворяет потребности и что стоит в нём изменить.

Ограничения
1. Мы измеряем всё человеко-днями и в оценке фич, и в подсчете капасити. Если мы измеряем объёмы работы разными переменными, то свести их воедино будет проблематично – каждая будет жить своей жизнью.
2. Капасити – величина динамическая. Мы должны работать с верными и точными данными на проекте. Если все-таки кто-то уходит на больничный или в отпуск, то капасити пересчитывается. Благодаря этому мы формируем правильные ожидания у заказчика.
3. В подсчёте капасити учтены созвоны по фичам, активности лидов, но не учтены багофикс, техдолги и прочее. Исходя из особенностей проекта, его срока жизни, количество необходимых фиксов и задач техдолга может варьироваться от нескольких десятков до нескольких сотен.