Всем привет! Я, Дианов Стас, product manager. Сегодня разработка фичей и продуктов действительно очень похожа на сложный производственный конвейер, только вместо токарных станков — Jira, пайплайны CI/CD и вечный, леденящий душу вопрос «а когда в прод?» от бизнеса.

На таком «заводе», особенно если мы говорим о финтехе с его регуляциями и ценой ошибки, выживают те команды, которые не только пишут чистый код, но и умеют измерять, как этот код проходит путь от идеи до продакшена. Об этом и поговорим.

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

Зачем вообще нужны метрики и причем тут команда разработки?

Бизнес, как правило, всегда хочет одного: чтобы мы делали гораздо больше, чем физически позволяет размер команды. Желание «впихнуть невпихуемое» — это классика. 

Для тимлида и продакта метрики — это не «цифры ради отчёта», а способ ответить на простые вопросы: почему мы всё время опаздываем, где именно застревают задачи и как ускориться, не превратив команду в цех переработки нервной системы в страдания.

Метрики помогают увидеть реальный поток задач, а не ощущение «мы же целый день заняты», и позволяют говорить с бизнесом на языке скорости и рисков, а не «нам ещё немного пооптимизировать».

Еще раз скажу: разработка — это «поток», а не магия.

Чтобы управлять этим потоком без шаманства, обычно смотрят на время цикла (сколько реально делаем задачу), пропускную способность (сколько задач финишим за период) и WIP — сколько задач держим «в работе одновременно».

Как мы искали идеальную метрику и почему из семи оставили только одну

Когда наш продукт  и команда росли, и давление бэклога усилилось, мы в команде поняли, что нам нужна прозрачность. Никто не спускал нам директив сверху и не заставлял насильно внедрять «слежку». Мы сами, по личной инициативе, решили оцифровать свою работу, чтобы процессы стали кристально понятными для всех. Для этого выписали пул из 7 метрик, которые должны были помочь нам стать лучше:

1. Отработанные часы в Jira (с точностью до 15 минут, чтобы видеть, куда уходит время).

2. Индивидуальная Velocity (сжигание Story Points на конкретного разработчика).

3. Time to Market (считали от первой идеи бизнес-заказчика до продакшена).

4. Throughput (пропускная способность — сколько карточек мы закрываем).

5. WIP (лимиты на количество задач в работе).

6. DORA (метрики частоты деплоев и стабильности).

7. Cycle Time (время выполнения задачи от «In Progress» до «Done»).

Что произошло дальше? Классическое «KPI-караоке» методом перебора

Мы не вываливали все эти метрики разом. Мы пошли путем последовательных экспериментов: брали одну метрику, пробовали с ней жить, понимали, что она ломает процесс или не приносит пользы, отказывались от нее и переходили к следующей. Никаких штрафов или выговоров за «плохие цифры» у нас не было в принципе, но удивительным образом система всё равно раз за разом хакалась нашим же подсознанием.

Сначала мы попробовали трекать часы в Jira. Хотели кристальной прозрачности, но в итоге товарищи разработчки тратили по полчаса в день просто на то, чтобы вспомнить и аккуратно раскидать свои 8 часов по таскам. Мы быстро поняли, что это бессмысленная рутина, и отказались от нее.

Следующей гипотезой стала Индивидуальная Velocity. И тут сработала психология: люди (сами того не замечая) перестали брать сложные задачи или очень сильно дробили их. Зачем рисковать закопаться и испортить свою красивую статистику спринта? Вместо этого разработчики начали наперегонки разбирать легкие минорные баги. Увидев, что командная работа превращается в соревнование, мы свернули и этот эксперимент.

Дальше мы взялись за Time to Market. Ситуация стала ещё абсурднее. Задача могла месяцами лежать в бэклоге, пока бизнес писал аналитику, а итоговый график TtM показывал «медленную команду». И хотя санкций не следовало, ребят это дико демотивировало — цифры выглядели так, будто мы плохо работаем. Мы осознали, что оценивать инженерию метрикой, на которую она влияет лишь частично, бессмысленно.

Пытаясь найти рабочую альтернативу, мы поочередно пробовали опираться на Throughput, WIP и DORA. Но без уже выстроенной культуры это тоже давало сбои: Throughput за счет искусственного дробления задач на микроскопические части, а попытка деплоить чаще (ради красивых метрик DORA) приводила к нестабильности тестовых стендов.

Развязка. Пройдя путь проб и ошибок, мы собрали большое ретро, честно обсудили наш опыт и признали: мы искали не там. Мы выкинули весь индивидуальный трекинг, который невольно искажал мотивацию, и отказались от перебора сложных систем.

Мы остановились только на Cycle Time. Почему? Потому что это единственная метрика из списка, которая честно оценивает работу всей системы (процесса), а не утилизацию конкретного человека. Она показала нам, где лежат реальные проблемы в разработке, не заставляя инженеров подстраиваться под графики.

