DORA vs SPACE vs DevEx: какой фреймворк выбрать в 2026 году?
Stack Overflow Developer Survey (2023) показал, что удовлетворённость разработчиков напрямую предсказывает удержание и качество результата. Одновременно DORA-метрики предсказывают эффективность организации. Тем не менее многие инженерные лидеры рассматривают эти подходы как конкурирующие, а не как взаимодополняющие линзы. В 2026 году проблема не в нехватке фреймворков — а в выборе правильной комбинации. DORA, SPACE и DevEx — каждый заявляет, что измеряет «продуктивность разработчиков». Ни один из них не измеряет одно и то же.
Вот как разобраться в этом шуме.
Три фреймворка: обзор
Прежде чем сравнивать, определим, что каждый фреймворк из себя представляет и откуда появился.
DORA-метрики
Происхождение: Команда DevOps Research and Assessment (DORA), изначально независимая, приобретена Google в 2018. Основана на 10+ годах исследований десятков тысяч организаций.
Опубликовано в: Accelerate: The Science of Lean Software and DevOps (2018), авторы — Nicole Forsgren, Jez Humble, Gene Kim. Обновляется ежегодно в State of DevOps Report.
Что измеряет: Эффективность доставки ПО — как быстро и надёжно инженерная команда поставляет изменения в продакшен.
Четыре метрики:
| Метрика | Измеряет | Направление |
|---|---|---|
| Deployment Frequency | Как часто деплоите в продакшен | Чем больше, тем лучше |
| Lead Time for Changes | Время от коммита до продакшена | Чем меньше, тем лучше |
| Change Failure Rate | % деплоев, вызывающих сбои | Чем меньше, тем лучше |
| Mean Time to Restore (MTTR) | Время восстановления после сбоя | Чем меньше, тем лучше |
Сильные стороны: Объективные, измеряемые из системных данных (опросы не нужны), хорошо исследованные, отраслевые бенчмарки.
Ограничения: Измеряет только пайплайн доставки. Не отражает опыт разработчика, качество коллаборации и то, создаёт ли команда правильные вещи.
SPACE-фреймворк
Происхождение: Nicole Forsgren (опять), Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler. Опубликован в 2021.
Опубликовано в: ACM Queue (март 2021), "The SPACE of Developer Productivity."
Что измеряет: Продуктивность разработчиков по пяти измерениям. SPACE — акроним:
| Измерение | Что охватывает | Примеры метрик |
|---|---|---|
| Satisfaction and well-being | Как разработчики себя чувствуют | Опрос: удовлетворённость, риск выгорания |
| Performance | Результаты работы | Качество, надёжность, влияние на клиентов |
| Activity | Наблюдаемые действия | Коммиты, PR, деплои, код-ревью |
| Communication and collaboration | Как люди работают вместе | Скорость ревью, обмен знаниями, нагрузка митингами |
| Efficiency and flow | Скорость и прерывания | Частота flow state, время ожидания, задержки передачи |
Сильные стороны: Целостный взгляд, комбинирует количественные данные с опросами, явно предостерегает от использования метрик для индивидуальной оценки.
Ограничения: Требует опросов (постоянные затраты), многие метрики субъективны, сложнее бенчмаркить между организациями, нет стандартной реализации.
DevEx-фреймворк
Происхождение: Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler. Опубликован в 2023.
Опубликовано в: ACM Queue (апрель 2023), "DevEx: What Actually Drives Productivity."
Что измеряет: Реальный опыт разработчиков по трём измерениям:
| Измерение | Что охватывает | Примеры метрик |
|---|---|---|
| Feedback loops | Как быстро разработчики получают ответы | Скорость CI, скорость код-ревью, время деплоя |
| Cognitive load | Умственное усилие для выполнения работы | Сложность кодовой базы, качество документации, количество инструментов |
| Flow state | Способность сконцентрироваться и добиваться прогресса | Прерывания за день, блоки без митингов, переключения контекста |
Сильные стороны: Ориентирован на разработчика, подкреплён исследованиями, фокусируется на измерениях, на которые инженерные лидеры могут непосредственно влиять.
Ограничения: Преимущественно основан на опросах, более новый (меньше лонгитудинальных данных), нет устоявшихся отраслевых бенчмарков.
Ключевые различия
Что они измеряют
Эти фреймворки измеряют принципиально разные вещи:
| Фреймворк | Измеряет | Аналогия |
|---|---|---|
| DORA | Результат системы доставки | Спидометр и расход топлива |
| SPACE | Множество измерений продуктивности | Полная диагностическая панель автомобиля |
| DevEx | Опыт водителя | Опрос об удобстве и эргономике |
DORA отвечает: «Как быстро и надёжно наш пайплайн доставляет софт?»
SPACE отвечает: «Насколько продуктивна наша инженерная организация по множеству измерений?»
DevEx отвечает: «Как наши разработчики переживают ежедневную работу?»
Источники данных
| Фреймворк | Основной источник данных | Нужен ли опрос? | Уровень автоматизации |
|---|---|---|---|
| DORA | Системные данные (Git, CI/CD, отслеживание инцидентов) | Нет | Полная автоматизация |
| SPACE | Смешанный (системные данные + опросы) | Да | Частичная автоматизация |
| DevEx | Преимущественно опросы + некоторые системные данные | Да | В основном ручной |
Это различие важно операционно. DORA-метрики можно полностью рассчитать из системных данных — без опросов, без ручного ввода, без ежеквартальных упражнений по сбору данных. Подключили Git-провайдер и CI/CD-систему — и метрики готовы.
SPACE и DevEx требуют постоянных программ опросов. Опросы нужно проектировать, распространять, собирать и анализировать. Response rate имеет значение. Формулировки влияют на результаты. Усталость от опросов реальна. Это создаёт операционный оверхед, которого DORA избегает.
Исследовательская база
| Фреймворк | Лет исследований | Размер выборки | Прогнозная валидность |
|---|---|---|---|
| DORA | 10+ лет (2014–настоящее) | 36 000+ специалистов | Доказана: предсказывает эффективность организации |
| SPACE | 3+ года | Подкреплён исследованиями, но меньшая эмпирическая база | Теоретический фреймворк, валидированные измерения |
| DevEx | 2+ года | Подкреплён исследованиями, отраслевые опросы | Формирующаяся валидация |
DORA имеет самую сильную эмпирическую основу. Исследования, проведённые под руководством Nicole Forsgren и опубликованные через Google Cloud, продемонстрировали статистически значимую связь между DORA-метриками и бизнес-результатами (прибыльность, доля рынка, удовлетворённость клиентов). Примечательно, что SPACE-фреймворк был написан Forsgren как намеренное расширение охвата DORA, а не замена. DevEx, опубликованный в ACM Queue Noda, Storey, Forsgren и Greiler, концептуально обоснован и подкреплён исследованиями, но имеет меньше лонгитудинальной валидации.
Когда использовать каждый фреймворк
Используйте DORA, когда:
Нужно измерить и улучшить пайплайн доставки. DORA не имеет себе равных для ответа на вопрос «как быстро и надёжно мы поставляем софт?»
Нужны объективные, автоматизированные метрики. Без опросов, без мнений — только данные из ваших систем.
Нужны отраслевые бенчмарки. Бенчмарки Elite/High/Medium/Low позволяют сравниться с отраслью.
Отчитываетесь перед руководством или советом директоров. Четыре метрики DORA достаточно просты для нетехнических стейкхолдеров. «Мы деплоим 3 раза в день с 10% failure rate и 45-минутным временем восстановления» — это фраза, которую CFO может обработать.
Ваша команда любого размера. DORA масштабируется от стартапа из 5 человек до предприятия из 5 000.
Используйте SPACE, когда:
Подозреваете, что с метриками доставки всё в порядке, но что-то всё равно не так. Если DORA-показатели хорошие, но разработчики выгорают, текучка высокая и мораль низкая — SPACE улавливает то, что DORA пропускает.
Управляете крупной инженерной организацией. Широта SPACE полезна на уровне VP/CTO, когда нужно понять продуктивность десятков команд с разным контекстом.
Хотите измерить качество коллаборации. DORA не измеряет напрямую, насколько хорошо люди работают вместе. Измерение Communication в SPACE заполняет этот пробел.
Есть операционные ресурсы для постоянных опросов. SPACE требует инфраструктуры опросов и человека для управления программой.
Используйте DevEx, когда:
Удержание разработчиков — приоритет. DevEx напрямую измеряет факторы, которые определяют, останется разработчик или уйдёт: когнитивная нагрузка, flow state, циклы обратной связи.
Инвестируете в инструменты для разработчиков. Если тратите деньги на внутренние платформы, порталы для разработчиков или улучшение инструментария — DevEx-опросы измеряют, чувствуют ли разработчики эффект.
Хотите выявить точки трения. Фокус DevEx на когнитивной нагрузке и flow state отлично выявляет конкретные раздражители (плохая документация, медленный CI, слишком много митингов), делающие ежедневную работу мучительной.
Аргумент за комбинирование фреймворков
Эти фреймворки — не конкуренты. Они измеряют разное и естественно дополняют друг друга.
Практическая комбинация для большинства организаций:
Уровень 1: DORA (всегда включён)
Автоматизируйте сбор DORA-метрик с первого дня. Это ваши непрерывные, объективные метрики доставки. Отслеживайте еженедельно, выводите на командные дашборды, обсуждайте на ретроспективах.
DORA даёт «что» — какова наша эффективность доставки сейчас?
Уровень 2: DevEx-опросы (ежеквартально)
Проводите фокусированный DevEx-опрос ежеквартально. Держите его коротким (15–20 вопросов). Фокус на:
- Скорость обратной связи (CI, код-ревью, деплой)
- Когнитивная нагрузка (сложность, документация, инструментарий)
- Flow state (прерывания, митинги, переключения контекста)
DevEx даёт «почему» — почему эффективность доставки такова?
Уровень 3: Измерения SPACE (ежегодный глубокий аудит)
Раз в год проведите комплексную оценку, включающую более широкие измерения SPACE: удовлетворённость, благополучие, коллаборация и результаты производительности.
SPACE даёт «куда» — куда инвестировать в следующем году?
Как они дополняют друг друга
| DORA показывает | DevEx объясняет | SPACE добавляет контекст |
|---|---|---|
| Lead Time растёт | «CI занимает 35 минут, и мне приходится ждать» | Удовлетворённость снижается; инженеры чувствуют себя заблокированными |
| Deployment Frequency на плато | «Я провожу 3 часа/день на митингах, не могу завершить фичи» | Оверхед коллаборации высок; слишком много церемоний |
| Change Failure Rate растёт | «Кодовая база слишком сложная, не могу понять влияние изменений» | Обмен знаниями низкий; нет культуры документации |
| MTTR высокий | «Я не знаю, какая команда владеет каким сервисом» | Каналы коммуникации неясны; нет карты владения |
Типичные ошибки
Ошибка 1: Выбор одного фреймворка и игнорирование остальных
«Мы используем DORA, значит, developer experience измерять не нужно.» Это ведёт к оптимизации метрик доставки при выгорании разработчиков. Можно иметь элитные DORA-показатели и 30% ежегодной текучки. Это не устойчиво.
Ошибка 2: Измерение всего разом
«Внедрим все три фреймворка в этом квартале.» Это перегружает команды метриками, опросами и дашбордами. Начните с DORA (автоматизированный, низкий оверхед), добавьте DevEx-опросы после определения базовых показателей, исследуйте измерения SPACE, когда будете готовы к комплексной оценке.
Ошибка 3: Использование любого фреймворка для индивидуальной оценки
Все три фреймворка явно предостерегают от этого. DORA-метрики — это показатели доставки на уровне команды. Измерения SPACE — сигналы организационного здоровья. Метрики DevEx — показатели опыта. Использование любых из них для ранжирования разработчиков создаёт извращённые стимулы, накрутку и недоверие.
Ошибка 4: Усталость от опросов
Если проводить опросы SPACE и DevEx ежемесячно, response rate упадёт ниже 30% в течение двух кварталов. Ежеквартально — правильная каденция для большинства организаций. Ежегодно — для комплексных оценок.
Ошибка 5: Игнорирование фреймворка, который бросает вам вызов
Если DORA-метрики отличные, будет соблазн отмахнуться от DevEx-выводов о недовольстве разработчиков. Если DevEx-оценки высокие, будет соблазн игнорировать DORA-метрики, показывающие, что вы деплоите раз в месяц. Каждый фреймворк выявляет слепые зоны. В этом и суть.
Ландшафт 2026 года
Несколько трендов формируют использование этих фреймворков в 2026 году:
ИИ-разработка меняет расклад. С ИИ-ассистентами, сокращающими Coding Time, относительная важность Pickup Time и Review Time (DORA) возрастает. Измерение «когнитивной нагрузки» DevEx становится критическим — ИИ генерирует код быстро, но разработчикам всё ещё нужно его понимать и ревьюить.
Platform engineering упрощает сбор DORA-метрик. Внутренние платформы разработчика всё чаще предоставляют DORA-метрики из коробки. Барьер для внедрения ниже, чем когда-либо.
Удалённая работа делает DevEx важнее. В распределённых командах трение, невидимое в офисе (ожидание ответа, неясное владение, плохая документация), становится измеримым и значимым. DevEx-опросы выявляют эти проблемы.
Регуляторное давление увеличивает спрос на DORA. Отрасли вроде финтеха, здравоохранения и гос. сектора всё чаще требуют доказательств зрелости доставки ПО. DORA-метрики дают эти доказательства. (EU Digital Operational Resilience Act — тоже называется DORA, что сбивает с толку — стимулирует интерес к DevOps DORA-метрикам как способу демонстрации операционной зрелости.)
Практические рекомендации по ролям
Для CTO
Начните с DORA. Это объективно, автоматизировано и говорит на языке бизнес-результатов. Добавьте ежеквартальные DevEx-опросы для понимания удовлетворённости разработчиков и рисков текучки. Используйте измерения SPACE для ежегодного стратегического планирования.
Для VP of Engineering
Внедрите DORA по всем командам. Используйте для выявления команд, нуждающихся в поддержке (а не наказании). Добавьте DevEx-опросы, чтобы понять, трансформируются ли улучшения DORA в лучший опыт разработчиков.
Для Engineering Managers
DORA — ваша еженедельная операционная метрика. Используйте на ретроспективах. DevEx-обратная связь от команды подсказывает, что исправлять. Не пытайтесь внедрять SPACE на уровне команды — он предназначен для организационной оценки.
Для DevOps / Platform Engineers
Фокусируйтесь на DORA. Ваша работа — пайплайн доставки, и DORA измеряет именно это. Используйте данные DevEx для приоритизации того, какие части пайплайна улучшать (разработчики сами скажут, что болит больше — скорость CI или сложность деплоя).
Как PanDev Metrics вписывается
PanDev Metrics — это DORA-first платформа. Мы автоматизируем сбор всех четырёх DORA-метрик из вашего Git-провайдера (GitLab, GitHub, Bitbucket, Azure DevOps) и проектного трекера (Jira, ClickUp, Yandex.Tracker). Lead Time разбит на четыре стадии (Coding, Pickup, Review, Deploy) для actionable инсайтов.
Мы дополняем DORA отслеживанием IDE heartbeats из 10+ плагинов (VS Code, JetBrains, Eclipse, Xcode, Visual Studio и других) — переходя на территорию DevEx за счёт измерения реальной активности разработчиков, а не только событий пайплайна. Это даёт данные о прокси когнитивной нагрузки (переключения контекста, работа с несколькими репозиториями) и индикаторах flow state (непрерывные блоки кодинга) без необходимости опросов.
Встроенный ИИ-ассистент (на базе Gemini) анализирует ваши метрики, выявляет паттерны и предлагает вмешательства — объединяя объективность данных DORA с контекстным интеллектом, который подчёркивают фреймворки SPACE и DevEx.
Источники фреймворков: DORA State of DevOps Reports (2014–2023); "The SPACE of Developer Productivity" (ACM Queue, 2021); "DevEx: What Actually Drives Productivity" (ACM Queue, 2023).
Начните с того, что можно автоматизировать. PanDev Metrics даёт DORA-метрики с первого дня — без опросов, без ручного сбора данных, без таблиц. Начать →