Обзор Conceptual Framework for Developer Experience

В 2022 году был опубликован концептуальный фреймворк DX Framework для улучшения Developer Experience от группы экспертов: Michaela Greiler, Margaret-Anne Storey и Abi Noda. Авторы поставили задачу понять, какие факторы влияют на Developer Experience. Представленный фреймворк служит ориентиром для организаций, стремящихся создать более продуктивную и эффективную рабочую среду для своих разработчиков. Авторы отмечают, что повышение счастья (Developer Happiness) и удовлетворенности разработчиков (Developer Satisfaction) является важной целью для многих организаций, так как это может приводить к более высоким уровням производительности и улучшать удержание сотрудников.

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

Мы подготовили подробный обзор исследования и фреймворка по следующей структуре:
  • Определение Developer Experience
  • Исследования факторов, влияющих на Developer Experience
  • Методология исследования для DX Framework
  • Факторы, влияющие на Developer Experience (DX Factors)
  • Контекстные характеристики и значимость факторов
  • Барьеры для улучшения Developer Experience
  • Индивидуальные стратегии улучшения Developer Experience
  • Командные стратегии улучшения Developer Experience
  • Механизмы адаптации
  • Применение и развитие фреймворка

Определение Developer Experience
Определение Developer Experience, используемое в исследовании: "То, как разработчики воспринимают свою работу, что они о ней думают и какую ценность ей придают".

Определение основано на работе Mikael Fagerholm и Jürgen Münch и опирается на социальную психологию, в частности на концепцию триады разума (Trilogy of the mind), согласно которой три ключевых измерения человеческого опыта — это когниция (Cognition), аффект (Affect, эмоции) и конативность (Conation, воля к действию). Учет этих трех измерений важен, поскольку "решение реальных задач происходит во взаимодействии с мотивационными и эмоциональными процессами, иногда согласованно, а иногда — противоречиво":
  • Когнитивное измерение связано с убеждениями разработчиков, тем, как они думают и оценивают свою инфраструктуру разработки, процессы, знания и навыки.
  • Аффективное измерение описывает эмоции разработчиков и то, как они относятся к своей работе.
  • Конативное измерение отражает ожидания и мотивацию разработчиков, а также то, как они воспринимают ценность своих рабочих действий (активностей, производительности и вклада).

В совокупности эти измерения взаимодействуют и формируют намерения относительно будущего поведения и действий в работе. Индивидуальные особенности личности и другие характеристики формируют эти три измерения, однако на них также влияют внешние и социальные факторы, такие как характер работы, рабочая среда и работа в составе команды или коллектива. Факторы, влияющие на одно измерение, как правило, оказывают влияние и на одно или оба других измерения. Теория триады разума согласуется с пониманием Developer Experience и помогает выявлять ключевые факторы, формирующие его в условиях совместной работы. Аналогично Maylett и Wride определяют Employee experience как совокупность опыта, восприятия и ожиданий сотрудников.

Исследования факторов, влияющих на Developer Experience
Предыдущие исследования были направлены на выявление факторов, которые могут влиять на счастье разработчиков, удовлетворенность работой, производительность разработчиков и мотивацию:
  • Fabian Graziotin и соавторы исследовали счастье разработчиков (Developer Happiness, аффективное состояние) с помощью опроса и выявили, что основными факторами, связанными с неудовлетворенностью, по степени влияния являются: застревание при решении задач, ощущение давления по срокам, низкое качество кода и практик разработки, недостаточная производительность коллег, чувство собственной некомпетентности, скучные или повторяющиеся задачи, необъяснимые ошибки в коде, плохое принятие решений в команде, ограничения, навязанные инфраструктурой, и личные проблемы, не связанные с работой. Также было установлено, что ощущение счастья коррелирует с воспринимаемой производительностью: более счастливые разработчики склонны оценивать свою производительность выше и наоборот. Aurélien Bellet и соавторы также отмечают сильную связь между производительностью и счастьем;
  • Emerson Murphy-Hill и соавторы исследовали, какие факторы могут предсказывать производительность разработки программного обеспечения, на основе исследования в трех компаниях. Они установили, что главным предиктором производительности является энтузиазм по отношению к своей работе, за которым следуют поддержка идей со стороны команды и наличие автономии в выборе инструментов и организации работы. Обзор литературы, выполненный Stefan Wagner и соавторами, описывает еще больше факторов, связанных с отчетной или воспринимаемой производительностью;
  • Margaret-Anne Storey и соавторы исследовали удовлетворенность разработчиков своей работой, опираясь на определение удовлетворенности работой Thomas A. Wright и Russell Cropanzano как "внутреннего состояния, выражающегося через аффективную и/или когнитивную оценку выполняемой работы с определенной степенью одобрения или неодобрения". Факторы удовлетворенности, выявленные в крупном опросе в Microsoft, включают: выполнение значимой работы, ощущение значимого вклада в команду, позитивную рабочую и командную культуру, ощущение продуктивности, получение признания и вознаграждения, а также баланс между работой и личной жизнью. Также была выявлена двусторонняя связь между удовлетворенностью и производительностью разработчиков, а также дополнительные факторы, влияющие на производительность: автономия в работе, способность завершать задачи и качество инженерной системы;
  • Dirk Steglich и соавторы, на основе обзора литературы, обобщили ряд социальных факторов, влияющих на участие разработчиков в экосистемах мобильных программных систем, включая возможность учиться новому, получать удовольствие и сотрудничать с другими.
  • Sarah Beecham и соавторы также исследовали мотивацию разработчиков в систематическом обзоре литературы и выявили множество личных и рабочих характеристик, которые модифицируют влияние различных мотивирующих факторов (например, хорошее руководство, соответствие задач, расширение полномочий) и демотивирующих факторов (например, плохое руководство, неблагоприятная рабочая среда, стресс);
  • Helen Sharp и соавторы проанализировали ряд моделей из литературы и предложили модель мотивации в программной инженерии, включающую мотиваторы, результаты, характеристики и контекст;
  • César França и соавторы выявили разнообразные факторы, влияющие на мотивацию, такие как карьерное развитие и автономия. Они отмечают, что мотивация и удовлетворенность работой не являются одним и тем же, что согласуется с трехмерной моделью Developer Experience, предложенной Fagerholm и Münch: мотивация ближе к конативному измерению, а удовлетворенность — к когнитивному.
