Как Google раскрывает и измеряет продуктивность разработчиков

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

Повышение производительности для одной из самых больших статей расходов на разработку программного обеспечения — людей, создающих его, — важнее, чем когда-либо.

Исследование продуктивности разработчиков измеряет способность инженера выполнять определенный объем работы в заданное время. Эта дисциплина изучает не только конечный результат, но и то, что социально-технические факторы влиять на это. Он все больше и больше пытается измерить опыт разработчиковтак как доказано, что DevEx повышает производительность.

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

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

В недавнем эпизоде Подкаст о технических возможностяххозяин Аби Нода интервью Сиера Джаспан и Коллин Грин, которые вместе возглавляют группу по исследованию производительности инженеров в Google. В Google, инженерная производительность через десятки тысяч инженеров сводится к «предоставлению инженерных решений без трения и отличных продуктов».

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

Подготовка: кто в команде

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

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

По словам Джаспана, фон социальных наук обеспечивает необходимый контекст. Анализ журналов — обычная отправная точка для исследования продуктивности разработчиков — дает лишь часть картины. «Он говорит вам, что делают разработчики. Но это не говорит вам, почему они это делают. Это не говорит вам, как они к этому относятся, [or] если то, что они делают, хорошо или плохо. Это не говорит вам, есть ли возможности для улучшения. Это только дает вам число, но вы не можете интерпретировать это число», — сказала она в подкасте. «Если у вас нет больше качественной стороны мира, и вы понимаете поведение и то, как это поведение меняется со временем, в зависимости от того, как вы меняете контекст».

Вот почему команда по исследованию продуктивности наняла своего первого UX-исследователя около пяти лет назад, чтобы помочь разработать более качественные опросы. Затем, объединив специалистов по UX с инженерами, они смогут оптимизировать не только то, что просили, но и когда и как. Например, это объединение позволило проводить выборку опыта, интегрируя опросы в тот момент, когда разработчики запускают сборку. Инженеры могут помочь предоставить как личный опыт, так и технические решения, которые масштабируют исследования UX.

«Прямой доступ к экспертам в предметной области, которые глубоко в этом разбираются и находятся на вершине своей области, является действительно мощным дополнением к этому колчану со стрелами, который представляет собой методы поведенческих исследований», — сказал Грин. «Экспертиза в предметной области, масштабируемость и технические навыки с инженерной стороны в сочетании с широким разнообразием методов исследования поведения и возможностью учета таких вещей, как предвзятость, то, как люди работают, и на что следует обратить внимание в ответах на опросы. или интервью », от социологов объединяются для исследования UX способом, который может быть уникальным для Google. Специалисты по UX обнаружили систематическая ошибка неполучения ответов и инженеры обнаружили ошибки в исходной части, потому что все просто выглядело неправильно.

Продуктивность разработчиков — цель всей организации

Первым клиентом этой команды является собственная команда разработчиков, которая создает инструменты разработчика для всей организации. Цель состоит в том, чтобы помочь им улучшить инструменты инфраструктуры, процессы и передовой опыт.

«Когда они хотят, например, понять, что делает разработчиков продуктивными и что может сделать их более продуктивными, наши данные [and] наше исследование — одно из мест, куда они обращаются, чтобы понять, как это вообще измерить», — сказал Грин.

Группа по исследованию производительности также сотрудничает с другими командами, включая отделы эксплуатации, недвижимости и рабочих мест, корпоративных инженеров, которые создают инструменты для всех сотрудников Google, а не только для инженеров, и другие команды, которые могут влиять на общий опыт разработчиков. И тогда, конечно, уроки продуктивности разработчиков могут принести пользу другим нетехническим командам. До тех пор, пока происходит общение между компаниями.

«Поэтому, когда вы сосредотачиваетесь на производительности инженеров, вы сосредотачиваетесь на большой части населения Google, и поэтому есть большой интерес к тому, что мы находим», — сказал Грин.

Инженерная команда Google также выступает в качестве связующего звена между различными командами разработчиков. Как сказал Джаспан: «Компания действительно большая. Люди занимаются разными видами развития. Люди, создающие инструменты, могут не знать обо всех видах выполняемой работы».

Все это создает то, что Грин называет «игровой площадкой правильно сформированных данных» в сочетании с инженерами, имеющими реальный опыт решения стоящих проблем.

Скорость, простота и качество повышают производительность

Итак, если бы у вас был технический бюджет Google, что бы вы измерили?

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

По словам Джаспана, группа по исследованию производительности разработчиков придерживается философии: не существует единого показателя, который бы определял производительность разработчиков. Отсюда, объяснила она, команда проводит триангуляцию по трем пересекающимся осям:

Например, Грин однажды предложил — иронично подчеркнув, — что самый быстрый способ повысить производительность — это убрать обзоры кода — чему, конечно же, все сопротивлялись, потому что, хотя это увеличило бы скорость и простоту выпуска, это г снизить качество. И исследование команды доказало, что качество кода повышает продуктивность разработчиков.

