Как метрики бизнес-процессов помогают оптимизировать IT-разработку на примере T-Банка

Денис Котов
Денис Котов
Дата публикации: 19 июня 2025 г.
Дата обновления: 19 июня 2025 г.

В этой статье мы подробно разберём, что такое метрики бизнес процессов, как они помогают понять и оптимизировать работу IT-команд, и почему доверие к этим метрикам – основа эффективного управления. Материал основан на опыте Владимира Коноплёва, технического директора T-Банка, который поделился своими знаниями и примерами практического применения метрик в IT-разработке.

Если вы хотите научиться измерять и анализировать процессы разработки, а также принимать решения на основе фактов, а не интуиции, эта статья для вас.

Владимир Коноплёв На Конференции Stormconf 2025 2

Шаг 1: Что такое метрики и зачем они нужны? 📊

Метрики – это числовые значения, которые отражают характеристики или параметры процессов. В IT и бизнесе это показатели, которые помогают понять, как работает система, команда или процесс, и насколько они эффективны.

Пример метрики – количество пользователей, время выполнения задачи, количество багов, среднее время отклика системы. Важно, что метрики бывают разными и дают представление о состоянии и динамике процессов во времени.

Зачем нужны метрики бизнес процессов в IT?

  1. Понимание текущей ситуации. Метрики позволяют объективно увидеть, что происходит в процессах, без субъективных оценок и догадок.
  2. Оценка эффективности. Вы можете понять, насколько быстро и качественно выполняются задачи, какие есть узкие места и проблемы.
  3. Принятие решений. На основе метрик можно решать, что менять, улучшать, автоматизировать или оставить как есть.
  4. Контроль изменений. После внесения улучшений метрики показывают, действительно ли ситуация изменилась к лучшему.

Таким образом, метрики – это объективный инструмент управления, который помогает перейти от ощущений и догадок к фактам и цифрам.

Пример Графиков С Метриками Пользователей И Процессов 3

Шаг 2: Как IT-разработка связана с бизнес-процессами? 🔄

Процесс разработки – это цепочка шагов, начиная с идеи или запроса и заканчивая выпуском продукта и его поддержкой. Аналогично бизнес-процессам, где есть участники, задачи, очереди и результаты.

Пример упрощённого процесса разработки:

  • Поступает запрос (бэклог) от продакта, аналитика или бизнеса.
  • Уточнение и планирование задачи: зачем и как её делать.
  • Проектирование решения, выбор архитектуры и технологий.
  • Разработка кода, код-ревью и тестирование.
  • Релиз и поддержка в продакшене.

Каждый этап – это часть процесса, в котором участвуют разные люди и команды. Важный момент – процессы могут быть не линейными, этапы смешиваются, релизы бывают разной частоты и масштаба. Но суть остаётся: процесс и его метрики.

Обзор Процесса Разработки  От Запроса До Релиза 4

Шаг 3: Артефакты разработки – основа для измерений 🗂️

Невозможно измерить то, чего нет. В IT ключевыми артефактами являются:

  • Код в репозиториях.
  • Задачи и тикеты в системах управления (JIRA, Trello, Notion).
  • Документация, архитектурные решения (ADR – Architecture Decision Records).
  • Релизы и логи из продакшена.

Без этих следов жизнедеятельности разработчиков и команд нельзя построить метрики. Поэтому важно, чтобы процессы оставляли такие «цифровые отпечатки», которые потом можно анализировать.

Артефакты Процесса Разработки  Код, Задачи, Документация 5

Шаг 4: Какие метрики бизнес процессов в IT важны? 📈

Метрики можно разделить на несколько категорий, каждая из которых показывает разные аспекты процесса и команды:

  • Временные метрики: время выполнения задачи, время ожидания, время на ревью, время от кода до релиза.
  • Объёмы и количество: количество задач в бэклоге, количество завершённых задач, количество багов.
  • Активность и загрузка: количество задач в работе (Work In Progress), пропускная способность команды.
  • Качество и надёжность: количество сбоев, время безотказной работы, количество критичных багов.
  • Ресурсы: стоимость команды, затраты на инфраструктуру.
  • Социальные метрики: опросы выгорания, удовлетворённости, вовлечённости.

Рассмотрим подробнее несколько примеров из практики.

Временные метрики: скорость выполнения задач

Одна из ключевых метрик – сколько времени команда тратит на выполнение задач. Например, время от постановки задачи до её завершения. Часто используют перцентили, чтобы видеть не среднее, а распределение:

  • 95-й перцентиль показывает, что 95% задач выполняются быстрее указанного времени.
  • Это помогает отбрасывать редкие долгие задачи (хвосты), которые искажают среднее.

Пример: команда выполняет 95% задач за 17 дней, но есть редкие случаи до 44 дней. Если динамика ухудшается, это повод для анализа и действий.

График Скорости Выполнения Задач С Перцентилями 6

Активное время и блокировки

Важно не только сколько времени занимает задача, но и сколько из этого времени над ней реально работают. Иногда задачи стоят в очередях или блокируются, что снижает эффективность.

Пример: команда тратит 80-90% времени на активную работу, остальные 10-20% – ожидание и блокировки, что считается нормой. Если блокировки достигают 50%, это серьёзная проблема и повод разбираться.