В совокупности предыдущие исследования выявили сотни факторов, и многие из них пересекаются, поскольку удовлетворенность, производительность и мотивация являются взаимосвязанными и частично перекрывающимися аспектами Developer Experience. Текущее исследование охватывает не один или два конструкта, такие как счастье, удовлетворенность или производительность, а направлено на влияние на Developer Experience в целом. При этом фокус — определить, какие из этих факторов являются наиболее значимыми, почему они важны и какие из них могут быть применены на практике.

Методология исследования для DX Framework
Методология исследования включала полуструктурированные интервью с разнообразной выборкой разработчиков с точки зрения роли, индустрии, проектов и опыта. В соответствии с качественным подходом к исследованию, исследовательские вопросы формировались и уточнялись по мере сбора и анализа данных. Исходный направляющий вопрос исследования был следующим: какие факторы являются наиболее значимыми и применимыми на практике для влияния на Developer Experience?

По мере проведения интервью выявлялись не только факторы, важные для разработчиков, но и обнаружились контекстные характеристики их работы, которые определяют относительную значимость этих факторов (например, уровень опыта разработчика). В итоге сформировались следующие вопросы:
  • RQ1: Какие значимые факторы влияют на Developer Experience?
  • RQ2: Какие контекстные характеристики могут влиять на значимость фактора для конкретного разработчика?
  • RQ3: Какие барьеры препятствуют разработчикам и их командам улучшать факторы, влияющие на Developer Experience?
  • RQ4: Какие стратегии используют разработчики и их команды для улучшения Developer Experience?
  • RQ5: Какие механизмы адаптации используют разработчики, когда факторы, негативно влияющие на Developer Experience, не улучшаются?

В рамках интервью авторы стремились изучить, какие факторы разработчики считают влияющими на Developer Experience, а также понять, каким образом они улучшают эти факторы в своих командах. Каждое интервью длилось от 45 до 90 минут. Для записи интервью использовался Zoom, а для расшифровки — программное обеспечение для транскрибирования. Транскрипты использовались в основном для поиска по интервью и для установления связей между заметками и концепциями. Вопросы интервью основывались на гайдлайне доступном на GitHub:
  • В первой части интервью каждому участнику давалось общее определение Developer Experience: "Developer Experience — это восприятие разработчиком работы, процессов и культуры, с которыми он сталкивается при разработке программного обеспечения в команде". Затем участников спрашивали, какие факторы, по их мнению, влияют на их опыт.
  • Во второй части интервью участники вовлекались в обсуждение значимости факторов и их применимости на практике. Для углубления обсуждения им демонстрировался список факторов, выявленных в предыдущих исследованиях. Эти факторы использовались как стимул для расширения обсуждения и побуждения участников учитывать факторы, которые не приходят на ум сразу. Список был сформирован путем объединения факторов из литературы, представленных выше, устранения дубликатов и последующего сокращения до факторов, которые считаются применимыми на уровне разработчиков и их команд. Для снижения когнитивной нагрузки факторы были сгруппированы по категориям перед представлением участникам.
  • В третьей части интервью фокус был направлен на понимание того, могут ли участники влиять на свой Developer Experience и каким образом они это делают. На основе инсайтов и опыта, которыми делился каждый участник, вопросы о значимости и применимости уточнялись и адаптировались под контекст интервьюируемого. Это позволило исследовать новые области и последовательно собирать дополнительные точки зрения по темам, поднятым предыдущими участниками.

Для отбора участников исследования использовалась Convenience sampling: авторы привлекали разработчиков через социальные и коммуникационные каналы. Критерии отбора заключались в том, что участники должны были иметь не менее шести месяцев профессионального опыта разработки и на момент участия работать разработчиками или руководителями разработки. Перед каждым интервью авторы запрашивали согласие на участие и разрешение на запись сессии. Участникам сообщалось, что они могут прекратить участие в любой момент, и в этом случае их ответы будут удалены. Форма согласия и инструкции для интервью доступны в дополнительных материалах.
Авторы стремились к разнообразию участников по опыту, компаниям, странам и полу. В результате:
  • удалось привлечь участников из различных стран и регионов Америки и Европы;
  • 16 из 21 участников имели более шести лет профессионального опыта разработки программного обеспечения, из них пять — более 20 лет;
  • четыре участника имели от двух до пяти лет опыта, и один — шесть месяцев опыта в роли профессионального разработчика;
  • участники работали в различных индустриях (включая Medical sector, Developer tooling, HR software, Consulting);
  • размер команд варьировался от 2 до 100 человек, а размер компаний — от 5 до более чем 20000 сотрудников.

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

Для анализа интервью использовался подход открытого кодирования (Open Coding), при котором кодирование выполняется индуктивно (снизу вверх). Интервью проводились и кодировались двумя или более авторами в несколько итеративных циклов. Записи интервью и их расшифровки неоднократно пересматривались в ходе итеративного процесса. При обработке каждого нового интервью авторы возвращались к предыдущим, чтобы проверить, упоминали ли ранее респонденты новые выявленные инсайты. Когда в трех последовательных интервью перестали появляться новые коды и инсайты, авторы сочли, что достигнуто насыщение и прекратили привлечение новых участников. Авторы разбивали транскрипты интервью на согласованные смысловые единицы (предложения или абзацы) и присваивали им предварительные коды, отражающие ключевые идеи, озвученные участниками. Затем согласовали набор фокусных кодов, которые отражают наиболее частые и значимые факторы Developer Experience. Далее применили осевое кодирование (Axial coding) для группировки кодов по категориям. Этот процесс выполнялся с использованием инструментов визуального маппинга в несколько итераций с обсуждением между авторами. В ходе кодирования также формировали заметки по кодам и категориям и фиксировали связи между кодами.

