1.10 Эффективность инженерии и продуктивность разработчиков

Обзор и мотивация

Каждый руководитель большой программной организации рано или поздно задаёт один и тот же вопрос в разных вариантах: становимся ли мы лучше в создании программ и как мы об этом узнаем? Эта глава о честном ответе на него. Эффективность инженерии это то, насколько хорошо ваша организация превращает инженерные усилия в ценное, надёжное программное обеспечение. Продуктивность разработчиков это сторона отдельного человека и команды: сколько полезного результата разработчик способен произвести и сколько его времени и внимания рабочая среда ему возвращает, а не отнимает.

Беда начинается в момент, когда кто-то пытается свести это к одному числу. Считайте строки кода, и люди будут писать больше кода. Считайте story points, и оценки вырастут. Считайте коммиты, запросы на слияние или часы за столом, и вы вознаграждаете движение вместо прогресса. Продуктивность работника умственного труда не количество изделий. Разработчик, удаливший десять тысяч строк мёртвого кода или потративший день на парную работу, чтобы коллега избежал сбоя в эксплуатации, сделал отличную работу, которую не фиксирует никакая наивная метрика. Честный ответ на «насколько мы продуктивны?» многомерен и воспринимает опыт разработчика от работы как реальный сигнал, а не мягкий.

Это важнее, а не менее важно, по мере масштабирования. В корпорации с десятками команд небольшие объёмы трения (медленная сборка, нестабильный набор тестов, двухдневное ожидание среды), умноженные на сотни инженеров, дают огромную потерю мощности. В государстве, где у результата нет рыночной цены, риск это «театр результатов»: измерение выпущенных документов или закрытых тикетов, пока общественная ценность остаётся неизмеренной. Цель этой главы помочь измерять и повышать эффективность инженерной организации и повседневный опыт её разработчиков без накруток, слежения и ранжирования людей друг против друга.

Ключевые принципы

Продуктивность многомерна. Её не охватывает ни одно число. Любая метрика, предлагаемая как та самая мера, неверна.
Измеряйте, чтобы убирать трение, а не ранжировать людей. Предмет измерения система, а не человек.
Триангулируйте. Сочетайте то, что разработчики говорят о том, каково работать, с тем, что системы реально фиксируют.
Опыт разработчика это данные. Петли обратной связи, когнитивная нагрузка и поток измеримы и стоят улучшения.
Предполагайте, что любая метрика будет накручена. Проектируйте против закона Гудхарта с помощью нескольких измерений и честного намерения.
Связывайте с результатами осторожно. Эффективность должна подниматься к бизнес-ценности, не становясь целью, которая искажает.

Рекомендации

Отвергните ловушку единственной метрики

Первая дисциплина состоит в отказе называть одно число продуктивностью. Строки кода, число коммитов, velocity в story points и отработанные часы имеют общий фатальный изъян: они измеряют активность, а не ценность, а активность тривиально раздуть. Это закон Гудхарта в действии: когда мера становится целью, она перестаёт быть хорошей мерой. Velocity была придумана как вспомогательное средство прогнозирования самой команды; как только руководитель сравнивает баллы одной команды с баллами другой, команды тихо переоценивают свои оценки, и число становится бессмысленным. Когда кто-то требует единственный KPI продуктивности, воспринимайте это как запрос, который нужно переформулировать, а не выполнить. Предложите вместо этого небольшой сбалансированный набор и объясните, почему одно число ввело бы в заблуждение.

Используйте SPACE, чтобы структурировать измеряемое

Модель SPACE даёт пять измерений, которые стоит держать вместе: Satisfaction and well-being (удовлетворённость и благополучие), Performance (результативность), Activity (активность), Communication and collaboration (коммуникация и сотрудничество) и Efficiency and flow (эффективность и поток). Смысл SPACE в том, что нужно выбрать как минимум несколько измерений, никогда не одно и никогда не все из одной категории. Метрики активности (коммиты, развёртывания) соблазнительны, потому что их легко собирать, но сами по себе они искажают. Сочетайте их с сигналом удовлетворённости и сигналом результативности, чтобы ни одно измерение нельзя было накрутить без разоблачения другими. Команда, выпускающая больше развёртываний, пока удовлетворённость рушится, а доля неудачных изменений растёт, не продуктивнее, и сбалансированный набор показывает это немедленно.

