Когда команда состоит из десяти человек, понять, что происходит с поставкой, просто. Но когда инженеров становится больше, интуиция и метрики начинают подводить. А понять, стали мы работать лучше или хуже, получается всё сложнее.
Меня зовут Сергей Долгодворов, я тимлид онлайн‑бухгалтерии в Точка Банк. В статье расскажу про набор показателей, с помощью которых можно быстро понять состояние команды и управлять процессом поставки. Он помог нам увеличить пропускную способность на 39% и сэкономить компании 112 миллионов рублей.
Когда данных слишком много
За последние годы наша команда сильно выросла. Когда я пришёл, в онлайн‑бухгалтерии было всего 10 человек. Сейчас в кластере больше 50 инженеров.
По мере роста команды менялось всё: продукт, процессы, инженерные практики. Параллельно росло и количество доступных данных. И в какой‑то момент возникла проблема: я перестал понимать, улучшается ли процесс поставки или мы просто имитируем бурную деятельность?
На тот момент у нас было много разных метрик, но данные были разрознены. А хотелось получить некий «светофор», глядя на который можно сразу понять, в порядке ли всё с командой или нужно бить тревогу.
Почему нам не подошла DORA
Сначала мы смотрели в сторону стандартных метрик DORA, которые включают четыре параметра:
Deployment Frequency — частота развёртывания.
Lead Time for Changes — время выполнения изменений.
Change Failure Rate — время восстановления после сбоев.
Mean Time To Recovery — частота сбоев при изменениях.
С помощью этих показателей можно оценить зрелость процесса разработки. Но на практике возникли сложности.
Разные процессы релиза. Внутри кластера разрабатывается много сервисов, и процессы релизов исторически были очень разные — где‑то через теги, где‑то через слияние с ветками, где‑то через отдельный пайплайн. Поэтому весь этот зоопарк пришлось бы сводить к единому виду.
Проблемы с Change Failure Rate. Для расчёта метрики нужно понимать, какой релиз оказался успешным, а какой привёл к проблемам. Часть ошибок мы видим через системы мониторинга, но значительное количество проблем обнаруживают сами клиенты. Автоматически связать их с конкретным релизом трудно.
MTTR требует сквозной связности данных: для расчёта времени восстановления нужно объединить данные из множества систем — мониторинга, релизного процесса, трекера задач, системы управления инцидентами.
В итоге мы пришли к выводу, что внедрение DORA потребует слишком больших изменений в процессах. Пришлось бы перекраивать всю инфраструктуру релизов, поэтому решили отложить эту идею и пойти другим путём.
Наша система метрик
Мы решили разработать собственный подход и выбрать показатели, по которым будет сразу понятно, что происходит с командой. Для этого использовали два типа метрик:
Стратегические: отвечают на вопрос «что происходит?». Помогают быстро оценить состояние команды, понять, насколько стабильно идёт поставка и на что уходят основные усилия.
Тактические: отвечают на вопрос «почему это происходит?». Позволяют детально разобрать конкретный участок процесса и найти источник проблемы.
Таким образом, у нас получилась выстроенная система:
Сигнал → Диагностика → Улучшение
То есть сначала стратегические метрики показывают отклонение от нормы, затем тактические помогают найти причину. Такой подход оказался гораздо полезнее десятков разрозненных графиков.
Стратегические метрики
Для оценки текущего состояния команды мы собрали радар из шести показателей. В центре радара находятся три базовые метрики, которые дают общую оценку: зелёный, жёлтый, красный.
Скорость поставки помогает понять, ускоряемся мы или тормозим. Рассчитывается как соотношение текущей скорости к базовой (скользящее среднее за 3–4 месяца).
Предсказуемость показывает, насколько сильно тормозят самые долгие задачи по сравнению с типичными (сравниваем 50-й и 85-й перцентили времени выполнения).
Вариативность показывает, как сильно отличается объём завершённых задач от периода к периоду. Например, если команда завершает 35 задач в одну неделю и 5 задач в следующую, а затем снова 30, то предсказуемость процесса низкая.
Также есть три вспомогательные метрики для лучшего погружения в контекст:
Загруженность потока (WIP) — количество задач, которые одновременно находятся в работе.
Объём поставки — количество завершённых задач за период.
Время цикла — текущая скорость выполнения задач.
Такой набор метрик работает как приборная панель автомобиля: не объясняет причины проблем, но позволяет быстро понять, что в процессе поставки что‑то изменилось и требует внимания команды.
Тактические метрики
Когда стратегические показатели сигнализируют о проблеме, мы опускаемся на уровень тактических метрик:
-
Время цикла и время производства: показывают, как долго задача в работе до её завершения. Смотреть лучше не на среднее значение, а на 50-й перцентиль, 85-й перцентиль и динамику изменения во времени.
Пропускная способность: количество задач, завершённых за период. По сути, это замена Velocity, но без привязки к конкретной методологии. При этом важно анализировать не только объём, но и его стабильность.
Распределение времени цикла: показывает разброс времени выполнения задач и частоту их появления. Позволяет увидеть длинные «хвосты» — задачи, которые длятся непозволительно долго. Или, наоборот, много мелких задач, из‑за которых приходится часто переключаться, что ведёт к замедлению работы над основным потоком.
-
Разбивка времени цикла: показывает время выполнения задачи по этапам и позволяет обнаружить узкие места процесса.
Например, диаграмма Санкей на тему разбивки времени цикла подарила нам важные инсайты. Мы обнаружили, что часть обязательных этапов процесса фактически не используется. То есть формально они существуют, но задачи почти никогда через них не проходят.
На что тратится время
Второй важный блок метрик показывает, куда на самом деле уходят усилия команды. Скорость поставки сама по себе не объясняет происходящее. Две команды могут показывать одинаковые показатели по времени цикла и пропускной способности, но за ними могут скрываться совершенно разные процессы.
Чтобы сделать эту картину видимой, мы разделили задачи на три категории:
Рутина: поддержание существующей системы (ошибки, техдолг, сопровождение).
Развитие: то, что улучшает продукт (новые фичи, развитие внутренних инструментов).
Пожары: всё, что появляется внезапно (баги, инциденты, срочные задачи, которые «нужно было сделать ещё вчера»).
Особенно полезно смотреть на эти категории в динамике. Такое разделение позволяет увидеть то, что обычно остаётся за пределами классических метрик поставки. Снижение скорости, например, может быть вызвано не проблемами процесса, а ростом количества инцидентов. А команда, которая показывает высокий объём поставки, может практически не заниматься развитием продукта.
Такой дашборд помогает гораздо лучше интерпретировать остальные метрики и понимать причины происходящих изменений.
Примеры из практики
Давайте посмотрим на несколько примеров из реальной жизни.
Команда А. Объём поставки варьируется. Скорее всего, задачи перетекают из итерации в итерацию, предсказуемость низкая. Если команда берёт задачу в работу, то с большой долей вероятности не попадёт в срок. Задачи на «развитие» выполняются охотно, но вместе с тем растут и «Пожары».
Вывод: команда берётся за новые фичи, но не учитывает риски и не закладывает время на рутину. Это приводит к авралам. Такой команде я бы посоветовал увеличить долю «рутины» для предотвращения пожаров, даже если это замедлит развитие в моменте.
Команда Б. Объём поставки стабильный, предсказуемость высокая, задачи сдаются в срок. Скорость выполнения держится на хорошем уровне, но есть небольшой нисходящий тренд и редкие «пожары». Задач на развитие становится всё больше, и они, вероятно, накапливаются.
Вывод: возможно, снижение скорости вызвано тем, что команда тратит время на поддержание сложного кода. Им стоило бы обратить внимание на техдолг.
Что нам дали новые метрики
Сами по себе метрики ничего не улучшают. Но благодаря им мы можем системно учиться на своих ошибках. Этот процесс выглядит так:
Фиксируем сигнал на стратегическом радаре.
Спускаемся к тактике, находим причину.
Формулируем гипотезу и проводим эксперимент (2-4 спринта).
Оцениваем эффект по данным. При этом отсутствие эффекта — тоже результат.
Например, в прошлом году мы поставили цель — управлять процессом поставки. И смогли уменьшить время цикла с 14 до 10 дней, а также увеличить пропускную способность на 39%.
Также мы попробовали посчитать экономический эффект, сравнив первый и четвёртый квартал. Взяли дельту пропускной способности и пересчитали её в FTE (полный рабочий день). Получилось, что мы приросли примерно на 25 условных инженеров без дополнительного найма. В деньгах, если умножить на средний фонд оплаты труда инженера, это около 112 миллионов рублей в год дополнительной производственной мощности.
Немного выводов
Проблема редко заключается в отсутствии метрик, скорее в их избытке. Когда команда смотрит одновременно на десятки показателей, становится трудно понять, что действительно важно. В результате значительная часть времени уходит не на улучшение процесса, а на попытки разобраться в самих данных.
В конечном счёте задача метрик не построить ещё один красивый дашборд, а помочь команде замечать проблемы и лучше понимать собственную работу. Тогда метрики выполняют свою функцию независимо от того, сколько их в системе — пять или пятьдесят.