На раннем этапе анализа авторы выявили ряд основных категорий:
  • факторы Developer Experience (DX Factors);
  • контекстные характеристики (Contextual characteristics), влияющие на значимость факторов;
  • барьеры (Barriers), препятствующие улучшать Developer Experience;
  • стратегии улучшения (Improvement Strategies) факторов DX;
  • механизмы адаптации (Coping mechanisms) в случаях, когда Developer Experience не улучшается.
На начальном этапе анализа авторы предполагали, что смогут соотнести выявленные факторы с тремя измерениями триады разума, однако это не подтвердилось. Например, одним из факторов, выявленных в исследовании, стало состояние кодовой базы (Codebase health). Этот фактор влияет на то, как разработчики думают о своей работе, но также влияет на их эмоциональное состояние (например, фрустрация или гордость) и мотивацию.

Основным результатом исследования является — DX Framework (приведен на схеме в конце обзора). Центральным элементом в этом фреймворке является Developer Experience, который характеризуется тремя измерениями триады разума (когниция, аффект и конативность) и основан на предыдущих исследованиях (рассмотренных выше). Две другие части DX Framework (левая и правая стороны) были сформированы в результате текущего исследования:
  • В левой части DX Framework представлены две основные категории, выявленные в ходе исследования и связанные с пониманием Developer Experience. Эти категории включают факторы, выявленные в первой части интервью (факторы, которые разработчики называли наиболее значимыми без дополнительных подсказок), а также контекстные характеристики, которые могут определять значимость этих факторов для участников;
  • В правой части DX Framework представлены три основные категории, выявленные в ходе исследования и связанные с улучшением Developer Experience. К ним относятся барьеры, препятствующие улучшению Developer Experience, стратегии его улучшения, а также механизмы адаптации разработчиков в случаях, когда Developer Experience не может быть существенно улучшен.

Факторы, влияющие на Developer Experience (DX Factors)
Авторы стремились определить, какие факторы разработчики считают наиболее значимыми для Developer Experience. Для этого итеративно кодировали ответы на вопрос "какие факторы влияют на ваш опыт" и группировали их по категориям. В результате получился следующий список категорий:
  • Разработка и поставка (Development and release);
  • Управление продуктом (Product management);
  • Взаимодействие и культура (Collaboration and culture);
  • Поток и удовлетворенность разработчика (Developer flow and fulfillment).
Категории, к которым отнесли факторы, в определенной степени обусловлены собственным опытом и знаниями авторов в области разработки программного обеспечения, и возможны альтернативные варианты категоризации. В процессе не проводился количественный подсчет частоты упоминания факторов, поскольку интервью носили открытый характер, и такие подсчеты могли бы вводить в заблуждение. Тем не менее, все представленные факторы были упомянуты как минимум двумя участниками.

Категория Разработка и поставка (Development and release)
Категория включает следующие факторы:
  • Состояние кодовой базы (Codebase health) отражает качество, поддерживаемость и удобство работы с кодом, а также их влияние на Developer Experience. Как отметил участник: "Часть того, что влияет на Developer Experience, — это сама кодовая база. Это сложная проблема. Работа с legacy кодом. Он плохо спроектирован и его сложно понимать. Сильная связанность. Все те вещи, которые делают кодовую базу сложной для работы и изменений. Это действительно важный фактор";
  • Окружение разработки (Development environment). Участник отметил: "Первое, что пришло мне в голову, — это инструменты и любые сложности, связанные с ними: делают ли они путь от идеи до тестирования и продакшена простым или, наоборот, усложняют переход от точки A к точке B". Он также добавил: "На Developer Experience влияет то, как быстро я могу скомпилировать код, насколько быстро работает CI, сколько времени занимает поставка изменений в тестовые или production окружения, насколько надежны мои тесты [...] все, что увеличивает цикл обратной связи". Этот фактор также включает аспекты инженерной инфраструктуры, такие как настройка и конфигурация, а также отладка и мониторинг;
  • Автоматизированное тестирование (Automated testing). Участник отметил: "Недостаточное покрытие тестами, например, сильно усложняет любые изменения. Все, что повышает уверенность, помогает понять происходящее и быть уверенным, что изменения сделаны правильно. Для меня это важный фактор Developer Experience";
  • Беспрепятственные релизы (Frictionless releases). Участник отметил: "Мы тратим много усилий на сокращение Cycle Time и улучшение процессов для Pull Requests, чтобы сократить время, необходимое для поставки изменений и их безопасного развертывания. Все эти аспекты в совокупности позволяют быстрее поставлять программное обеспечение и вносить небольшие, инкрементальные изменения без возникновения проблем".

