What Improves Developer Productivity at Google? Code Quality
В 2022 году Google опубликовали внутреннее исследование по продуктивности разработчиков. Если коротко, то основной вывод: лучший способ повысить продуктивность - улучшить качество кода.
Вывод, с одной стороны, выглядит логичным, а с другой - достаточно популистским, на уровне "уберите встречи, давайте четкие задачи, не отвлекайте, давайте только лучшие инструменты и полную свободу действий, а я уж напишу код". Давайте разберемся, что такое продуктивность, качество кода и как вообще проходило исследование и в чем его ключевая фишка.
В Google периодически разработчикам рассылают опрос в стиле "насколько вы удовлетворены" - работой, инструментами, коллегами и тд. Отвечать на них нужно в спектре нет - скорее нет - не знаю - скорее да - да. Каждый разработчик проходит такой опрос раз в 9 месяцев. Также в Google собирают различные данные по работе разработчиков - время на code review, время на влитие изменений, количество написанных строчек кода и тд
В исследовании ищут связь между ответом на вопросом "насколько вы были продуктивны последние 3 месяца" и ответами на другие вопросы (субъективные метрики) и метриками (объективные цифры). Искали корреляцию между ответом на "вы продуктивны?" и 39 метриками. Важное отличие исследования - для выявления связи был выбран метод панельного анализа - это когда вывод делается на основе слежения за одним и тем же человеком какое-то время. Панельный анализ выявил причинно-следственную связь "качество кода" => "продуктивность"
Выглядит хорошо, но следует учитывать, что в данном исследовании качество кода это "удовлетворенность качеством кода", а продуктивность это "ощущаемая продуктивность". Т.е. в целом правильный вывод такой - если разработчики чувствуют, что у них хороший код, то они чувствуют, что у них повышается продуктивность.
Что больше всего влияет на ощущаемую продуктивность (расположено в порядке убывания влияния):
- Удовлетворенность качеством кода 📈(выше - лучше)
- Смена приоритетов 📉 (негативное влияние)
- Тех долг проекта 📉
- Использование новейших тулов и инфры 📈
- Удовлетворенность тулингом и инфрой 📈
- Медленное Code Review 📉
- Сложное изучение инструментария 📉
- Тех долг зависимостей 📉
- Скорость сборки приложения 📈
- Организационные изменения 📉
Также, популярные в среде разработчиков причины снижения продуктивности, связь с которыми не подтвердилась:
- Длительность встреч
- Качество документации
- Физическая или организационная дистанция до менеджера и ревьюеров
По результатам исследования Google решили заняться повышением качества кода:
- Провели несколько внутренних конференций по качеству кода
- Создали модель Technical Debt Maturity Model и фреймворк для управления техническим долгом
- Команды поставили цели в OKR по управлению техническим долгом
- Раздают награды за большой вклад в улучшение качества кода
Какие минусы у исследования:
- Это Google. Многие идеи актуальны только в контексте Google и не подходят другим контекстам
- Мало объективных метрик, но много субъективных. Многие метрики, имхо, странные (физическое расстояние до менеджера). В то же время, нет многих других метрик (ну например, количество, приемочных багов)
- Особенно странно, что целевая метрика - "ощущаемая человеком продуктивность" - тоже субъективная
- Замерялся индивидуальный перформанс, а не командный
- Выводы на основе 2х замеров каждого разработчика. 2х замеров, имхо, мало.
Тем не менее, выводы очень интересные. Если вам нужно будет кому-то доказать, что пора заняться исправлением техдолга, повышением качества кода или улучшением инструментария - можете ссылаться на этот документ (или мой пост 🙃)
В документе есть много интересного - не поленитесь почитать сами.
https://storage.googleapis.com/gweb-research2023-media/pubtools/6862.pdf
#development #research #google #codequality #technicalDebt #productivity
В 2022 году Google опубликовали внутреннее исследование по продуктивности разработчиков. Если коротко, то основной вывод: лучший способ повысить продуктивность - улучшить качество кода.
Вывод, с одной стороны, выглядит логичным, а с другой - достаточно популистским, на уровне "уберите встречи, давайте четкие задачи, не отвлекайте, давайте только лучшие инструменты и полную свободу действий, а я уж напишу код". Давайте разберемся, что такое продуктивность, качество кода и как вообще проходило исследование и в чем его ключевая фишка.
В Google периодически разработчикам рассылают опрос в стиле "насколько вы удовлетворены" - работой, инструментами, коллегами и тд. Отвечать на них нужно в спектре нет - скорее нет - не знаю - скорее да - да. Каждый разработчик проходит такой опрос раз в 9 месяцев. Также в Google собирают различные данные по работе разработчиков - время на code review, время на влитие изменений, количество написанных строчек кода и тд
В исследовании ищут связь между ответом на вопросом "насколько вы были продуктивны последние 3 месяца" и ответами на другие вопросы (субъективные метрики) и метриками (объективные цифры). Искали корреляцию между ответом на "вы продуктивны?" и 39 метриками. Важное отличие исследования - для выявления связи был выбран метод панельного анализа - это когда вывод делается на основе слежения за одним и тем же человеком какое-то время. Панельный анализ выявил причинно-следственную связь "качество кода" => "продуктивность"
Выглядит хорошо, но следует учитывать, что в данном исследовании качество кода это "удовлетворенность качеством кода", а продуктивность это "ощущаемая продуктивность". Т.е. в целом правильный вывод такой - если разработчики чувствуют, что у них хороший код, то они чувствуют, что у них повышается продуктивность.
Что больше всего влияет на ощущаемую продуктивность (расположено в порядке убывания влияния):
- Удовлетворенность качеством кода 📈(выше - лучше)
- Смена приоритетов 📉 (негативное влияние)
- Тех долг проекта 📉
- Использование новейших тулов и инфры 📈
- Удовлетворенность тулингом и инфрой 📈
- Медленное Code Review 📉
- Сложное изучение инструментария 📉
- Тех долг зависимостей 📉
- Скорость сборки приложения 📈
- Организационные изменения 📉
Также, популярные в среде разработчиков причины снижения продуктивности, связь с которыми не подтвердилась:
- Длительность встреч
- Качество документации
- Физическая или организационная дистанция до менеджера и ревьюеров
По результатам исследования Google решили заняться повышением качества кода:
- Провели несколько внутренних конференций по качеству кода
- Создали модель Technical Debt Maturity Model и фреймворк для управления техническим долгом
- Команды поставили цели в OKR по управлению техническим долгом
- Раздают награды за большой вклад в улучшение качества кода
Какие минусы у исследования:
- Это Google. Многие идеи актуальны только в контексте Google и не подходят другим контекстам
- Мало объективных метрик, но много субъективных. Многие метрики, имхо, странные (физическое расстояние до менеджера). В то же время, нет многих других метрик (ну например, количество, приемочных багов)
- Особенно странно, что целевая метрика - "ощущаемая человеком продуктивность" - тоже субъективная
- Замерялся индивидуальный перформанс, а не командный
- Выводы на основе 2х замеров каждого разработчика. 2х замеров, имхо, мало.
Тем не менее, выводы очень интересные. Если вам нужно будет кому-то доказать, что пора заняться исправлением техдолга, повышением качества кода или улучшением инструментария - можете ссылаться на этот документ (или мой пост 🙃)
В документе есть много интересного - не поленитесь почитать сами.
https://storage.googleapis.com/gweb-research2023-media/pubtools/6862.pdf
#development #research #google #codequality #technicalDebt #productivity
👍14❤4