DX Core 4
Четыре метрики от getdx.com и почему они вызывают споры
Откуда взялся DX Core 4
В конце 2023 — начале 2024 года Аби Нода и его компания getdx.com (бывшая DX) предложили ещё один фреймворк для измерения Developer Experience — DX Core 4. Идея — дать компаниям минимальный набор метрик, с которого можно стартовать. Не пятнадцать измерений и не сложные матрицы, а четыре числа. К этому моменту Нода уже был известен в DX-сообществе как один из соавторов DevEx Framework вместе с Форсгрен и Стори, его голос имел вес.
DX Core 4 выделяет четыре метрики: Speed (скорость), Effectiveness (эффективность), Quality (качество) и Impact (влияние). Четыре коротких слова, каждое покрывает важный аспект работы разработчика. Но как только начинаешь копаться в деталях, появляются вопросы — поэтому DX Core 4 вызвал заметную дискуссию в сообществе.
Четыре метрики
Speed — скорость
Насколько быстро разработчик выполняет работу: скорость сборки, тестов, деплоя, code review. Переосмысление Feedback Loops из DevEx Framework и Lead Time из DORA, упакованное в одно слово. Измеряется комбинацией системных метрик (время CI, время до первого review) и опросов (как разработчик воспринимает скорость). С этой метрикой вопросов меньше всего — скорость обратной связи одна из ключевых вещей в DX, и в этом фреймворки сходятся.
Effectiveness — эффективность
Насколько легко разработчику выполнять работу и насколько мало препятствий на его пути. Перекликается с когнитивной нагрузкой из DevEx Framework и с Efficiency & Flow из SPACE. Понятны ли системы, хорошо ли настроены инструменты, есть ли лишняя ручная работа. Измеряется в основном опросами: «насколько легко выполнять типовые задачи?», «как часто вы сталкиваетесь с препятствиями?».
Quality — качество
Насколько разработчик и команда поддерживают качество кода и продукта. Change Failure Rate, количество багов, технический долг, покрытие тестами. Перекликается с Performance из SPACE и со стабильностью в DORA. Опросная сторона: «насколько вы уверены в качестве кода, который деплоите?», «как оцениваете уровень технического долга?».
Impact — влияние
Самая интересная и самая спорная метрика. Чувствует ли разработчик, что его работа имеет значение, что она влияет на продукт и бизнес. Чисто перцептивная метрика, измеряется через опросы: «чувствуете ли вы, что ваша работа влияет на успех продукта?», «понимаете ли, как ваш код связан с бизнес-результатами?». Идея: разработчик, который видит смысл в работе, более мотивирован и продуктивен. Это подтверждается исследованиями в организационной психологии.
Почему это вызывает споры
Критика DX Core 4 идёт по нескольким направлениям, и эти возражения стоит рассмотреть серьёзно, прежде чем брать фреймворк на вооружение.
Во-первых, коммерческая предвзятость. DX Core 4 разработан компанией, которая продаёт платформу для измерения Developer Experience — getdx.com. Очевидный конфликт интересов: компания определяет, что нужно измерять, и одновременно продаёт инструмент для измерения. DORA вырос из независимого академического исследования, SPACE был опубликован как исследовательская работа Microsoft Research. DX Core 4 — продуктовый маркетинг, упакованный в формат фреймворка.
Во-вторых, недостаток академической строгости. За DX Core 4 нет такой исследовательской базы, как у DORA (годы данных тысяч организаций) или SPACE (исследовательская работа с рецензированием). Это экспертное мнение людей, которые хорошо разбираются в теме, и его стоит отделять от научного обоснования.
В-третьих, упрощение бывает чрезмерным. Четыре широкие категории — Speed, Effectiveness, Quality, Impact — настолько общие, что под них подводится почти что угодно. Это делает фреймворк привлекательно простым и потенциально бесполезным: когда всё подходит, ничто не помогает выделить приоритеты. Для сравнения, в DevEx Framework три измерения (Feedback Loops, Cognitive Load, Flow State) конкретны и сразу подсказывают, куда копать.
Контраргументы
У DX Core 4 есть и сильные стороны, которые нечестно игнорировать. Простота — не всегда недостаток. Многие команды вообще не измеряют DX, потому что существующие фреймворки кажутся им слишком сложными. Если DX Core 4 окажется точкой входа — это уже хорошо. Любое измерение лучше, чем никакого, и четыре понятных слова легко объяснить менеджменту и получить бюджет на улучшения.
Команда Ноды сделала много для популяризации темы Developer Experience, у них практический опыт работы с десятками компаний. Они видели, что работает и что не работает, и DX Core 4 — кристаллизация этого опыта.
Как DX Core 4 соотносится с другими фреймворками
Если расположить фреймворки на шкале от «узко и конкретно» до «широко и всеобъемлюще», получится примерно так: DORA (только delivery pipeline) → DevEx Framework (три конкретных измерения опыта) → DX Core 4 (четыре широких категории) → SPACE (пять измерений продуктивности). У каждого своя зона покрытия, и они скорее дополняют друг друга, чем конкурируют. Хотя маркетинг каждого, конечно, продвигает свой подход как единственно правильный.
Практическая рекомендация
Не привязывайтесь к одному фреймворку. DORA — для мониторинга delivery pipeline, проверенные метрики. DevEx Framework — для понимания повседневного опыта разработчиков, конкретные и практичные измерения. Если DX Core 4 помогает объяснить руководству, зачем измерять DX, и получить бюджет — используйте его как коммуникационный инструмент, не обязательно как единственную систему измерения.
Главное — не выбор фреймворка, а сам факт того, что в компании начинают разговаривать с разработчиками об их опыте, собирать данные и принимать решения на основе этих данных, а не интуиции.