| Сигнал | Что смотреть | Порог внимания | Горизонт |
|---|---|---|---|
| WIP | Открытые PR и задачи in progress | +20% неделя к неделе | 1–2 нед. |
| Cycle time | От старта работы до merge/релиза | +25% к 4-нед. среднему | 2–4 нед. |
| Очередь PR | Open PR на ревьюера | >5 на человека | 1–3 нед. |
| CFR | Failed deploys / все deploys | Рост 2 недели подряд | 2–4 нед. |
| Зависимости | days_in_state | >7 дней | 4–10 нед. |
| Решения | Дней без именованного owner | >7 дней | 6–10 нед. |
Почему статусы в Jira обманывают
Исследования крупных IT-программ показывают: перерасход бюджета и сроков накапливается постепенно, а не «внезапно в конце». Отчёт с цветом светофора — запаздывающий индикатор в обличье опережающего: к моменту «жёлтого» сбой уже произошёл в потоке работ.
Для CTO внутренних команд важнее не «сколько задач в работе», а как быстро стареют блокеры и меняется ли сама работа под ногами у команды. Эти данные уже есть в Jira, GitLab и CI/CD — не хватает измерительного слоя, который смотрит на производные (тренды), а не на интеграл (количество открытых тикетов).
Сигналы из потока разработки (2–4 недели)
Шесть инженерных индикаторов реагируют раньше, чем PM назовёт срок «под угрозой». Их можно снять из GitLab, merge requests и пайплайнов без ручного отчёта.
1. Рост WIP (work in progress)
Команда начинает больше, чем завершает. Создаётся иллюзия прогресса — «смотрите, сколько работы в полёте» — при падающем throughput. Порог: рост WIP более 20% неделя к неделе. Действие: остановить старт новых приоритетов, разобрать блокеры, снять лишние параллельные эпики.
2. Удлинение cycle time
От старта работы до merge и релиза идёт дольше обычного. Cycle time надёжнее velocity, потому что измеряет фактический поток, а не story points. Порог: более 25% выше скользящего среднего за четыре недели. Смотрите по фазам: кодинг, review, CI, деплой — не «в среднем по больнице».
3. Очередь PR на ревью
Готовый код ждёт, а не поставляется. Каждый PR в очереди — работа, которая сделана, но не доставлена; контекст теряется, растут конфликты merge. Порог: более 50% рост открытых PR или более пяти PR на одного ревьюера.
4. Падение частоты деплоев
Pipeline «забивается»: реже выкаты, больше накопленных изменений. Deployment frequency (одна из метрик DORA) падает раньше, чем срывается дедлайн в roadmap.
5. Рост change failure rate
Больше hotfix, rollback и инцидентов после релиза. Качество и стабильность деградируют до того, как статус в трекере сменится на «жёлтый».
6. Рост unplanned work
Доля срочных задач, багов с прода и «пожаров» растёт неделю за неделей. Команда тушит, а не поставляет запланированный scope — и прогноз по throughput уходит в минус.
Сигналы координации и программы (6–10 недель)
Шесть управленческих индикаторов видны на стыке команд, в трекере зависимостей и в журнале решений. Они предсказывают срыв раньше, чем любой RAG-отчёт.
7. Старение зависимостей
Ошибка типичных дашбордов: считают количество зависимостей, а не возраст в
текущем статусе. Десять закрытых за три дня и две, висящие девятнадцать дней, на
сводке выглядят одинаково «нормально». Пороги: менее трёх дней — норма;
три–семь — внимание; более семи — эскалация. Добавьте колонку days_in_state:
топ-10 самых «старых» — реальный risk register недели.
8. Старение решений
Программы срываются не потому, что «сложно решить», а потому что непонятно, чьё это решение. Пока owner не назван, команды строят под разные допущения. Практика: у каждого открытого решения — одно имя (не «Eng leadership»), дата поднятия вопроса и heatmap «владелец × макс. дней ожидания» на еженедельном обзоре.
9. Энтропия критериев приёмки
Число правок acceptance criteria после входа истории в спринт. Правки до commit — норма; после — земля уходит из-под ног у команды. Порог: более шести правок за неделю на историю — зона риска; более десяти — разговор о re-baseline scope.
10. Scope slip при «стабильном» velocity
Story points и закрытые тикеты в норме, но roadmap постоянно сдвигается. Измеряется активность, а не предсказуемость поставки для бизнеса.
11. Рост lead time при неизменном throughput в спринте
«Закрываем задачи», но путь до прода удлиняется. Узкое место в системе — review, релизы, зависимости — а не «недостаточные усилия команды».
12. Прогноз по throughput vs дедлайн
85%-й прогноз завершения позже обещанной даты. Считайте по фактическому throughput за 8–12 недель, а не по оценкам на планировании: оптимистичная дата (50%), рабочая (85%), безопасная (95%) — и сравнение с commitment перед руководством.
Как переделать еженедельный обзор
Обзор по светофору занимает 30 минут и не даёт решений. Формат на 25 минут:
- 8 минут — три графика: WIP/cycle time, старение зависимостей, старение решений. Без обсуждения RAG.
- 12 минут — только «горячие» решения с именованным владельцем и дедлайном до следующей встречи.
- 5 минут — одно улучшение и одно ухудшение недели; фиксируется в заметке.
Статус-нота после встречи: три сигнала, три числа, три действия — без формулировок «направленно зелёный». Если руководству нужен один цвет для exec-дашборда — это их задача перевести; программа не производит светофор ради светофора.
Что сделать на этой неделе
- Добавить возраст зависимостей. В трекере уже есть timestamps смены статуса — выведите
days_in_stateи отсортируйте открытый список по убыванию. - Назначить owner каждому решению. Замените «команда» и «steering committee» на одно имя; если имени нет — это problem statement, а не пункт decision log.
- Запустить запрос по AC. Audit log Jira/Azure DevOps/Linear: истории, у которых описание менялось после входа в спринт. Топ-5 за прошлый квартал — кейсы для разговора с leadership.
От сигналов к governance
Инженерные дашборды в GitLab и Jira полезны командам. CTO портфеля внутренних команд нужен executive layer: единая методика, сравнение трендов, алерты по порогам и отчёт для управленческого комитета — без микроменеджмента по людям.
Продолжение темы: как CTO видит эффективность команд, метрики разработки для CTO и шаблон отчёта CTO. Обзор платформы, которая собирает такой слой из GitLab и Jira — на странице «Кабинет CTO».
FAQ
Какие сигналы риска поставки смотреть в первую очередь?
Начните с WIP, cycle time и очереди PR — они реагируют на перегруз и узкие места в GitLab за 2–4 недели до срыва срока. Для кросс-командных программ добавьте старение зависимостей и решений.
Нужно ли отказываться от story points и RAG-статусов?
Story points полезны для планирования спринта, но не для commitment перед руководством. RAG-отчёты отражают политику, а не траекторию поставки — их дополняют, а не заменяют опережающими сигналами.
Чем сигналы риска отличаются от дашборда Jira?
Jira показывает статусы задач. Опережающие сигналы — тренды системы: как быстро стареют блокеры, растёт ли cycle time, меняются ли критерии приёмки после старта работы. Executive-слой нужен, чтобы сравнивать внутренние команды в одной методике.