Проходя интервью на управленческие позиции в IT (например, Team Lead), часто можно попасть на секцию по опыту менеджмента командой. Казалось бы, рассказываешь о своем опыте, о принятых решениях и в целом о том, как успешно твоя команда выпускает релизы...

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

И в голове щелкнет: что‑то я, видимо, упускаю.

О чем пост

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

Поправляйте или дополняйте меня в комментариях, поможем друг другу понять, для чего же нужны метрики техническому лидеру проекта!

Зачем нужны метрики

Частым заблуждением новичков является то, что метрики, в основном, считает бизнес (Product Owner/etc.). Это, в общем‑то, верно: с помощью бизнес‑метрик мы можем проектировать product vision продукта и корректировать векторы развития.

Самое интересное то, что с помощью метрик (других, разумеется), мы можем точно так же влиять на процесс реализации того самого продукта! Разбавим красивые предложения несколькими примерами на «простом языке»:

1. «Тимлид, почему фичи не успели в срок?»

2. «Мсье, мы нашли на проде N багов, это нормально?»

3. «Товарищ, у нас система до сих пор лежит на проде, а вы прикрываетесь заполненным капасити?»

И таких примеров, к сожалению, очень много. О чем это нам говорит? Что‑то не так в наших процессах, и найти эти bottle neck'и нам как раз и помогут метрики.

Не одной метрикой едины

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

1. Delivery & Flow (производительность и предсказуемость)

2. Quality (качество процессов)

3. Process Efficiency (эффективность процессов)

4. People & Team (здоровье команды)

5. Business Impact

6. Product & Value

7. * Composite Metrics

5 и 6 метрики больше нужны PO и прочим деятелям бизнес-направления. Нам же, как тимлидам, больше интересны первые 4. Так же пометил седьмую под звездочкой, можно считать это объединением метрик выше для получения новых показателей.

Delivery & Flow

Эти метрики рассчитаны на то самое больное, с чем обычно приходят к техническому руководителю: объем фичей в поставке, burnout спринта и прочие прелести процесса delivery.

Velocity

Средний объем работы, которую команда выполняет за спринт. В зависимости от особенностей проекта, это может считаться по-разному, вот 2 самые популярные формулы:

-
-

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

Throughput

Количество завершенных задач за период времени. Считается просто: делим количество готовых задач на период времени.

Lead Time

Интересная метрика, показывающая, сколько времени заняла задача с момента ее появления в бэклоге до момента завершения задачи. Эту метрику любят многие управленцы.

Cycle Time

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

WIP

А-ля Work in Progress. Самая простая метрика, показывающая, сколько задач в работе на данный момент времени. Чем больше WIP, тем больше переключений между задачами и потерь контекста.

Predictability

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

Quality Metrics

Если Delivery-метрики дают нам понять темп нашего процесса delivery, то эта группа метрик показывает нам качество разработки этого самого delivery. В работе вам часто придется использовать эти две группы вместе для лучшего анализа процессов.

Defect Density

Количество багов на единицу объёма кода или фич. Если на простую задачу вы получаете тонну багов - это повод сделать аудит разработки.

Escaped Defects

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

Change Failure Rate

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

MTTR

Очень важная метрика, особенно для high load: показывает среднее время восстановления системы после инцидента. Чем ниже этот показатель, тем выше availability и меньше время простоя.

Code & Test Coverage

Объединил эти две метрики в одну, так как они больше применимы к разработке: доля коммитов, прошедших ревью, и процент покрытия кода тестами. Обе, разумеется, повышаем. Есть еще метрика на время «висения» PR в ревью, но это опционально под проект.

Process Efficiency

Я выделил эти метрики в отдельную группу, хотя они тесно связаны с предыдущей группой. Почему? Потому что они больше про время разработки, а время чаще всего прямо связано с качеством.

Flow Efficiency

Самая стандартная метрика в этой группе, показывающая долю активной работы во время цикла. Считаем просто, запоминаем: .

Queue Time / Wait Time

Время, когда задача висит без работы. Запрос информации у аналитика? Передали задачу дальше, но ее не взяли? Случился hold по какой-то причине? Вот и посчитаем, сколько времени у нас "улетает", а потом будем оптимизировать это место.

Blocked Time

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

Meeting Load

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

People & Team

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

Team Satisfaction / eNPS

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

Burnout Risk

Эмоциональное состояние команды, особенно актуально в период "горячки", когда или сроки поджимают, или нагрузка выше нормы. Особенно актуально, когда это длится не один спринт. Следите за выгоранием команды!

Skill Growth

Показательная метрика, если вы практикуете PDP/ИПР/прочие индивидуальные программы роста - сможете увидеть изменение компетенций в цифрах.

1:1 Frequency, Psychological Safety

Тут все прозаично, как часто вы проводите 1:1, как безопасно выражать мнение и так далее. Не мог не включить, так как полезно для общего развития. Если вы выстраиваете хорошую коммуникацию в команде, то на эти метрики можно не смотреть.

Что в итоге?

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

Можно ли все это сделать без метрик? Конечно да. Интуитивно вы, скорее всего и так понимаете, где у вас проблемы, однако взять себе в привычку следить за метриками очень сильно упростит ваш процесс управления.

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