Рассматривайте опыт разработчика как петли обратной связи, когнитивную нагрузку и поток

Опыт разработчика (DevEx) это то, каково заниматься здесь инженерной работой, и он конкретнее, чем звучит. Он опирается на три вещи, которые можно измерять и улучшать. Петли обратной связи это то, как долго разработчик ждёт, чтобы узнать, сработало ли что-то: время локальной сборки, длительность набора тестов, оборачиваемость ревью кода, время развёртывания. Медленные петли заставляют переключать контекст и простаивать в ожидании. Когнитивная нагрузка, общее умственное усилие, которого требует задача, растёт, когда разработчику приходится жонглировать слишком многими инструментами, недокументированными системами и запутанными зависимостями ради простого изменения. Поток это состояние сосредоточенного продуктивного погружения, которое разрушают раздробленные календари и постоянные прерывания. Когда вы укорачиваете петлю обратной связи, убираете понятие, которое разработчик должен был держать в голове, или защищаете блок времени для концентрации, вы улучшили продуктивность так, как не зафиксирует никакой подсчёт активности. Это та же забота о DevEx, которой служит платформенная инженерия через проторённые дороги и самообслуживание (глава 8.4).

Триангулируйте восприятие с системными метриками

Ни один источник данных не заслуживает доверия сам по себе, поэтому объединяйте два вида. Данные восприятия приходят от самих разработчиков через опрос об опыте разработчика: регулярную, в основном анонимную анкету о том, насколько уверенно они выпускают, где теряют время и что их раздражает. Системные данные приходят от ваших инструментов: тайминги конвейеров, задержка ревью, частота инцидентов. Каждый исправляет другой. Опросы улавливают боль, которую инструменты упускают, например деморализующий график дежурств или ненавистный унаследованный сервис. Системные метрики улавливают проблемы, которые люди привыкли не замечать и перестали сообщать. Когда опрос говорит, что сборки мучительны, а данные конвейера подтверждают медианную сборку в пятнадцать минут, у вас есть приоритетное, обоснованное вложение. Проводите опрос с устойчивой периодичностью, делайте его коротким и всегда замыкайте петлю, показывая, что изменилось благодаря ему.

Используйте DORA как сигнал поставки, а не таблицу лидеров

Четыре метрики DevOps Research and Assessment (DORA) (частота развёртываний, время выполнения изменений, доля неудачных изменений и время восстановления сервиса) это сильное, подкреплённое исследованиями чтение вашей способности поставки, сочетающее скорость со стабильностью, так что ни одна не приносится в жертву другой. Глубина по ним в главе 11.5, а конвейер поставки, который они измеряют, в главе 11.2; используйте их там. Здесь совет о том, как с ними обращаться. Считайте DORA сигналом здоровья на уровне команды, показывающим, улучшается ли ваша система поставки, а не табло для ранжирования команд или людей. Как только числа DORA появляются в чьём-то ревью результативности, команды начинают дробить развёртывания, чтобы набить частоту, и скрывать инциденты, чтобы защитить долю неудач, и сигнал умирает.

Измеряйте систему, никогда не следите за человеком

Это черта, которую нельзя пересекать. Агрегируйте метрики до уровня команд и организации и используйте их, чтобы находить и убирать трение. Не стройте панели, ранжирующие разработчиков по коммитам, часам или «оценкам продуктивности», и не позволяйте индивидуальной телеметрии питать оплату или повышение. Слежение разрушает психологическую безопасность и доверие, от которых зависит эффективная инженерия, и учит людей оптимизировать метрику вместо работы. Индивидуальный рост и оценка принадлежат отдельным человеческим механизмам карьерных лестниц и разговоров с руководителем (глава 1.3). Измерение эффективности спрашивает «что замедляет наши команды?». Оно никогда не спрашивает «кто наш самый медленный инженер?».