Категория Управление продуктом (Product management)
Категория включает следующие факторы:
  • Четкие цели, объем работ и требования (Сlear goals, scope and requirements). Все это существенно влияет на Developer Experience. Участник описал, что требуется дополнительное усилие для согласования с другими участниками того, что выполняются правильные задачи, а также необходимость декомпозиции крупных задач на управляемые: "С точки зрения процессов, [Developer Experience] также означает, что четкие цели очень помогают. Если вокруг задач много неопределенности или если это очень крупные и плохо определенные задачи, то возникает ощущение, будто идешь по болоту. Очень сложно продвигаться. И вся работа по прояснению — разбиение задач или снижение неопределенности — не воспринимается как настоящая работа. Для команд разработки это не ощущается как результат, потому что ты не создаешь Pull request, а вместо этого общаешься с множеством людей и пишешь документы, после чего из одной задачи получается пять. И это не воспринимается как достижение, потому что ты не деплоишь и не пишешь код";
  • Итеративный формат работы (Working iteratively). Участник отметил важность итеративной работы небольшими задачами, что многие участники выделяли как фактор Developer Experience;
  • Нереалистичные сроки (Unreasonable deadlines), приводящие к неэффективным компромиссам в планировании, дорожной карте и приоритизации, описывались участниками как источник стресса и фактор, негативно влияющий на Developer Experience. Участник отметил: "Цели и амбиции продуктовой команды понятны, и я вижу, что эти проекты важны, но сроки, в которые их хотят реализовать, не способствуют созданию качественного и устойчивого программного обеспечения. Возникает определенное напряжение". Он также добавил: "Я наблюдал, что проекты с высоким уровнем стресса и жесткими сроками приводят к ухудшению опыта и взаимодействия между инженерами". Влияние нереалистичных сроков на уровень счастья разработчиков также отмечено в исследовании Fagerholm и соавторов.
  • Участие в составлении дорожной карты и приоритетов (Having a say on roadmap/priorities). Участники подчеркивали, что участие в составлении дорожной карты и выборе приоритетов улучшает Developer Experience;
  • Создание ценности для бизнеса (Providing value to the business). Многие участники отмечали, что для них важно приносить ценность бизнесу. Например, участник сказал: "Для меня самое ценное в работе — это то, что я приношу ценность бизнесу. Даже если я нахожу баг, что может быть не самым интересным занятием, если это разблокирует работу бизнеса, я считаю, что сделал что-то полезное в этот день". Предыдущие исследования также показывают, что выполнение значимой работы положительно влияет на производительность и удовлетворенность разработчиков;
  • Неожиданные изменения в развитии продукта (Unforeseen changes in product direction). Участники отмечали, что неожиданные изменения в направлении продукта могут приводить к потере проделанной работы. Как отметил участник: "Худший Developer Experience — это когда у меня есть четкая цель, я заканчиваю или почти заканчиваю задачу, и внезапно оказывается, что все нужно полностью изменить, и приходится начинать с нуля". Участник отметил, что гибкие процессы могут приводить к частой смене требований: "Много работы, которую я делаю, почти сразу заменяется другой работой. Я вижу результаты своей работы, но, возможно, около 30% уходит впустую именно из-за изменения ситуации".

Категория Взаимодействие и культура (Collaboration and culture)
Категория включает следующие факторы:
  • Поддержка коллег (Supportiveness). Разработчики зависят от поддержки коллег и возможности быстро получить помощь, когда они сталкиваются с трудностями. Участник отметил: "Я бы сказал, что один из самых важных факторов — это количество времени, которое более опытные разработчики могут уделить вам. Я заметил, что в дни, когда все заняты [...] и у людей нет времени на меня, уровень моей фрустрации растет экспоненциально. Когда я часами борюсь с проблемой, решение которой кто-то уже знает, но у него нет времени дать мне небольшую подсказку [...] Это, вероятно, главный фактор того, будет ли у меня хороший или плохой день на работе". Влияние поддержки со стороны команды на культуру и производительность также отмечалось в предыдущих исследованиях. Например, Benjamin Schneider и соавторы показали, что позитивные комментарии на встречах улучшают поведение команды, а поддержка новых идей была одним из ключевых факторов, предсказывающих производительность в исследовании Emerson Murphy-Hill и соавторов;
  • Обмен знаниями и ощущения связанности (Knowledge sharing and feeling connected). Участник объяснил: "Есть ощущение связанности с коллегами вокруг, и это помогает, когда у вас есть прямая и мгновенная коммуникация с ними. Это помогает выстраивать связи, что, в свою очередь, улучшает взаимную поддержку в команде. И это очень важно для разработчика, потому что я full stack разработчик и работаю с несколькими системами и языками программирования, и я не могу знать все системы. Поэтому я сильно завишу от информации от коллег. Если у меня есть такая спонтанная связь с ними, гораздо легче получать информацию и понимать, что происходит и что нужно сделать в различных системах";
  • Процесс ревью кода (Code review process). Процесс ревью кода был выделен как отдельный фактор, связанный с обменом знаниями и поддержкой. Участники отмечали, что ревью кода способствует улучшению качества кодовой базы, а также поддерживает обмен знаниями и наставничество. Однако некачественный процесс может негативно влиять на Developer Experience. Например, участники отмечали, что придирки (Nitpicking) или чрезмерно критичный подход к изменениям ухудшают их опыт. Участник подчеркнул, что важен тон обратной связи в процессе ревью. Важность ревью кода для формирования позитивной командной культуры также рассматривается в работе Alberto Bacchelli и соавторов;
  • Взаимодействия между различными подразделениями (Collaboration between departments). Эффективное взаимодействие важно не только внутри команд — почти все участники отмечали значимость взаимодействия между различными подразделениями. Разработчики отдельно выделяли взаимодействие с командами продуктового менеджмента, дизайна и обеспечения качества;
  • Психологическая безопасность (Psychological safety). Ощущение, что можно свободно выражать свое мнение, является важным фактором, влияющим на Developer Experience. Несколько участников отмечали, что открытая культура, в которой менее опытные разработчики могут высказываться, является для них значимой, и что руководство играет ключевую роль в обеспечении психологической безопасности. Per Lenberg и соавторы показали, что психологическая безопасность связана с более высокой самооценкой производительности и удовлетворенности работой. При этом их исследование показывает, что ясность норм является более сильным предиктором, что соотносится с фактором из области управления продуктом — наличием четких целей и ожиданий;
  • Коммуникация (communication) между разработчиками и командами, согласованность ценностей (having aligned values), признание работы (getting recognition) со стороны коллег и руководителей, также относятся к важным факторам. Эти факторы также выявлены в других исследованиях, посвященных удовлетворенности, счастью и производительности разработчиков.
