Привет, Хабр! Я Александр Блинов — технический руководитель B2C-направления в hh.ru (та самая часть, которую знают все соискатели). Наш сервис достаточно большой, ему недавно исполнилась четверть века.
Когда мы вносим изменения в работу такого сервиса, риск что-нибудь сломать очень высок. Поэтому у нас сформировалась жёсткая культура метрик. Мы измеряем многое: процесс, продукт, технические показатели.
В этой статье расскажу о том, как мы работаем с метриками, поделюсь своим подходом к ним и приведу пример нескольких незаурядных метрик, которые вы сможете использовать в своих проектах.
Начну с истории.
Как на бумаге команда бьёт все рекорды
Однажды мне написал проджект-менеджер: «Саш, что-то команда у тебя очень хорошо работает. В этом квартале вы делаете всё в два раза лучше, чем в прошлом. Можешь объяснить? Хочу зарепортить, как мы работаем!»
Я попросил график и увидел, что за год эффективность команд выросла в три раза.
Возник вопрос, с чем связаны такие показатели.
Дашборд показал интересную статистику:
Выросло число задач, которые делают мои команды.
Снизилось время производства (lead time) — мы работаем намного быстрее.
У меня закралась мысль, что здесь какая-то ошибка, потому что ребята, конечно, хорошо работают, но объективно не должно быть прироста на 50%.
Я стал разбираться, что в метриках могло пойти не так.
Возможно, мы вообще неправильно определили задачу. Или что-то не так с размером учитываемых задач? А может быть, мне вообще в заслугу поставили чужие задачи? Или это вообще ошибка в данных?
Я проанализировал дашборд детальнее.
Здесь заметно, что стратегических задач стало ощутимо меньше, при этом почему-то выросло число задач на техдолг. Точно что-то не так.
Смотрим на данные по графикам. Оказывается, туда попало очень много маленьких задач на перевод небольших сервисов на Spring Boot, такие же задачи для фронтенда, а ещё затесались правки для мобильных релизов. Не это я бы хотел видеть на графике, который ещё и хотят показывать руководству.
Итак, я нашёл несколько проблем:
Проблема с определением, что такое фича. Не уверен, что нужно отражать в графике перевод сервисов на Spring Boot.
Проблема с размером фичей. Когда мы говорим, сколько сделали продуктовых, бизнесовых инкрементов, маленький экспериментик несоизмерим с большой доработкой.
В данные попадают мусорные сущности, например мобильный релиз — это, наверное, последнее, что мы хотели бы увидеть в списке задач.
Все вместе они делают график просто бесполезным. Сегодня эти проблемы в прошлом — чтобы больше не получать такие графики, мы решили сформулировать принципы работы с метриками, и это помогло.
Принципы работы с метриками
1) Реальность должна совпадать с метриками.
Есть системы реального мира: как мы с вами живём, как делаем задачи, как их получаем. Когда вы отмечаете эти процессы в своём трекере задач, нужно, чтобы то, что вы фактически делаете, и цифровые данные совпадали.
2) Поддерживайте данные в актуальном состоянии.
Обычно система работы со временем эволюционирует, хочется, чтобы метрики и её цифровое представление актуализировались со временем. Поэтому неплохая практика — смотреть, по-прежнему ли ваша метрика актуальна.
3) Метрики — это способ найти проблему, не сама цель.
Можно смотреть на одну метрику в отрыве других. Можно добавить больше метрик в попытке измерить вообще всё. Но это не самый лучший подход, потому что метрики — это не самоцель. Нам главное, чтобы команды хорошо работали, а не просто показать приятные показатели на графиках. Помним про то, что не все аспекты работы команды можно (и нужно) измерять.
4) Бессмысленные метрики не нужны.
Вот что нужно учесть при работе с метриками:
Если по метрике нельзя понять, это хорошо или плохо, то она наверняка бесполезная.
Если вы начинаете работать с метрикой, важно не просто знать, как она считается, а понимать, какие данные под ней лежат, как их отфильтровывать, откуда берётся ваш финальный график.
Если вы создали метрику, сделайте для неё пример интерпретации. Так другому человеку будет легче с ней работать. Для этого я рекомендую заводить отдельную страничку с подробной информацией о каждой метрике: зачем она нужна, где её нужно проверять, какие аномалии по ней можно смотреть, какие у неё ожидаемые значения.
Хорошо, мы сформировали набор принципов, по которым нужно работать с метриками. Теперь поговорим про петли обратной связи — процесс, в котором результат действия возвращается в систему и влияет на последующие действия.
Когда не хватает ретро
Мы в команде используем несколько видов петель обратной связи:
Ретро — обсуждаем, что хорошо, что плохо, какие ошибки повторять не нужно. Согласитесь, такое ретро больше про эмоции и рефлексию прошедшего периода.
Разбор фичи — анализируем разработку функционала по горячим следам.
Ревью поставки (именно на ней я сфокусируюсь в этой статье) — смотрим на проделанную работу и процессы в команде с точки зрения графиков и метрик.
Live-мониторинг и алертинг. В первых трёх видах петель разбираем результаты постфактум. Но мы же хотим не только анализировать проблемы, но и не допускать их. Неплохо, когда у вас есть система live-метрик, которые отслеживают нарушения и оповещают о них. Например, тимлид получает от бота уведомление и благодаря этому вовремя подключается к инциденту.
Как подготовиться к ревью поставки
Здесь нам помогут графики. Разберём пошагово, как их составить:
1) Определяем нужный период. Нужно выбрать более длинный срок (1–2 периода до текущего), чтобы увидеть динамику.
2) Очищаем данные:
Удаляем весь шум и нерелевантные случаи. Например, в кейсе, о котором я рассказывал выше, нужно вычистить всё, что касается мобильных релизов.
Убираем выбросы (аномальные скачки) с графиков.
Обязательно эти выбросы и разбираем.
Например, если вы делали задачу 150 дней вместо обычных 15–30, то график сожмётся, и вы на нём ничего не увидите. Поэтому аномальные пики лучше срезать и рассмотреть отдельно. То есть на графике мы смотрим на тенденции и на то, какие у нас возникали аномалии.
3) Создаём график в своей системе отчётов и копируем его на доску для анализа.
Мне очень нравятся в этом плане Miro-подобные инструменты, когда можно не просто посмотреть на график, а нанести какую-то разметку. Мы отмечаем границы нормальных значений и выбросы. Обязательно туда добавляем ссылки, например на задачи с выбросами, чтобы не забыть их проанализировать. Также обязательно нужно приложить ссылку на исходный график со всеми фильтрами, чтобы потом можно было посмотреть, откуда он вообще взялся.
Вот как это выглядит график на доске для анализа:
График, который находится у вас прямо в системе, без всего, не совсем понятный. Когда график отображает, что конкретно вам необходимо поменять, — это уже намного лучше. Вы понимаете, где попадаете в ожидаемые значения, где — в неожидаемые и где у вас пиковые значения.
Помимо графика нужно учесть ещё два момента. Во-первых, определите, что конкретно вы хотите рассказать команде на встрече с разбором.
На любом ретро, на любом ревью поставки вам нужно понять, к какому выводу вы хотите привести команду. Да, вы сами проведёте анализ, найдёте, в чём проблема, но важно, чтобы всё это поняла команда — и её нужно аккуратно к этому подвести.
У меня много команд, и я часто видел, когда тимлид на таких встречах пытается сам оправдать каждую аномалию и не даёт команде подумать и найти проблему. Так делать не стоит, потому что важно не просто сгладить углы, а подсветить проблемы и вместе придумать для них решения.
Если вы не слышали про Radical Candor, обязательно прочитайте. Это подход к управлению, согласно которому при работе с командой вы, с одной стороны, достаточно требовательны, с другой — помогаете достичь этих требований. Это очень клёвый подход, если вы руководитель — рекомендую.
Человеку проще поверить в мысль, когда он сам пришёл к ней. Поэтому когда вы проводите встречу, направляйте команду, чтобы она дошла до этих результатов.
Во-вторых, обдумайте, как поработать над найденными проблемами.
Бывает так, что вы провели ретро, описали, какие есть проблемы и что нужно поменять, но к следующему ревью так ничего и не сделали. У меня самого такое было. Вроде бы все понимают проблему, но её проще прокрастинировать, потому что решение проблемы сложное, над ним нужно думать. Можно пустить всё на самотёк, авось само решится. Но само часто почему-то не решается.
Вариантов решения много, начать можно с этого:
Сделать общий процесс внедрения изменений и сфокусироваться на нём.
Продать тимлиду и членам команды индивидуальный план развития, что конкретно им нужно делать.
Начинать новое ревью поставки с обзора того, что обсуждали в прошлый раз.
Итак, с теоретической частью закончили, перейдём к практике.
Примеры метрик из практики hh.ru
Этот раздел построен так, как я завещал составлять страницу по разбору метрик. Расскажу, какую проблему можно решить метрикой, как и где собирать данные, какие бывают целевые значения, на что ориентируемся мы в нашей команде, и приведу пример разбора с интерпретацией, как с метрикой работать.
Обратная связь по работе с командой
Это самая простая метрика, поэтому начну с неё.
Вы работаете, у вас есть продакт (заказчик), и его что-то не устраивает. Он копит недовольство и потом подходит к точке невозврата. Когда продакт взрывается, это недовольство прилетает туда, куда не нужно. Хочется такие случаи предотвратить, заранее купировать, пока они не приняли необратимый характер.
Цель — вовремя заметить тревожные сигналы и сделать управляющее действие.
Теперь поэтапно:
1) Собираем обратную связь с помощью опроса.
Вот пример сопроводительного текста, который я пишу команде:
Продакты — занятые люди, для них время всегда очень важно. Поэтому я пишу, что опрос займёт 5–10 минут и в результате принесёт им пользу. И они отвечают, представляете? Они знают, что я их не обману.
Опрос состоит из двух блоков. Мне интересны следующие призмы:
Насколько быстро, качественно команда работает?
Насколько она помогает продакту заниматься продуктом?
В первом блоке я задаю несколько вопросов с вариантами ответов: «да», «скорее нет, чем да», «скорее да, чем нет», «нет». Каждый вопрос включает в себя дополнительные опциональные комментарии. Я прошу: «Если вы ответили не „да“, то, пожалуйста, напишите почему». Это поможет мне сделать управляющие действия.
Во втором блоке прошу оценить удовлетворённость работой с командой по шкале от 0 до 10.
Прохождение опроса реально занимает 5 минут.
2) Интерпретируем результаты.
Фишка такой шкалы в том, что нет среднего значения — либо скорее плохо, либо скорее хорошо. Если у вас превалирует «Скорее нет, чем да» — это красный флаг, звоночек бежать и решать эту проблему.
Второй блок оценивается по стандартному NPS: если 9−10 — всё отлично, 7−8 — пойдёт, 0−6 — катастрофа, здесь лучше разобраться.
Почему сбор обратной связи — это тоже метрика? Я регулярно провожу такие опросы раз в квартал, вношу результаты в табличку и смотрю, как они меняются со временем. Если продакт стал менее довольным, то есть он у него было «Да», потом «Скорее, да, чем нет», то что-то произошло, и лучше прояснить это при удобном случае.
Метрики ревью
Начну с байки.
Однажды к нам в мобильную команду устроился новый разработчик. В середине испытательного срока мы с ним обменялись обратной связью по сотрудничеству, и он неожиданно сказал, что у нас очень долгое ревью. Мы удивились — вроде всё в порядке, жалоб от команды не было.
Я проверил статусы в Jira, и у этого разработчика реально залёживаются задачи в статусе Need Review. Значит, что-то не так, решил разобраться. По Jira детально не посмотришь: там не видно время первой реакции на ревью, нет информации о процессе, были ли доработки, статус может быть неактуальным и так далее. Поэтому я пошёл туда, где лежат все ревью, — в GitHub. Мы вытащили все даты обновления PR: нужно было посчитать время до первой реакции и время от начала работы над PR до мёрджа. В результате получилось, что у этого разработчика PR реально не смотрят. Графиков из тех времён у меня уже не сохранилось, но на основе той идеи мы собрали следующие дашборды:
У нас получились такие общие метрики. 80-й перцентиль как раз срезает все лишние выбросы, потому что здесь, конкретно на этом графике, мы хотим видеть именно тенденцию, без аномальных значений.
Этот график идеально подходит для технических руководителей: Android-техлид, iOS-техлид, фронтенд, бэкенд и так далее. Но когда тимлид смотрит на работу своей команды, он хочет видеть не это — он хочет посмотреть, как работает конкретный человек. Для этого есть дашборд, где можно отсортировать всё по времени реакции и итоговому времени до мёрджа. Я показал вам только правую часть графика, левую часть с именами показывать, конечно же, не буду!
У того разработчика была похожая ситуация: его реально долго не ревьюили и достаточно быстро мёрджили.
Позже мы разобрались, почему возникла такая проблема. Оказалось, что у каждой мобильной команды своя доска с задачами, где в колонку с необходимостью review попадают задачи других команд, и каждого нового сотрудника добавляют на все эти доски. Как вы понимаете, того разработчика не добавили ни на одну доску. Поэтому его ревьюил только один человек, его сокомандник. А когда этот коллега ушёл в отпуск, новичка перестали ревьюить совсем.
Что ещё можно вытащить из метрик на GitHub
Для начала можно посмотреть, сколько люди ревьюят.
Мы хотим, чтобы нагрузка по ревью была равномерная. Но на этом графике видно, что как у верхних ребят что-то не так. При этом есть герои-ревьюеры, которые за 90 дней умудряются оценить феноменальное число задач.
Также можно посмотреть условное качество ревью.
Почему говорю «условное качество»? Потому что количество комментариев, которые оставляет ревьюер, — это не совсем про качество ревью, возможно, комментарии чистая субъективщина, и они по своей сути бессмысленны.
Более интересная метрика — сколько человеку накидывают разных комментариев, потому что тут можно увидеть тенденции.
Если человеку стабильно накидывают много комментов, а его pull request заворачивают, значит, что-то не так, возможно, нужно поработать с ним и понять, что вообще происходит. На этом графике три первые строчки как раз заняли сотрудники, которые недавно к нам присоединились и ещё не до конца разобрались, как принято писать код.
По этому графику я хотел подсветить ещё важную часть: метрики могут врать. Не забывайте выгружать данные, чтобы сравнить их с реальностью. Важно, чтобы вы всегда могли посмотреть сырые данные по графикам, потому что они могут помочь понять, что в ваших процессах было хорошо, а что плохо.
Послесловие
Так что с начальными метриками, о которых я рассказал? Метрики хорошие, но важно их правильно «приготовить»:
Определиться, что вообще такое фича. В метрику могут попасть разные работы. А чтобы отсеять лишнее, нужно изначально определить, что является фичей для этой метрики.
Отфильтровать лишние данные (помните мобильные релизы?).
Графики «Распределение LT» и «Пропускная способность» нужно смотреть для схожих по объёму фичей. Здесь я бы разделил фичи на корзинки, например по объёму (или значимости) на маленькие, средние, большие. Потом в конце квартала посмотрел показатели: так, у меня команда выпустила пять больших и три маленьких фичи, и вот уже можно более-менее оценить эффективность. А дальше я могу отслеживать тенденции, например каких фичей стало меньше или больше, и анализировать это.
Чек-лист проведения анализа по метрикам
Рекомендации, что можно сделать, если вы хотите проводить ретро, ревью поставки:
Убедитесь, что цифровые пайплайны отражают реальный процесс командной работы.
Добейтесь, чтобы статусы в системе соответствовали реальному положению дел (автоматизация, боты, контроль).
Выберите набор метрик, по которым однозначно понятно, что хорошо, а что плохо.
Настраивайте дашборды внимательно: правильные периоды, фильтрация мусора.
Визуализируйте проблемные зоны для наглядности.
Радикально и открыто обсуждайте выявленные проблемы с командой.
Чётко выстройте процесс внедрения изменений.
Статья написана на основе моего выступления на конференции TeamLead Conf 2025. Следующая крупная встреча для тимлидов состоится на Saint TeamLead Conf 2026 — 25–26 июня в Санкт-Петербурге. Присоединяйтесь, чтобы послушать доклады от успешных управленцев в IT и других отраслях и поучаствовать в крупнейшем нетворкинге. А ещё подписывайтесь на телеграм-канал hh team, чтобы быть в курсе новостей компании.