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 растёт, а удовлетворённость работой резко падает — возможно, команда просто обменивает будущую производительность на красивые цифры сегодня.
Хорошая система метрик должна показывать не только, насколько быстрее стала команда.
Она должна помогать вовремя заметить, какой ценой появилось это ускорение.
· 01.10
Я бы рядом со скоростью смотрел долю незапланированной работы: инциденты, срочные правки, помощь соседним командам. Иначе ускорение легко оплатить вечерами техлида, а на графике всё будет зелёным. У вас такая работа попадает в общий учёт или остаётся за кадром?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён