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

В 2020 году мы, как и все, перешли на удаленку. Логично, что через некоторое время у менеджмента возник вопрос — насколько мы там эффективны? И второй, вытекающий из первого: что мы, как менеджмент, делаем для управления этой самой эффективностью?

Для ответов одних бизнес-показателей, очевидно, недостаточно, — они не отвечают на вопрос на сколько эффективно мы растем в ИТ. Нам нужны были метрики производства с учетом методологий и процессов применяемых в организации. В конце концов, мы же хотим понять — эффективна удаленка или нет?

Собираем и отсеиваем метрики

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

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

• Time to market (TTM) — время доставки до рынка.

• Time to lead (TTL) — время производства.

• Committed vs Delivered (C\D) — соблюдение сроков.

• Velocity — скорость.

• Delivery — кол-во доставок до прома.

• Rollback — кол-во откатов с прома.

• Duration — нахождение задачи в статусе.

• Quantity — кол-во сделанных задач.

• Показатель качества — работа с инцидентами прома

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

Большинство показателей оказались не репрезентативными ввиду большого разнообразия стеков и платформ, на которых мы строим свои продукты. Вдобавок абсолютные значения некоторых метрик, по сути, ни о чем нам не говорят. Например, Velocity команды A 10 sp (стори пойнтов), а команды B — 20 sp. Можно ли говорить, что команда B перфомит в 2 раза больше команды A? Очевидно, нет, потому что 1 sp у каждой команды свой и они не сравнимы.

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

№1. Сначала определились с базисом расчета. Им, как ни странно, оказался спринт: он фиксирован по времени, по ресурсу и регулярно повторяется (есть ритм).

№2. Затем ушли от абсолютных значений в метриках из-за проблем, описанных выше. В результате некоторые метрики стали считать по формуле относительного отклонения от уровня, вычисленный эмпирически либо по команде, либо по платформе.

№3. В конце проскорили полученные метрики через ключевые, на наш взгляд, характеристики, определяющие эффективность производства:

• соблюдение сроков;

• скорость;

• качество.

Также исключили метрики, которые дают неоднозначные сигналы. Например, Rollback не всегда означает, что что-то пошло не так, иногда его применяют для отключения эксперимента на фиче. 

В итоге остановились на следующем наборе:

№1. C\D — отношение количества задач завершенных за спринт к запланированным в спринт.

№2. Velocity — отклонение суммы завершенных story points за спринт от медианного уровня по завершенным спринтам глубиною в год в разрезе команды.

№3. Delivery (финальное название «Внедрения») — отклонение количества поставок изменений в пром за спринт от медианного уровня по завершенным спринтам глубиною в год в разрезе продукта/системы.

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

• соблюдение SLA — это отношение не просроченных инцидентов к общему количеству за отчетный период в разрезе критичности;

• снижение числа открытых инцидентов — это соблюдение дельты между количеством открытых инцидентов на начало и конец отчетного периода менее или равное «-1».

Визуализируем метрики: инструменты

После того, как обкатали большинство наших метрик в «excel-ях», задумались о том, где же нам все-таки вести метрики, чтобы было наглядно. 

В первую очередь смотрели на источники данных и думали о возможностях построения дашбордов в них. На тот момент (уже ближе к концу 2020) у нас была Atlassian Jira и Service manager (SM).

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

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

Ниже как наши метрики выглядят на графиках. Например, на первом графике слева сверху видно, насколько успешно командам удается выдерживать сроки по задачам, запланированным в спринт. На графике справа сверху показана динамика изменения скорости команд (ускорение/замедление). А снизу справа показывает насколько успешно команды управляют качеством продукта/системы.

Итак, как же теперь использовать метрики?

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

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

Дальше проще — встроили оценку показателей в свои процессы по работе с эффективностью, а единый набор метрик позволил нам смотреть их на разных уровнях: Дирекция → Направление → Команда.

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

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

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

Заключение: про банальное и неочевидное

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

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

Конечно, мы не первые в организации занимались оценкой эффективности. Попытки до нас разбивались о стену непонимания целей или дальнейших шагов, отсутствие мотивации. Но, как вы догадались из предыстории, в этом долгосрочном проекте мы смогли внедрить на уровне департамента (2000+ сотрудников) в рабочий процесс базовый набор метрик. И это главная наша победа.

В комментариях будет интересно узнать ваш опыт по работе с эффективностью в ИТ и какие инструменты помогли вам прийти к успеху.