Velocity выше среднего, SLA зелёные, багов немного.
Звучит как здоровый проект - пока заказчик не пишет второй эскалационный.
Это классика работы только с lagging indicators: они показывают прошлое.
- Velocity: сколько задач закрыто (не значит, что ценные).
- SLA: насколько быстро ответили (не значит, что решили).
- Дефекты: сколько нашли (не значит, что не появятся новые).
В них нет прогноза, они честно фиксируют факт, но слишком поздно.
Для прогноза нужны leading indicators.
- Work Item Aging: если задачи висят неделями, релиз уже под угрозой.
- Flow Efficiency: если 70% времени задачи ждут - у тебя не поток, а очередь.
- Decision Latency: если решение по блокеру занимает 5 дней, команда встанет на шестой.
Что с этим делать PM-у?
1. Держать оба типа метрик: lagging для отчетов, leading для управления.
2. Вести разговор со стейкхолдерами на языке будущего, а не только прошедшего.
3. Сравнивать: «velocity зелёный, но aging показывает риск» → это сигнал действовать.
Lagging нужны для истории.
Leading - для того, чтобы у этой истории было продолжение.
