Измерения и данные (Measurements and Data)Для исследования был создан кросс-секционный опрос, основанный на вопросах, ранее валидированных в научной литературе, а также на вопросах, разработанных и уточнявшихся со временем при участии экспертов. Вопросы, которые дорабатывались со временем, создавались совместно с предметными экспертами и совершенствовались на протяжении трех лет.
Этот процесс включал:
- пилотный сбор данных;
- последующую итеративную доработку и анализ вопросов;
- регулярные улучшения на основе экспертной обратной связи и статистического анализа.
Вопросы для каждой исследуемой конструкции (Constructs) приведены ниже:
Состояние потока (Flow State)- У меня есть значительное количество времени для глубокой работы (deep work) в течение рабочего дня.
- В течение типичной недели как часто вас прерывают, чтобы заняться чем-то другим, что не было запланировано или было срочно запрошено?
- Задачи по разработке, над которыми я работаю, скорее вовлекающие, чем скучные.
Циклы обратной связи (Feedback Loops)- Как часто получение ответа на внутренний технический вопрос (например, о коде, системе или предметной области, с которой вы работаете) занимает более 10 минут?
- Какой примерно % ревью кода, которые вы запрашиваете, завершается в течение 4 рабочих часов?
Когнитивная нагрузка (Cognitive Load)- Для основной команды, в которой вы работаете, как бы вы оценили простоту поставки изменений?
- Как часто вы можете легко понимать код, с которым работаете?
- В целом процессы, которым мне необходимо следовать для выполнения работы, легко понять.
- В целом инструменты разработчика, которыми я пользуюсь, являются интуитивно понятными и простыми в использовании.
Результаты для разработчиков (Developer Impacts)- За последний месяц я освоил новые навыки, связанные с моей работой.
- В течение последнего месяца я ощущал себя очень продуктивным.
- В течение последнего месяца я проявлял креативность в своей работе.
Результаты для команд (Team Impacts)- Как бы вы оценили качество кода, с которым работаете?
- Как часто технический долг влияет на вашу способность выполнять новую работу?
Результаты для организаций (Organization Impacts)- Как часто вы ищете работу в других компаниях? (этот вопрос является приватным и доступен только исследовательской команде.)
- Культура моей компании поддерживает инновации.
- Моя организация достигает своих целей.
- Моя организация является прибыльной.
В отчете для вопросов указаны среднее значение (Mean) и стандартное отклонение (SD, standard deviation, в скобках). Для конструкций приведены значения CR (composite reliability, композитная надежность) и AVE (average variance extracted, средняя извлеченная дисперсия).
Сбор данных проводился через опрос, организованный компанией DX, предоставляющей SaaS платформу для измерения Developer Experience. Участниками стали разработчики из компаний, являющихся клиентами DX. Среди этих клиентов разработчики регулярно проходят опросы, посвященные DevEx (далее — регулярный опрос). Сразу после завершения регулярного опроса разработчикам предлагалось принять участие в данном исследовании (исследовательский опрос).
Прохождение обоих опросов было добровольным, однако приглашение к исследовательскому опросу получали только разработчики, завершившие регулярный опрос. Ни один вопрос не дублировался между двумя опросами. В портфеле клиентов DX уровень завершения регулярного опроса превышает 90%, а медианное время его прохождения составляет 10 минут.
За пять недель сбора данных приглашение пройти исследовательский опрос получили 2213 участников, из которых 219 завершили его, что соответствует уровню отклика 9,9%. При этом уровень завершения среди участников, открывших исследовательский опрос, составил 87%. Медианное время прохождения исследовательского опроса составило 2.5 минуты. Поскольку исследовательский опрос проводился после регулярного и был добровольным, низкий уровень отклика мог быть связан с нехваткой времени, что часто характерно для разработчиков в Enterprise компаниях. Среди завершивших опрос 170 человек (77,6%) работали в компаниях, основной бизнес которых связан с технологиями, а 200 человек (91,3%) работали в компаниях с численностью более 500 сотрудников (порог для средних и крупных компаний). Из-за соображений конфиденциальности исследовательская команда не собирала демографические данные участников, такие как пол, возраст или количество лет опыта.
Анализ и результаты модели (Analysis and Model Results)Предложенная исследовательская модель была протестирована с использованием анализа PLS (Partial least squares, метод частичных наименьших квадратов), выбранного по трем причинам:
- хорошо подходит для исследовательского анализа и построения теории;
- PLS не требует предположений о многомерном нормальном распределении данных;
- PLS хорошо работает с выборками малого и среднего размера.
В данном исследовании крупнейшими структурными моделями являются конструкции Developer Experience, каждая из которых содержит три связи с исследуемыми результатами. Таким образом, размер выборки в 219 участников значительно превышает минимально необходимый размер выборки, равный 30.
Анализ проводился с использованием SmartPLS 4. В соответствии с предыдущими исследованиями, использующими методы PLS, анализ модели включал два этапа:
- оценку измерительной модели (Measurement model);
- оценку структурной модели (Structural model).
При тестировании модели авторы включили две контрольные переменные: размер организации и отрасль. На основе типов компаний в выборке эти переменные были сведены к двум бинарным значениям и включены в модель как Dummy переменные:
- размер организации кодировался как small (менее 500 сотрудников) или not-small (500 и более сотрудников);
- отрасль кодировалась как primarily tech или not primarily tech.
Анализ показал, что контрольные переменные не являются статистически значимыми.
Результаты проверки гипотез:
- H1 утверждает, что состояние потока (Flow state) положительно влияет на результаты разработчиков, команд и организаций. Эта гипотеза полностью подтверждена;
- H2 утверждает, что циклы обратной связи (Feedback loops) положительно влияют на результаты разработчиков, команд и организаций. Эта гипотеза подтверждена частично: циклы обратной связи влияют на результаты команд, но не оказывают значимого влияния на результаты разработчиков и организаций;
- H3 утверждает, что когнитивная нагрузка (Cognitive load) положительно влияет на результаты разработчиков, команд и организаций. Эта гипотеза полностью подтверждена.
IPMA: где изменения дают наибольший эффектПоскольку PLS ориентирован на максимизацию предсказательной способности зависимых переменных, этот метод также предоставляет дополнительное понимание факторов, которые могут оказывать непропорционально сильное влияние. Авторы провели анализ IPMA (importance-performance map analysis) для исследовательской модели, чтобы определить факторы, способные дать командам и организациям дополнительные практические инсайты. В общем виде этот анализ выявляет факторы, которые обладают высоким влиянием и высокой результативностью относительно рассматриваемой зависимой переменной.
- Для улучшения результатов разработчиков наибольшим потенциальным влиянием обладают глубокая работа (Deep work) и вовлекающая работа (Engaging work).
- Для улучшения результатов организаций наибольший потенциал влияния имеют несколько факторов: глубокая работа, вовлекающая работа, интуитивно понятные процессы и интуитивно понятные инструменты разработчика;
- Для результатов команд авторы не смогли провести этот анализ из-за особенностей сформировавшейся модели.
Авторы отмечают, что эти результаты основаны на контексте исследования, однако они дают ориентиры, которые могут быть полезны для команд и организаций. Например, если организация стремится улучшить результаты разработчиков, стоит задуматься о создании условий для глубокой работы. Это может включать практики выделенного времени для концентрации отдельных разработчиков, а также согласованного времени фокусировки для команд, например дней с минимальным количеством встреч или полностью без встреч. Также можно искать возможности для создания вовлекающей работы и обучения, например через Hack days.
Анализ показывает, что глубокая и вовлекающая работа оказывают непропорционально сильное влияние на организационные результаты, включая инновации, удержание сотрудников, прибыльность и достижение более широких организационных целей. Интуитивно понятные процессы и инструменты также способствуют достижению этих целей. Организации могут искать способы упрощения и повышения прозрачности процессов, что уже было признано значимым фактором в других исследованиях, а также предоставлять разработчикам интуитивно понятные и удобные инструменты. Предыдущие исследования показали, что неэффективные рабочие процессы являются одной из ключевых проблем для разработчиков, а улучшения процессов и инструментов выступают важным драйвером результатов.
Альтернативные моделиЧтобы рассмотреть результаты в более прикладном контексте, авторы анализируют, каких результатов можно ожидать при внедрении конкретных инициатив DevEx. Ниже представлены статистические результаты, полученные в рамках анализа вероятностей, сгруппированные по трем измерениям DevEx: состояние потока, когнитивная нагрузка и циклы обратной связи.
Состояние потока (Flow State)- Разработчики, у которых выделено значительное количество времени для глубокой работы, ощущают себя на 50% более продуктивными по сравнению с теми, у кого нет специально выделенного времени. Безусловно, разработчикам не всегда просто резервировать временные блоки в календаре, особенно если они работают в командах, распределенных по разным часовым поясам. Однако выделение времени для глубокой работы — это практика, которая приносит значительную отдачу с точки зрения возможности действительно продуктивно работать. Важно поощрять разработчиков и команды выделять время для концентрации, а рабочая среда должна поддерживать эту практику за счет минимизации прерываний;
- Разработчики, считающие свою работу вовлекающей и интересной, ощущают себя на 30% более продуктивными по сравнению с теми, кто считает свою работу скучной. Здесь может помочь пересмотр распределения задач между участниками команды или между командами внутри организации. Не оказываются ли одни и те же разработчики постоянно заняты менее привлекательными проектами и задачами, что со временем может приводить к выгоранию? Не поручаются ли некоторым командам на постоянной основе активности, которые они считают скучными или оторванными от миссии компании и потребностей клиентов?
Когнитивная нагрузка (Cognitive Load)- Разработчики, которые хорошо понимают код, с которым работают, ощущают себя на 42% более продуктивными по сравнению с теми, кто сообщает о низком уровне понимания или его отсутствии. Когда командам необходимо двигаться быстро, и они начинают пренебрегать понятностью, простотой или качественной документацией кода. Иногда это действительно необходимо, однако в долгосрочной перспективе подобный подход может серьезно снижать производительность команды. Инструменты и соглашения, помогающие делать код понятным внутри команд и между командами, способны поддерживать производительность в будущем;
- Разработчики, считающие свои инструменты и рабочие процессы интуитивно понятными и простыми в использовании, ощущают себя на 50% более инновационными по сравнению с теми, кто работает с непрозрачными или сложными для понимания процессами. Неинтуитивные инструменты и процессы становятся как источником потерь времени, так и причиной фрустрации — в обоих случаях они серьезно ограничивают креативность отдельных сотрудников и команд.
Циклы обратной связи (Feedback Loops)- Разработчики, которые отмечают быстрое прохождение ревью кода, ощущают себя на 20% более инновационными по сравнению с разработчиками, сообщающими о медленном прохождении ревью. Быстро завершаемые ревью кода позволяют разработчикам и командам быстрее переходить к следующим идеям, создавая условия для появления новых значимых решений;
- Короткие циклы обратной связи также приводят к еще одному положительному результату. Команды, которые быстро отвечают на вопросы разработчиков, сообщают о снижении технического долга на 50% по сравнению с командами, где ответы предоставляются медленно. Полезно документировать повторяющиеся вопросы разработчиков или внедрять инструменты, позволяющие быстро находить нужные ответы, а также применять качественные практики разработки и готовые решения непосредственно в процессе написания кода, что способствует снижению технического долга.
Как обосновывать инвестиции в Developer ExperienceБольшинство разработчиков понимают, что для выполнения своей работы наилучшим образом им необходим качественный DevEx. Более того, поскольку сегодня огромное количество компаний зависит от программного обеспечения, их способность быть прибыльными напрямую связана со способностью разработчиков работать продуктивно и креативно, а также создавать и поддерживать качественное программное обеспечение с низким уровнем технического долга. Даже способность компании внедрять инновации и сохранять прибыльность зависит от DevEx, потому что если выполнять повседневную работу слишком сложно, то заниматься инновациями тем более будет сложно.
Однако интуитивного понимания важности DevEx не всегда достаточно, чтобы убедительно донести эту идею до руководства. Когда руководство справедливо спрашивает, влияет ли DevEx на бизнес, данное исследование позволяет дать ответ, показывая, что DevEx влияет на результаты отдельных разработчиков, команд и организаций. Более того, анализ ясно показывает, каким факторам необходимо уделять приоритетное внимание, чтобы команды достигали положительных результатов. Эти данные могут служить обоснованием для инициатив DevEx, а также давать практические ориентиры для улучшения Developer Experience.
Авторы приводят пять важных шагов, которые помогут продвигать постоянные улучшения Developer Experience, опираясь на данные.
- Соберите данные о текущем Developer Experience. Необходимо понять, каким является DevEx в вашей организации. Для компаний, только начинающих путь в направлении DevEx, это означает сбор новых данных, позволяющих выявить основные проблемные точки, а также понять текущие возможности организации по внедрению изменений. Для этого можно использовать или адаптировать опрос, применявшийся в данном исследовании, либо использовать SaaS платформы инженерной аналитики, такие как DX. Если вы впервые собираете данные о DevEx, они станут вашей базовой точкой отсчета (Baseline). Если же организация уже занимается инициативами DevEx, эти данные можно интегрировать в существующие показатели и обновить метрики;
- Формируйте цели на основе данных Developer Experience. Используйте данные DevEx для определения целей и направлений инвестиций. Они могут основываться на текущих бизнес приоритетах, данных DevEx и выводах из исследования. Изучив данное исследование, вы видите, что три категории DevEx оказывают значимое влияние, а глубокая и вовлекающая работа обладают особенно сильным эффектом. Это создает хорошую основу для постановки целей. Любой из перечисленных выше факторов может стать отправной точкой для инвестиций;
- Создайте условия для успеха команд. После анализа данных и постановки целей важно использовать существующие в компании механизмы, которые помогут вам и вашим командам добиться успеха. Это может означать постановку командных OKR (Objectives and Key Results) или создание общего OKR с другой командой для формирования совместной ответственности. Коммуницируйте цель своей команде и организации. Регулярно возвращайтесь к ней и отслеживайте прогресс;
- Делитесь прогрессом и подтверждайте ценность инвестиций. Делитесь результатами как с разработчиками, так и с руководителями DevEx и бизнеса, чтобы оценивать и обсуждать ценность сделанных инвестиций. Анализируйте, какие инициативы дали результат, что оказалось неожиданным и какие выводы удалось сделать. Особенно полезно делиться неожиданными результатами, поскольку это подчеркивает ценность работы с данными и способность быстро корректировать направление действий. Периодически переоценивая текущее состояние DevEx и демонстрируя улучшения, вы сможете повышать уверенность в том, что инвестиции действительно приносят результат;
- Повторяйте процесс. Вернитесь к первому шагу и соберите новые данные. При этом анализируйте предыдущий опыт, чтобы обновлять и улучшать подходы к сбору данных и самим инициативам. Следует помнить, что, за исключением исправления ошибок, изменения в подходе к сбору данных обычно должны быть минимальными, чтобы сохранялась возможность сравнения результатов во времени.
Авторы рекомендуют повторять этот процесс сбора данных и постановки целей каждые 3-6 месяцев.