Атакуйте рутину и трение напрямую

Как только вы видите, где время утекает, вложите его обратно. Многое из ограничивающего эффективность это рутина (toil), ручная, повторяющаяся, автоматизируемая работа, растущая вместе с масштабом и не приносящая устойчивой ценности (глава 9.1). Медленные ревью тоже трение, поэтому оптимизация ревью кода (глава 2.5) с помощью более мелких изменений и ясных ожиданий укорачивает основную петлю обратной связи. Проторённые дороги и платформы самообслуживания (глава 8.4) убирают целые категории ожидания и когнитивной нагрузки сразу. Также закладывайте бюджет против технического долга, накопленной стоимости прошлых упрощений, облагающей налогом каждое будущее изменение, потому что кодовая база, которую никто не может безопасно менять, самая глубокая яма продуктивности.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Единственная метрика продуктивности (LOC, velocity, коммиты)	Дёшево, просто, одно число для руководителей	Накручивается немедленно; измеряет активность, а не ценность; разъедает доверие
Сбалансированный набор в духе SPACE	Устойчив к накруткам; отражает реальность	Больше работы по сбору; труднее подытожить одной цифрой
Опрос DevEx (восприятие)	Улавливает ощущаемую боль, которую упускают инструменты	Субъективен; нужны доверие и доведение до конца для честности
Системные метрики (DORA, тайминги конвейера)	Объективны, непрерывны, трудно подделать в совокупности	Слепы к моральному духу и контексту; опасны при применении к людям
Триангуляция обоих	Каждый источник исправляет другой; устойчиво	Требует вложений в инструменты и дисциплину опросов

Основное напряжение это строгость против честности. Единственное число легко отчитывать и легко испортить; богатая, многомерная картина честна, но труднее для передачи занятому руководителю. Разрешите это, выбрав небольшой сбалансированный набор (несколько измерений SPACE плюс опрос плюс DORA как чтение поставки), сообщая тренды, а не снимки, и явно говоря, что числа существуют ради улучшения системы, а не оценки людей. Когда руководство хочет «один график», дайте тренд нескольких взаимодополняющих сигналов и откажитесь от соблазна свернуть их в ложный композит.

Вопросы для обсуждения с командой

