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, а скорее более сфокусированная линза для тех же проблем. Если SPACE даёт вам широкую картину из пяти измерений, то DevEx сужает фокус до трёх вещей, которые, по мнению авторов, оказывают наибольшее влияние на повседневный опыт разработчика. Satisfaction из SPACE — это скорее следствие, а Feedback Loops, Cognitive Load и Flow State — это причины. Улучшите причины, и удовлетворённость вырастет сама.

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

С чего начать

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