Так-с, как и обещал в пятницу, делаю обзорчик.
Короче, Google снова выкатил вайтпейпер — статью-исследование на базе своих инженерных практик.
На этот раз про измерение Developer Experience.
Что такое Developer Experience?
Как мы помним, DevEx — это, конечно же, про печеньки, сырки и массажные кресла. Ну и зарплату! 🤑
На самом деле — нет.
DevEx — это про:
кайфовые инструменты, с которыми приятно работать;
процессы, которые помогают, а не мешают;
и то самое счастье разработчика, которое мы все ищем, но никак не найдем.
Что делает Google?
У них уникальный кейс: опросы по DevEx они ведут уже более 6 лет. Не просто «отправили анкету», а строят настоящую исследовательскую платформу.
Ключевые идеи из статьи:
1. Оценивайте сценарий, а не инструмент
Разработчик не мыслит: «поднять под».
Он мыслит: «выкатить сборку», «откатить фичу», «найти баг».
Хороший DevEx-опрос спрашивает не «нравится ли тебе Jenkins», а «насколько удобно тебе деплоить хотфикс».
2. Считайте NPS по сценариям
Идея крутая: применяй NPS (оценка 0–10, насколько порекомендуешь) к конкретным инженерным процессам.
Анализируй, где friction. Улучшай. Измеряй снова.
3. Опрос - это часть DevEx-продукта
Опрос - это не ради галочки. Это:
способ тестировать гипотезы;
метод влияния на культуру;
механизм игры в долгую.
4. Нет wow-эффекта → не проводите следующий опрос
Провели опрос - обязательно покажите, что изменилось:
- демо там проведит,
- пост в блоге напишите,
- внутреннюю рассылку намутите.
Вот вы проходили опрос. Мы внесли такие-то изменения. Вот, как стало лучше.
Без этого люди решат, что потратили время впустую.
5. Пульс-опросы раз в квартал
Google бьёт инженеров на 3 когорты и проводит опросы раз в квартал.
Хороший темп, если у вас 500+ инженеров. Почему бы и нет?
6. Команда: инженер + исследователь
Один - поддерживает инфраструктуру, второй - отвечает за вопросы и анализ.
У меня пока такого нет. Есть проджект, который держит опрос. Но под такой рост — модель классная.
7. Добавляешь вопрос - убирай старый
Желание добавить «вот ещё один важный вопросик» бесконечно. Но если вы дадите 50 пунктов — на 31-м люди будут тыкать в потолок. Ладно, не в потолок, а в среднее значение
Лучше меньше, но с фокусом и частотой. И с действием.
8. Не жди - встраивай обратную связь в продукт
Опрос - это отложенная реакция.
А лучше всего: встраивай оценку прямо в flow. После деплоя, после ревью, после CI-ошибки.
Так ты увидишь реальные данные - в моменте.
DevEx Starter Pack
Если ты только начинаешь и хочешь понять, где болит — вот 10 проверенных вопросов:
1. Насколько тебе удобно настроить окружение, чтобы начать новую задачу?
2. Насколько быстро ты получаешь фидбэк после коммита (CI, ревью, тесты)?
3. Насколько удобно тебе выкатывать фичу в прод в текущем процессе?
4. Если что-то ломается на проде, насколько просто найти и устранить причину?
5. Насколько тебе понятно, кто отвечает за нужный тебе компонент или систему?
6. Насколько удобно тебе получать помощь по внутренним тулзам и системам?
7. Насколько просто тебе разобраться в незнакомом коде?
8. Насколько удобно тебе участвовать в код-ревью (и получать его)?
9. Насколько ты можешь работать в фокусе, без постоянных отвлечений?
10. Насколько ты чувствуешь, что можешь влиять на процессы в команде?
DevEx начинается с вопросов. Главное - задавать их правильно.
Народ, а у вас в компании уделяют внимание DevEx?
💯 - дааа, все по кайф
🔥 - я и есть тот, кто делает DevEx
❤️ - помнишь мы планируем разобраться с естественным интеллектом к 27+? Ну там и к DevEx приступим 😁
@badtechproject