Категория Поток и удовлетворенность разработчика
Категория включает следующие факторы:
  • Автономия (Autonomy). Одним из часто упоминаемых факторов, влияющих на поток (flow), является автономия. Участник отметил: "Насколько у меня есть свобода в принятии технических решений по сравнению с ситуацией, когда кто-то говорит мне, какой подход использовать для решения конкретной задачи". Однако не все разработчики стремятся к полной автономии. Несколько участников подчеркнули, что автономия важна, но должна иметь границы. Например, участник объяснил: "Автономия — это первое, что приходит в голову, но не безграничная. Важно понимать свои границы. Понимать, куда можно двигаться, а куда нельзя. Где безопасно экспериментировать и проявлять креативность [...] Одна из моих текущих проблем — я не понимаю, куда нельзя идти. Я не знаю, что запрещено, а значит, потенциально запрещено все. И это создает ощущение ограниченности";
  • Сложная и стимулирующая работа (Challenging and stimulating work). Участники также говорили о важности оптимально сложной и стимулирующей работы — когда задачи не являются ни скучными, ни чрезмерно сложными. Участник отметил: "Еще одна часть [Developer Experience] — это сама работа. Есть диапазон: от "это просто простая рутинная работа" до середины, где "я изучаю что-то новое, это сложно, но я справляюсь", и до верхнего уровня, где "сделай это, но ты вообще не понимаешь, что делаешь". Важно иметь правильный уровень сложности задач". То, что описывают участники, соответствует концепции Mihaly Csikszentmihalyi, одного из основателей позитивной психологии: состояние потока достигается при балансе между сложностью задачи и уровнем навыков. Поток также рассматривается как важное измерение производительности разработчиков;
  • Возможность продвигаться без препятствий (Making progress without obstacles), наличие достаточного времени для непрерывной работы (Uninterrupted time), баланс между работой и личной жизнью (Work-life balance), возможность учиться в процессе работы (Learning), а стабильность работы и команды (Stability of job and team), наличие понятных возможностей для карьерного роста (Clear paths for career growth), также относятся к факторам в этой категории.
Контекстные характеристики и значимость факторов
Во второй части интервью участников просили объяснить, почему те или иные факторы являются для них значимыми:
  • Проблемные факторы важнее других факторов. Одной из закономерностей является то, что разработчики сильнее воспринимают наличие проблемных факторов (и, соответственно, считают их более значимыми), чем факторы, положительно влияющие на их опыт. Этот эффект известен как асимметрия позитивного и негативного (positive-negative asymmetry) или склонность к негативности (negativity bias), когда негативные события оказывают большее влияние на восприятие и память, чем позитивные;
  • Ожидания определяют значимость. Участники отмечали, что проблемы, которые воспринимаются как нормальные или ожидаемые, вызывают меньшее раздражение, чем те, которые, по их мнению, могли бы быть решены лучше. Например, участник отметил: "Это настолько нормально, что [Continuous Integration] работает медленно, что это уже почти не обсуждается. К тому же это занимает много времени, и у нас есть отдельная команда, которая этим занимается";
  • Уровень опыта (Seniority) влияет на значимость. Более опытные инженеры способны учитывать большее количество факторов (например, процессы релизов или командную культуру), тогда как менее опытные чаще фокусируются на потоке и состоянии кодовой базы. Участник отметил: "Вес этих категорий сильно меняется в зависимости от уровня разработчика. Junior разработчики в первую очередь обращают внимание на кодовую базу и рабочий процесс разработки". Кроме того, от Senior разработчиков чаще ожидается ответственность за определенные факторы, что делает их более значимыми для них;
  • Личные интересы влияют на значимость. Участники отмечали, что личные интересы могут усиливать или снижать значимость факторов. Например, участник сказал: "Некоторые люди настолько оторваны от других аспектов разработки продукта, что это похоже на безразличие. Им не важен продукт и его направление. У них есть задача, которую нужно выполнить, и они не задумываются о развитии продукта или о том, как команда может улучшаться. Они просто делают свою работу";
  • Цели компании влияют на значимость факторов. Цели компании определяют, какие факторы воспринимаются как важные. Например, если компания ориентирована на частые релизы, то связанные с релизами факторы становятся более значимыми из-за повышенных ожиданий. Участник отметил: "Для быстрой поставки все зависит от целей компании. Если компания выпускает релизы три-четыре раза в год, процесс деплоя не требует такой оптимизации, как в компании, которая деплоит каждый день";
  • Зрелость компании определяет значимость. Разработчики отмечали, что уровень зрелости компании влияет на значимость факторов. В более зрелых компаниях выше ожидания к качеству среды разработки и наличию специализированных команд (например, для дизайна или тестирования);
  • Частота проблем усиливает значимость. Наконец, многие участники отмечали связь между частотой возникновения проблем и их значимостью: чем чаще возникает проблема, тем сильнее ее влияние и тем выше ее значимость.

