Определение Developer Experience

Зачем вообще определять Developer Experience

Термин Developer Experience на первый взгляд кажется очередным модным словом из категории тех, которые добавляют в резюме, чтобы казаться современнее, а на практике за ними не стоит ничего конкретного. Но если копнуть глубже, выясняется, что за красивой аббревиатурой DX стоят вполне конкретные академические работы, эмпирические исследования и, что самое важное, измеримые последствия для бизнеса — и вот тут становится по-настоящему интересно, потому что оказывается, что разница между командой с хорошим DX и командой с плохим DX — это не просто разница в настроении разработчиков, а разница в скорости доставки, качестве кода и текучке кадров.

Определение Фагерхольм и Мюнх (2012)

Первую серьёзную попытку дать академическое определение Developer Experience предприняли финские исследователи Фабиан Фагерхольм и Юрген Мюнх в 2012 году в работе «Developer Experience: Concept and Definition», опубликованной в рамках International Conference on Software and System Process. Они определили DX через три измерения, которые заимствовали из психологии пользовательского опыта и адаптировали для контекста разработки программного обеспечения.

Первое измерение — когнитивное (cognition): что разработчик думает о своих инструментах, процессах и инфраструктуре. Насколько понятна документация, насколько предсказуемо ведёт себя API, легко ли разобраться в архитектуре проекта новому человеку. Второе измерение — аффективное (affect): что разработчик чувствует в процессе работы. Это про фрустрацию от медленного CI, радость от хорошо спроектированного фреймворка, раздражение от непонятных ошибок без контекста. Третье измерение — конативное (conation): что разработчик намерен делать. Хочет ли он вносить вклад в проект, рекомендовать инструмент коллегам, или наоборот — тихо искать новую работу, потому что каждый рабочий день превращается в борьбу с инфраструктурой.

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

DevEx Framework (2023)

Через одиннадцать лет после работы Фагерхольм и Мюнх вышла статья, которая фактически переопределила DX для современного мира: «DevEx: What Actually Drives Productivity» авторов Abi Noda, Margaret-Anne Storey и Nicole Forsgren, опубликованная в ACM Queue в 2023 году. Они предложили смотреть на Developer Experience через три линзы, каждая из которых гораздо более операциональна, чем академические измерения 2012 года. Этот подход подробно разобран в главе про DevEx Framework.

Feedback loops — петли обратной связи. Насколько быстро разработчик узнаёт, правильно ли он делает свою работу. Сюда входит время сборки, скорость прогона тестов, время ожидания code review, скорость деплоя. Чем длиннее петля обратной связи, тем хуже DX, потому что разработчик вынужден переключать контекст, забывает о чём шла речь, и тратит ментальную энергию на восстановление состояния. Исследования показывают, что даже 15-минутное ожидание результата CI ломает поток — разработчик отвлекается на Slack, потом тратит 10 минут на то, чтобы вспомнить, где он остановился.

Cognitive load — когнитивная нагрузка. Сколько ментальных усилий требуется для выполнения задачи, не связанных напрямую с её сутью. Если для того, чтобы поднять сервис локально, нужно прочитать 40-страничный README, настроить три переменных окружения, запустить Docker Compose с правильным профилем и помолиться, чтобы порты не были заняты — это высокая когнитивная нагрузка. Если вместо этого можно сделать одну команду и получить работающее окружение — нагрузка низкая, и разработчик может сосредоточиться на том, за что ему платят: решать бизнес-задачи.

Flow state — состояние потока. Насколько легко разработчику войти в продуктивное состояние и оставаться в нём. Бесконечные встречи, прерывания в Slack, непредсказуемые дежурства, обязанность параллельно вести три проекта — всё это враги потокового состояния. По данным исследования Microsoft, после одного прерывания разработчику нужно в среднем 23 минуты, чтобы вернуться к задаче, а если прерываний пять в день — это почти два часа чистой продуктивности, которые просто исчезают.

Практическое определение

Если отбросить академический жаргон и сказать совсем просто, то Developer Experience — это ответ на вопрос «насколько легко и приятно разработчику делать свою работу». Не насколько комфортен офис и не сколько печенек в кухне, а насколько инструменты, процессы, архитектура, документация и культура компании помогают (или мешают) человеку писать хороший код, доставлять его в продакшен и не сходить с ума в процессе.

Хороший DX — это когда новый разработчик делает первый осмысленный коммит в первый день, а не через три недели. Когда CI проходит за 5 минут, а не за 45. Когда для создания нового микросервиса есть шаблон и golden path, а не устная традиция в голове одного человека, который ушёл в отпуск. Когда документация актуальна, потому что она генерируется из кода, а не пишется вручную раз в год по случаю аудита.

Почему это не просто «настроение»

Самое распространённое возражение со стороны менеджеров: «DX — это про то, чтобы разработчики были довольны, но мы не можем оптимизировать всё под чувства, у нас бизнес». И это возражение основано на непонимании того, что DX — это не про чувства ради чувств. Исследование Forsgren и соавторов 2023 года показало прямую корреляцию между тремя измерениями DevEx и производительностью команд: команды с быстрыми петлями обратной связи, низкой когнитивной нагрузкой и возможностью войти в поток доставляют больше ценности, допускают меньше ошибок и реже выгорают.

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