Команда регулярно выпускает новые фичи и трудится в поте лица, а продукт почему-то отстаёт от графика. Сглазили? Возможно. Но скорее проекту не хватает показателей, чтобы отслеживать влияние проделанной работы на бизнес.
Метрики эффективности помогают команде провести диагностику процессов и понять, соответствуют ли они ожиданиям и целям компании. Если один из показателей сбоит, это повод перебрать возможные причины, построить гипотезы и начать тестировать решения. Обсудим, как это сделать, чтобы все были в выигрыше.
Что такое метрики эффективности и зачем их отслеживать
— измеримые показатели, которые помогают оценить работу команды, успехи проекта или процесса. Они могут показывать скорость работы, качество, предсказуемость и другие важные характеристики
Зачем нужны метрики
Без метрик менеджер проекта оценивает продвижение работы интуитивно — с опорой на личные представления о том, что такое хороший результат. И опыт действительно может давать верные подсказки! Тем не менее ничто не укажет на сильные и слабые стороны процесса так точно, как это умеют цифры. Если подружиться с фактами, будет легче принимать управленческие решения, планировать нагрузку и влиять на развитие продукта.
При этом просто посмотреть на количество выполненной работы и сделать выводы об эффективности не получится. Разработчик может написать 2000 строк сложного кода там, где было более быстрое и лаконичное решение. Несмотря на объём проделанной работы, польза для проекта здесь скорее отрицательная — из-за растущего техдолга.
Зато вот как можно оптимизировать процесс, опираясь на метрики:
Метрики — то же, что KPI?
KPI (Key Performance Indicator) — ключевой показатель эффективности, или КПЭ. Это такой инструмент, который показывает, как бизнес, команды или сотрудники достигают стратегических целей. Метрики эффективности — любой измеримый показатель. Они помогают точнее оценить, что происходит внутри рабочего процесса.
На приборной панели автомобиля есть куча разных индикаторов, которые показывают состояние системы: скорость, уровень топлива, обороты двигателя. Это всё метрики. Некоторые из показателей напрямую связаны с целью поездки — скажем, доехать до точки Б за три часа. Чтобы её достичь, нужно поддерживать скорость не менее 80 км/ч. Это KPI.
Однако если смотреть только на него, легко упустить из виду другие сигналы — то, как стрелка уровня топлива отчаянно стремится влево, а лампа замены масла мигает всё чаще. Тогда мы будем ехать с нужной скоростью — но ровно до тех пор, пока машина не заглохнет посреди трассы. Поэтому для эффективности проекта важно отслеживать разные показатели.
Каждая метрика показывает нам определённый аспект нашей системы. Например, можно увеличить пропускную способность, но одновременно получить рост незавершённой работы и времени производства. Формально команда делает больше, но результат быстрее не доставляет
Я предпочитаю смотреть на набор взаимосвязанных метрик. В потоке они как раз позволяют увидеть систему с разных сторон: сколько работы мы завершаем, сколько ещё находится внутри системы и сколько времени занимает её прохождение по доске от начала и до конца
Собирать вообще все известные метрики тоже не стоит. Часть из них будет избыточной: вы потратите время, но не получите ощутимого эффекта. Хороший набор метрик — тот, который позволяет однозначно понять, движемся мы к нужному результату или нет, и при этом помогает принимать решения
Если говорить шире, то метрики эффективности стоит связывать с целью проекта. Сам факт того, что время производства снизилось, ещё не означает, что проект стал успешнее. Нужно понимать, зачем мы его сокращаем и какой результат для бизнеса или пользователя хотим получить
Какие метрики используют в IT
Есть две большие группы IT-метрик: потока задач и поставки ПО. Первые используют для управления процессами по Scrum и Kanban. Они показывают, как задачи движутся по этапам разработки и как быстро реализуется бизнес-ценность от идеи до получения пользы. Вторые, метрики поставки ПО, нужны, чтобы оценить скорость и стабильность работы команды программистов с технической точки зрения. Вот они, слева направо сверху вниз:
Метрики потока задач
Lead Time (время выполнения) показывает время от принятия задачи командой до её полного завершения. Учитывает, сколько задача прождала в очереди.
❗️Важно сразу определить и зафиксировать точку, в которой задача будет считаться принятой, — например, это может быть дата создания карточки или первичный скоринг. Отсюда и начинается отсчёт времени выполнения. Если же постоянно выбирать точкой старта разные события, сравнить показатели нормально не получится.
Cycle Time (время цикла) тоже измеряет время, но, в отличие от соседа Lead Time, не учитывает промежуток ожидания в бэклоге. Cycle Time нужен, чтобы проследить путь задачи от момента начала работы над ней до её завершения. Сюда же входят паузы, которые могут возникнуть после старта.
Throughput (пропускная способность) подсчитывает количество задач, завершённых за определённый период. Например, команда закрыла 10 задач за месяц — это и есть её пропускная способность. Вот так легко!
WIP (Work in Progress, работа в процессе) показывает, сколько задач команда начала, но ещё не закончила на момент замера. Если таких задач становится слишком много, работа идёт сразу по нескольким направлениям, а сотрудники чаще переключаются между ними.
🤓 Кстати, количество незавершённой работы можно ограничивать! Такой приём даёт возможность сосредоточиться на действительно важных задачах и успевать больше. В таск-менеджере Weeek есть настройки колонок: заходишь туда и выбираешь максимум задач, которые команда может взять на определённом этапе. Теперь система покажет, насколько заполнена колонка:
Work Item Age (возраст элемента работы) показывает время, прошедшее с момента начала работы над задачей. Применяется только для незавершённой работы. Когда её выполнили, возраст перестаёт расти и метрика превращается в Cycle Time.
Velocity (скорость) оценивает объём работы, который команда выполняет за спринт. Используется для внутреннего планирования, чтобы предположить, сколько задач команды смогут взять в следующий период.
Метрики поставки ПО: пять DORA-метрик
— показатели эффективности процессов разработки и поставки программного обеспечения. Название получили от создателей — исследовательской группы DevOps Research and Assessment, принадлежащей Google
DORA-метрики отражают уровень зрелости DevOps-процессов и скорость технического конвейера. Измеряются только в контексте одного приложения или сервиса, так как у каждого продукта своя архитектура и уровень сложности. Всего их пять:
Lead Time for Changes (время выполнения изменений) показывает, сколько времени проходит от коммита кода до его попадания в продакшен. Данные для оценки берутся из системы контроля версий — она отмечает точное время создания изменений в коде. Чтобы узнать точку финиша, обращаются к системе автоматизации.
Lead Time из метрик потока и Lead Time for Changes кажутся похожими. Их может быть легко перепутать. Запомни важное отличие: Lead Time оценивает путь задачи с точки зрения бизнеса, Lead Time for Changes — со стороны разработки.
Deployment Frequency (частота развёртывания) измеряет, как часто команда успешно выпускает обновления в продакшен. Чем чаще релизы, тем они меньше и безопаснее. Данные для измерения берут из отчётов систем автоматизации CI/CD.
Failed Deployment Recovery Time (время восстановления после неудачного развёртывания) оценивает срок от сбоя в продакшене до восстановления нормальной работы сервиса. Источником данных могут быть системы мониторинга или управления инцидентами, которые помогают установить момент сбоя. Чтобы зафиксировать точку исправления, используют системы автоматизации.
Change Failure Rate (доля неудачных развёртываний) нужна для расчёта процента релизов, которые привели к деградации сервиса или потребовали вмешательства для его восстановления. Данные берутся из систем автоматизации и мониторинга.
Deployment Rework Rate (частота исправлений при развёртывании) — доля кода или задач, которые потребовали доработок из-за некорректно реализованных требований. Данные можно найти в таск-менеджере и системе контроля версий.
Как выбрать метрики и внедрить их в работу
Принцип «чем больше, тем лучше» вообще работает редко. С метриками уж точно! Как бы ни хотелось на волне вдохновения попробовать всё и сразу, сложные дашборды со старта и куча показателей крупно рискуют превратиться в беспорядок. Потом ищи того, кто будет с ним разбираться... Нет, всё-таки лучше выбрать другой подход.
Шаг 1. Определи цель
Для начала выбери конкретную бизнес- или техническую проблему. Ведь к ней и нужно подобрать ключик! Какой именно — подскажут данные. Задай себе вопрос: «Что я хочу улучшить?» Например, клиенты жалуются, что баги фиксятся неделями. Или крупные релизы каждый раз оборачиваются негативом, потому что приложение начинает жутко тормозить. А вдруг всё вместе?.. Ой!
Шаг 2. Наведи порядок в системах
Качественные показатели ну никак не собрать без надёжных источников данных. Если в процессах нарушена логика, метрики будут обманывать — конечно, не специально. С командой лучше договориться о статусах, чётко зафиксировать правила перемещения задач в таск-менеджере, разделить задачи по типам — баг, фича, техдолг или другой. Аналогично с DevOps-инструментами: нелишним будет привести к единому стандарту коммиты, зафиксировать, что считается деплоем, и связать алерты с инцидентами.
Шаг 3. Настрой сбор данных
Алгоритм зависит от сервиса, где работает команда. В некоторых системах управления задачами есть встроенные отчёты — например, статистику по проекту или отдельному члену команды можно посмотреть в Weeek. Отчёт представлен как график, где каждый столбец показывает количество задач за один день. Сверху видно затраченное время:
Шаг 4. Анализируй результаты
В метрики важно не только погрузиться самому, но и подключить команду. Это полезно, чтобы все могли увидеть слабые места и найти решения вместе. На дейликах смотри на возраст задачи. Это поможет ускорить её движение. Для ретроспектив пригодятся показатели времени цикла и количества незавершённых задач — чтобы подумать, как мы докатились до жизни такой. При планировании оцени пропускную способность. Так ты распределишь нагрузку точнее.
Условно, если вы собрали метрики за 2025 год, но решили оценить их только в конце 2026 года — это поздно. А вот проводить ретроспективу по разбору метрик за 1-2 прошедших спринта — самое то
Ежедневно можно смотреть на количество незавершённой работы и её старение (Work Item Age) — при условии, что стоит задача оперативно обнаруживать зависшую работу. Для анализа времени производства, пропускной способности и трендов полезнее брать более длинный период. Иначе мы начинаем реагировать на естественные колебания системы и принимать поспешные решения
Так что универсального правила смотреть раз в неделю или раз в месяц нет. Частота должна зависеть от скорости изменения системы и от управленческих решений, которые мы принимаем
Пример оценки IT-проекта: от исходных данных до решения
Чтобы избежать эффекта «ничего не понятно, но очень интересно», приведём учебный пример. Представим, что команда разработки создаёт сайт для крупного заказчика — с каталогом, формой оплаты, личным кабинетом. В первом спринте команда выполнила и выкатила в прод 60 задач. Внешне всё выглядело хорошо.
Однако внутри процесса назревал кризис. Заказчику не нравилось, что простые задачи вроде добавления баннера теряются в разработке на недели. На стендапах коллеги говорили о высокой нагрузке: каждый из них вёл по 3-4 задачи, постоянно переключая контекст. Менеджер постепенно терял контроль над сроками и не мог спрогнозировать выход следующей фичи. Наконец, два деплоя из шести закончились сбоями.
Нужно было что-то делать, и менеджер решил начать с оцифровки происходящего. Он выгрузил данные из таск-трекера и системы автоматизации за истекший период. Затем провёл несколько расчётов:
- WIP: 20 задач со статусом «В работе». Они перегружают команду и заставляют прыгать от задачи к задаче
- Lead Time: от создания заявки менеджером до релиза проходило в среднем 18 дней. При этом показатель Cycle Time сводился к 10 дням
- Deployment Frequency: 6 деплоев за месяц. Один деплой раз в 5 дней. Показатель говорит о низком уровне зрелости процессов. Внутри одного релиза на прод уходит код, накопленный за неделю
- Change Failure Rate: 2 деплоя из шести привели к аварии. 2/6*100% = 33,3% — довольно высокий процент сбоёв
Эти цифры менеджер принёс на ретроспективу и предложил договориться о правилах на второй спринт. Во-первых, ввели WIP-лимиты — нельзя брать в работу новое дело, пока не закрыто старое. Одновременно можно вытягивать не более десяти карточек на команду. Во-вторых, на ежедневных встречах решили контролировать Work Item Age — если задача застревает в одном статусе дольше трёх дней, её нужно продвинуть. Ещё отказались от еженедельных релизов в пользу автоматического CI/CD, когда готовый маленький фрагмент кода сразу катится на прод.
Теперь разработчики смогли сфокусироваться на завершении работы. Команда начала деплоить каждый рабочий день. Так как релиз содержал минимум изменений, искать среди них баги стало проще, а фичи больше не конфликтовали друг с другом.
В конце второго периода менеджер снова сел за расчёты:
- WIP снизился до десяти задач, что избавило от ощущения аврала
- Lead Time сократился до девяти дней, а Cycle Time — до пяти. Это значит, что бизнес стал получать фичи в два раза быстрее
- Deployment Frequency теперь один раз в день
- Change Failure Rate упал с 33,3% до 10%. Сайт работает стабильно
По результатам в выигрыше все: команда работает в спокойном режиме и погружается в решение одной задачи за раз, заказчики получают стабильную пользу, сайт работает без перебоев и не нуждается в срочном участии разработчиков при сбое. А менеджер имеет на руках достаточное количество данных, чтобы планировать загрузку и выход фич. Всего этого не получилось бы добиться, если бы управление опиралось только на ощущения. Метрики помогли найти слабые места и разработать подходящее решение.
Как анализировать метрики IT-проекта
Чтобы метрики не превратились в измерения ради измерений, они должны переходить в управленческие решения и влиять на процессы. Для этого можно двигаться по схеме: сигнал → проверяемая гипотеза → возможное действие. Посмотрим, как переложить её на некоторые метрики:
| Метрика | Что происходит | Что думать | Что делать |
|---|---|---|---|
| Lead Time | Показатель растёт, хотя Cycle Time в пределах нормы | Задачи слишком долго остаются на этапе предварительного анализа или согласований | Утвердить набор критериев, которым должна соответствовать задача для того, чтобы её можно было взять в работу (Definition of Ready). Проводить планирование чаще |
| Cycle Time | Время разработки растёт, пропускная способность падает | В процессе появилось «узкое место», или задачи слишком объёмные | Провести аудит этапов разработки. Дробить крупные дела на подзадачи |
| Velocity | Скорость колеблется от спринта к спринту | Нет единого понимания баллов Story Points. Может быть влияние внешних факторов | Откалибровать оценку через покер планирования. Не брать задачи с блокерами |
| WIP | Объём задач в работе растёт, но пропускная способность стоит на месте | Фокус команды потерян. Разработчики могут бросать сложные задачи и браться за новые попроще | Установить WIP-лимиты |
| Work Item Age | Отдельные задачи висят дольше среднего времени разработки | Задача столкнулась со сложностью или ждёт внешнего ответа | Сделать такие задачи главным фокусом встреч. Назначить ответственного |
| Deployment Frequency | Команда стала выкатывать код значительно реже | Релизы стали слишком тяжеловесными. Ручной регресс занимает много времени. Появились бюрократические трудности | Инвестировать в автотесты в CI/CD. Упростить согласование |
| Change Failure Rate | Процент проблемных релизов вырос | Скорость выросла в ущерб качеству. Ревью проводится формально | Ужесточить правила код-ревью |
Частые вопросы о метриках эффективности
Какие метрики выбрать для небольшого проекта?
Если речь именно про эффективность поставки, то для небольшого проекта я бы начал с трёх метрик: время производства (Lead time), пропускная способность (Throughput) и количество незавершённой работы (WIP)
В целом этого будет достаточно, чтобы сформировать базовое представление об эффективности потока. Если вы работаете по Scrum, спринтами, то полезными могут быть метрики предсказуемости спринта (соотношение запланированных целей спринта к выполненным и соотношение запланированных Story Points к закрытым) и скорость (Velocity) с ёмкостью (Capacity) команды — для работы с последними двумя нужно оценивать задачи в Story Points. Они служат отражением производительности команды и позволяют планировать работу
Если есть проблема с долгоживущими задачами, добавил бы мониторинг старения незавершённой работы (Work Item Age). Так вы сможете выявлять наиболее старые задачи и фокусно работать с ними. Время цикла (Cycle time) имеет смысл использовать, если интересно посмотреть, сколько времени проводят задачи в конкретных этапах вашего процесса, например только в разработке или только в тестировании
Главное — не пытайтесь внедрить всё сразу и не собирайте метрики ради галочки. Большое количество таких показателей само по себе не делает управление точнее
Что делать, если данных пока мало?
Если же данные есть, но их мало, не обязательно ждать, пока накопится «достаточно». Вам уже есть что изучить и на основании чего строить гипотезы. Главное — не забывайте об ограничениях текущей выборки данных. Особенно осторожно я бы относился к попытке делать выводы по средним значениям на маленьком объёме данных. Например, несколько закрытых задач ещё не дают нам надёжного представления о типичном времени производства команды
На старте важнее получить базовый ориентир и дальше смотреть на динамику. По мере накопления данных мы сможем видеть распределение, выбросы, тренды и точнее прогнозировать результат