Если бы завтра руководитель потребовал единственное число продуктивности, что бы вы ему дали? Этот вопрос показывает, понимает ли ваша организация ловушку. Честный ответ в том, что ни одно число не безопасно, и ваша задача переформулировать запрос в небольшой сбалансированный набор, устойчивый к накруткам. Принесите метрики, о которых вы уже сообщаете, и спросите для каждой: «как умная, циничная команда раздула бы это, не работая лучше?». Если ответ прост, метрика опасна в момент, когда становится целью. Обсудите, что вы предложили бы вместо этого и как объяснили бы руководству, почему одно число заставило бы его оптимизировать не то. Качество этого разговора предсказывает, поможет ли вам измерение или испортит вас.
Какая у вас самая медленная петля обратной связи и чего она стоит вам каждый день? Петли обратной связи это то место, где продуктивность тихо утекает: пятнадцатиминутная сборка, двухдневное ожидание ревью, нестабильный набор тестов, подтачивающий доверие к каждой зелёной галочке. Принесите реальные числа из опроса об опыте разработчика и из инструментов конвейера и посмотрите, согласуются ли ощущаемая боль и измеренная задержка. Оцените ежедневную стоимость, умножив ожидание на число разработчиков, сталкивающихся с ним, и частоту, и обоснование вложения обычно получается само. Решите, какую петлю укорачивать первой и кто отвечает за исправление. Команда, не способная назвать свою самую медленную петлю, ещё не начала измерять самое важное.
Где ваше измерение рискует ощущаться как слежение и как вы это предотвратите? Разница между измерением системы и наблюдением за людьми это разница между доверием и страхом, и её легко пересечь, не заметив. Пройдитесь по каждой панели и отчёту и спросите, мог бы какой-нибудь из них ранжировать человека или питать ревью результативности. Решите явно, что остаётся агрегированным, что анонимным и что под запретом, затем скажите об этом открыто измеряемым командам. В корпоративной и государственной среде, где давление надзора и аудита сильно, соблазн спуститься до отдельных людей постоянен, поэтому ограждением должен быть заявленный принцип, а не надежда. Если разработчики верят, что числа используются против них, они будут оптимизировать числа, и правда исчезнет.
Когда мы в последний раз спрашивали разработчиков, каково работать, что изменилось в результате и узнали ли они об этом? Опрос, не дающий видимых действий, учит разработчиков перестать отвечать честно, поэтому второй молчаливый опрос получает меньше и более бесцветных ответов, чем первый, и инструмент, на который вы полагаетесь, разлагается именно по мере его масштабирования. Для большой организации потери нарастают: сотни людей тратят время на сообщения о трении, отчёт циркулирует, и ничего не выпускается. Принесите три главных вывода последнего опроса, конкретную работу, которую запустил каждый, и как вы сообщили результат тем, кто поднял вопрос. Взвесьте противоположное тяготение между действием по самой громкой жалобе и по самой распространённой, потому что это часто разные проблемы. В корпоративной и государственной среде, где усталость от опросов и перегрузка консультациями уже высоки, воспринимайте замыкание петли как обязательство управления: назовите, кто отвечает за реакцию, опубликуйте, что изменилось, и примите, что неотвеченный опрос хуже отсутствия опроса.
Как нам сравнивать команды, не строя таблицу лидеров, наказывающую честность? Руководители больших организаций естественно хотят знать, какие команды процветают, а какие застряли, но ранжирование команд по сырой velocity, частоте развёртываний или числам DORA игнорирует то, что платёжная команда под жёстким регулированием и прототипная команда с нуля живут в разных мирах. Противоположное соображение реально: вам нужно замечать команды в беде и распространять то, что работает, но как только сравнение становится табло, команды переоценивают оценки, скрывают инциденты и дробят развёртывания, защищая своё положение. Принесите конкретные примеры того, как контексты команд различаются в вашей организации, вместе с предложением сравнивать каждую команду с её собственной траекторией во времени, а не с соседями. В корпоративной и государственной среде, где давление аудита и надзора сильно подталкивает к межкомандному ранжированию, заранее договоритесь, что можно сравнивать, что будет читаться только как тренд команды и кто уполномочен отказать в несправедливом сравнении.
Как связать эффективность с реальными результатами, не превращая метрику поставки в искажающую цель? Эффективность, никогда не поднимающаяся к ценности, выглядит для руководства самосозерцанием, но как только сигнал поставки вроде времени выполнения или частоты развёртываний становится целью в ревью результативности, команды оптимизируют число и бросают результат, для которого оно было заменителем. Для большой организации напряжение острое, потому что руководители хотят чистой линии от инженерных усилий к бизнес-результатам, а честная линия запутана и запаздывает. Принесите ваши нынешние меры результата, сигналы поставки, с которыми вы их бы связали, и явный отчёт о том, как каждый мог бы быть накручен, став целью. Взвесьте тяготение между простой историей, которую руководство может пересказать, и правдивой картиной, устойчивой к искажениям. В государстве или нерыночной внутренней платформе, где нет выручки для привязки ценности, будьте готовы определять результаты как надёжность сервиса, время цикла исправлений и общественную пользу, а не сырую активность, и защищать этот выбор перед надзорными органами, которые могут предпочесть легче подсчитываемые артефакты.

Взгляд по секторам

