Привет, Хабр! Сегодня с вами Дарья Шаваракова, process driver во Flowwow.
Ни для кого не секрет, что бизнесу важно зарабатывать много и стабильно. Разработка выступает одним из ключевых факторов, который напрямую на это влияет: фичи, улучшения и исправление багов вносят огромный вклад в выручку и удержание пользователей. Конечно, у работы команды есть понятный итог — выкаченная фича. Но как понять, что сам процесс создания продукта действительно эффективен и не сжигает лишние ресурсы на пути к этому результату?
Без метрик разработка превращается в «черный ящик»: непонятно, где теряется время, накапливаются блокеры и почему замедляются релизы. Смотреть только на итог тоже поздно: когда проблема становится заметной, бизнес уже теряет деньги из-за задержек релизов, перегруженных команд или узких мест. К тому же итог показывает последствия, а не причины.
Метрики процесса позволяют увидеть эти проблемы раньше и дают возможность управлять процессом до того, как это ударит по бизнес-показателям. Если флоу ускоряется и выравнивается, бизнес быстрее получает результат.
При этом важно отметить: для нас метрики — это не самоцель. Мы рассматриваем их в контексте бизнес-результатов, продуктовых изменений, финансового эффекта и специфики команды. Это инструмент, который помогает понять, что происходит внутри процесса, заранее увидеть проблемы и принять решения, а не собирать метрики для галочки.
Сегодня расскажу о том, как мы внедряли процессные метрики в компании: с чего начали, какие сложности поймали по дороге и какие выводы сделали. А главное — покажу, какой эффект это дало для команд, скорости разработки и бизнеса в целом.
Как все начиналось
Метрики и процесс работы с ними никогда не появляются сразу в готовом и удобном виде. Это поэтапный и долгий путь. Так же он выстраивался и у нас: медленно, постепенно и, конечно же, не без ошибок.
В самом начале работы компании мы вообще не смотрели на метрики, а фокусировались на том, чтобы просто поставлять ценность: пилить фичи, развивать продукт, двигаться вперед. Но со временем и быстрым ростом команды стало понятно, что без прозрачности в процессе начинает расти хаос: появляются задержки, что-то теряется, сроки плывут.
Тогда мы и начали выстраивать системную работу с метриками. Старт был очень простым: данные собирались руками — мы выгружали задачи из таск-трекера в Excel и пытались собрать общую картину. На это уходило по несколько дней каждый месяц.
Никаких дашбордов и автоматизации тогда не было — по сути, мы собирали только количество закрытых задач и SP (Story Point) за месяц, постепенно дополняя эту статистику другими метриками процесса.
От базовых метрик к аналитике
Со временем стало очевидно, что для осмысленного анализа и понимания того, что происходит в процессах, нам не хватает данных. Количество закрытых задач давало только общий срез, но не помогало понять, где возникают задержки, почему таски долго не закрываются и за счет чего команды работают по-разному.
Поэтому мы начали постепенно расширять набор метрик: добавили Cycle Time и отслеживали, сколько времени тратится на задачу на каждом этапе работы. Мы также стали смотреть, сколько тикетов создается и закрывается, нет ли накопления незавершенной работы, какова доля багов, а также оцениваются ли задачи в принципе и не появляется ли среди них слишком объемных.
Но чем шире становился анализ, тем очевиднее было, что вручную такая система тяжело масштабируется. Со временем число команд и количество метрик стали быстро расти, а мы по-прежнему собирали статистику через выгрузки из таск-трекера в Excel. Естественно, на это требовалось все больше времени. В какой-то момент мы пришли к тому, что в начале каждого месяца два-три человека тратили несколько рабочих дней на сбор и подготовку итоговой статистики.
При этом даже в таком формате метрики начали приносить пользу: стало проще видеть загрузку команд, планировать работу и замечать узкие места в процессе разработки. Но поддержка такой системы обходилась дорого. Поэтому мы начали искать более устойчивое решение и вместе с аналитиками собрали первые дашборды. Они помогли упростить нашу работу: часть метрик стало легче отслеживать, а аналитику — проще воспринимать.
При этом дашборды не закрывали все задачи целиком: они требовали времени на развитие и разбор, были отдельным инструментом и давали срез только в моменте.
Переход к автоматизации
Какое-то время мы отслеживали данные в смешанном формате: часть показателей собирали вручную, часть брали из дашбордов и все потом сводили вместе. Но это требовало слишком много ручной работы, поэтому мы пошли в сторону автоматизации: внедрили бота, отслеживающего все необходимые нам данные прямо в корпоративном мессенджере.
Бот работает довольно прямолинейно: запускается по расписанию, собирает нужные задачи по командам и рассчитывает метрики.
После этого результат автоматически отправляется в канал в корпоративном мессенджере, где команды уже могут его посмотреть и обсудить.
С технической стороны это отдельный Python-сервис. Под капотом используется связка PostgreSQL, Google Sheets, n8n и Python/Django. Триггером запуска служит n8n: раз в месяц он инициирует сбор статистики, после чего сервис делает выборки из БД, рассчитывает метрики и отправляет готовый отчет через API мессенджера.
Отдельная сложность была в том, что данные приходилось собирать из разных источников и учитывать дополнительный контекст: например, производственный календарь, отпуска и структуру команд. Часть таких данных кешируется отдельно, чтобы не собирать их заново при каждом расчете.
Важно: бот не просто собирает цифры, а сразу создает удобный для чтения формат: например, разбивает статистику на блоки, где отдельно подсвечиваются оценка задач, баланс потока, метрики производительности, аномалии по статусам, Cycle Time и его динамика.
Такой формат позволяет закрыть сразу несколько проблем:
Мы почти полностью убрали ручной сбор. На текущий момент мы проверяем только корректность выгрузки по аномалиям и трендам Cycle Time, но в ближайшее время планируем автоматизировать и эти пункты.
Сделали процесс стабильным — статистика теперь формируется регулярно и одинаково.
Сильно снизили порог доступа к данным: командам больше не нужно идти в отдельные инструменты, все приходит прямо в рабочий чат, а результаты обсуждаются в треде — без переключения между инструментами.
Бот не заменил дашборды, а дополнил их. Дашборды мы используем для анализа в моменте, чтобы смотреть текущие значения, динамику и детали. Бот решает другую задачу: собирает месячную статистику, учитывает контекст и подсвечивает аномалии, чтобы лиды могли быстро увидеть общую картину. Вместе эти инструменты дают идеальную синергию: закрывают как детальный анализ, так и быстрый обзор.
Что это дало бизнесу
Такой подход к метрикам дал вполне прикладной эффект: стало меньше хаоса и больше прозрачности, а команды начали быстрее замечать отклонения и реагировать на них. Метрики изначально были важны для управляемости процессов, а автоматизация позволила убрать ручной рутинный труд и снизить влияние человеческого фактора.
Эффект можно увидеть и на цифрах. За три года медиана Cycle Time снизилась почти вдвое. Сократился и «хвост»: P85 упал на 28%. При этом среднее число закрываемых тикетов увеличилось почти в 2,7 раза, то есть разработка значительно ускорилась. Причем увеличение темпа совпадало с шагами автоматизации: сначала — с внедрением сбора метрик, затем — с появлением дашбордов и бота с ежемесячной рассылкой.
Мы используем метрики и для анализа узких мест, поиска причин и проверки гипотез, например, на ретроспективах. Также с их помощью оцениваем влияние внедрения AI в процесс разработки: где инструменты помогают ускорять работу, а где эффект пока неочевиден. В результате появляется понятный цикл: заметили изменение — разобрали причину, попробовали решение — посмотрели на эффект. Если перевести это на язык бизнеса, то в итоге мы получаем более предсказуемую разработку, более быстрый вывод изменений и меньше потерь внутри процесса, а значит, более управляемую систему, через которую бизнес быстрее и стабильнее получает результат.
А какие метрики вы отслеживаете в своих командах?
