🗣 Одна метрика сообщает факт. Комбинация метрик подсказывает, что делать

После насыщенных выходных, сложно наступать на правую ногу, хочется верить, что это не старость, а всего лишь последствие долгих прогулок в лоферах.🤣

Но неделю хочу начать с моей любимой темы - метрик. Но сегодня без привычного: «CT снизился на 12%, давайте покрасим ячейку в зеленый».

Коротко о героях поста: — CT - сколько задача находится в работе; — LT - сколько проходит от запроса до результата; — TTM - путь от идеи до выхода на рынок; — Sprint Velocity - объем работы команды за спринт; — Deploy Frequency - частота поставок в промышленную среду.

По одной метрике диагноз не поставить. Зато их комбинации уже превращаются в подсказки.

CT растет, velocity падает Задачи выполняются дольше, а команда завершает меньше. Что проверить: размер задач, число переключений, технические ограничения и незавершенную работу. Что делать: декомпозировать задачи, ограничить параллельную работу и убрать лишние приоритеты. Просить команду «просто ускориться» не стоит. Возможно, она и так быстро бегает - просто между пятью пожарами.

CT стабилен, LT растет Разработка работает с прежней скоростью, но задачи все дольше ждут своей очереди. Что делать: пересмотреть входящий поток, правила приоритизации и почистить бэклог. Бэклог на три года - это не стратегия. Это музей несбывшихся надежд.

Velocity растет, TTM не сокращается Команда делает больше, но продукт не выходит быстрее. Значит, задержка находится за пределами разработки: согласования, безопасность, тестовые контуры или зависимости. Что делать: посмотреть на весь путь от идеи до клиента и найти реальные очереди. Ускорять один вагон бесполезно, если весь поезд стоит перед семафором.🫡

Velocity высокая, Deploy Frequency низкая Задачи готовы, но изменения редко доходят до пользователей. Что делать: уменьшать размер поставки, автоматизировать сборку и тестирование, использовать функциональные переключатели. Большая куча задач в статусе «готово, но не установлено» - это не ценность. Это склад без отдела доставки.

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

CT снижается, velocity и Deploy Frequency растут На первый взгляд - идеальная картина. Но пора проверить качество, инциденты и продуктовый эффект. Команда действительно ускорилась - или просто научилась быстрее выпускать то, чем никто не пользуется? Что делать: связать показатели потока с дефектами, использованием функций и бизнес-результатом.

Главный вывод: метрика должна приводить к управленческому действию.

Если после просмотра дашборда мы можем сказать только «тут красное», значит, перед нами пока не система управления, а дорогой корпоративный светофор. А какие комбинации метрик помогают вам находить узкие места? 🤓