Как не исказить Cycle Time: очистка delivery-метрик
Меня зовут Герман Дьяков, я IT Project & Delivery Manager. В контрактном проекте заказной веб-разработки я выстроил регулярную delivery-отчётность и пересчитал метрики на очищенной базе. Рабочий Cycle Time составил около 65 часов вместо 200+ в исходных данных; недельный throughput за время проекта вырос примерно в 1,8 раза.
Почему сырые метрики завышают Cycle Time
Cycle Time и Lead Time в сырой выгрузке раздувают две вещи: выбросы — единичные аномально долгие задачи — и залежавшийся бэклог, где карточки числятся в работе только формально. Такая цифра смешивает активную поставку и состояние учёта, поэтому плохо подходит для управленческих решений.
Как считал честно
- Отделил выбросы и залежавшийся бэклог от активного потока.
- Пересчитал Cycle/Lead Time на очищенной базе → ~65 часов реального времени цикла.
- Диагностировал топ-ограничения поставки и предложил меры: WIP-лимиты, критерий Ready-for-Development, стабилизацию спринтов.
Что построил вокруг метрик
Настроил daily, ежемесячное ретро, регулярную отчётность, дашборд delivery-метрик и ежемесячный обзор результатов. Метрики снимал из Jira и отдельно фиксировал правила очистки данных.
- Почему нельзя доверять Cycle Time из сырой выгрузки?
- Потому что выбросы и «мёртвые» карточки в бэклоге завышают его в разы. Прежде чем принимать решения, поток надо очистить от того, что не является реальной работой.
- Как быстро вырос throughput?
- За время проекта недельный throughput вырос примерно в 1,8 раза без расширения команды. Одновременно внедрялись delivery-ритмы и отчётность, но имеющиеся данные не позволяют приписать весь рост одному изменению.
Смотреть дальше
Профиль и другие кейсы Личный кабинет застройщика: MVP → первая сделка Резюме PDF Публичный кейс на Хабре