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 — когнитивная нагрузка

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

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

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

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

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

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

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

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

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

С чего начать

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