Барьеры для улучшения Developer Experience
Авторы спрашивали разработчиков, что мешает им и их командам улучшать Developer Experience, и обнаружили, что основные барьеры носят организационный, а не технический характер:
  • Низкий приоритет улучшений (Low prioritization). Один из наиболее распространенных барьеров — это недостаточный приоритет улучшений. Улучшение Developer Experience требует выделения времени и ресурсов, однако организации часто отдают приоритет другим задачам. Например, разработчики отмечали, что снижение технического долга рассматривается как менее приоритетная задача по сравнению с поставкой новых функциональностей: "Хотя наш продуктовый менеджер понимает, что технический долг нужно снижать, нам иногда приходится бороться за место в спринте для улучшений из-за давления. Давления со стороны компании, инвесторов, на продуктового менеджера, на продукт — чтобы мы показывали нужные KPI". Аналогично, несколько разработчиков отмечали, что выполнение тестов замедляет их работу, однако улучшение тестирования и тестовой инфраструктуры не является приоритетом для компании.
  • Невозможность количественной оценки проблем (Inability to quantify problems). Многие разработчики отмечали, что отсутствие возможности количественно оценить проблемы мешает обосновывать необходимость улучшений. Участник сказал: "Продукту легко сказать: у нас есть клиенты и потенциальная выручка, но сложно аргументировать инвестиции в улучшение тестирования, потому что нет явных данных, показывающих, что вы теряете, например, 30 часов работы 30 инженеров в неделю из-за тестирования". Участник добавил: "Пока это не отражается в KPI, это не считается важным для компании. [...] Сложно это обосновать".
  • Недостаточная видимость и осведомленность (Lack of visibility/awareness). Помимо отсутствия метрик, разработчики сталкиваются с недостаточной осведомленностью о проблемах как внутри команды, так и среди внешних стейкхолдеров. Некоторые отмечали, что не всегда понятно, сталкиваются ли коллеги с теми же трудностями. Участник отметил: "Я думаю, что часть этого опыта действительно общая. Я обсуждал это с коллегами, и есть вещи, с которыми они согласны. Но мне сложно понять, насколько сильно их это беспокоит". Он также добавил, что коллеги могут обсуждать проблемы неформально, но не поднимают их публично на встречах;
  • Недостаток поддержки со стороны стейкхолдеров (Lack of buy-in). Разработчики часто отмечали, что отсутствие поддержки со стороны заинтересованных сторон мешает улучшениям. Видимость проблем и наличие метрик являются важными инструментами для получения такой поддержки. Кроме того, разработчики подчеркивали важность доверия и делегирования со стороны руководства. Участник отметил: "Хороший менеджмент должен поддерживать такие решения и помогать людям в улучшении кодовой базы";
  • Отсутствие зон ответственности (Lack of ownership). Отсутствие четкой ответственности за проблемные области является существенным барьером. Например, участник описал ситуацию, когда команда сталкивалась с серьезными проблемами в пайплайне релизов, но не могла их улучшить, так как за это отвечала другая команда, и у них не было полномочий вносить изменения. Наличие зон ответственности помогает преодолевать другие барьеры — например, позволяет самостоятельно приоритизировать улучшения и не зависеть от согласования с другими;
  • Неопределенные ожидания (Undefined expectations). Участники часто отмечали, что не воспринимают улучшения как свою ответственность. Участник отметил: "Мое представление о норме — это когда компания публикует вакансию с требованиями и затем ожидается, что вы присоединитесь к команде и будете работать так, как она уже работает, а не добавите нового человека и начнете обсуждать, что можно улучшить. Для меня это выглядит нетипично". Некоторые участники описывали этот барьер как "принятие статус-кво";
  • Отсутствие стимулов (Lack of incentives). Недостаток стимулов или признания может снижать мотивацию к улучшениям. Например, участник говорил о проблемах в процессе ревью кода и связывал это с отсутствием вознаграждения или признания за такую работу. Второй участник рассказал, что вложил значительные усилия в улучшение тестов, однако это не воспринималось как ценная работа, так как от него ожидали выполнение задач Backend разработчика. Третий отметил, что чувствовал недооцененность и отсутствие признания и в итоге перестал выполнять дополнительную работу вне своих обязанностей;
  • Неопределенный процесс (Unclear process). Несколько участников отметили отсутствие процесса для улучшений. Как отметил один из участников: "В моей предыдущей компании процесс был сложным и неэффективным, и никто его не улучшал. Я пытался продвигать изменения и обсуждать эти вопросы, но ничего не происходило. Не было процесса для улучшений";
  • Отсутствие реализуемых решений (No viable solutions). Участники отмечали, что им и их командам иногда сложно находить решения проблем. Например, участник описал, что их пайплайн деплоя был сложным и приводил к значительным потерям производительности, однако у команды не было достаточных навыков и знаний для его улучшения. Разработчики также отмечали, что многие проблемы носят организационный характер и затрагивают несколько команд и подразделений. Дополнительной сложностью является необходимость согласования решений между различными стейкхолдерами. Участник отметил: "Сложно добиться того, чтобы все согласились с одним решением — это почти никогда не происходит";
  • Организационная политика (Organizational politics). Организационная политика и иерархии также часто назывались барьером для улучшений. Junior разработчики отмечали, что их воспринимают как менее опытных, что снижает их способность инициировать изменения — их идеи и проблемы чаще игнорируются. Senior разработчики также сталкиваются с подобными трудностями. Например, участник описал ситуацию, когда смена руководства привела к потере автономии и полномочий, а борьба за влияние и политические войны препятствовали улучшениям.
Анализ показал, что обычно не один, а несколько барьеров одновременно мешают командам улучшать Developer Experience. Например, отсутствие зон ответственности может приводить к тому, что разработчики не поднимают проблему внутри команды, поскольку считают ее нерешаемой. Это, в свою очередь, приводит к отсутствию осведомленности на уровне организации и препятствует улучшениям.

В ходе интервью изучались стратегии, которые разработчики и их команды используют для улучшения Developer Experience. Разработчики описывали как индивидуальные, так и командные стратегии.

Индивидуальные стратегии улучшения Developer Experience
Индивидуальные стратегии направлены на изменение поведения, рабочей среды или деятельности разработчика с целью достижения улучшений.
  • Изменение содержания работы (Job crafting). Одной из распространенных стратегий является активное изменение разработчиками своих обязанностей или задач в ответ на проблемы Developer Experience. Например, разработчик может увидеть, что тесты недостаточны, и начать уделять больше внимания написанию автотестов и их интеграции в процессы релиза и деплоя. При этом разработчик может выходить за рамки своей первоначальной роли. Участник отметил: "Я начал искать способы улучшить наши процессы и системы, создать своего рода защитные механизмы. Мне казалось, что это приносит ценность бизнесу, потому что помогает избежать откатов релизов и снижает количество проблем [...] Я начал заниматься задачами, выходящими за рамки моей зоны ответственности";
  • Принятие рисков (Taking risks). Многие разработчики говорили о том, что они идут на риск ради улучшения Developer Experience, и некоторые упоминали подход "сначала сделать, потом согласовать" (Ask for forgiveness instead of permission). Участник отметил: "Я понимал, что могу влиять на выбор инструментов, которые помогают экономить время и предотвращать ошибки. Но чаще я действовал по принципу "лучше потом извиниться, чем заранее спрашивать разрешение". Потому что, если спрашивать, скорее всего скажут нет. Поэтому нужно просто сделать это в доступное время и потом показать, какую ценность это приносит — хотя это требует дополнительных усилий, которые могут не вознаграждаться";
  • Озвучивание проблем (Speaking up). Стратегия, которую упоминали все участники, — это открытое обозначение проблем. Это происходило на one-on-one встречах, ретроспективах или в неформальном общении. Разработчики либо делали проблемы видимыми, либо предлагали конкретные улучшения. Например, участник отметил: "Я достаточно настойчив. Я начал говорить: раньше у нас не было таких требований, и это приводило к проблемам. И я просто не начинаю задачу, пока у меня нет всей необходимой информации". Другой участник добавил: "На последних ретроспективах [...] все ставили смайлик, отражающий настроение [...] Я поставил тройку и выбрал злое лицо гориллы, тогда как остальные ставили 6, 7 или нейтральные эмоции. Я сделал это намеренно, чтобы обозначить проблему";
  • Локальные улучшения (Local improvements). Разработчики часто концентрируются на локальных изменениях, а не на глобальных проблемах. Например, участник отметил, что взаимодействие с командой дизайна было неэффективным. Не имея возможности изменить процесс на уровне всей компании, он выстроил более эффективное взаимодействие с конкретным дизайнером: "Конечно, хотелось бы глобальных изменений, но я Junior разработчик и у меня ограниченное влияние. Поэтому мы с дизайнером просто начали работать более тесно и выстраивать сотрудничество самостоятельно";
  • Обходные решения (Workarounds). Альтернативой системным улучшениям являются индивидуальные обходные решения. Например, один из разработчиков объяснил, что работа над несколькими задачами одновременно помогает справляться с медленным ревью кода и долгими тестами: "Тесты выполняются очень медленно — от 20 до 40 секунд локально. Плюс длительный процесс ревью кода, который может занимать до двух недель. [...] Поэтому мы работаем параллельно над несколькими задачами — приходится постоянно переключаться".
  • Копирование успешных практик (Mimicking success). Еще один подход — перенимать успешный опыт других. Разработчики отмечали, что наблюдают за более опытными коллегами или сотрудниками с большим стажем, чтобы понять, как эффективно влиять на процессы и реализовывать изменения. Это помогает лучше понимать границы автономии и допустимый уровень риска;
  • Прагматичный подход (Being pragmatic). Прагматичность позволяет делать улучшения достижимыми. Разработчики отмечали, что важно балансировать между стремлением улучшать Developer Experience и целями организации. Это включает учет компромиссов и реалистичный подход к изменениям, позволяющий согласовать интересы разработчиков и бизнеса. Как отметил участник: "Обычно оптимальное решение находится где-то посередине. Важно понимать, сколько времени можно потратить, какие улучшения действительно нужны, а какие — нет. Иногда важно не сделать идеально, а довести до уровня 70–80%".

