Как измерять продуктивность разработчиков с DX Core 4

Выпуск открывает разбор white paper команды DX — платформы, которая профессионально измеряет инженерную продуктивность, — и Александр сразу называет предков фреймворка: DORA, SPACE, DevEx. Евгений формулирует первое впечатление резче: это как со стандартами, где ради решения проблем предыдущих выпускают ещё один; новизна есть, но многое взято у предшественников. Александр добавляет прагматичный мотив: опыт у авторов богатый, но собственный фреймворк нужен, чтобы наполнять фичами свою платформу под своим брендом. Родословную Евгений отсчитывает от книги Accelerate, которая популяризировала метрики DORA: он сам узнал о них оттуда и, по его словам, полгода назад перечитал книгу уже иначе. Ценил он в DORA не инструменты, а референс-модель — линейку, по которой можно откалиброваться относительно компаний, выкатывающихся чуть ли не по сто раз в день, и поставить цель дорасти до элитной категории.

Александр напоминает, что цифры выросли из опросов про DevOps: отчёты, по его словам, примерно с тринадцатого по семнадцатый год легли в основу книги, и перечитать он хочет как раз главы про дизайн опросов. Дальше идёт анекдот про шестидесятилетнего пациента, которому врач советует про личную жизнь рассказывать так же, как рассказывает сосед: в опросной механике есть зазор между честным и социально приемлемым ответом. Свежий пример — отраслевой отчёт про платформы в эпоху Gen AI, где, по его прикидкам, около шестисот опрошенных дружно отчитались, что у них уже всё внедрено. Оттуда же он вытаскивает связку частоты поставки и lead time: авторы отсылают к lean-практикам и маленьким батчам, но вопроса про размер батча не придумали и взяли обратный показатель — как с колбасой: чем чаще отрезаешь, тем тоньше куски. Евгений отмечает, что DORA дёшево начать мерить, ведь Git, пайплайны и трекер уже стоят. Александр вспоминает, как обещал на конференции подарок тому, кто расшифрует четыре буквы DORA, — не смог почти никто.

Проблема DORA, по Евгению, в адресате: это метрики для технических лидеров, а CEO lead time ни о чём не говорит; людей же они не измеряют вовсе. Отсюда SPACE — гибрид, где satisfaction и wellbeing считают опросниками в духе NPS, которые ещё надо задизайнить, а communication и collaboration ловят косвенно: у себя они используют Jellyfish, который смотрит, кто ревьюит чьи пиары, кто кому отвечает в мессенджере и какую долю спринта команда проводит на встречах. Александр называет такую аналитику скорее исследовательской: его коллеги строили граф взаимосвязей и увидели «пуповину» между бэкендерами и QA-инженерами, откуда пошла идея отдать ответственность за качество бэкенду, а тестировщика сделать кроссфункциональным. Метрики, по его мнению, заводят под конкретную проблему, как в observability, а не потому, что так велено; Евгений соглашается: двух-трёх часто достаточно. Сам он спроектировал две платформенные команды и описывает эволюцию: сначала коллабораций со стрим-командами много, потом всё меньше, зрелая часть платформы живёт как сервис, а дешёвый индикатор — канал с запросами и число встреч.

Последним появился DevEx, и с ним у DX возник отдельный продукт: DORA и SPACE продавались как исследование с бенчмарками, а платформу с feedback, cognitive load и flow state уже интегрируют с системами компании ради дашбордов и рыночного бенчмарка — в нём компания и видит конкурентное преимущество. Консультант Игорь Курочкин, назвавший компанию термином из Team Topologies, около полугода назад упрекнул Александра, что тот отстал: платформа нарастила команду и сделала адаптеры к GitLab, GitHub и прочим системам. Сам Core 4 Александр поначалу считал ребрендингом. В анонсе авторы подсвечивают многомерность данных, уровни от отдельного инженера до организации, разворачивание за недели и защиту от гейминга — иначе мотивация смещается к тому, чтобы быть хорошим внутри системы оценивания, и срабатывают законы Гудхарта и Кэмпбелла: метрика, ставшая целью, перестаёт быть хорошей метрикой. Данные берут из систем и опросов, а сверху добавляют интервью с частью инженеров и свободные поля, где иногда встречается крик души; начинать советуют с бейзлайнов, низко висящих фруктов и аккуратной коммуникации.

Core 4 назван по четырём направлениям: скорость, эффективность, качество и импакт, — и импакт Евгений считает находкой авторов. В каждом направлении есть ключевая метрика, которую, как вспоминает Евгений, в статье вроде бы называют output-метрикой, и вторичные, балансирующие: если геймить скорость, открывая больше пиаров, должен просесть кто-то из балансиров вроде lead time или частоты поставки, и станет видно, что продуктивность не изменилась. Ключевая метрика скорости — изменения на инженера, то есть открытые и смерженные пиары. Про воспринимаемую скорость поставки Евгений деталей не помнит, и Александр объясняет: это когда люди жалуются, что важные задачи едут слишком медленно. Он же приводит пример гейминга: если дифы считают по эпикам, растянувшийся эпик дропают, заводят новый и перепривязывают задачи — метрика выглядит отлично, а балансира вроде числа дропнутых эпиков не хватает. Свои балансиры под собственные механики гейминга, предупреждает Александр, дописывать всё равно придётся.

Эффективность меряют индексом Developer Experience — опросным по сути, вроде NPS, — а балансируют его временем до десятого пулреквеста и regrettable attrition: первый пиар можно закрыть правкой readme, десять уже показывают, каков онбординг, а уход людей, о которых компания жалеет, растёт там, где много бюрократии. Александр уточняет, что на attrition влияют и рынок, и деньги, но один из факторов — насколько инженеру приятно работать с тем, что для него построили. В качестве ключевая метрика — change failure rate из DORA, причём ноль тоже плохой знак: команда, вероятно, боится выкатываться; балансир — время восстановления, фичатоглы и стратегии выкатки. Воспринимаемое качество Александр раскладывает на клиентское, то есть баги с прода, и внутреннее — техдолг, из-за которого дорабатывать код всё труднее. Ось импакта — доля времени на новое: Евгений вспоминает, как дашборд с разложением инвестиций подтянул гигиену в Jira, а Александр — каскадный дашборд на тысячу инженеров, где было видно, что больше половины времени уходит на техническую часть — миграции и архитектурные изменения, и это можно вовремя объяснить бизнесу.