Capacity

Capacity (ёмкость) продуктовой команды — это максимальный объём работы, который команда может выполнить за определённый период времени (спринт, квартал и т. д.) с учётом доступных ресурсов, навыков и внешних ограничений.

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

В чём смысл Capacity?

Capacity нужна, чтобы:
✅ Оценить, сколько задач команда реально может сделать (без переработок и выгорания).
✅ Сбалансировать нагрузку между разработкой, исследованиями, дизайном и другими активностями.
✅ Избежать иллюзий у стейкхолдеров ("Почему вы сделали только 5 задач, а не 10?").

Как Capacity помогает продуктовой команде?

1. Планирование спринтов – если Capacity команды 100 часов, а задачи оцениваются в 120 часов, что-то придётся убрать или перенести.
2. Прогнозирование сроков – если бэклог на 6 месяцев, а Capacity позволяет делать только 20% в месяц, релиз задержится.
3. Баланс между feature work и tech debt – если Capacity учитывает не только новые фичи, но и технические долги, команда не скатывается в хаос.
4. Переговоры с руководством – "Нам нужно больше людей, потому что Capacity не позволяет закрыть все запросы".

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

• Планирование спринтов (Scrum, Kanban).
• Оценка roadmap (сколько месяцев займёт реализация).
• Обсуждение найма новых сотрудников (если Capacity постоянно меньше потребностей).
• Анализ перегрузки команды (почему падает скорость? Может, Capacity давно не пересматривали?).

Плюсы Capacity

✔ Реалистичное планирование – меньше срывов сроков.
✔ Прозрачность для стейкхолдеров ("Почему мы не делаем быстрее?" – "Вот наши ресурсы").
✔ Защита команды от нереалистичных ожиданий.
✔ Выявление узких мест (например, дизайнеры загружены на 150%, а разработчики на 70%).

Минусы Capacity

❌ Неточные оценки – если Capacity считается "на глаз", а не на основе данных.
❌ Жёсткость – если команда не может гибко перераспределять ресурсы.
❌ Иллюзия контроля – Capacity не учитывает непредвиденные проблемы (болезни, баги, срочные задачи).

Выводы

1. Capacity – полезный инструмент, но не панацея.
2. Лучше считать Capacity на основе исторических данных (сколько задач обычно делаем за спринт?).
3. Важно пересматривать Capacity, если меняется состав команды или процессы.
4. Не стоит фетишизировать цифры – Capacity должна помогать, а не ограничивать.

Итог: Используйте Capacity, чтобы работать устойчиво, но не забывайте про гибкость. 🚀