Командные стратегии улучшения Developer Experience
Командные стратегии направлены на влияние и реализацию изменений с участием других людей внутри команды или организации:
  • Выстраивание взаимодействия (Building bridges). Опытные участники отмечали, что выстраивание взаимодействия является ключевым фактором успешного улучшения Developer Experience. Например, участники описывали, как они целенаправленно выстраивают отношения с другими командами, такими как продуктовый менеджмент или обеспечение качества, чтобы иметь союзников, которые хорошо понимают Developer Experience и существующие проблемы;
  • Обеспечение прозрачности (Creating transparency). Создание прозрачности позволяет разработчикам давать стейкхолдерам и другим командам полное представление о своих проблемах, чтобы получить необходимую поддержку (Buy-in) для изменений. Участник отметил: "Все, что мы делаем и считаем влияющим на Developer Experience, также видно продуктовой команде, потому что это не происходит за закрытыми дверями [...] В итоге не возникает ситуации, когда нужно что-то защищать, потому что они не понимают, что происходит, или продавливать нереалистичные решения, потому что не понятен контекст. Речь идет о формировании общего понимания и доверия: если я говорю, что это важно, продуктовый менеджер отвечает — тогда давайте это сделаем";
  • Убеждение других (Convincing others). Когда для улучшений требуется поддержка команды или руководства, важной стратегией становится убеждение других в значимости проблемы или предлагаемых решений. Помимо убеждения, важно объяснять, как проблемы влияют на качество продукта и производительность разработки;
  • Пошаговые изменения (Making incremental changes). Некоторые проблемы, влияющие на Developer Experience, слишком сложны или масштабны для быстрого решения. Разработчики отмечали, что такие проблемы разбиваются на более мелкие части и решаются постепенно. Например, снижение технического долга часто рассматривается как задача, требующая постепенного улучшения, а не разового решения;
  • Использование метрик и измерений (Having metrics and measurements). Важной стратегией является наличие инструментов для количественной оценки проблем. Метрики помогают не только сделать проблемы видимыми, но и отслеживать прогресс и результаты улучшений. Это снижает риск того, что даже успешные изменения останутся незаметными, а также помогает избежать затрат ресурсов на неэффективные инициативы. Кроме того, метрики позволяют командам анализировать результаты своих действий и совершенствовать подходы к решению задач;
  • Наличие драйвера (Having a driver). Некоторые участники отмечали, что для успешных улучшений необходим драйвер — человек, обладающий необходимыми навыками и влиянием для продвижения изменений. Такие люди пользуются уважением в команде и имеют достаточные связи, чтобы влиять на других участников, от которых зависит успех изменений;
  • Привлечение экспертов (Involving experts). Наконец, участники отмечали, что привлечение экспертов помогает в ситуациях, когда в команде не хватает необходимых знаний или компетенций. Участник Pрассказал, что в их команде не хватало экспертизы в области пайплайнов, и они привлекли инженера, который помог оптимизировать процесс.

