| Метрика | Что сравниваем | Типичная ошибка |
|---|---|---|
| Cycle time (медиана) | Тренд за 8–12 недель | Сравнение сырого среднего с выбросами |
| Change failure rate | Стабильность при той же частоте релизов | Игнорировать разный CI/CD maturity |
| Throughput | Завершённые единицы потока в неделю | Путать объём с ценностью (мелкие PR vs архитектура) |
| Review time | Очереди и задержки согласований | Не учитывать размер PR и число ревьюеров |
| Investment mix | Доля новых фич / поддержка / долг | Сравнивать Product и Platform без контекста миссии |
| Planning accuracy | Обещано vs поставлено в итерации | Наказывать за промах оценки, а не за системный scope slip |
Почему «сравнение команд» ломается
Три системные причины, почему CTO отказываются от leaderboard и возвращаются к интуиции:
- Разные определения. «Done» в Jira ≠ deploy в prod. Lead time считается от разных точек.
- Разный контекст. Platform держит платформу; Product гонит фичи. Сравнение cycle time без учёта типа работы искажает картину.
- Метрики объёма. Команда с пятью крупными изменениями выглядит «медленнее», чем команда с пятьюдесятью мелкими PR — если не смотреть на поток и качество, а не на счётчик.
Engineering performance calibration — замена opinion-based сравнений на общую рамку: команды в колонках, метрики в строках, базовая линия и пороги для эскалации.
Шаг 1. Зафиксировать методику (governance)
До первого сравнения CTO и Head of Engineering согласуют:
- Источники данных — GitLab, Jira, CI/CD; какие репозитории и проекты входят в scope команды.
- Определения метрик — от какого события lead time, что считается failed deployment, какой период для CFR.
- Исключения — hotfix, chore, эксперименты: что не входит в сравнительную базу.
- Каденс — еженедельно сигналы риска, ежемесячно портфельное сравнение.
Без этого шага любой benchmark превращается в спор на обзоре. Подробнее о слое над дашбордами — в статье дашборды GitLab/Jira vs governance.
Шаг 2. Выбрать метрики сравнения
Минимальный набор для портфеля внутренних команд:
- Cycle time (медиана) — устойчивее среднего, не раздувается выбросами.
- Change failure rate — баланс к скорости; elite-команды по DORA держат CFR и высокую частоту деплоев одновременно.
- Throughput — сколько единиц потока завершается за период (не story points).
- Review time — системное узкое место, видимое на уровне портфеля.
- Investment allocation — куда уходит capacity: новые возможности, поддержка, техдолг. Ориентиры из практики зрелых org: ~60% новые фичи, ~15% продуктивность, ~10% KTLO — как стартовая гипотеза, не догма.
DORA-метрики используйте как диагностику, а не как табло для наказаний: найти самое узкое место в системе и снять его, а не «догнать соседнюю команду».
Шаг 3. Сравнивать траектории, не снимки
Главное правило калибровки: сначала команда против себя. Cycle time команды A вырос на 20% за два месяца — сигнал, даже если абсолютное значение «лучше», чем у команды B.
Портфельное сравнение имеет смысл, когда:
- методика едина;
- смотрите медианы и тренды за 8–12 недель, а не одну неделю;
- учитываете investment mix и зрелость CI/CD.
Сводный индекс (например, Team Score) упрощает executive-обзор, но drill-down до метрик обязателен — иначе score становится leaderboard без диагностики.
Шаг 4. Матрица калибровки на обзоре
Формат, который работает на ежемесячном review CTO:
- Строки — 5–7 метрик из таблицы выше.
- Колонки — команды + «медиана портфеля» как референс.
- Ячейки — не сырые числа, а статус: норма / внимание / эскалация (по согласованным порогам).
- Итог — 2–3 команды в зоне внимания, 1–2 системных паттерна (например, «review time растёт везде»).
Такой формат отвечает на вопрос «куда вмешаться», а не «кто худший». Решения фиксируются: владелец, срок, ожидаемый эффект на метрику.
Типичные ошибки
- Stack ranking инженеров — убивает помощь коллегам и обмен знаниями.
- Story points как KPI — Goodhart в чистом виде: оптимизация под цифру, а не под поставку.
- Игнор качественных сигналов — выгорание, отток, молчание на ретро важнее dashboard.
- Сравнение без контекста домена — Infra и Product в одной гонке по throughput бессмысленны.
- Только lagging metrics — CFR и срыв срока видны поздно; добавьте опережающие сигналы.
Как объяснить CEO результат сравнения
Бизнесу не нужна таблица cycle time. Нужны три вывода:
- Предсказуемость — какие потоки стабильны, где риск срыва roadmap.
- Куда инвестировать — какая команда/узкое место тормозит портфель.
- Что уже делаем — конкретные решения с владельцем и сроком.
Перевод метрик в этот язык — в статье про DORA для руководства и шаблоне отчёта CTO.
Чек-лист внедрения методики
- Определения метрик задокументированы и одинаковы для всех команд.
- Есть базовая линия (8–12 недель) по каждой команде.
- Пороги «внимание / эскалация» согласованы с EM.
- Ежемесячный обзор использует матрицу, а не устные «у них лучше».
- Нет публичного рейтинга людей — только системные метрики и решения.
Платформа с единой методикой и автоматическим сбором из GitLab/Jira снимает ручную работу с калибровки — см. «Кабинет CTO».
FAQ
Можно ли сравнивать команды по story points или velocity?
Нет для портфельного сравнения. Story points — инструмент планирования внутри одной команды, не метрика продуктивности. Для сравнения используйте метрики потока и качества в единой методике: cycle time, CFR, throughput, review time.
Как сравнивать команды с разной сложностью задач?
Смотрите тренды относительно собственной базовой линии и investment allocation (доля новых фич vs поддержка). Абсолютное «кто быстрее» без контекста домена вводит в заблуждение.
Сколько команд можно сравнивать в одной методике?
Практичный диапазон — 3–15 потоков разработки. Больше — нужна группировка по доменам (Platform, Product, Infra) и сводный score на уровне портфеля.