Метрики экономики здравоохранения

Тема 66 из 91· Разработка ПО и цифровая доставка

SPACE и DevEx (SPACE and DevEx)

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

Почему это важно

Обе рамки кодируют тот же урок, с трудом усвоенный исследованиями исходов здоровья десятилетиями раньше: единая цифра (строки кода; артериальное давление) искажает многомерную реальность, а её оптимизация порождает манипуляции, а не улучшение. SPACE предписывает комбинировать метрики как минимум из трёх измерений, смешивая телеметрию с самоотчётом — структурно идентично тому, как EQ-5D профилирует пять измерений прежде вычисления какого-либо индекса, и почему PROMs существуют наряду с клиническими измерениями. Удовлетворённость/благополучие — тоже не мягкое украшение: оно питает экономику удержания персонала, где отток оценивается в месяцах полной зарплаты.

Математика

Ни одна из рамок не является формулой; обе — это схемы измерения:

Правило SPACE: ≥ 3 измерения, ≥ 1 перцептивная (опрос) + ≥ 1 системная (телеметрия) метрика

Измерения DevEx и примеры пар:
  петли обратной связи → длительность CI (телеметрия) + «ожидание кажется медленным» (опрос)
  когнитивная нагрузка  → находимость документации, время онбординга + воспринимаемое усилие
  состояние потока      → плотность встреч/прерываний + самоотчёт о фокусе

Производные индексы (напр., DXI от DX) отображают композиты опросов на время:
заявление вендора ≈ 13 мин/разработчик/неделю на балл индекса — рассматривайте как
бенчмарк вендора для локальной валидации, а не как константу природы.

Практический пример

Команда платформы обосновывает инвестицию в DevEx (ускорение CI + переработка документации) для 300 разработчиков:

Базовый уровень: CI p75 = 28 мин; опрос «Я теряю фокус, ожидая сборки»: 62% согласны
После:           CI p75 = 9 мин;  согласие 24%

Возвращённое время (телеметрия): 6 сборок/день × 19 мин × 0.4 полезных = ~45 мин/день/разработчик
Ценность мощности: 300 × 0.75ч × 220д × £60/ч ≈ £2.97M/год (не высвобождающая денежные средства —
см. cash-releasing-vs-non-cash-releasing.md; коэффициент полезности 0.4 — это скидка на
фрагментацию из practitioner-time.md)
Перцептивное подтверждение — вот что делает заявление по телеметрии убедительным — каждое
по отдельности подвержено манипуляции; вместе они образуют триангуляцию.

Связь с разработкой программного обеспечения

Этот документ и есть программная сторона; перенос идёт в сторону экономики здравоохранения. «Инженеро-год с поправкой на качество» — время, взвешенное стандартизированным индексом опыта — это конструкция QALY, применённая к инженерной мощности, и она наследует правила QALY: веса из валидированного инструмента (согласованный опрос, опубликованная система подсчёта), извлечённые до сравнения, никогда не подгоняемые ради лести избранному инструменту. Урок SF-6D против EQ-5D тоже применим: разные инструменты дают систематически разные цифры, поэтому никогда не сравнивайте индексы DevEx между инструментами разных вендоров.

Подводные камни

  • Схлопывание в единую метрику: дашборды, сводящие SPACE к одному баллу, воссоздают проблему, для предотвращения которой существует рамка.
  • Метрики активности как исходы: коммиты, PR и story points — это Активность — измерение, которое SPACE явно предупреждает как наиболее подверженное манипуляциям (аналог в здравоохранении: подсчёт процедур, а не выздоровлений).
  • Усталость от опросов и эффекты Хоторна: лёгкие квартальные инструменты лучше еженедельного допроса.
  • Сравнение команд: как больничные турнирные таблицы без корректировки на микс случаев — различия контекста (домен, груз legacy-кода, дежурства) доминируют.

Источники