Что такое «Cycle Time»?

Cycle Time — это время от момента, когда команда действительно начала работать над задачей, до момента, когда результат можно считать завершённым (обычно — до состояния «в проде» или хотя бы Done, если релизы батчевые). В классическом определении это от входа в «In Progress» до попадания в «Done».

Cycle Time начинается, когда задача переведена из To Do в первый «рабочий» статус — например, In Progress или «В разработке». А заканчивается, когда задача находится в статусе Done или «В продакшене» (главное, договориться, учитываете ли вы время релиза внутрь Cycle Time).

Важный момент: ожидание в бэклоге — это не Cycle Time, это lead time и вопросы приоритизации, поэтому «лежит в backlog две недели» не должно портить вам картину по скорости выполнения.

В чём измерять?

• В большинстве продуктовых команд имеет смысл мерить Cycle Time в рабочих днях; для инцидентов и срочных багов — в часах.

• Для анализа удобно смотреть не только среднее, но и медиану и, например, 85‑й перцентиль: «половина задач закрывается за 2 дня, 85% — не дольше чем за 5 дней».

Как читать Cycle Time?

Cycle Time отвечает на вопрос «Сколько времени задача проводит внутри системы разработки?» Если вы видите рост, например, раньше Cycle Time составлял «2,7 дня», а сейчас «4 дня», значит где‑то появилось узкое место (ревью, тесты, деплой), или раздут WIP, и задачи просто толкутся в очереди.

Полезная практика — разбирать на ретро задачи с самым длинным Cycle Time: где они застряли, что можно убрать или автоматизировать. К примеру, в одной из моих команд бизнес постоянно жаловался: «Разработчики делают интеграцию с новым шлюзом уже три недели, почему так долго?!». Разработчики же клялись, что код написан за пару дней. Мы включили трекинг Cycle Time с разбивкой по статусам и увидели шокирующую картину: медианное время в статусе «In Progress» (написание кода) составляло 2,5 дня. 

А вот время в статусах «Code Review» и «Ожидание AppSec» (проверка безопасниками) составляло суммарно 14 дней! Задача просто лежала и ждала, пока у смежного отдела появится окно. Метрика Cycle Time спасла команду от выгорания: мы перестали давить на разработку и пошли договариваться с отделом ИБ о том, что наши фичи не такие страшные как платежи или кредиты и можно проявить немного спокойствия и лояльности(менеджерские хитрости). Скорость доставки выросла кратно.

Как мы внедряли Cycle Time:

• Договорились, какие статусы считаются началом и концом работы для задач команды.

• Включили отчёт по времени в статусах в Jira/YouTrack (можно использовать плагины «time in status» — большинство трекеров это умеют).

• Зафиксировали целевой ориентир, например, «85% задач среднего размера должны укладываться в 3 рабочих дня».

• Раз в спринт смотрели на хвост задач, выбивающихся за этот порог, и обсуждали причины: ревью, ожидание тестов, зависимость от других команд и т.п.

Свой путь: почему метрики нельзя просто «скопировать»

Значит ли наш опыт, что Throughput, WIP или DORA — это плохие метрики? Абсолютно нет. Главный вывод, который мы сделали на своих ошибках: не все метрики подходят друг другу, и не все можно безболезненно внедрять в любой момент.

У каждой команды должен быть свой эволюционный путь. Cycle Time стал нашим ключом к выздоровлению — именно с него мы начали распутывать процессный клубок. Другой команде, возможно, жизненно необходимо прямо сейчас ввести жесткие лимиты WIP, чтобы перестать тонуть в незавершенке. Третьей — посмотреть на DORA, чтобы перестать ронять прод каждую пятницу.

Поэтому ниже я подробнее разберу четыре базовые концепции, чтобы вы смогли собрать свой собственный, работающий набор (для этого нужно понимать физику этих инструментов)

Базовый минимум по цифрам, которые объясняют ,«Почему мы не успеваем»

№1. Throughput: сколько готовых задач вы реально выдаете

Throughput — это количество задач, которые команда завершает за выбранный период: за неделю, спринт, месяц. Это про общий «выход готового продукта» из вашей команды.

Как измерять?

Самый простой вариант: посчитать задачи, переведённые в Done за спринт или неделю. Лучше разделять типы задач: фичи, баги, техдолг — иначе есть соблазн «набить Throughput» мелкими фиксками. После нескольких итераций можно смотреть средний Throughput и доверительные интервалы, чтобы использовать это для планирования.

Как читать Throughput?

Throughput отвечает на вопрос «сколько мы реально успеваем», а не «сколько хотим успеть». Его удобно использовать:

• для планирования спринтов: ориентироваться на прошлый Throughput вместо «оптимистичных хотелок»;

• для отслеживания тренда: если состав команды не менялся, а Throughput падает — где‑то ухудшился процесс или накопился техдолг.

