Хотя само понятие DevEx появилось довольно давно, популярность этого подхода к разработке резко выросла в последние годы. Его часто рассматривают как следующий этап после DevOps, хотя на самом деле DevEx скорее дополняет и развивает и этот подход, и UX. Этот текст — о том, почему DevEx важен для повышения продуктивности и какие полезные практики есть в этом подходе.
Что такое DevEx, и как возник этот подход
DevEx (Developer Experience, опыт разработчика) — это подход, предлагающий отталкиваться от опыта разработчика и его потребностей. Впервые о DevEx заговорили в 2011 году — этот термин возник по аналогии с UX (User Experience, пользовательским опытом). Подход предполагал, что с точки зрения продуктивности работы важно, чтобы у разработчиков были все необходимые инструменты, удобная среда и другие факторы, способствующие концентрации на работе. Иначе говоря, что их опыт разработки — тоже часть конечного пользовательского опыта. Эта связь сохранялась и в дальнейшем: DevEx смотрит на разработку с точки зрения UX, просто на место обычного пользователя ставится внутренний «пользователь» — разработчик.
Настоящий расцвет этого подхода пришелся уже на
По сути DevEx направлен на то, чтобы разработчику было максимально удобно заниматься своей основной деятельностью, то есть собственно разработкой, не отвлекаясь ни на что второстепенное. На практике это означает оптимизацию инструментов, платформ и процессов, с которыми работают инженеры. Большое внимание, как и в случае с UX, уделяется не только формальным показателям, но и субъективному опыту разработчика: инструмент не должен мешать, среда должна поддерживать фокус и состояние потока, а системы — помогать в работе. Все это должно повысить продуктивность и удовлетворенность работой, а в конечном итоге — улучшать качество продукта и одновременно с этим удерживать разработчиков в компании.
Частью DevOps на практике является исследование взаимодействия разработчиков с инструментами, фреймворками, интерфейсами, а также их влияние на психологическое состояние сотрудника. Как и в случае с другими подходами, довольно быстро возникла необходимость в механизмах оценке DevEx и дальнейшего его улучшения — и стали возникать платформы и инструменты для этого.
Также DevEx рассматривают в рамках более широкой системы метрик, таких как SPACE (Satisfaction, Performance, Activity, Collaboration, Efficiency), предложенной Microsoft.
Еще одна полезная система метрик, часто используемая при оценке DevEx — DORA (DevOps Research and Assessment). Этот метод предполагает оценку по четырем основным параметрам — они позволяют оценить скорость работы (для этого используются характеристики время выполнения изменений и частота развертывания) и стабильность системы (среднее время восстановления и коэффициент отказов изменений).
DevEx в сравнении с DevOps и UX
Если сравнить DevEx с двумя основными направлениями, которые он продолжает и развивает — DevOps и UX — можно оценить, в чем плюсы этого подхода.
DevEx и DevOps
DevOps сфокусирован на автоматизации, методике CI/CD (непрерывной интеграции и непрерывного развертывания) и общей связи разработки и поддержки. Практики DevOps становятся фундаментом для хорошего DevEx, который расширяет возможности DevOps, добавляя человекоцентричные метрики и цели.
DevEx — в целом более человекоцентричный подход. Он предусматривает не только формальные практики и автоматизацию, но и такие параметры, как удобство работы, скорость обратной связи, психологический комфорт, снижение когнитивной нагрузки и отслеживание метрик счастья разработчиков.
Два подхода могут органично дополнять друг друга: DevOps обеспечивает структуру, надежность и скорость, а DevEx делает среду удобной, создает комфорт и повышает эффективность работы. В идеале DevOps решает «как», а DevEx заботится о том, «насколько удобно».
Например, DevOps автоматизирует и ускоряет процессы — и это напрямую снижает трение и улучшает DevEx. Один из примеров интеграции DevEx и DevOps — платформенная инженерия. Создание внутренних платформ для разработчика помогает сформировать удобную, самодостаточную среду для кодинга, позволяющую разработчику абстрагироваться от инфраструктурных сложностей и не отвлекаться на лишние шаги.
DevEx и UX
DevEx возник как аналог UX, только ориентированный на опыт разработчиков, а не конечных пользователей. Его можно назвать UX для внутреннего пользователя — поэтому вместо удобства конечного продукта он предусматривает удобство инструментов, документации, рабочих процессов и культуры.
С точки зрения практики это означает, что DevEx и UX сосредотачиваются на разных вопросах и проблемах. UX — на интерфейсе конечного продукта, взаимодействии с ним, эмоциях при использовании продукта. DevEx — на среде, в которой работает разработчик, удобстве инструментария, процессах, ощущении от работы. При этом они не противоречат друг другу, а скорее дополняют: хороший DevEx создает фундамент качественного UX, ведь быстрый, понятный и стабильный процесс разработки позволяет создавать лучше продуманные продукты.
Сравнение трех подходов
| |
UX | DevOps | DevEx |
|---|---|---|---|
| Фокус | Конечный пользователь продукта | Автоматизация и интеграция Dev ↔ Ops | Опыт разработчика: инструменты, процессы, культура |
| Цель | Удовлетворенность и удобство | Быстрый, надежный релиз | Повышение продуктивности, удовлетворенности, удержания |
| Связь | UX → DevEx (вдохновение, аналогия) | DevOps — фундамент для DevEx | DevEx расширяет DevOps + человекоцентричность |
| Ключевые моменты | UI, визуал, удобство использования | CI/CD, мониторинг, инфраструктура | Адаптация, поток, документация, внутренняя платформа |
Полезные практики DevEx
Вот несколько практик и методов, используемых в DevEx для улучшения опыта разработчика и повышения эффективности его работы.
1. Понимание пути разработчика (Developer Journey)
Для этого нужно выделить этапы взаимодействия с продуктом: предварительное изучение (Discover), оценка (Evaluate), обучение (Learn), выстраивание (Build), масштабирование (Scale). На каждом этапе разработчику нужно задавать себе вопрос, действительно ли ему подходит этот формат работы — если ответ отрицательный, значит, необходимо что-то менять. Эффективный DevEx обеспечивает бесперебойный переход от одного шага к другому, минимизируя проблемы и фрустрацию разработчика.
2. Работа с документацией
Для того, чтобы разработчику было удобно работать с документацией, она должна быть интуитивно понятной, актуальной и доступной. Нужно избавляться от излишнего жаргона, затрудняющего понимание, а также поддерживать актуальность документации после каждого изменения. Также важно максимально упрощать поиск необходимой информации: в этом помогут порталы для разработчиков, кодовые примеры, FAQ и поисковая база.
3. Удобная самостоятельная работа (self-service)
Нужно настроить все так, чтобы разработчик по максимуму мог работать самостоятельно. Такие процессы, как интеграция, получение API-ключей, тестирование и др. должны происходить без участия других людей. Вхождение в продукт помогут упростить и ускорить такие инструменты, как встроенные playground, песочницы и примеры кода.
4. Автоматизация и сокращение рутинных задач
Продуктивность и вовлеченность разработчиков повысит освобождение их от рутинных и неинтересных задач. Нужно по максимуму автоматизировать такие процессы, как CI, QC (Quality Control, контроль качества), тестирование, внедрение. Хорошим решением может быть платформенная инженерия, предоставляющая интерфейс для запуска и управления.
5. Отзывчивость и выявление ошибок
Разработчики должны быстро понимать, что идет не так, что сломалось. В этом поможет постоянный мониторинг и выстраивание наблюдаемости с помощью метрик, логов, трассировки и др. Также важна возможность обратной связи. Еще одной полезной практикой является Shift-Left — ранний запуск проверки качества и безопасности (статический анализ, тесты) на этапе CI.
6. DevEx-аудит и DPE
Полезно организовать DevEx-аудит: опрос пользователей, сбор обратной связи, исследование «болей» разработчиков. Еще один лайфхак — использование подхода DPE (Developer Productivity Engineering), позволяющего повысить продуктивность разработчиков. DPE-подход предусматривает, в частности, CI/CD, автоматическое тестирование, регулярный анализ и улучшение.
7. Здоровая среда для работы в потоке
Подходящая для продуктивной разработки среда должна помогать войти в состояние потока — то есть максимальной погруженности в работу и концентрации на задаче. Здесь особенно важно устранение помех для этой концентрации: нужно выстроить работу так, чтобы у разработчиков было меньше встреч и других второстепенных задач, ревью были короткими, а максимум времени уходило непосредственно на разработку. Это позволяет войти в поток и работать более эффективно, ни на что не отвлекаясь.
8. Сообщество и обмен опытом
Хотя для продуктивной работы важна возможность самостоятельной работы и отсутствие лишних помех, одновременно с этим не менее важен обмен опытом и совместные обсуждения. Для этого хорошо подходят митапы, вебинары, конференции, хакатоны. Все эти мероприятия позволяют выстраивать сообщество, а также помогают мотивировать разработчиков и способствуют обучению менее опытных сотрудников.
9. Метрики DevEx
Нужно серьезно подходить к разработке метрик, по которым вы будете оценивать работу, и не ограничиваться традиционными метриками продуктивности. Полезно будет внедрить показатели удовлетворенности (Developer Satisfaction Score), удержания, узких мест в процессах, обратную связь. Хороший пример — метрики SPACE (Satisfaction, Performance, Activity, Collaboration, Efficiency), предложенные Microsoft, или DORA. Еще одна популярная в последнее время метрика для оценки продуктивности — DX Core 4, предложенная компанией DX.
10. Постоянные улучшения
DevEx — это не одномоментные улучшения, а постоянный процесс. Новые улучшения нужно внедрять на всех этапах работы и при всех изменениях в процессах. Кроме того, сами изменения нужно внедрять пошагово, постоянно анализировать результаты изменений и соответственно корректировать их.
11. Снижение трения через стандарты и упрощение
Важными элементами в DevEx являются упрощение процессов и внедрение стандартов. Нужно документировать соглашения по кодированию, архитектурным паттернам, рабочим процессам — это само по себе упростит работу и снизит трение. Простые, воспроизводимые, документированные окружения и Git-процессы — залог комфорта и эффективности. Такие практики, как TDD, CI/CD, рефакторинг, также помогут упростить процессы и снизить трение.
Заключение
Уже не в первой компании я вижу на практике, как DevEx помогает ускорить разработку, улучшить показатели и сделать работу более комфортной. При этом есть довольно много исследований, подтверждающих, что практики DevEx повышают продуктивность работы.
Так, исследование, подготовленное в числе прочего экспертами из Microsoft и Github, свидетельствует, что углубленная работа в состоянии потока без отвлечения на второстепенные рабочие вопросы повышает продуктивность разработчиков на 50%. Кроме того, если разработчики занимаются интересными им задачами, а не чем-то скучным, они отмечают рост продуктивности на 30% — это также относится к сфере DevEx. Другое исследование демонстрирует, что 74% компаний, использующих практики DevEx, отметили связанный с этим рост продуктивности, а окупаемость инвестиций (ROI) в некоторых случаях достигала 433%.
