Определение Developer Experience
Три академических определения DX и почему бизнесу стоит обратить внимание
Зачем определять то, что и так понятно
DX — слово, которое за последние пару лет обросло смыслами как корабельное днище ракушками. Для кого-то это внутренние тулзы, для кого-то — настроение команды, для кого-то — DORA-метрики. В одном разговоре про «улучшение DX» три собеседника обсуждают три разные темы.
Поэтому начнём с двух академических определений, на которые опирается всё остальное.
Фагерхольм и Мюнх, 2012
Финны Фабиан Фагерхольм и Юрген Мюнх опубликовали статью «Developer Experience: Concept and Definition» на конференции по процессам разработки. Они взяли три измерения из психологии UX и натянули их на разработчика.
Когниция — что разработчик думает об инструментах. Понятна ли документация, предсказуем ли API, разберётся ли новичок в архитектуре за разумное время.
Аффект — что он чувствует. Бесит ли медленный CI, нравится ли работать с фреймворком, выводят ли из себя ошибки без контекста.
Конация — что он намерен делать. Будет ли вкладываться в проект, посоветует ли инструмент коллегам, или уже листает hh.
Деление на три части выглядит сухо, но работает как диагностический чек-лист. Команда понимает архитектуру, но злится на процессы — это аффект, надо чинить процессы. Любят культуру, но тонут в коде — это когниция, надо чинить документацию и онбординг. Со всем справляются и тихо увольняются — это конация, и замечают её последней, когда уже поздно.
DevEx Framework, 2023
Через одиннадцать лет Abi Noda, Margaret-Anne Storey и Nicole Forsgren выпустили в ACM Queue статью «DevEx: What Actually Drives Productivity» — она ближе к инженерной практике, чем академическая триада 2012 года. Подробный разбор — в главе про DevEx Framework, здесь только суть.
Feedback loops. Сколько ждать, чтобы узнать, правильно ли всё сделано. Сборка, тесты, ревью, деплой. Длинная петля убивает контекст: пока CI считает двадцать минут, разработчик успевает переключиться в мессенджер, ответить на два сообщения и забыть, зачем вообще запускал сборку.
Когнитивная нагрузка. Сколько ментальной работы уходит не на задачу, а на её обвязку. Поднять сервис локально: прочитать README на сорок экранов, выставить три переменных окружения, угадать профиль docker-compose, перебить занятые порты. Или: одна команда, рабочее окружение через минуту. Разница в нагрузке выливается в реальные часы рабочего дня.
Flow state. Получится ли войти в поток и удержаться в нём. Митинги через каждые два часа, дежурства, три параллельных проекта — поток умирает на старте. Microsoft в одном из исследований намерили среднее время возврата к задаче после прерывания: около двадцати минут. Пять прерываний в день — и полтора-два часа просто нет.
Если совсем коротко
DX — это ответ на вопрос «насколько легко разработчику делать свою работу». Печеньки и эргономичный стул сюда не входят. Входят инструменты, процессы, архитектура, документация и то, как устроена коммуникация в команде.
Хороший DX выглядит так: новичок делает осмысленный коммит на первой неделе, CI отрабатывает за время кофе, новый сервис создаётся из шаблона, а не по советам Васи из соседнего отдела (Вася, кстати, в отпуске). Документация актуальна, потому что её сложнее не обновить, чем обновить.
«Это же про настроение»
Главное возражение от менеджмента звучит примерно так: «Нельзя оптимизировать бизнес под чувства разработчиков». Возражение слабое, потому что DX — не про чувства. Forsgren с соавторами в 2023 году показали корреляцию между тремя измерениями DevEx и производительностью команды. Команды с короткими петлями, низкой когнитивной нагрузкой и возможностью войти в поток поставляют больше, ломают меньше и выгорают реже.
Улучшение DX — это инженерные решения с измеримым эффектом. Ускорить CI. Сократить шаги локальной разработки. Убрать ручные согласования из релизного процесса. Каждое решение можно померить, и про это — раздел про метрики.