Три набора метрик для трех состояний команды 🔍

Я не сторонник списка из 40 показателей, их можно загуглить.
Вот то, что реально работает у меня

Если у вас хаос, пожары и всё срочно, хочется считать скорость. Но без контроля качества и блокеров тушить придётся вечно.
1) TTM (Time to Market) время от первого запроса до поставки пользователю. Покажи стейкхолдерам цифру, и спор о "долго" закончится.

2) Время простоя в блокировках. Если задача делается 2 дня, а ждёт решения по зависимости 14? Проблема не в разработке, проблема в системе. Как труба с засором: вода есть, а не течёт.

3) Качество декомпозиции. Процент задач, которые решаются за длину спринта или другого вашего цикла. Если много задач находятся в статусе в работе более одного спринта, это вероятно значит, что вы плохо организовали декомпозицию на PBR или оцениваете таски на глаз.

4) CFR (Change Failure Rate) доля релизов, которые привели к инцидентам или хотфиксам. Иначе можно выиграть неделю в TTM, но получить два падения в проде. Бизнес спасибо не скажет.

Если процессы уже более-менее выстроены, старые метрики можно оставить, но фокус смещается.
1) Flow Efficiency доля активной работы (аналитика, дизайн, код, ревью, тесты) в общем времени. Если активного времени 15–20%, остальное ожидание,ты не управляешь потоком, ты управляешь ожиданием. Хороший показатель >45%, если команда и заказчики довольны.

2) CTR (Cancelled Tasks Rate) процент отмененных задач. Если показатель высокий, вы плохо проверяете гипотезы на входе. Команда пашет впустую.

3) Predictability это насколько план совпадает с фактом. Если системно расхождение больше 30% проблема в планировании.

Если у вас несколько команд и сложная система, добавь эти метрики на общий уровень, предыдущие оставь на уровне команд.
1) Количество кросс-командных зависимостей. Каждая зависимость это риск. Считай не только количество, но и время их разрешения. Меньше зависимостей = быстрее и чаще релизы.

2) Сколько передач (handoffs) проходит задача до релиза. Передача из команды в команду, от аналитика к разработчику, от разработчика к тестировщику, каждая теряет контекст и удлиняет срок.

3) полный System Cycle Time с учётом ожиданий между командами на него чаще всего мы и хотим влиять.


А теперь вопросы на засыпку:

1) TTM упал с 5 до 3 месяцев. Радуешься??
Зависит от контекста. Если CFR не изменился, то радуюсь, еще и пива команде поставлю. Если CFR вырос всё не точно хорошо. Метрики смотрят вместе, как врачи на показатели: давление, пульс, температура.

2) TTM = 1 месяц это быстро или долго? CFR = 32% это много или как?
Надеюсь, мы друг друга поняли, ответ всегда: все зависит от контекста. Как мы договорились с бизнесом, стейкхолдерами и заказчиками.

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

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

Делитесь своими наборами метрик в комментариях! 👇🏼

🔮Управление без иллюзий. Подписывайтесь и делитесь с коллегами!
#инструменты