Механизмы адаптации
В ходе интервью участники рассказывали, как они справляются с низким уровнем Developer Experience, который не удается существенно улучшить. Эти механизмы адаптации демонстрируют конкретные способы, которыми Developer Experience влияет на производительность, вовлеченность и удержание сотрудников:
  • Фокус на личных проектах (Focusing on personal projects). Один из механизмов адаптации — переключение внимания на личные проекты вместо основной работы. Через сторонние проекты, например участие в Open Source, разработчики компенсируют недостаток удовлетворения от основной работы. Участник отметил: "За последние шесть месяцев, когда было сложно что-то довести до продакшена и возникало ощущение застоя, работа над небольшим проектом вне работы с коллегами, которых я хорошо знаю, помогла мне справиться с синдромом самозванца. Я вижу, что когда работаю с людьми, которых знаю, и над понятными задачами, я могу быть продуктивным и поставлять код".
  • Подтверждение негативного опыта (Validating negative experiences). Еще один распространенный механизм — подтверждение негативного опыта через общение с коллегами. Осознание того, что другие также сталкиваются с теми же проблемами, помогает легче переносить негативный опыт, даже если его невозможно улучшить. Участник отметил: "Во многом это просто подтверждение того, что тебя слышат. На встречах мы не всегда согласны с происходящим, но когда обсуждаем это потом, звучит: я тоже это заметил или я понимаю, о чем ты. [...] Это скорее признание того, что мы видим одно и то же и не согласны с этим, но мало что можем изменить; Некоторые разработчики даже говорили, что сближаются на фоне плохого Developer Experience";
  • Работа сверх нормы (Working overtime). Низкий уровень Developer Experience может приводить к переработкам в попытке улучшить ситуацию. Участники отмечали, что они выполняли задачи параллельно, занимались улучшениями вне рабочего времени, откладывали задачи или делали перерывы между встречами, что приводило к значительному увеличению рабочего дня. Участник отметил: "Это действительно может приводить к тому, что улучшения выполняются вне рабочего времени, что само по себе не является хорошей практикой";
  • Прекращение озвучивания проблем (No longer speaking up). Распространенный механизм адаптации — перестать поднимать проблемы, что является противоположностью стратегии улучшения. Например, участник отметил: "Это стало настолько нормальным, что CI работает медленно, что это уже почти не обсуждается. К тому же это занимает много времени, и у нас есть отдельная команда, которая этим занимается";
  • Снижение вовлеченности (Reducing engagement). Несколько разработчиков описывали ситуацию, когда они переставали вовлекаться. В таких случаях они продолжали выполнять работу, но только минимально необходимый объем задач. Участник отметил: "Качество и общий уровень сервисов снижались по мере роста компании. Я начал задаваться вопросом, почему мы приоритизируем одни проекты вместо улучшения качества [...] Я стал терять доверие к роадмапу и к тому, как принимаются решения. Я пытался поднимать эти вопросы [...] но мои аргументы не принимались. В итоге я стал относиться к работе более цинично и перестал обращать внимание на эти вещи";
  • Манипуляции с системой (Gaming the system). Еще один механизм адаптации — различные способы обхода системы. Например, один из участников рассказал, что сознательно завышал оценки задач на 100-200%, чтобы снизить ожидания со стороны менеджмента и получить время для улучшений, которые приходилось делать вне рабочего времени. Другой участник отметил: "Задача могла занимать один-три дня, но мы специально растягивали ее на неделю и объясняли это разными причинами. Иногда блокеры были формальными — на самом деле я просто замедлялся, чтобы не показывать, что могу работать быстрее, иначе это станет новым ожиданием, и начнут оценивать мою ценность исходя из этого темпа";
  • Уход из компании (Leaving their job). Почти все участники упоминали уход из компании как крайний механизм адаптации в ситуации, когда Developer Experience не улучшается. Участник отметил: "В моей предыдущей компании процессы были перегружены сложностями, и это приводило к неудовлетворенности работой. В итоге я ушел — это была не единственная причина, но одна из них: было сложно что-либо сделать, и не было ощущения, что компания пытается это улучшить".

Применение и развитие фреймворка
DX Framework может применяться через процесс Ask-Plan-Act. DX Framework может служить основой для системного подхода к оценке и улучшению Developer Experience. Для этого предлагается следующий трехшаговый процесс:
  1. Ask: сделать проблемы видимыми. Первый шаг — понять повседневный опыт разработчиков. Поскольку значимость факторов зависит от роли и задач, важно собирать обратную связь от каждого разработчика. Факторы и барьеры из модели могут использоваться как основа для сбора обратной связи через структурированные (например, опросы) и неструктурированные методы (например, ретроспективы, one-on-one встречи);
  2. Plan: планировать улучшения на уровне разработчика, команды и организации. После сбора обратной связи необходимо определить области для улучшения. Для обеспечения изменений рекомендуется назначать ответственных за каждую область. Также важно заранее выделять время и ресурсы на улучшения;
  3. Act: реализовывать непрерывные небольшие улучшения. Эффективнее всего работать итеративно с быстрыми циклами обратной связи. Стратегии из DX Framework, такие как выстраивание взаимодействия, убеждение и обеспечение прозрачности, помогают преодолевать барьеры. Разработчики также могут использовать индивидуальные стратегии для улучшений, не полагаясь только на команды или руководство. Факторы могут использоваться для разработки метрик оценки Developer Experience и отслеживания прогресса. Это делает проблемы и результаты улучшений более видимыми. После реализации изменений процесс повторяется для обеспечения непрерывного улучшения.

Также DX Framework может использоваться для формулирования теоретических предположений о том, какие инициативы могут улучшить Developer Experience. Несмотря на то, что авторы описывают стратегии и механизмы адаптации, выявленные в ходе исследования, они не могут утверждать наличие корреляционных или причинно-следственных связей между элементами модели. Ожидается, что дальнейшие исследования будут развивать фреймворк и формировать теории улучшения Developer Experience, а не только его описания или прогнозирования. Например, исследователи могут изучать такие инициативы, как поощрение разработчиков к более активному обозначению проблем, обучение работе небольшими итерациями, а также использование выявленных факторов для рефлексии над своим опытом. В дальнейшем также важно разработать модели измерения для этих факторов. Например, одни факторы могут лучше предсказывать удержание сотрудников, тогда как другие — вовлеченность разработчиков или качество поставляемого программного обеспечения.
Примерами дальнейшего развития DX Framework являются DX25 Core Model, DevEx Framework и DX Core 4.

Концептуальный фреймворк для понимания и улучшения Developer Experience (DX Framework) представлен ниже:
Если вам интересно исследование и улучшение продуктивности и опыта разработчиков (Developer Productivity, Developer Experience) в вашей компании, обращайтесь к нам за помощью.

Мы помогаем компаниям и руководителям оценивать, измерять и развивать инженерную культуру, процессы и практики, помогаем адаптировать фреймворки (DORA, SPACE, DX, DX25, DevEx, DX Core 4) под контекст, принципы и культуру компании, развиваем внутренние платформы и DX/Enabling команды.

Не забывайте подписываться на наш канал Enabling.team Insights, чтобы быть следить за состоянием в индустрии.