Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

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

Почему это актуально?

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

Последние несколько лет я занимаюсь трансформацией подходов к управлению на основе Agile и также внедряю метрики в компании.

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

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

Эффективная команда

Базовое определение эффективности — это способность достигать целей за наименьшее количество ресурсов (как временных так и денежных)

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

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

Зачем нам что-то измерять?

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

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

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

Ключевые группы метрик в Aimger

У нас есть следующие категории метрик:

Метрики скорости
Метрики результативности
Метрики качества
Метрики потока выполнения
Технические метрики инженерной зрелости
Проектные метрики (отслеживание хода проекта)

А данной статье мы рассмотрим некоторые из них.

Метрики скорости и гибкости

Метрики, ориентированные на скорость доставки ценности клиенту и гибкость производственного процесса.

Time to market (Lead time, Cycle time и Time to learn) - время от идеи до клиента
Release frequency - частота релизов за единицу времени
Release stabilisation period / Change failure rate - время стабилизации / количество ошибок после деплоя
Mean time to repair - время восстановления после сбоя

Time to market измеряет время, необходимое для того, чтобы новый продукт, функция или изменение достигло рынка с момента начала его разработки или концепции. Она является важным показателем для компаний, стремящихся быть конкурентоспособными и адаптироваться к быстро меняющимся рыночным условиям. По сути - это главный показатель скорости компании.

Однако, помимо Time to market, есть еще один важный показатель, расширяющий time to market - это time to learn.

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

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

Lead time - время от момента взятия обязательств делать задачу до ее поставки.

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

Для того чтобы вычислить перцентиль необходимо собирать время выполнения по каждой задаче (lead time).

Чтобы посчитать 85 перцентиль за период нужно взять распределение времени выполнения (то есть те задачи которые завершились в данном периоде и вычислить значение до какого значения завершилось 85% задач). Такое значение называется 85-м процентилем. Это значение выводится в виде числа.

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

Картинка иллюстрирующая схематично метрики, включая time to market:

Рис.3 Распределение Lead time

Метрики результативности

Это метрики, ориентированные на пропускную способность и прогнозируемость производственного процесса:

Запланированное/фактическое кол-во целеи;
Запланированное/фактическое кол-во фич/эпиков;
Запланированное/фактическое кол-во US (пользовательских истории);
Запланированное/фактическое кол-во Story points;
Средняя скорость – Velocity – фактическое кол-во SP за период.

Ниже вы увидите пример метрик выведенных в дашборд Aimger.

Рис. 4. План/факт по количеству задач за спринт

Рис. 5. План/факт по количеству Story points и среднее Velocity

Метрики качества - метрики, ориентированные на качество производственного процесса

Technical debt на конец итерации (или планируемого периода);
Critical bugs на конец итерации (или планируемого периода);
Critical vulnerabilities на конец итерации (или планируемого периода);
Количество новых тест кейсов;
Unit test coverage.

Рис. 6. Дефекты накопительным итогом

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

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

Пример из реальной жизни:

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

Количество выполненных Story Points (причем измеряется каждая отдельная задача для каждого сотрудника, а не общая продуктовая фича несущая ценность);
Точность оценок по срокам для задач (также измеряется отдельно по каждой задаче, а не в контексте всей фичи);
Соотношение запланированных Story Points к выполненным. (также в контексте подзадач)

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

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

Как собирать метрики?

Для того чтобы помочь компаниям быстро внедрять метрики и визуализировать их в дашборды, мы с командой сделали Aimger - инструмент сбора и анализа метрик на основе AI, с визуализацией дашбордов, который мы внедряем и настраиваем в компаниях.

Инструмент быстро встраивается в экосистему организации, а также мы помогаем определить и внедрить правильный набор метрик. А AI помощник помогает анализировать данные и делать выводы быстрее.

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

Если хотите получить презентацию продукта, оставляйте заявку по ссылке в сообщении “хочу на презентацию Aimger”.

А также если понравилась статья подписывайтесь на мой телеграм канал.

Как улучшать эффективность разработки через метрики? Фреймворк метрик