Метрика Активного Времени Работы Над Задачей 7

Бэклог и пропускная способность

Бэклог – это накопленные задачи, которые ещё не выполнены. Анализ динамики бэклога и пропускной способности (количество задач, выполненных за период) помогает понять, насколько команда справляется с нагрузкой.

  • Если бэклог уменьшается, значит команда успевает решать задачи.
  • Если бэклог растёт, это сигнал проблем: либо команда перегружена, либо есть препятствия.
  • Пропускная способность показывает, сколько задач команда закрывает за единицу времени.

Важно смотреть на эти метрики комплексно, учитывая размер команды. Например, если в команде 3 человека, а в работе одновременно 9 задач, это тревожный сигнал.

График Накопления Бэклога И Пропускной Способности Команды 8

Метрики этапов разработки

Можно углубиться и смотреть метрики по отдельным этапам процесса.

  • Проектирование: время на создание и ревью архитектурных документов (ADR). Средний срок ревью – 13 дней.
  • Кодирование: время от написания кода до его попадания в продакшен. Google рекомендует эту метрику для оценки продуктивности.
  • Код-ревью: размер изменений (строчки кода) и время на ревью. Лучше делать маленькие итерации, чтобы ревью было быстрее и эффективнее.
  • Релизы: частота выката новых версий. Чем чаще, тем лучше, чтобы не копить технический долг и быстро исправлять ошибки.

Пример: команда, которая релизит несколько раз в день, работает более гибко, а команда, выпускающая релизы раз в квартал, рискует накопить проблемы.

 

График Частоты Релизов Команд 9

Шаг 5: Метрики участников процесса и ресурсов 👥💰

Метрики касаются не только процессов и артефактов, но и людей, которые участвуют в работе, а также ресурсов, которые используются.

Метрики команд и сотрудников

Измерять продуктивность отдельных разработчиков сложно и часто некорректно. Вот три важных мысли по этому поводу:

  1. Нет универсальной метрики, которая точно определяет качество работы разработчика.
  2. Исследования Яндекса показывают, что регулярность вклада в кодовую базу коррелирует с успешностью сотрудника.
  3. Используют перцентили по разным активностям (код, сообщения, встречи) для оценки положения сотрудника относительно коллег.

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

Опросы и социальные метрики

Опросы сотрудников помогают понять уровень выгорания, удовлетворённости и вовлечённости. Хотя конверсия прохождения часто невысока, даже 30% респондентов могут дать полезные инсайты.

Пример: команда с уровнем выгорания выше среднего по компании – повод для руководителя обратить внимание и проводить дополнительные беседы.

Ресурсы и затраты

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

Пример: рост затрат на инфраструктуру без роста функциональности или производительности – тревожный сигнал.

График Стоимости Команды И Инфраструктуры 10

Шаг 6: Работа с проблемными задачами и долгими запросами 🕵️‍♂️

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

В T-Банке внедрена практика автоматического уведомления тимлидов о задачах, которые висят более 90 дней. Тимлиды отмечают причину задержки, что даёт ценную статистику для анализа и принятия мер.

Основные причины долгих задач:

  • Большой объём работы, требующий декомпозиции.
  • Проблемы с командным взаимодействием и гигиеной.
  • Отсутствие менеджмента и контроля статусов.

Такая практика помогает выявлять узкие места и улучшать процессы.

 

Шаг 7: Регулярный обзор и доверие к метрикам 🔍

После настройки метрик важно регулярно проводить их обзор, иначе все усилия теряют смысл. В T-Банке существует операционное ревью – регулярные встречи (раз в 1-3 месяца) для анализа ключевых показателей и принятия решений.

Главный критерий эффективности метрик – доверие к ним.

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

Метрики должны быть инструментом для объективного принятия решений, а не поводом для сомнений или манипуляций.

Доверие К Метрикам – Основа Эффективного Управления 12

Часто задаваемые вопросы (FAQ) ❓

Можно ли измерять продуктивность отдельных разработчиков?

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

Как часто нужно анализировать бэклог и метрики команды?

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

Стоит ли использовать KPI для разработчиков?

В T-Банке KPI для разработчиков не используются в классическом виде с финансовыми штрафами или бонусами. Вместо этого таргетируются метрики систем и процессов, например, надёжность и доступность сервисов.

Как бороться с долгими задачами?

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

Как повысить доверие к метрикам в команде?

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

Заключение

Метрики бизнес процессов – мощный инструмент для управления IT-разработкой и повышением эффективности команд. Они помогают перейти от субъективных ощущений к объективным фактам, выявлять проблемы и принимать обоснованные решения.

Опыт Владимира Коноплёва и T-Банка показывает, что важно не просто собирать метрики, а:

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

Новые статьи в вашем электрическом ящике

Обзоры конференций, лучшие практики процессного подхода и учебные статьи в вашей почте. Не чаще 1 раза в неделю.

Без спама, только то, что вы запросили.

Бесплатно моделируйте бизнес-процессы в BPMN без ошибок

Stormbpmn автоматически анализирует ваши модели по 60+ правилам, ускоряя работу и предотвращая ошибки.

Проверка качества BPMN