Сравнивать Throughput разных команд «в лоб» почти бессмысленно: у каждой свой контекст, размер задач и доля поддержки против фич.

№2. WIP или сколько «незавершёнки» висит в системе

WIP (Work in Progress) — это количество задач, которые уже начаты, но ещё не завершены в текущий момент. В канбан‑терминах это всё, что находится между колонками In Progress и Done.

Как измерять?

Чтобы посчитать WIP, достаточно:

• определить, какие статусы считаются «в работе» — обычно это разработка, ревью, тесты, готово к релизу;

• подсчитать количество карточек в этих колонках; можно делать это ежедневно или раз в несколько часов, если хотите строить графики.

Некоторые команды дополнительно смотрят WIP в сторипоинтах — так видно не только количество задач, но и их суммарный «вес».

Как читать WIP?

Здесь вступает в игру закон Литтла: при фиксированной пропускной способности системы среднее время цикла примерно равно отношению WIP к Throughput. Это означает: чем больше вы набрали задач в работу, тем дольше в среднем каждая из них будет идти до конца.

Высокий WIP = много переключений внимания, очереди перед узкими местами и затянувшийся Cycle Time. Если WIP растёт, а Throughput и число задач в Done не растут, система перегружена.

Как внедрить управление WIP?

1. Явно установите WIP‑лимиты на ключевых стадиях: например, не больше 2 задач на разработчика в In Progress и не больше 5 задач в Testing.

2. Договоритесь: если колонка достигла лимита, новые задачи туда не тянем, пока не освободится место — сначала заканчиваем начатое.

3. Отслеживайте, на каких стадиях лимиты постоянно пробиваются: это хороший индикатор узких мест.

№4. Узкие места: где «бутылочное горлышко» съедает релизы

Узкое место — это этап, который ограничивает скорость всей системы: например, ревью или QA, если там образуется очередь.​ Типичный симптом: в одной колонке доски скапливаются карточки, а время ожидания там непропорционально большое (например, разработка 1 день, ревью 3 дня).​

Чтобы искать такие места не на глаз, используют разбор времени по статусам (это часто умеют трекеры задач) и визуализации потока вроде value stream mapping и cumulative flow diagram (CFD).​

А есть еще что-нибудь из метрик?

Можно ли брать на вооружение другие метрики, которые не указаны в статье? Но тут как говорили классики — «Можно, но зачем?». Мы взяли стартовый набор, который команда любой зрелости может применить к себе в любой момент. Нам хватило. Остальное излишне.

Мини‑шпаргалка (что мерить и зачем)

Как внедрять метрики и не устроить «KPI-казнь»?

Метрики ломаются, когда их используют как дубинку для людей — тогда команда начинает оптимизировать цифры, а не результат (например, дробить задачи до абсурда или избегать рискованных, но нужных изменений). Рабочий подход — договориться, что метрики описывают систему, и на ретро обсуждать только улучшения процесса: что уменьшит ожидание, снизит аварийность или ускорит релизный цикл.

План на месяц — лёгкий, но действенный):

• Неделя 1: договориться о дефинициях (что такое “начали”, что такое “done”, включаем ли релиз).

• Неделя 2: включить сбор Cycle Time/Throughput/WIP из трекера и посмотреть, где накапливаются очереди.

• Неделя 3-4: выбрать одно узкое место и провести маленький эксперимент 

• Неделя 4: добавить DORA‑метрики из CI/CD/инцидентов и проверить баланс «скорость vs надежность».

Современный стек инструментов сам по себе реализует многие принципы производственного подхода, если им пользоваться дисциплинированно .

• Трекеры задач (Jira, YouTrack и др.) дают доски, лимиты WIP, контроль времени в статусах и отчёты по циклу задач, если команда честно обновляет статусы.

• CI/CD‑системы (GitLab CI/CD, GitHub Actions и т.п.) автоматизируют сборку, тестирование и деплой, убирая ручные узкие места и зависимость от «того самого человека, который умеет катить релизы».

• Мониторинг и observability‑платформы помогают быстро находить проблемы в продакшене и снижать MTTR, чтобы команда меньше жила в режиме бесконечных пожаротушений.

На этом всё. Если возникнут вопросы или требуется уточнение — задавайте в комментариях, на конструктивные вопросы я с радостью отвечу.

Читайте также:

• Почему роль Delivery Manager не работает в большинстве компаний

• Сложно читать IT литературу на кривом русском? Есть решение — книжный ревью (рефакторинг)

• Техсобес: боли, ошибки и рецепты успеха для тех, кто нанимает и нанимается

• История вайб‑кодера: «Я был скептиком, но до 4 утра спорил с GLM-5»

Подписывайтесь на Телеграм-канал Alfa Digital — там рассказываем о работе в IT, делимся новостями, анонсами митапов и квартирников, рассказываем о технологиях, делимся советами наших экспертов, вакансиями и стажировками, иногда шутим.