DevEx Framework

От продуктивности к опыту

В 2023 году Аби Нода, Маргарет-Энн Стори и Николь Форсгрен опубликовали статью «DevEx: What Actually Drives Productivity». Это следующий шаг после DORA и SPACE: вместо того чтобы измерять продуктивность разработчиков (вещь спорная и трудноопределимая), авторы предложили сосредоточиться на Developer Experience — на том, как разработчик переживает свою работу. Логика такая: если опыт разработчика хороший (быстрая обратная связь, понятные системы, возможность сосредоточиться), продуктивность подтянется следом.

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

Три измерения

Feedback Loops — петли обратной связи

Скорость, с которой разработчик получает информацию о результатах работы. Сюда входят время прохождения CI-пайплайна (запушил код — когда узнаешь, прошли ли тесты), скорость code review (открыл PR — когда придёт первый комментарий), время деплоя (от мёржа до продакшена), время ответа на вопрос в чате коллеге или в тикете другой команде.

Длинные петли разрушают рабочий процесс системно. Если CI проходит сорок минут, разработчик не сидит и не ждёт — он переключается на другую задачу, теряет контекст первой, а когда CI падает, заново вспоминает, что он там делал. По имеющимся исследованиям, каждое переключение контекста стоит пятнадцать-тридцать минут на восстановление фокуса. Медленный CI — мультипликатор потерь времени.

Как измерять: системные сигналы — медианное время прохождения CI, медианное время до первого комментария на PR, время от мёржа до продакшена. Опросные сигналы — «насколько вы довольны скоростью обратной связи в работе?», «как часто приходится ждать чего-то, прежде чем продолжить?».

Cognitive Load — когнитивная нагрузка

Объём ментальных усилий, которые уходят на выполнение задачи. Высокая когнитивная нагрузка появляется там, где системы сложные и плохо документированные, где для одной задачи нужно взаимодействовать с пятью сервисами и тремя системами конфигурации, где инструменты неинтуитивны и требуют знаний, которые нигде не записаны, где приходится держать в голове слишком много контекста.

Это самое недооценённое измерение DX — его не видно в метриках CI/CD или в дашборде DORA. Команда деплоит десять раз в день с нулевым Change Failure Rate и при этом тратит семьдесят процентов времени на то, чтобы разобраться, как устроена система, в которой надо поменять две строчки. С точки зрения DORA всё отлично, разработчики при этом выгорают.

Как измерять: опросы — основной инструмент, нагрузка субъективна по природе. «Насколько сложно разобраться в кодовой базе сервиса X?», «как часто приходится просить помощи на рутинной задаче?», «насколько понятна документация?». Системные сигналы косвенные: число сервисов, с которыми взаимодействует разработчик, число инструментов для типовой задачи, частота обращений за помощью в чатах.

Flow State — состояние потока

Способность разработчика входить в глубокую концентрацию и оставаться в ней достаточно долго для сложной творческой работы. Программирование требует длительной непрерывной концентрации: загрузить контекст в голову, продумать решение, реализовать, протестировать. Постоянные прерывания — митинги каждый час, оповещения, on-call дежурства, срочные запросы от менеджеров — убивают поток на старте.

Как измерять: опросные сигналы — «сколько часов непрерывной работы было вчера?», «как часто вас прерывают в течение дня?», «удаётся ли удержаться на одной задаче?». Системные сигналы — число митингов в календаре, паттерны активности (короткие серии коммитов с большими перерывами — признак фрагментированного дня), число переключений между проектами и репозиториями.

Как DevEx связан с SPACE

DevEx Framework дополняет SPACE, но фокусируется уже: три измерения вместо пяти, каждое конкретнее. Satisfaction из SPACE — следствие, а Feedback Loops, Cognitive Load и состояние потока — причины. Улучшите причины, и удовлетворённость подтянется.

DevEx Framework лучше подходит для оперативной работы: понять, что улучшить прямо сейчас, чтобы разработчикам стало легче. SPACE лучше для стратегического обзора: оценить общее состояние организации и найти слепые пятна.

С чего начать

Простое упражнение: попросите каждого разработчика в течение недели записывать моменты, когда пришлось чего-то ждать (feedback loops), когда не получилось в чём-то разобраться (cognitive load) и когда прервали посреди работы (поток). Через неделю обсудите результаты. Скорее всего, проявятся чёткие паттерны, и они сразу подскажут, что делать: главная боль — медленный CI, идёте оптимизировать CI; непонятная документация — идёте её писать; митинги — пересматривать календарь. Поэтому DevEx Framework и работает на практике: показывает не абстрактные «проблемы с DX», а конкретные места, где болит.