Стартап. С горсткой инженеров и небольшим запасом времени полностью пропустите панели и измеряйте две вещи, движущиеся быстрее всего: опрос об опыте разработчика из десяти вопросов и базовые тайминги конвейера. Ваш самый большой риск продуктивности это медленный или нестабильный набор тестов и постоянное переключение контекста, поэтому найдите худшую петлю обратной связи, укоротите её и двигайтесь дальше. Не поднимайте программу измерений, которую некому вести, потому что один честный разговор о том, где утекает день, лучше любого инструмента, который потом придётся поддерживать.

Малый бизнес. Без специалиста по измерениям и при ограниченном бюджете опирайтесь на то, что уже фиксируют ваши инструменты: время сборок, задержку ревью и число инцидентов из систем, за которые вы уже платите. Купите лёгкий инструмент опросов, а не стройте его, и сопротивляйтесь предложению поставщика панели индивидуальной продуктивности, которая обойдётся доверием, которое вы не можете себе позволить потерять. Подавайте всю работу как устранение трения для небольшой команды, не способной тратить впустую ничей день.

Крупная организация. Между десятками команд приз это возвращённая в масштабе мощность, а опасность центральная панель, тихо сползающая в ранжирование людей. Стандартизируйте сбалансированную программу (ежеквартальный опрос DevEx, несколько измерений SPACE и DORA как тренд поставки по каждой команде) и управляйте ею так, чтобы индивидуальная телеметрия никогда не собиралась. Сравнивайте каждую команду с её собственной траекторией, обосновывайте вложения в платформу (глава 8.4) трением, которое раскрывают данные, и дайте одному ответственному владельцу полномочие отклонять любую метрику, которая стала бы таблицей лидеров.

Государственный сектор. Без рыночной цены результата и при сильном давлении надзора тяга к театру результатов (подсчёт документов и закрытых тикетов) постоянна, а тяга следить за названными людьми под аудитом ещё сильнее. Вместо этого измеряйте результаты и способность поставки: как быстро сервис выпускает исправление, насколько он надёжен и как сотрудники и подрядчики воспринимают работу в анонимном опросе. Измеряйте гражданских служащих и подрядчиков на одной системной основе, публикуйте, для чего служит измерение, и будьте готовы доказывать законодательному органу, что тренд поставки по команде более честное чтение общественной ценности, чем любая индивидуальная оценка.

Примеры

Стартап. Стартап из двадцати человек замечает, что выпуск замедлился, хотя все заняты. Вместо установки панели продуктивности инженерный руководитель проводит опрос DevEx из десяти вопросов и снимает базовые тайминги конвейера. Опрос и данные согласуются: набор тестов идёт двадцать две минуты и падает случайно, поэтому люди накапливают изменения и переключают контекст, пока ждут. Команда тратит две недели на исправление нестабильных тестов и распараллеливание набора, сократив его до четырёх минут. Частота развёртываний растёт сама собой, удовлетворённость подскакивает в следующем опросе, и никого для этого не ранжировали и не оценивали.

Крупная организация. Банк с сорока инженерными командами хочет обосновать дальнейшие вложения в свою внутреннюю платформу. Платформенная группа принимает сбалансированную программу измерений: ежеквартальный опрос DevEx по всем командам, сигналы в духе SPACE и метрики DORA, читаемые на уровне команды как тренд здоровья поставки (глава 11.5). Принципиально, они справедливо оценивают команды, сравнивая каждую с её собственной траекторией во времени, а не друг с другом, потому что контексты команд сильно различаются. Данные показывают, что команды на проторённых дорогах (глава 8.4) адаптируют новых инженеров за дни, а не недели, и сообщают о гораздо меньшей когнитивной нагрузке. Это свидетельство, поданное как возвращённая мощность по сотням разработчиков, финансирует платформу ещё на год. Индивидуальная телеметрия намеренно никогда не собирается.

