| Метрика | Что показывает CTO | Красный флаг |
|---|---|---|
| Lead / Cycle Time | Скорость и «заторы» в потоке | Cycle time ↑ 2 месяца подряд |
| Change Failure Rate | Стабильность релизов | CFR растёт при той же частоте деплоев |
| Review Time | Очереди на согласованиях | Review time ↑ быстрее объёма задач |
| Bug rate после релиза | Качество для бизнеса | Рост дефектов при «зелёном» статусе |
| Прогноз риска сроков | Ранний сигнал срыва | Только субъективная оценка PM |
Почему статусы в Jira обманывают
Статус «В работе» или «На ревью» описывает процесс, а не результат для бизнеса. Команда может закрывать задачи в срок, но накапливать технический долг, растягивать cycle time или увеличивать долю дефектов после релиза.
CTO нужна картина на уровне delivery-потока: как часто команда выводит изменения в прод, как долго идут согласования, где узкие места в review и тестировании. Эти сигналы живут в GitLab, CI/CD и связке с задачами — не в ручных статусах.
Что смотреть вместо «процента выполнения»
Минимальный набор для контроля внутренних команд без микроменеджмента:
- Lead Time / Cycle Time — скорость прохождения работы от идеи до продакшена.
- Change Failure Rate — доля релизов, после которых нужны исправления.
- Review Time — задержки на согласовании кода и архитектуры.
- Bug Rate после релиза — деградация качества, а не «количество багов в спринте».
- Прогноз риска сроков — отклонение от базовой скорости команды, а не субъективная оценка PM.
Важно сравнивать команды в одинаковой методике — иначе «хорошая» цифра у одной команды не сопоставима с другой.
Team Score как язык для руководства
Team Score — сводный индекс по согласованным весам метрик. Он не заменяет разбор инцидентов, но даёт CTO и Head of Engineering единую шкалу для портфеля внутренних команд: кто стабилен, кто деградирует, где нужны ресурсы или изменение процесса.
Без такого слоя метрики остаются в инженерных дашбордах, до совета директоров доходит уже постфактум — перерасход бюджета или срыв релиза.
Чек-лист: 6 вопросов на ежемесячном обзоре
- Какая команда увеличила cycle time два месяца подряд?
- Где review time вырос быстрее, чем объём задач?
- Есть ли команды с ростом CFR при том же объёме релизов?
- Совпадает ли «зелёный» статус в трекере с фактической частотой деплоев?
- Какие delivery-потоки дают наибольшую стоимость фичи при падающем throughput?
- Какие риски сроков видны по тренду, а не по словам PM?
От дашбордов к governance
Дашборд в GitLab или Jira полезен команде. Руководству нужен executive layer: сравнение команд, тренды, алерты и отчёт для управленческого комитета. Разница — в гранулярности и в ответственности: governance отвечает на вопрос «куда вмешаться», а не «сколько коммитов вчера».
Подробнее о платформе, которая собирает такой слой из ваших систем — на странице «Кабинет CTO». Полезные продолжения: метрики разработки для CTO и шаблон отчёта CTO.
Подход согласуется с метриками потока из исследований DORA и практикой сравнения команд по единой методике, а не по «проценту выполнения» в трекере.
FAQ
Какие метрики лучше статусов в Jira показывают реальный delivery?
Смотрите метрики потока и качества: lead time, cycle time, throughput, review time и change failure rate (CFR). Они показывают скорость прохождения работы, узкие места и стабильность релизов.
Как CTO контролировать delivery без микроменеджмента по людям?
Контролируйте систему: тренды cycle time и review time, стабильность релизов (CFR), прогноз риска сроков и блокировки в потоке. Вмешательство — по сигналам процесса, а не по активности отдельных разработчиков.
Зачем нужен executive-слой над инженерными дашбордами?
Чтобы сравнивать команды в одной методике, видеть тренды и алерты, и принимать решения «куда вмешаться». Инженерные дашборды полезны командам, а руководству нужен управленческий уровень.