В середине 2026 года была опубликована
статья в журнале ACM Queue в которой представлен фреймворк измерения продуктивности Engineering Thrive (EngThrive). Фреймворк применяется на практике в Microsoft, охватывает десятки тысяч разработчиков и подготовлен экспертами из Microsoft Research: Brian Houck, Tim Bozarth, David Liu и Dean Carignan. В опубликованной статье представлены описание и принципы проектирования фреймворка, измерения и метрики, платформа для измерения и аналитики, а также несколько кейсов, демонстрирующих применение на практике.
Фреймворк EngThrive организует продуктивность в трех измерениях (
Speed,
Ease,
Quality) и связывает измерения с
Thriving в качестве защитного механизма (Guardrail) обеспечивающего улучшение опыта разработчиков (Developer Experience) наряду с продуктивностью (Productivity). Фреймворк EngThrive объединяет метрики ориентированные на результат (North Star metrics) с диагностическими субметриками, сочетая инженерную телеметрию с опросами разработчиков для обеспечения контекста и масштаба. Фреймворк EngThrive фокусируется на создании практического способа измерения продуктивности, выявления узких мест, обеспечения непрерывного улучшения и повышения эффективности.
Выводы, представленные в опубликованной статье, основаны на внутренней телеметрии и опросах, проведенных среди инженерного персонала Microsoft на протяжении нескольких лет. Это включает данные репозиториев и сборок, метрики взаимодействия, данные об инцидентах и масштабные опросы об опыте разработчиков. Цель авторов — предоставить проверенный, масштабируемый подход к измерению и улучшению продуктивности разработчиков. Опираясь на скорость, простоту и качество, авторы показывают, как перейти от фреймворка к инженерной операционной системе, предлагая конкретную, применимую точку отсчета для организаций, стремящихся развивать собственные фреймворки и подходы.
ВведениеФундамент фреймворка EngThrive опирается на несколько направлений исследований последних лет, каждое из которых указывает на то, что продуктивность разработчиков многомерна:
- Фреймворк SPACE предложил пять измерений: удовлетворенность (Satisfaction), результативность (Performance), активность (Activity), коммуникация (Communication) и эффективность (Efficiency), и обосновал, что ни одна единственная метрика не способна отразить полную картину. Подход к измерению в SPACE должен охватывать не менее трех измерений, включать по меньшей мере один перцептивный показатель (Perceptual measure) и исходить из того, что правильно подобранные метрики будут естественным образом создавать напряжение (Tension) между собой;
- Работа DevEx in action, количественно определила статистические связи между такими факторами, как состояние потока (Flow state), обратная связь (Feedback loops) и когнитивная нагрузка (Cognitive load), и результатами на индивидуальном, командном и организационном уровнях. Работа доказала, что улучшение Developer Experience ведет к росту индивидуальной продуктивности и креативности, повышению качества кода команды и снижению технического долга, а также к росту удержания персонала и прибыльности организации;
- Исследование The SPACE of AI подтвердило, что даже новые инструменты порождают эффекты, охватывающие множество измерений и не поддающиеся простому обобщению.
- Эксперты DORA (DevOps Research and Assessment) внесли вклад в виде одного из наиболее распространенного фреймворка DORA/Accelerate, который включал четыре метрики: частота развертывания, срок поставки, неуспешные изменения и среднее время восстановления. Эти метрики дали множеству организаций первую эмпирическую опору для понимания того, насколько хорошо работают их инженерные системы.
Фреймворк EngThrive представляет собой попытку ответить на следующие вопросы: Что делать дальше? Что делать на практике?
Принципы фреймворка EngThriveВ фреймворке EngThrive для каждого измерения выделены основные North Star метрики. Это показатели ориентированные на результат и поддерживаются субметриками, обеспечивающими диагностическую детализацию и практические рычаги воздействия:
- Метрики North Star отвечают на вопрос "Улучшаемся ли мы?";
- Субметрики позволяют углубиться в конкретные активности и компоненты, чтобы понять "Почему да или почему нет?".
На практике North Star метрики часто требуют зрелой, кросссистемной телеметрии, которой большинство организаций не располагает с самого начала. Субметрики это метрики, с которых следует начинать, однако они никогда не должны служить ориентиром для принятия решений. Организациям следует определять свои North Star заранее, еще до того, как появится возможность их измерять, и выстраивать движение к ним итеративно.
Четыре принципа проектирования фреймворка EngThrive:
- Измерения в сравнении с метриками (Measures versus metrics). Авторы намеренно различают измерения и метрики. Измерение описывает реальность: это точка данных, наблюдение, факт о мире. Метрика определяет, что имеет значение: это измерение, которое было отобрано, помещено в контекст и снабжено целевым значением, поскольку организация установила, что оно отражает нечто, ради чего стоит проводить оптимизацию. Не каждое измерение должно становиться метрикой. Акт превращения измерения в метрику представляет собой заявление о ценностях и должен рассматриваться вдумчиво;
- Не навреди (Do no harm). Скорость, простота и качество определены как триада: каждая метрика существует в контексте двух других и спроектирована таким образом, чтобы взаимно усиливать их. Метрика считается улучшенной только в том случае, если она сохраняет или усиливает две другие, обеспечивая, чтобы прирост носил аддитивный характер, а не представлял собой сокрытие издержек или перераспределение. Этот принцип служит опорой для всей системы: продуктивность растет тогда, когда триада движется совместно, а не тогда, когда одно измерение улучшается за счет целого;
- Согласование манипулирования (Gaming alignment). Распространенное возражение против метрик продуктивности заключается в том, что ими можно манипулировать. Авторы рассматривают это как просто ограничение проектирования, которое следует принять. Хорошо спроектированные метрики согласуют манипулятивное поведение (Gaming behavior) со значимыми результатами. В качестве примера можно рассмотреть метрику Time-to-first-PR для новых сотрудников. Когда одна из организаций намеренно "манипулировала" этой метрикой, назначая новичкам тривиальные PR в первый день работы, само манипулирование породило устойчивые положительные результаты — не вопреки тому, что метрикой манипулировали, а именно потому, что акт манипулирования вынудил к правильному поведению. Цель заключается в выборе таких метрик, при которых манипулирование само по себе представляет собой улучшение, а не простое изменение активности;
- Смешанные методы (Mixed methods). Каждый уровень измерения EngThrive сочетает объективную телеметрию (системные логи, данные репозиториев, активности в календаре) с субъективными данными опросов (ответы разработчиков об удовлетворенности, барьерах и субъективном восприятии опыта). Ни один из этих источников сам по себе не является достаточным. Телеметрия способна показать, что фокусированное время (Focus time) разработчика снизилось, однако не способна объяснить причину. Опросы способны выявить, что разработчики испытывают разочарование из-за процессов развертывания, однако не способны количественно определить масштаб проблемы среди десятков тысяч инженеров. Сочетание этих методов дает больше, чем простое сложение. Это разница между наблюдением симптома и пониманием состояния.
Структура фреймворка EngThriveФреймворк EngThrive организует продуктивность в трех измерениях (Speed, Ease, Quality) и связывает измерения с Thriving в качестве защитного механизма. Разберем подробнее измерения фреймворка:
Скорость (Speed). Скорость отражает темп, с которым разработчики и команды преобразуют замысел в поставленную работу, измеряемый преимущественно в единицах истекшего календарного времени.
Основная метрика:
- Idea-to-customer (I2C, от идеи до заказчика). I2C измеряет истекшее время от первых артефактор планирования до момента, когда работа оказывается в руках заказчиков. Это North Star для скорости, поскольку метрика охватывает весь пайплайн целиком, а не отдельную его стадию. Команда может демонстрировать высокую скорость PR (PR velocity) и при этом оставаться медленной, если требования сформулированы нечетко, ревью образуют узкое место или развертывания заблокированы процессами ручного согласования. Метрика отвечает на вопрос, действительно важный для руководителей: сколько времени требуется, чтобы превратить замысел в результат?
Ключевые субметрики:
- Time to Nth PR (время до N-го PR). Измеряет, насколько быстро новые инженеры начинают вносить вклад в кодовую базу своей команды и достигают определенных контрольных отметок по коммитам (check-in milestones). Целевые значения намеренно агрессивны: первый PR в течение семи дней, десятый PR в течение следующих нескольких недель. К моменту десятого PR нового сотрудника вероятность предсказать паттерны его результативности написания кода на следующие два года превышает 50%. Эта субметрика является опережающим индикатором (leading indicator) долгосрочной инженерной траектории;
- PR completion time (время завершения PR). Измеряет истекшее время от создания PR до слияния (Merge). Это опыт разработчика в цикле ревью, то есть в цикле обратной связи, определяющем, насколько быстро работа переходит из состояния "готово на моей машине" в состояние "слито и поставляет ценность". Анализ жизненного цикла PR на масштабе Microsoft подтвердил тесную взаимосвязь: сокращение времени завершения не просто ощущается лучше, оно обеспечивает измеримо более высокую пропускную способность во всей системе. PR completion time представляет собой одну из наиболее непосредственно применимых на практике субметрик в составе I2C, поскольку она выявляет узкие места, которые команды способны устранять на своем уровне.
Простота (Easy). Простота отражает степень, в которой разработчики способны выполнять свою работу без излишнего трения (Friction), прерываний (Interruption) или рутинных издержек (Toil). Если скорость измеряет темп продвижения вперед, простота измеряет то, что этому препятствует, и эти метрики преимущественно опираются на единицы времени разработчика.
Основная метрика:
- Innovation time ratio (Коэффициент времени на инновации). Innovation time представляет собой измерение количества часов в среднем периоде (например, неделе), затрачиваемых на создание ценности, а не на поддержание текущей деятельности (run-the-business) или административные задачи (business-overhead). Инновационная работа (innovation work) включает активности, создающие новую ценность: создание продуктовых функций, улучшение пользовательского опыта, инвестиции в автоматизацию, устраняющую целые классы рутинных издержек, а также совершенствование пайплайнов тестирования и релиза для повышения качества. Работа по поддержанию текущей деятельности (run-the-business work) обеспечивает функционирование системы: миграции, дежурства (on-call operations), реагирование на инциденты, диагностику и исправление багов, а также поддержку существующих сервисов. Административная нагрузка (business overhead) охватывает координационную и административную нагрузку: регулярные статусные совещания, отчетность, задачи по соответствию требованиям (compliance) и безопасности, процессные издержки и прочую работу, необходимую для функционирования организации, но не связанную напрямую с созданием или поддержанием продуктовой ценности. В Microsoft оценивают innovation time, начиная с фокусированного времени (focus time) и используя телеметрию для выявления активностей разработки, снижающих innovation time (например, работа над инцидентами, сбои сборки (build failures), нагрузка совещаниями, задачи compliance), после чего вычитаем их из общего фокусированного времени. Это дает направленное, системное измерение защищенного времени для создания ценности. Дополняя телеметрию простыми опросами (например: "Какой % вашей недели затрачивается на инновации, поддержание текущей деятельности и административную нагрузку?"). Даже при небольших размерах выборки эти опросы обладают высокой практической применимостью и помогают валидировать и калибровать оценки на основе телеметрии на уровне команды.
Ключевые субметрики:
- Perceived ease of delivery (Субъективно воспринимаемая простота поставки). Отражает через опрос, насколько сложным разработчики находят выполнение своей работы в рамках текущей системы. Это субъективное дополнение к innovation time ratio. Телеметрия способна показать, что разработчик потерял часы на совещания или сбои сборки, однако только сам разработчик способен сообщить, ощущались ли оставшиеся часы продуктивными или же были потрачены на навигацию по неясным требованиям, ожидание согласований или переключение контекста между несвязанными задачами. Когда perceived ease расходится с innovation time ratio, это выявляет системные проблемы, которые невозможно обнаружить одной лишь телеметрией.
- Anti-innovation time factors (Факторы, снижающие время на инновации). Эти факторы раскладывают телеметрическую сторону уравнения на составляющие. В Microsoft отслеживается нагрузка совещаниями, часы реагирования на инциденты и время, затрачиваемое на обязательства compliance и безопасности, как самостоятельные категории эрозии времени. Каждая из них измерима и применима на практике независимо от прочих. Именно эта декомпозиция делает innovation time ratio диагностической метрикой, а не просто описательной.
Качество (Quality). Качество отражает, приводит ли выполняемая работа к устойчивым, надежным результатам. Скорость без качества — это лишь суета без результата (churn); команда, поставляющая быстро, но при этом постоянно что-либо ломающая, не является продуктивной, она порождает переделки (rework). Само качество многогранно: оно охватывает дефекты, доходящие до production, скорость восстановления при возникновении проблем и, в конечном счете, удовлетворенность заказчика поставленным результатом. Здесь метрики сосредоточены на измерениях, наиболее непосредственно связанных с опытом разработчиков и устойчивой инженерной практикой, а не на попытке охватить каждый аспект качества единым показателем. В этом измерении используется две взаимодополняющие North Star метрики. Одна отражает частоту нарушений, связанных с качеством (PR на инцидент), другая отражает стоимость этих нарушений (время устранения инцидента).
Основные метрики:
- PRs per incident (PR на инцидент). PRs per incident отражает соотношение между продвижением вперед (завершенные PR) и операционными нарушениями (зарегистрированные инциденты). По сути, это трактовка change failure rate (доли неудачных изменений): вместо измерения процента развертываний, приводящих к сбоям, измеряется, сколько работы, ориентированной на продвижение вперед, команда завершает по отношению к порождаемым ею нарушениям. Чем выше значение, тем лучше. Команда, завершающая 20 PR на каждый инцидент, находится в принципиально иной позиции по сравнению с командой, завершающей 3 PR. PRs per incident выступает North Star для качества, поскольку отражает баланс, имеющий наибольшее значение: строим ли мы быстрее, не увеличивая при этом количество поломок? Эта метрика намеренно двусторонняя. Низкое значение соотношения может указывать либо на слишком большое количество инцидентов (проблема качества), либо на слишком малое количество PR (проблема скорости). Диагностическая ценность заключена именно в соотношении, а не в числителе или знаменателе по отдельности. Это делает метрику естественным дополнением к I2C на стороне скорости; вместе они отвечают на вопрос о том, поставляет ли команда инновации устойчивым образом.
- Incident mitigation time (Время устранения инцидента). Incident mitigation time измеряет истекшее время от обнаружения инцидента до его устранения для проблем на действующем сервисе (live-site issues). По сути, это наша версия стандартной отраслевой метрики mean time to mitigate (MTTM, среднее время устранения). Важно отметить, что эта метрика формулируется как измерение нарушения опыта разработчика, а не качества, ориентированного непосредственно на заказчика. Когда возникает инцидент на действующем сервисе, он отвлекает разработчиков от запланированной работы, разрушает фокусированное время (focus time) и порождает неудовлетворенность. Более быстрое устранение означает меньшее нарушение работы инженерной системы в целом. Incident mitigation time сообщает не только о том, высоко ли качество, но и о том, во сколько команде обходится снижение качества.
Thriving. Thriving не является четвертым измерением наряду со скоростью, простотой и качеством. Это защитный механизм (Guardrail), то есть проверка, обеспечивающая, чтобы оптимизация не осуществлялась за счет инженеров, выполняющих работу. Метрики этой области измеряются в единицах удовлетворенности разработчиков (Developer happiness).
Основные метрики:
- Net Satisfaction (NSAT). Измеряет настроение (Sentiment) с помощью двух взаимодополняющих инструментов. Первый — NSAT, производный от нашего опроса об инженерном опыте (Engineering Experience Survey), который отражает удовлетворенность разработчиков инженерной системой: их инструментами, процессами и рабочими процессами. Второй — более широкий показатель Thriving score, полученный из программы измерения настроений сотрудников Microsoft, который измеряет, ощущают ли сотрудники наличие возможностей для выполнения своей работы наилучшим образом, испытывают ли энергию от того, чем занимаются, и воспринимают ли свою работу как значимую. Обоснование важности этого guardrail однозначно. Разработчики, неудовлетворенные своей работой, в 25 раз чаще сообщают о непродуктивности и в два раза чаще увольняются в течение года. Это не "мягкий" вопрос. Это прямой предиктор потенциала и устойчивости инженерной организации. Авторы подходят к Thriving прагматично: если вмешательство улучшает метрики скорости, простоты и качества, однако thriving снижается, значит, во вмешательстве что-то не так. Guardrail фиксирует это и позволяет исследовать, в чем наше понимание узких мест и реального опыта разработчиков неполно или ошибочно.
- Bad developer days (BDD, плохие дни разработчика). Если NSAT отражает то, как разработчики ощущают свой опыт, BDD отражает то, что реально с ними произошло. BDD представляет собой композитную метрику, развивающую идеи, впервые предложенные в Google, которая количественно определяет ежедневные рутинные издержки (toil) разработчиков. Хотя концепция BDD универсально применима, конкретные субметрики, входящие в состав BDD, специфичны для каждого отдельного бизнеса. Плохим днем считается день, в который разработчик сталкивается с превышающим пороговое значение объемом трения (friction) от любой комбинации выявленных субметрик: чрезмерное переключение контекста, рутинные издержки реагирования на инциденты и работы на действующем сервисе (live-site toil), сбои сборки (build failures) или ее медленная работа, недостаточное фокусированное время (focus time) либо обязательства compliance и безопасности. BDD выступает North Star для thriving, поскольку сводит множество форм разочарования разработчиков в единое сопоставимое число, которое может собираться в реальном времени. При расчете BDD в масштабе всей организации результат оказался отрезвляющим: 52% всех дней разработчиков были квалифицированы как плохие. Разработчики, испытывающие три или более плохих дня в неделю, в три раза чаще увольнялись с работы и создавали на 20% меньше кода по сравнению с коллегами, имевшими меньше плохих дней. BDD, по сути, представляет собой налог на рутинные издержки (toil tax), и toil представляет собой налог на инновации. Каждый час, который разработчик тратит на борьбу с нестабильными сборками (flaky builds) или на восстановление после ненужных переключений контекста, — это час, не потраченный на творческую, высокоценную работу, в которой организации действительно нуждаются. Чтобы BDD оставалась применимой на практике и информативной, она должна соответствовать следующим критериям: количество метрик, включенных в композитный показатель, должно быть небольшим (эксперименты показали, что более шести метрик порождает путаницу), и каждая метрика должна быть измерима независимо от других в рамках того же временного интервала (то есть ежедневно). Эти условия необходимы для того, чтобы композитная метрика не становилась чрезмерно абстрактной. Формулировка thriving через BDD намеренно прагматична: здесь не задается вопрос о том, испытывают ли разработчики восторг, а способны ли разработчики выполнять свою работу без противодействия со стороны системы. Это различие имеет значение: восторг представляет собой результат устранения трения, а не самостоятельную цель.
Система измерения (The Measurement System)Если скорость, простота и качество описывают то, что измеряет EngThrive, три взаимно усиливающих компонента описывают то, как реально происходят изменения:
- Культура (Culture) охватывает организационные нормы, поведение руководителей и разделяемые ожидания, определяющие, действительно ли данные измерения приводят к изменениям: действуют ли руководители на основании того, что раскрывают данные, ощущают ли команды себя в безопасности при выявлении проблем и вознаграждается ли улучшение.
- Инсайты (Insights) охватывают сами данные: опросы, телеметрию, аналитику и исследования, порождающие понимание.
- Инфраструктура (Infrastructure) охватывает инструментарий, дашборды и системы, делающие инсайты доступными и применимыми на практике в масштабе.
Ни один из этих компонентов не работает в одиночку. Инсайты без культуры порождают неиспользуемое ПО (Shelfware): красивые дашборды, на основании которых никто не принимает решения. Культура без инсайтов порождает интуицию: руководители принимают решения вслепую. Инфраструктура без культуры и инсайтов порождает возможности без цели. Система измерения работает тогда, когда все три компонента функционируют совместно, поэтому в Microsoft построили полноценную систему измерения, спроектированную так, чтобы сделать многомерные данные доступными, применимыми на практике и безопасными.
Платформа данных. Прежде чем дашборды, опросы или аналитика могли принести пользу, нам требовался фундамент: единая платформа данных, объединяющая телеметрию разработчиков из десятков разрозненных систем в единый согласованный нормализованный слой. Данные системы контроля версий из GitHub, телеметрия сборок из внутренних систем непрерывной интеграции и непрерывной поставки (CI/CD), данные календарей из Outlook и Viva, данные управления инцидентами, отслеживание compliance и многое другое объединяются и согласуются в рамках единой модели данных. Эта платформа служит фундаментом для всего, что следует далее. Метрики вычисляются согласованно во всех командах, ответы опросов могут быть обогащены телеметрией для более глубокого анализа, а исследователи получают возможность изучать кросс-системные взаимосвязи (например, связь между нагрузкой совещаниями и скоростью PR), обнаружение которых было бы невозможно в рамках любого отдельного изолированного хранилища данных.
Опросы. Опрос об инженерном опыте (Engineering Experience Survey) проводится среди всех инженеров Microsoft. Он структурирован вокруг измерений скорости, простоты и качества, при этом каждый раздел содержит как пункты по шкале Ликерта (Likert scale), так и вопросы для выявления барьеров. Разработчики указывают, какие конкретные барьеры оказывают наибольшее влияние на их опыт (трение при развертывании, надежность сборки, нагрузка совещаниями, неясные требования), и эти ответы о барьерах напрямую связываются с показателями удовлетворенности для выявления областей, в которых вмешательства принесут наибольший эффект.
Опрос также фиксирует распределение времени, разработчики оценивают:
- какая доля их недели затрачивается на инновации (новые функции, улучшения);
- поддержание текущей деятельности (обслуживание, операционная работа);
- административную нагрузку (совещания, compliance, административные задачи).
Эта декомпозиция обладает высокой аналитической ценностью, поскольку выявляет структурные проблемы. Организация, в которой разработчики тратят 30% своего времени на административную нагрузку, сталкивается с принципиально иным вызовом по сравнению с организацией, где 30% времени тратится на операционные рутинные издержки (toil), даже если обе организации сообщают об одинаковом общем уровне удовлетворенности.
Дашборды и персоны. Данные фреймворка EngThrive визуализируются через систему дашбордов, спроектированную для разных персон:
- Организационные дашборды (Org dashboards) обслуживают руководителей групп численностью 50 и более индивидуальных участников (individual contributors) из числа инженеров-программистов; они делают акцент на трендах, кросс-командных сравнениях и стратегическом распределении ресурсов.
- Командные дашборды (team dashboards) обслуживают менеджеров и технических лидов групп численностью пять и более участников; они делают акцент на выявлении барьеров и локальных возможностях для улучшения.
В этой иерархии намеренно отсутствует дашборд индивидуального уровня. Метрики EngThrive не являются показателями индивидуальной результативности и никогда не используются для оценки, ранжирования или сравнения отдельных инженеров. Система измеряет среду, в которой работают разработчики, а не самих разработчиков. Менеджеры и руководители несут ответственность за создаваемую ими среду, и дашборды спроектированы так, чтобы отражать эту ответственность.
Организационные дашборды агрегируются по крупным популяциям, а командный дашборд ограничен данными самой команды. Пороги агрегации (Aggregation thresholds) предотвращают идентификацию отдельных лиц в небольших группах.
Рекомендации по использованию фреймворка EngThriveДля организаций, стремящихся внедрить многомерный подход к измерению, авторы приводят практическое руководство:
- Начинайте даже при неидеальных данных. Располагаете ли вы точными, основанными на телеметрии данными по каждому рабочему элементу, коммиту, ревью кода, сборке или развертыванию? Если да, вы находитесь в необычно выгодном положении для того, чтобы приступить к внедрению EngThrive. Однако даже при полном отсутствии этих сигналов возможно быстро войти в эту область с помощью целевых опросов EngThrive и базовой телеметрии. Хотя опросы не дают телеметрии в реальном времени, они позволяют быстро понять основные узкие места вашей системы и сформировать точный набор измерений;
- Выбирайте одну-две метрики на измерение. Для каждого измерения отбирайте небольшое количество метрик, обеспечивающих баланс субъективных и объективных сигналов. Метрика скорости на основе телеметрии в сочетании с вопросом об удовлетворенности из опроса дает больше информации, чем пять метрик телеметрии по отдельности. Дисциплина в отношении метрик имеет значение: избыточное количество метрик размывает фокус и затрудняет выявление того, что реально меняется;
- Сосредоточьтесь на непрерывном улучшении. Каждая метрика обладает числовым значением, однако культура EngThrive сфокусирована на непрерывном улучшении. Первый шаг заключается в понимании имеющихся данных, формировании вмешательств, направленных на изменения, и измерении этих изменений с течением времени;
- Ожидайте манипулирования и проектируйте с его учетом. Выбирайте метрики, ориентированные на результат. Если вашу метрику возможно улучшить только путем правильных действий, манипулирование ею неотличимо от подлинного улучшения. Если ее возможно улучшить лишь путем неверных действий, выберите другую метрику;
- Итерируйте. Метрики представляют собой живые системы. То, что имеет значение для вашей организации сегодня, может не иметь значения через год. Периодически пересматривайте свои метрики — не для того, чтобы гнаться за трендами, а для того, чтобы удостовериться, что они по-прежнему отражают ваши реальные приоритеты и вызовы. Если метрика перестала быть информативной, откажитесь от нее. Если возникает новый вызов, не охватываемый текущими метриками, добавьте новую метрику вдумчиво.
ЗаключениеПродуктивность разработчиков многомерна, связана с человеческим фактором и сопротивляется простым измерениям. Исследовательское сообщество достигло значительного прогресса в обосновании этого тезиса благодаря DORA, SPACE и DevEx. Фреймворк EngThrive представляет собой следующий шаг: от принципов к практике, от фреймворка к операционной системе. Организуя измерения вокруг скорости, простоты и качества, фреймворк EngThrive предоставляет конкретную структуру для внедрения, гибкую для адаптации и устойчивую, чтобы пережить любой отдельный технологический цикл.
Визуализация фреймворка EngThrive: