DX Core 4

Откуда взялся 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) и опросов (восприятие скорости разработчиком). Здесь пока всё понятно и непротиворечиво — скорость обратной связи действительно одна из самых важных вещей в Developer Experience, и в этом все фреймворки сходятся.

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 есть и сильные стороны, которые нечестно было бы игнорировать. Простота — это не всегда недостаток. Многие команды не измеряют Developer Experience вообще, потому что существующие фреймворки кажутся им слишком сложными, и если DX Core 4 станет тем, с чего они начнут — это уже хорошо. Любое измерение лучше, чем никакого, и четыре понятных слова — Speed, Effectiveness, Quality, Impact — легко объяснить менеджменту и получить бюджет на улучшения.

Кроме того, Аби Нода и его команда действительно сделали много для популяризации темы 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, и получить на это бюджет — используйте его для этого, в качестве коммуникационного инструмента, не обязательно в качестве единственной системы измерения.

Самое важное — не какой фреймворк вы выберете, а то, что вы вообще начнёте разговаривать с разработчиками о их опыте, собирать данные и принимать решения на основе этих данных, а не на основе интуиции менеджера, который последний раз писал код пять лет назад.