Сегодня я хочу рассказать о метриках. Но не о тех, которые обычно обсуждают, к примеру, на конференциях, где каждый рассказывает о своём продукте. Я буду говорить о командных метриках и о нашей команде Sber Data Exchange.

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

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

Проблема №1: много незавершённой работы

Однажды к нам пришёл разработчик Вася и сказал: «Ребята, у нас слишком много фича‑веток». Мы используем feature branching: каждая новая задача разрабатывается в отдельной ветке, тестируется и только потом вливается в релизную ветку. Но Вася пожаловался, что постоянные вливания, устранение регрессионных дефектов и необходимость работать с несколькими окружениями отнимают у него кучу времени.

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

Решение оказалось очевидным — внедрить лимиты на количество задач в работе (Work in Progress, WIP). Мы установили отдельные лимиты для разработки и тестирования и начали измерять количество работы в процессе. В нашем случае это были Jiroвские истории. Это позволило нам видеть, где происходит перекос, и вовремя притормаживать. Например, если разработчики начинали слишком много задач, то мы перенаправляли их на завершение уже начатых.

В 2022 году у нас было в работе 10–15 историй, что в 2–3 раза превышало количество разработчиков и тестировщиков. Слишком много. Но благодаря лимитам мы смогли устаканить процессы. Мы научились:

• определять перегрузку в процессах;

• сокращать количество параллельных задач;

• ускорять завершение историй.

Проблема № 2: огромная очередь на тестирование

Как только мы сократили количество незавершённой работы, скорость выпуска историй увеличилась. Но тут снова пришла Маша: «Вы так ускорились, что у меня образовалась огромная очередь на тестирование. Я ничего не успеваю!»

Мы оценили ситуацию: около 20 историй висели в очереди. Первое, что приходит в голову в такой ситуации, — увеличить количество тестировщиков. Но в банке, как и в любой другой компании, ресурсы просто так не выделяют. Тогда мы начали отслеживать очередь и смогли сократить её в три раза, не увеличивая количество ресурсов. И привели скорость разработки в соответствие со скоростью тестирования.

Проблема № 3: минорные дефекты — скрытый враг

На этом наши проблемы не закончились. Пришёл Федя, ещё один разработчик, и сказал: «Вы говорите не брать новые истории, а завершать старые. Но чем мне заниматься, пока я жду?»

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

Мы начали отслеживать миноры. Оказалось, что у нас их больше 200, и количество продолжало расти. Ввели правило: разработчики приступают к минорам, когда очередь на тестирование переполнена и им запрещено брать новые истории. В результате сократили количество миноров в 4,5 раза.

Проблема № 4: мажорные дефекты и релизы

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

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

Проблема № 5: автоматизация и затраты на тестирование

Одна из наших ключевых задач — сокращение затрат на ручное тестирование. Мы начали развивать команду автоматизаторов, чтобы уменьшить нагрузку на ручных тестировщиков. Но как измерить эффективность автоматизации, чтобы соотнести с затраченными ресурсами?

На своём опыте мы поняли, что для оценки эффективности подойдёт как раз контроль рабочего времени. Мы отслеживаем, сколько времени тратится на ручной регресс, и сравниваем с затратами на автоматизацию. Так, мы с 2022 года с помощью автоматического тестирования сократили затраты на ручной регресс в 2,5 раза. Это помогло наглядно увидеть, что мы двигаемся в правильном направлении. И ещё автоматизация позволила разгрузить тестировщиков и направить их усилия на более сложные задачи.

Проблема № 6: Справедливое распределение затрат

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

Мы начали искать более справедливые драйверы для распределения затрат. Сейчас мы движемся в направлении разделения функциональности на базовую и опциональную. Базовую, которой пользуются все бизнес‑блоки, все пользователи оплачивают поровну. А опциональную функциональность, которой пользуются только некоторые клиенты, они оплачивают индивидуально. Для этого мы используем данные о фактических затратах на каждую функцию продукта. Это позволяет клиентам выбирать, за что они платят, и делает распределение затрат более прозрачным.

Почему метрики важны?

Метрики — это не просто числа. Это инструмент, который помогает нам принимать обоснованные решения и быть прозрачными перед бизнесом. Если у нас есть числа, то мы можем аргументированно обсуждать с руководством и заказчиками, куда идут ресурсы и почему. Например, когда мы говорим о расширении команды автоматизаторов, то можем показать, сколько это сэкономит на ручном тестировании. Когда бизнес спрашивает, за что ониплатят, мы можем детально объяснить, как распределяются затраты.

Работа с метриками помогла нам:

• сократить количество незавершённых задач;

• уменьшить очередь на тестирование;

• сократить технический долг;

• повысить прозрачность затрат для бизнеса.

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

Каждая команда уникальна, и метрики должны быть адаптированы под её контекст. Но универсальные принципы — такие как ограничение работы в процессе, баланс между разработкой и тестированием, контроль времени — могут быть полезны в любой команде. Главное — адаптировать метрики под свой контекст и регулярно анализировать результаты, потому что работа в IT‑команде — это постоянный поиск баланса между скоростью разработки, качеством продукта и эффективностью процессов.

Есливаше мнение основано на числах, то с вами будут считаться. Если это просто мнение, то всегда найдётся кто‑то, чьё мнение важнее.

Кстати, много разных мнений и примеров от продуктологов и ИТ‑экспертов из разных компаний будет на конференции Sbergile Product Days. В прошлом году она прошла только «для своих», а в мае 2025 впервые станет открытой. Вы можете не только посетить её, но и стать докладчиком. 17 февраля после 17:30 начнётся сбор заявок на выступления. Подавайте заявку и вы, если есть реализованные проекты и доклады, которыми хотите поделиться с коллегами по цеху.

Татьяна Арзуманян

руководитель направления в трайбе «Корпоративная аналитическая платформа SberData», Сбер