EngThrive: какой ценой команда стала быстрее
В мае 2026 года Microsoft Research опубликовала EngThrive: Make It Fast and Easy to Do Great Work — систему измерения и улучшения инженерной эффективности, которую уже используют внутри Microsoft.
Проблема знакомая.
У нас есть SPACE, DORA и DevEx. Но у руководителя всё равно остаётся практический вопрос:
Что именно смотреть каждую неделю, чтобы понимать состояние разработки?
EngThrive предлагает три основных измерения:
Speed — насколько быстро работа проходит через систему.
Ease — насколько легко разработчику эту работу выполнять.
Quality — насколько качественным получается результат.
А поверх них — Thriving: благополучие разработчиков как защитное ограничение для всей системы.
И это, на мой взгляд, самая интересная часть подхода.
Throughput действительно можно увеличить довольно простым способом: добавить давления.
На некоторое время.
Поэтому Thriving здесь не отдельная HR-метрика про настроение сотрудников. Это guardrail, который помогает отличить устойчивое улучшение от эффективности, взятой в долг у следующего квартала.
Что из этого забрать тимлиду
Нельзя оценивать эффективность разработки по одной метрике.
Lead Time снизился, но количество инцидентов выросло — это не улучшение.
Throughput увеличился, но разработчики стали тратить больше времени на ручную рутину — результат тоже сомнительный.
Velocity растёт, а удовлетворённость работой резко падает — возможно, команда просто обменивает будущую производительность на красивые цифры сегодня.
Хорошая система метрик должна показывать не только, насколько быстрее стала команда.
Она должна помогать вовремя заметить, какой ценой появилось это ускорение.
В мае 2026 года Microsoft Research опубликовала EngThrive: Make It Fast and Easy to Do Great Work — систему измерения и улучшения инженерной эффективности, которую уже используют внутри Microsoft.
Проблема знакомая.
У нас есть SPACE, DORA и DevEx. Но у руководителя всё равно остаётся практический вопрос:
Что именно смотреть каждую неделю, чтобы понимать состояние разработки?
EngThrive предлагает три основных измерения:
Speed — насколько быстро работа проходит через систему.
Ease — насколько легко разработчику эту работу выполнять.
Quality — насколько качественным получается результат.
А поверх них — Thriving: благополучие разработчиков как защитное ограничение для всей системы.
И это, на мой взгляд, самая интересная часть подхода.
Throughput действительно можно увеличить довольно простым способом: добавить давления.
На некоторое время.
Поэтому Thriving здесь не отдельная HR-метрика про настроение сотрудников. Это guardrail, который помогает отличить устойчивое улучшение от эффективности, взятой в долг у следующего квартала.
Что из этого забрать тимлиду
Нельзя оценивать эффективность разработки по одной метрике.
Lead Time снизился, но количество инцидентов выросло — это не улучшение.
Throughput увеличился, но разработчики стали тратить больше времени на ручную рутину — результат тоже сомнительный.
Velocity растёт, а удовлетворённость работой резко падает — возможно, команда просто обменивает будущую производительность на красивые цифры сегодня.
Хорошая система метрик должна показывать не только, насколько быстрее стала команда.
Она должна помогать вовремя заметить, какой ценой появилось это ускорение.