¶ Блок 5 "Метрики эффективности проджекта"
¶ Зачем проджекту метрики?
Метрики — это не Excel ради Excel и не контроль ради контроля.
Они отвечают на управленческие вопросы:
-
Сколько работы команда реально может взять?
-
Насколько точно мы планируем спринт?
-
Где процесс замедляется?
-
Когда мы сможем выпустить фичу?
-
Есть ли риск не уложиться в сроки?
Без метрик управление превращается в интуицию.
С метриками — в систему.
Важно понимать:
метрики не оценивают людей — они оценивают процесс.
¶ 1. Capacity
¶ Что такое Capacity?
Capacity — это объём доступного ресурса команды на определённый период времени.
Проще говоря:
Сколько часов (или поинтов) команда реально может потратить на задачи в спринте.
Это плановая величина. Мы считаем её до начала спринта, чтобы понять, сколько работы можно безопасно взять.
¶ Почему нельзя считать 8 часов в день?
Потому что:
-
есть дейлики и созвоны,
-
есть обсуждения и ревью,
-
есть контекстные переключения,
-
есть форс-мажоры.
Реально продуктивное время обычно:
5–6 часов в день.
¶ Пример расчёта Capacity (в часах)
Предположим, у нас спринт длится 2 недели (10 рабочих дней).
Берём стандартную модель — 8 рабочих часов в день.
Состав команды:
-
Разработчики: 5 человек
-
Тестировщики: 3 человека
-
Дизайнер: 1 человек
¶ Расчёт
Разработчики:
- 5 человек × 10 дней × 8 часов = 400 часов
Тестировщики:
- 3 человека × 10 дней × 8 часов = 240 часов
Дизайнер:
- 1 человек × 10 дней × 8 часов = 80 часов
¶ Общая Capacity команды:
- Итого: 400 + 240 + 80 = 720 часов
¶ Теперь посчитаем ту же ёмкость через SP.
Пример расчёта Capacity через Story Points
Capacity команды — это объём работы, который команда может выполнить за один спринт.
Если команда использует Story Points, Capacity можно определить по тому, сколько SP команда обычно выполняет за один спринт.
Story Point — это условная мера сложности задачи.
Представим, что команда оценивает задачи:
- 1–2 SP — простая задача
- 3–5 SP — средняя задача
- 5–8 SP — сложная задача
Story Point не показывает количество часов или дней.
Представим, что команда уже несколько месяцев работает вместе и знает свою среднюю скорость.
За последние 3 спринта команда выполнила:
- Спринт 1 — 24 SP
- Спринт 2 — 28 SP
- Спринт 3 — 26 SP
Средняя Capacity:
- (24 + 28 + 26) / 3 = 26 SP
Значит, на следующий спринт команда может ориентировочно взять около 26 SP.
Как использовать Capacity при планировании
Предположим, Product Owner подготовил следующие задачи:
| Задача | Story Points |
|---|---|
| Задача A | 5 SP |
| Задача B | 8 SP |
| Задача C | 3 SP |
| Задача D | 5 SP |
| Задача E | 8 SP |
Общий объём:
- 5 + 8 + 3 + 5 + 8 = 29 SP
Capacity команды — 26 SP.
Значит, взять все задачи в спринт не получится.
Например, команда может взять:
- 5 + 8 + 3 + 5 = 21 SP
А задачу на 8 SP оставить на следующий спринт.
¶ 2. Velocity
¶ Что такое Velocity?
Velocity — это объём работы, который команда фактически завершила за спринт.
Ключевое слово — завершила.
Не «почти сделала», не «в процессе», не «на 90% готово»,
а именно довела до состояния Done.
Если упрощать:
-
Capacity — сколько ресурса у нас было
-
Velocity — сколько ценности мы реально доставили
Velocity считается в конце спринта и используется для прогнозирования будущих итераций.
¶ В чём измеряется?
Velocity может измеряться в:
-
Story Points (чаще всего в Scrum),
-
часах (в контрактной или аутсорс-модели),
-
количестве задач (реже и менее корректно).
Важно: внутри одной команды нельзя смешивать разные единицы измерения.
¶ Пример расчёта в часах
Допустим, на спринт было запланировано 100 часов задач.
К концу спринта команда полностью завершила задачи на 68 часов.
Часть задач осталась в статусе In Progress и не попала в релиз.
¶ Тогда:
Velocity = 68 часов
¶ Пример расчёта в Story Points
Допустим, в спринт было взято 40 SP.
Фактически завершены задачи на 32 SP.
¶ Тогда:
Velocity = 32 SP
Оставшиеся 8 SP переносятся в следующий спринт и в текущую velocity не входят.
¶ Зачем нужна Velocity?
Velocity позволяет:
-
прогнозировать сроки релизов,
-
понимать реальную скорость команды,
-
видеть стабильность работы,
-
корректировать планирование.
Если команда 3–4 спринта подряд показывает velocity около 30 SP,
значит, разумно планировать следующие спринты в диапазоне 28–32 SP.
¶ 3. Focus Factor
Focus Factor — это показатель того, насколько команда сосредоточена на выполнении запланированных задач в спринте. Он показывает, какая часть запланированного объёма работы была реально выполнена и помогает оценить точность планирования.
Формула:
Focus Factor = Velocity / Запланированный объём × 100%
Пример:
Запланировано: 90 часов
Сделано: 63 часа
Focus Factor = 63 / 90 × 100 = 70%
В терминах story points: если в спринт запланировано 50 SP, а команда закрыла 45 SP, то Focus Factor = 45 / 50 × 100 = 90%
Чем выше Focus Factor, тем точнее команда выполняет план. Низкий показатель может говорить о недооценке задач, отвлечениях или неверном распределении ресурсов.
¶ 4. Time to Market (TTM)
¶ Что такое Time to Market?
Time to Market (TTM) — это время от появления идеи до выхода продукта или фичи в продакшен.
Проще говоря:
Сколько времени проходит с момента «Давайте сделаем»
до момента «Пользователи уже этим пользуются».
Это уже не только командная, но и бизнес-метрика.
Чем быстрее компания доставляет ценность — тем выше её конкурентоспособность.
¶ Почему TTM важен для PM?
Time to Market напрямую влияет на:
-
скорость получения прибыли,
-
конкурентные преимущества,
-
удовлетворённость клиентов,
-
гибкость бизнеса.
Если две компании делают одинаковый продукт, выиграет та, которая выводит фичи быстрее.
¶ Из чего состоит Time to Market?
TTM можно разложить на несколько этапов:
-
Формирование идеи
-
Аналитика и проработка требований
-
Дизайн
-
Разработка
-
Тестирование
-
Релиз
Чтобы лучше управлять скоростью, используют дополнительные метрики:
¶ Lead Time
Lead Time — это время от начала аналитики до релиза в прод.
То есть:
Когда задача попала в работу —
и когда она стала доступна пользователям.
¶ Cycle Time
Cycle Time — это время от начала разработки до релиза.
Здесь аналитика уже завершена, и команда приступила к реализации.
¶ Пример
Допустим:
-
Идея появилась 1 марта
-
Аналитика началась 5 марта
-
Разработка стартовала 15 марта
-
Релиз состоялся 30 апреля
Тогда:
Time to Market = 1 марта → 30 апреля
Lead Time = 5 марта → 30 апреля
Cycle Time = 15 марта → 30 апреля
¶ Где возникают проблемы?
Чаще всего замедление происходит из-за так называемых bottlenecks (узких мест).
Это этап, где задачи начинают накапливаться и «застревать».
Типовые узкие места:
-
долгое согласование требований
-
перегруженный дизайнер
-
очередь на тестировании
-
сложный процесс релиза
-
зависимость от другой команды
¶ Пример узкого места
Задачи стабильно задерживаются на тестировании.
Возможные решения:
-
добавить тестировщика
-
внедрить автотесты
-
обязать разработчиков писать unit-тесты
-
изменить приоритизацию задач
Важно: каждое решение имеет цену.
Добавление человека требует времени на онбординг.
Автотесты требуют инвестиций.
PM должен выбрать вариант с наилучшим балансом скорости и затрат.
¶ Как использовать TTM на практике?
-
Измерять среднее время доставки фич
-
Сравнивать показатели от спринта к спринту
-
Анализировать, на каком этапе возникает задержка
-
Оптимизировать именно проблемный этап, а не весь процесс сразу
¶ 5. Burndown Chart
¶ Что такое Burndown Chart?
Burndown Chart — это график «сгорания» работы в спринте.
Он показывает, как уменьшается объём оставшихся задач по мере прохождения спринта.
Проще говоря:
Сколько работы осталось — и успеваем ли мы к дедлайну.
Это один из самых популярных инструментов контроля прогресса в Scrum.
¶ Как устроен график?
По вертикали — объём оставшейся работы
(часы или Story Points).
По горизонтали — дни спринта.
В начале спринта объём максимальный.
К последнему дню он должен дойти до нуля.
¶ Идеальная картина
Идеальный Burndown выглядит как почти прямая линия вниз.
Это значит:
-
задачи закрываются равномерно,
-
нет перегрузки в конце,
-
процесс предсказуемый.
¶ Что можно увидеть по графику?
¶ 1. Плоская линия в начале спринта
Команда долго не закрывает задачи.
Возможные причины:
-
задачи слишком крупные,
-
слабая декомпозиция,
-
задержки на старте,
-
блокеры.
¶ 2. Резкое падение в конце
Большинство задач закрываются в последние дни.
Это сигнал, что:
-
задачи декомпозированы слишком крупно,
-
тестирование откладывается на конец,
-
команда «закрывает пачкой».
Это рискованная модель — если что-то пойдёт не так, времени на исправление не останется.
¶ 3. Линия идёт вверх
Объём работы увеличился.
Причины:
-
добавили новые задачи,
-
пересмотрели оценки,
-
всплыл технический долг.
Это нормально, если контролируется.
Но если происходит регулярно — значит, спринт плохо защищён от изменений.
¶ Пример
Допустим, в спринт взяли 60 SP.
Идеальная динамика:
-
День 1 — 60 SP
-
День 5 — 35 SP
-
День 8 — 15 SP
-
День 10 — 0 SP
Если к 8 дню остаётся 40 SP —
значит, есть риск не успеть.
Burndown позволяет увидеть это заранее, а не в последний день.
¶ Зачем он нужен PM?
Burndown помогает:
-
быстро понять, идём ли мы по плану,
-
обнаружить проблемы в середине спринта,
-
вовремя перераспределить задачи,
-
принять решение о снижении объёма.
Это инструмент раннего предупреждения.
¶ Важный момент
Burndown не оценивает людей.
Он показывает:
-
динамику выполнения,
-
стабильность процесса,
-
риски срыва сроков.