Государственный сектор. Федеральное агентство цифровых услуг должно показать законодательному органу, что его инженерные расходы дают ценность, в условиях отсутствия рыночной цены результата. Оно отвергает театр результатов (подсчёт документов или закрытых тикетов) и вместо этого измеряет результаты и способность поставки: как быстро сервисы выпускают исправление, насколько они надёжны и как коллектив и его подрядчики воспринимают работу в анонимном опросе. Сигналы поставки в духе DORA показывают, действительно ли модернизация улучшает пропускную способность и стабильность, привязанные к общественным результатам, а не сырой активности (глава 11.5). Поскольку измерение никогда не ранжирует людей, а подрядчики и гражданские служащие измеряются на одной системной основе, агентство избегает проблем слежения и морали, топящих такие усилия, и даёт надзорным органам честное чтение ценности.

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от измерения и улучшения эффективности это возвращённая мощность, и в масштабе числа велики. Малые трения умножаются по большой организации: десятиминутная сборка, с которой сто инженеров сталкиваются несколько раз в день, это тысячи инженерочасов в год, потраченных на ожидание. Сократите эту петлю, и вы добавили значимую мощность, никого не нанимая. Основной ROI здесь тот же, что и в платформенной инженерии (глава 8.4): дорогое инженерное время, переадресованное с ожидания и рутины на ценную работу.

Совокупная стоимость владения скромна, но реальна. Вы платите за инструменты опросов и дисциплину их проведения, за инструментирование конвейеров и за внимание руководства, чтобы читать тренды и действовать на их основании. Больший риск для ROI это плохое измерение. Одна накрученная метрика или программа слежения может дать отрицательную отдачу: месяцы усилий по оптимизации числа, пока реальные результаты стагнируют, плюс разъедание доверия, затрудняющее каждое будущее изменение. Стоимость отсутствия измерения рассеяна и огромна: трение и рутина накапливаются невидимо, старшие инженеры выгорают на избегаемых потерях, а руководство не может сказать, помогают ли вложения. Обосновывайте руководству как рычаг и честность: небольшая, пользующаяся доверием, сбалансированная программа измерений, находящая, где большой коллектив теряет время, и окупающая себя многократно в момент, когда вы действуете по первой находке.

Антипаттерны и ловушки

Единственная метрика продуктивности. Любое одно число (LOC, velocity, коммиты, часы) накручивается в день, когда становится целью.
Ранжирование людей. Таблицы лидеров и индивидуальные «оценки продуктивности» разрушают доверие и учат людей оптимизировать метрику.
Измерение как слежение. Детальная индивидуальная телеметрия, питающая ревью, разъедает психологическую безопасность, нужную эффективной работе.
Опросы без доведения до конца. Спрашивать разработчиков, каково работать, и затем ничего не менять учит их перестать отвечать честно.
Сравнение сырых чисел команд. Контексты команд различаются; межкомандные сравнения velocity или DORA наказывают честность и вознаграждают накрутку.
Театр результатов. Подсчёт произведённых артефактов (документы, тикеты, функции), пока реальные результаты остаются неизмеренными, распространён там, где нет рыночной цены.
DORA в ревью результативности. Как только метрики поставки оценивают людей, команды скрывают инциденты и дробят развёртывания, и сигнал умирает.

Модель зрелости