Что касается скорости, они измеряют журналы, но они также измеряют восприятие инженерами того, насколько быстро, по их мнению, они работают, а также дневниковые исследования и интервью. Джаспан сказал: «Это одновременно использование нескольких показателей, а также обеспечение их проверки друг против друга».

Смешанные методы исследования подтверждают данные

Для более глубокого изучения поведения Google при разработке программного обеспечения команда провела межинструментальное исследование журналов, получение журналов из нескольких инструментов разработчика. Они также провели дневниковое исследование, в котором каждые несколько минут инженеры записывали, что они делали. Они сравнили их, чтобы создать уверенность в журналах данных. Поскольку каждый инженер работает и воспринимает свою работу по-своему, это может стать ситуацией яблок и апельсинов, поэтому они применяют то, что называется межрегиональная надежность для расчета согласия между двумя исследованиями.

«Мы предполагаем, что есть какая-то правда, которую мы не можем наблюдать напрямую, не сидя рядом с разработчиком и, возможно, не беспокоя его», — сказал Грин. «Итак, мы берем эти два источника и говорим: эти две линзы говорят нам об одном и том же мире?»

Исследование журналов данных может выполняться в масштабе пассивно, вообще не беспокоя инженеров, в то время как дневниковые исследования могут выполняться не более чем 50 инженерами одновременно — и это может стать раздражающим.

«Как только мы найдем убедительные доказательства того, что мы получаем одинаковую информацию из двух источников, мы можем использовать масштабируемый метод», — пояснил он.

Технический долг и исследование удовлетворенности инженеров

С 2018 года еще одним мощным инструментом измерения в Google является ежеквартальное исследование удовлетворенности инженеров, в котором одновременно принимает участие примерно треть инженеров. Грин признал, что руководители поначалу умалчивали об этом показателе, потому что это «всего лишь мнение людей». Во время изоляции от пандемии в 2020 году опрос сначала выявил всплеск производительности, за которым последовал большой спад в следующем квартале, поскольку время, проведенное дома в одиночестве, продолжалось.

Доказано, что технический долг негативно влияет на моральный дух разработчикова также снижает скорость разработки, поэтому неудивительно, что вначале в опросе было два вопроса: Влияние технического долга на производительность:

• Каковы основные причины технического долга, с которыми вы сталкиваетесь?
• Какие меры по устранению этого технического долга были бы уместны?

На протяжении многих лет команда Джаспана и Грина объединяла ответы, пока не остановилась на 10 категориях технического долга, который мог препятствовать производительности инженеров:

• Миграция необходима или выполняется.
• Документацию по проекту и/или API трудно найти, она отсутствует или неполна.
• Плохое качество теста или покрытие.
• Качество кода плохо продумано.
• Мертвый и/или заброшенный код не был удален.
• Кодовая база деградировала или не поспевает за меняющимися стандартами.
• Команде не хватает необходимой экспертизы.
• Зависимости нестабильны, быстро меняются или вызывают откат.
• Миграция была выполнена плохо или прекращена, что могло привести к сохранению двух версий.
• Процесс выпуска необходимо обновить, перенести или поддерживать.

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

Бумага об этом вопрос по техническому долгу признает, что показатели, основанные на опросах, являются запаздывающим индикатором — это становится реальной проблемой только тогда, когда технический долг становится достаточно серьезным, чтобы мешать инженерам. Однако, изучив 117 метрик, команде Google еще предстоит определить и предсказать, когда технический долг вскоре снизит производительность.

Они также добавили четыре вопроса о том, как команды управляют долгом, поскольку они стремятся к постоянному совершенствованию.

По мере того, как этот опрос становился все более важным для организации в целом, вице-президенты по инженерным вопросам начали задавать свои вопросы. Какое-то время это было полезно, но затем опрос пришлось снова упорядочить. Теперь каждый квартал за опрос отвечает другой UX-исследователь при поддержке другого инженера, а также обратной связи с командой. Грин признал, что опрос все еще довольно «тяжелый».

Независимо от размера (и бюджета) вашей организации, вам рекомендуется инвестировать в сочетание автоматизированных и измеримых, наблюдательных и экспериментальных исследований, чтобы понять ваш опыт разработки и продуктивность, которую он поддерживает или снижает.

Просто помните, что метрики будут меняться по мере изменения вашей команды и вашего кода. Как сказал Джаспан: «Мы знаем, что не существует единого показателя производительности разработчиков, поэтому мы пытаемся использовать все эти различные методы исследования, чтобы увидеть: все ли они согласованы? Они говорят нам, что происходит то же самое? Или они неправильно подобраны? В этом случае нам нужно копнуть глубже, чтобы понять, что происходит».