| Критерий | Дашборды GitLab/Jira | Engineering governance |
|---|---|---|
| Аудитория | Команда, тимлид | CTO, Head of Engineering, CEO |
| Охват | Одна команда / один репозиторий | Портфель команд, сравнение |
| Методика | Разная у каждой команды | Единые правила расчёта |
| Поставка | Частично (зависит от настройки) | Lead time, CFR, throughput из CI/CD |
| Алерты | Нет или ручные | Сигналы риска, пороги |
| Отчёт для руководства | Ручная сборка | Executive-слой, 1–2 страницы |
Что дают встроенные дашборды
GitLab — Insights, Value Stream Analytics, CI/CD-метрики: cycle time по стадиям, deployment frequency, pipeline duration. Полезно тимлиду: где узкое место в репозитории, как часто деплоим.
Jira — Dashboards, Sprint reports, Burndown, Control Chart: velocity, cycle time по статусам, throughput по спринтам. Полезно PM и Scrum Master: как идёт спринт, где застревают задачи.
Оба инструмента решают задачу локальной оптимизации: одна команда, один продукт, один процесс. Для CTO с 5–15 внутренними командами этого мало.
Почему дашбордов недостаточно для CTO
Разная методика — несопоставимые цифры
Команда A считает cycle time от «В работе» до «Done» в Jira. Команда B — от merge до deploy в GitLab. Команда C — по story points в спринте. CTO видит три «cycle time» — и не может ответить: «Какая команда деградирует?»
Governance задаёт единые правила: что считать lead time, что — деплоем, какие инциденты входят в CFR. Без этого сравнение команд — иллюзия контроля.
Jira не видит продакшен
Задача «Done» в Jira не означает, что изменение в проде. Поставка — это выкат в production, а не закрытие тикета. Метрики из одного Jira показывают процесс, но не результат для бизнеса.
Нужна связка: Jira (задачи, статусы) + GitLab (код, MR) + CI/CD (деплои, инциденты). Executive-слой собирает это в метрики потока и качества — lead time, CFR, deployment frequency.
Нет слоя для руководства
CEO не будет заходить в GitLab Insights. Ему нужен ответ: «Предсказуемы ли сроки? Где риск? Куда вмешаться?» — на 1–2 страницах, без инженерного жаргона. Дашборды не генерируют такой отчёт автоматически.
Подробнее о формате — в материалах «Шаблон отчёта CTO» и «Прозрачность разработки для бизнеса».
Что такое engineering governance
Governance — не ещё один дашборд. Это система принятия решений на основе согласованных метрик:
- Правила: какие метрики считать, пороги «красного» сигнала, определения Done и деплоя.
- Сравнение: все команды в одной шкале — Team Score, тренды, рейтинг по портфелю.
- Алерты: автоматические сигналы риска — рост cycle time, CFR, WIP — до срыва сроков.
- Отчётность: executive-слой для совета директоров — выводы, а не сырые цифры.
- RBAC: кто видит детали по людям, кто — только агрегаты по командам.
Дашборды GitLab и Jira остаются на уровне команды. Governance — над ними, для CTO и Head of Engineering.
Три уровня метрик
- Команда — GitLab Insights, Jira Control Chart, CI-дашборды. Тимлид оптимизирует локальный поток.
- Портфель — сравнение команд в единой методике, Team Score, сигналы риска поставки. CTO видит, куда вмешаться.
- Руководство — предсказуемость, риск, стоимость задержки. CEO получает ответ без погружения в инструменты.
Без уровней 2 и 3 метрики остаются в инженерных дашбордах — до совета директоров доходит уже постфактум.
Когда дашбордов хватает
Встроенные отчёты GitLab и Jira достаточны, если:
- Одна команда разработки, один продукт.
- CTO совмещает роль тимлида и не нуждается в cross-team сравнении.
- Руководство не запрашивает регулярные отчёты по поставке.
Governance нужен, когда:
- 5+ внутренних команд, разные стеки и процессы.
- CEO или собственник спрашивает «когда будет» и «где риск».
- Нужно сравнивать команды и принимать решения о ресурсах.
- On-premise и требования к данным — нельзя отдавать всё в облачные BI.
Как собрать governance-слой
Варианты:
- Ручная сборка — Excel + выгрузки из GitLab/Jira раз в месяц. Дёшево, но не масштабируется и устаревает к моменту совета директоров.
- BI-дашборды — Metabase, Grafana, Power BI поверх данных. Гибко, но требует настройки ETL, единой методики и поддержки.
- Специализированная платформа — готовый executive-слой с интеграциями GitLab, Jira, Team Score, алертами и отчётами. Обзор — «Кабинет CTO».
Критерий выбора: время до первого управленческого отчёта и возможность сравнивать команды без ручной унификации метрик.
Чек-лист: дашборды или governance?
Ответьте на 5 вопросов:
- Сколько внутренних команд в портфеле? (1 → дашборды; 5+ → governance)
- Можете ли сравнить cycle time двух команд в одной методике сегодня?
- Есть ли автоматические алерты при росте CFR или cycle time?
- Готов ли executive-отчёт для CEO без ручной сборки?
- Видите ли расхождение «зелёный Jira» и фактических деплоев?
Три и более «нет» — сигнал, что пора строить governance-слой, а не добавлять ещё один дашборд в GitLab.
FAQ
Достаточно ли дашбордов GitLab Insights для контроля поставки?
Для одной команды — часто да. Для портфеля из 5–15 внутренних команд CTO нужен единый слой: сравнение в одной методике, тренды, алерты и отчёт для руководства. GitLab Insights не решает задачу cross-team governance.
Почему Jira-отчёты не показывают реальную поставку?
Jira измеряет процесс (статусы, спринты, story points), а не результат в продакшене. Задача может быть «Done» в трекере, но не выкачена. Вывод в прод живёт в GitLab/CI — связка с Jira и единая методика дают полную картину.
Что такое engineering governance в контексте метрик?
Набор правил: какие метрики считать, как сравнивать команды, кто видит что, какие пороги — сигнал риска, как эскалировать. Governance — не дашборд, а система принятия решений на основе данных.