Уровень 1, Начальный: Продуктивность оценивается по ощущению или единственной накручиваемой метрике вроде строк кода, velocity или часов. Измерение стихийно и реактивно, трение невидимо, жалобы анекдотичны, и никто не может сказать, становится ли организация лучше.
Уровень 2, Развитие: Некоторые команды принимают базовые практики: несколько метрик, часто подсчёты активности, и редкий опрос об опыте разработчика. Практики непоследовательны от команды к команде, данные собираются, но редко используются, подкрадываются сырые межкомандные сравнения, а общего принципа, защищающего людей от ранжирования, нет.
Уровень 3, Стандартизация: Сбалансированная программа измерений задокументирована и применяется по всей организации, используя измерения в духе SPACE, регулярный опрос DevEx и DORA как сигнал поставки (глава 11.5). Метрики агрегируются до команд по политике, людей никогда не ранжируют, а находки запускают конкретную работу по укорачиванию петель обратной связи и сокращению рутины (глава 9.1).
Уровень 4, Управление: Программа измеряется и контролируется относительно базовых значений. Времена петель обратной связи, оценки опросов и тренды DORA имеют согласованные целевые значения и отслеживаются во времени; каждая команда сравнивается с собственной траекторией, а не с соседями; вложения в платформу и сокращение рутины обосновываются данными «до и после» о возвращённой мощности; а ухудшение любого сигнала запускает пересмотр, а не проходит незамеченным.
Уровень 5, Оркестрация: Измерение пользуется доверием, рутинно и адаптивно. Данные восприятия и системные данные триангулируются, тренды питают непрерывное улучшение, трение и когнитивная нагрузка активно выискиваются и устраняются, сам набор измерений пересматривается по мере изменения организации, а эффективность интегрирована с бизнес-результатами и общественными результатами, и ни одной метрике не позволено стать искажающей целью.

Идеи для обсуждения

Какие из ваших нынешних метрик циничная команда могла бы раздуть, не работая лучше, и чем вы их замените?
Если бы вы могли укоротить ровно одну петлю обратной связи по всей организации, какая вернула бы больше всего мощности?
Как справедливо оценивать многие команды, когда их контексты различаются, не создавая таблицу лидеров, наказывающую честность?
Где проходит черта между измерением системы и слежением за человеком и кто в вашей организации уполномочен её обеспечивать?
В условиях без рыночной цены результата, например в государстве или на внутренней платформе, как измерять реальную ценность, а не активность?
Что вы показали бы разработчику, чтобы доказать, что опрос этого квартала что-то изменил?

Главные выводы

Продуктивность инженеров многомерна. Отвергайте любое единственное число (строки кода, velocity, коммиты, часы) как ту самую меру, потому что закон Гудхарта гарантирует его накрутку.
Используйте модель SPACE (удовлетворённость и благополучие, результативность, активность, коммуникация и сотрудничество, эффективность и поток), чтобы держать несколько измерений вместе и ни одно нельзя было накрутить в одиночку.
Опыт разработчика сводится к петлям обратной связи, когнитивной нагрузке и потоку. Укорачивание петель и снятие нагрузки это реальная продуктивность, которую не показывают подсчёты активности.
Триангулируйте данные восприятия из опроса DevEx с системными данными ваших инструментов; каждый исправляет другой.
Рассматривайте метрики DORA как сигнал поставки на уровне команды, а не таблицу лидеров; их глубина в главе 11.5, а конвейер в главе 11.2.
Измеряйте систему, никогда не человека. Агрегируйте до команд, оставляйте оценку в отдельных человеческих каналах главы 1.3 и никогда не позволяйте измерению становиться слежением.
Тратьте возвращённое время на сокращение рутины (глава 9.1), ускорение ревью кода (глава 2.5) и мощение дорог (глава 8.4). Связывайте эффективность с бизнес-результатами, не позволяя ни одной метрике стать искажающей целью.

Источники и дополнительное чтение

Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity” (ACM Queue, 2021): the multidimensional framework.
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, “DevEx: What Actually Drives Productivity” (ACM Queue, 2023): feedback loops, cognitive load, and flow.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (the DORA metrics and their research basis).
DORA, Accelerate State of DevOps Report (annual): the ongoing research programme behind the four metrics.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (toil and its elimination).
Matthew Skelton and Manuel Pais, Team Topologies (cognitive load as a first-class design concern).
Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (the origin of flow state).
Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams (focus, interruption, and the human side of productivity).
Goodhart, C. A. E., “Problems of Monetary Management: The UK Experience” (1975): the origin of Goodhart’s law; see also Marilyn Strathern’s widely quoted formulation.
U.S. Government Accountability Office (GAO) guidance on performance measurement: measuring value in non-market public-sector settings.