Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up (Рубрика Management)

Это очередной обзор статьи из серии человеческого подхода к продуктивности разработчиков. Это статья фокусируется на критических аспектах онбординга и наращивания скорости работы инженеров.

Основные моменты этой статьи следующие

1. Вопрос онбординга очень важен - это процесс перехода нового инженера от новичка до продуктивного члена команды. Он важен как для индивидуального успеха, так и общекомандной производительности. Эффективный онбординг может сократить время "разгона" и улучшить долговременную продуктивность
2. Но адаптации инженеров часто мешают стандартные проблемы: недостаточная документация, отсутствие наставничества, неясные ожидания от инженера, а также сложные исходный код проектов. Эти факторы могут задерживать способность разработчика эффективно вносить вклад в работу команды
3. Для оценки качества онбординга надо уметь его измерять. По-факту, это измерение относиться к измерению продуктивности инженеров, но так как нас интересуют только результаты изменений в подходах к онбордингу, то авторы решили мерить не саму продуктивность, а изменения в ней.
4. Предыдущие подходы к ramp-up-time metrics включали сравнение параметров новчиков с опытными инженерами, но авторы этого исследования пошли своим путем, в котором им нужно было избежать сравнения между самими инженерами-новичками (иначе у них появилась бы мотивации геймить метрики и показывать как они здорово онбордятся). В итоге, они решили валидировать метрики-кандидаты относительно восприятия самих инженеров относительно того, насколько они заоонбордились в стандартные инженерные задачи.
5. Авторы исследовали 9 метрик-кандидатов и выбрали для дальнейшего анализа 3, в которых есть прогресс со временем работы и выход на некоторый стабильный уровень. Это метрики

• Active coding time per line of code (LOC)
• Reviewed LOC
• Submitted LOC Дальше авторы аггрегировали новых инженеров по недельным когортам, а потом начали отслеживать сколько недель потребуется этим метрикам, чтобы выйти на стабильный уровень и оставаться там по-крайней мере 4 недели.

6. Потом авторы запустили опросы для инженеров (что работали меньше 40 недель). Этот опрос прошло порядка 3к инженеров. Вопросы были вокруг 17 стандартных задач, навроде, writing code, reviewing other people's code, running build and tests, finding examples of API use by others at Googe и так далее. Вопросы были про опыт вокруг этих задач в последнюю неделю и было 5 вариантов ответов от "Я не выполнял таких задач", до "Я уже выполняю такие задачи на максимально эффективном уровне по моим ожиданиям".
7. Авторы нашли стат значимую негативню корреляцию между "Active coding time per LOC" и самооценкой эффективности выполнения 15 из 17 задач. А 6 из 17 задач стат значимо были связаны с submitted LOC. Авторы взяли и эту метрику в качестве ramp-ut-time.
8. Авторы рассказали про результаты COVID-19 для ramp-up-time, так как у них данные начали собираться еще до всей петрушки.

• Для инженеров до COVID-19 средняя круизная скорость была в 2.5 раза выше, чем начальная. А для выходящих в COVID она стала всего 1.5x
• До COVID 19 инженеры выходили на стабильный submitted LOC за 12 недель, а после - за 18 недель

9. Авторы думают, что смогут использовать результаты исследования для помощи коллегам, которые запускают образовательные инициативы и треннинги для инженеров внутри компании

Авторы предлагают следующие рекомендации для улучшения онбординга

• Предоставляйте исчерпывающую документацию и четкие guidelines.
• Назначайте наставников или «buddies» для помощи новым разработчикам.
• Реализуйте структурированные программы адаптации с определенными этапами.
• Поощряйте обратную связь от новых сотрудников для совершенствования процессов адаптации.
• Инвестируйте в инструменты и системы, которые упрощают навигацию по исходникам и рабочим процессам.

P.S. Разводящий пост с обзорами всех статей из серии доступен здесь.

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