[2/2] Measuring Developer Experience With a Longitudinal Survey (Рубрика DevEx)

Продолжая первый пост, расскажу про основные моменты в том, как устроены опросы про developer productivity в Google.

4. Основными фичами программы опросов в Google являются следующие моменты

• Каждый квартал за программу опросов отвечает новая пара: исследователь и инженер. Исследователь отвечает за развитие и эволюцию программы исследований и коммуникации, инженер отвечает за автоматизацию инфраструктуры обработки и анализа данных. Сменяемость этой пары позволяет лучше задокументировать процесс и сделать его безпристрастным и повторяемы
• Процесс проведения опросов четко описан и выстроен в формате пайплайна: определение изменений в опросах, имплементация изменений, верификация, запуск, анализ, подготовка и рассылка отчетов.
• Процесс хорошо автоматизирован и большая часть его проходит без участия человека

5. Такой процесс помог иссследователям получать крутые инсайты, например

• Какое было влияние пандемии COVID-19 на разработчиков в Google. Подробнее про это в моем разборе "Hybrid Productivity"
• Как валидировать другие метрики, например, так ребята изучали поток, фокус и friction при разработке - подробнее про это в моем разборе "Measuring Flow, Focus, and Friction for Developers"
• Как можно драматически улушить метрику, например, техдолг. Подробнее про это в моем разборе "Defining, measuring and managing technical debt" и в выпуске Research Insights Made Simple #2 с обсуждением этого whitepaper

6. Надо заниматься эволюцией опросов во времени, так как они имеют свойство удлиняться и может уменьшаться response rate. Авторы борятся с этим через 2 вещи

• Sampling. Авторы бьют всех инженеров на три когорты, а каждая когорт проходит опросы раз в 3 квартала (условно каждый квартал только треть инженеров отвечает на вопросы). Важно, что группы именно 3, так как это позволяет отвечать им на вопросы в разное время года
• Reporting. Авторы анонимизируют результаты и делают их доступными всем, а также показывают какие решения принимаются на их основе и к каким результатам они приводят. Это мотивирует инженеров их заполнять.

7. Последнее изменение опросов привело к тому, что авторы выкинули сильно специфические вопросы и сконцентрировались на тех, по которым можно принимать решения и отслеживать эффект

To better serve decisions at the company level, we opted for more generalizable questions focused on five outcome measures and four additional theme areas that are drivers of our outcomes Основными outcomes являются: satisfaction, productivity, speed, ease, quality. А темы можно посмотреть в приложенном изображении 8.) Напоследок авторы дают алгоритм с рекомендациями для создания своей программы longitudinal survey

• Establish a clear and unique goal for your survey (ensure that there are no other survey programs or data sources that you can already use).
• Collaborate with domain experts and researchers to develop an effective instrument.
• Gather stakeholder buy-in (for example, communicate the value of survey data and partner with teams that can act on your results).
• If you are planning to run a longitudinal survey, invest time in the beginning in setting up the right infrastructure, process, templates, and documentation.
• Maintain the health of your survey program (control survey length and sample strategically).
• Be transparent and accountable. The quality of your insights depends on the feedback provided by your developers, so make it clear why they should spend their time on it.

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

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes