[Перевод] Как спрогнозировать продуктивность разработчиков?28.09.2020 09:32

Компании могут разными способами помочь своим разработчикам добиться максимальной продуктивности: от изменения офисного пространства до приобретения более совершенных инструментов и очистки исходного когда. Но какие решения повлияют сильнее всего? Опираясь на литературу по разработке ПО и промышленной/организационной психологии, мы выявили связанные с продуктивностью факторы и опросили 622 разработчика из трёх компаний. Нас интересовали упомянутые факторы и то, как люди сами оценивают свою продуктивность. Полученные нами результаты предполагают, что на самооценку больше всего влияют нетехнические факторы: энтузиазм в работе, поддержка новых идей вашими коллегами, а также получение полезной обратной связи о вашей продуктивности. По сравнению с другими работниками умственного труда, оценка своей продуктивности разработчиками ПО сильнее зависит от разнообразия задач и возможности работать удалённо.

1. Введение

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

Компании нуждаются в практическим руководстве, какими факторами нужно манипулировать для максимального повышения продуктивности. Например, должен ли разработчик тратить время на поиск более совершенных инструментов и подходов, или ему следует выключать уведомления в течение рабочего дня? Следует ли руководителю вкладываться в рефакторинг для уменьшения сложности кода или дать разработчикам больше автономности в работе? Следует ли начальству вложиться в более совершенный инструментарий разработки или в создание более комфортного офиса? В идеальном мире мы вложились бы в разные факторы повышения продуктивности, но время и деньги ограничены, так что приходится выбирать.

Эта статья посвящена самому широкому на сегодняшний день исследованию прогнозирования продуктивности разработчиков ПО. Как описано в разделе 3.1, продуктивность можно измерить объективно (например, в строках кода за месяц) или субъективно (как её оценивает сам разработчик). Хотя ни один из подходов не является предпочтительным, мы постарались широко охватить эту тему с помощью субъективной оценки, чтобы ответить на три вопроса:

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

Для ответа на первый вопрос мы провели исследование в большой компании, разрабатывающей ПО.

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

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

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

В разделе 2 описаны исследованные нами компании. В разделе 3 описана методология исследования. В разделе 4 описаны и проанализированы полученные результаты. А в разделе 5 описаны другие работы по этой теме.

2. Исследованные компании

2.1. Google

У Google около 40 офисов разработки по всему миру, в которых работают десятки тысяч разработчиков. В компании ценится тесное взаимодействие внутри команд, и офисы обычно имеют открытую планировку, чтобы участники одной команды были ближе друг к другу. Компания относительно молода (основана в конце 1990-х), её организационная структура довольно плоская, у разработчиков большая автономия. Процесс продвижения по службе включает обратную связь от коллег, и для продвижения разработчикам не нужно переходить на управленческие должности. Разработчики сами планируют своё время, их календари отображаются в корпоративной сети. В Google используются гибкие процессы разработки (например, Agile), обычно применяемые ко всей команде.

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

2.2. ABB

У ABB далеко за 100 000 сотрудников по всему миру. Поскольку это инженерный конгломерат, в компании работают представители многочисленных профессий. Здесь около 4000 обычных разработчиков ПО и свыше 10 000 разработчиков приложений, которые создают промышленные системы с помощью характерных для разных отраслей визуальных и текстовых языков. Для эксплуатации своей большой ИТ-инфраструктуры в компании поддерживается значительный штат сотрудников, в чьи обязанности входит скриптовое и упрощённое программирование.

Хотя ABB поглотила ряд более мелких компаний, у неё есть центральная организация, отвечающая за унификацию процессов разработки ПО. Так что, несмотря на различия между департаментами, большинство инструментов и подходов унифицированы. То же самое относится и к большинству этапов карьерного роста: для технарей от младшего до старшего разработчика, а для управленцев — от лидера группы до лидера департамента и центрального руководства.

2.3. National Instruments

Компания National Instruments основана в 1970-х. Создание ПО в основном сосредоточено в четырёх международных центрах исследования и разработки. Календари сотрудников видны всей компании, любой может назначить встречу с любым другим сотрудником.

Служебные обязанности способствуют процессам разработки. Разработчики не могут самостоятельно выбирать проект, но могут браться за конкретные задачи или фичи. Большинство работает с общей монолитной кодовой базой, у её разных логических частей есть конкретные владельцы. Вносимый код должен получить одобрение от «владельца». Желательно, чтобы код анализировался техлидами. Эта политика не обязательна, но многие ей следуют.

У разработчиков много свободы в выборе инструментом. Общих инструментов нет, если только это не даёт немедленного преимущества. Например, выбор IDE сильно зависит от задачи. Есть ряд самописных инструментов для сборки и тестирования. В разных частях компании стандартизированы разные системы управления исходным кодом и его анализа. Обновления ПО обычно релизят поквартально или ежегодно, за исключением редких критических патчей.

Таблица 1. Профили трёх изученных компаний:

3. Методология

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

3.1 Оценка своей продуктивности

Сначала опишем, как мы будем измерять продуктивность. Рамирез (Ramírez) и Нембхард (Nembhard) предложили классификацию методик измерения продуктивности, описанных в литературе, в том числе анализ функциональных точек, самооценку, оценку коллегами, пропорциональность результатов и усилий, а также профессиональное использование времени [2]. Эти методики можно разделить на объективные (например, сколько строк кода написано за неделю) и субъективные измерения (например, самостоятельная оценка или оценка коллегами).

Ни одна методика не является предпочтительной, у обеих категорий есть недостатки. Объективным измерениям не хватает гибкости и игровой составляющей. Возьмём количество строк код в неделю. Продуктивный разработчик может написать однострочное исправление труднонаходимого бага. А непродуктивный разработчик легко может раздуть количество строк. С другой стороны, субъективные измерения могут быть неточными из-за когнитивных предубеждений. Возьмём оценку коллегами: продуктивного разработчика они могут недолюбливать, и поэтому его оценки будут хуже, даже если коллеги будут стремиться к объективности.

Как и коллектив исследователей под руководством Майер (Meyer), которые проанализировали продуктивность разработчиков ПО [3], мы использовали вопросы своего исследования в качестве субъективной оценки продуктивности. Основных причин две. Во-первых, как отметили Рамирез и Нембхард, исследования это «простой и популярный способ измерения продуктивности [работников умственного труда]». Во-вторых, исследования позволяют получить ответы от разработчиков, занимающих разные должности, а также позволяют респондентам добавлять различную информацию в оценку своей продуктивности.

Рис. 1. Методология исследования:

Мы спросили респондентов, насколько они согласны с утверждением:

Я регулярно достигаю высокой продуктивности.

С его помощью мы хотели измерить продуктивность максимально широко. Сначала мы сформулировали восемь вариантов вопроса, а затем свели их к вышеуказанному, неформально поговорив с пятью разработчиками Google об их интерпретации фразы (Рис. 1, внизу слева). В вопрос мы по трём причинам добавили оценочные слова «высоко» и «регулярно». Во-первых, мы хотели зафиксировать состояние, с которым люди могут себя сравнивать. Во-вторых, мы хотели, чтобы это состояние характеризовало высокий уровень, чтобы избежать эффектов достижения потолка в ответах респондентов. В-третьих, мы хотели, чтобы респонденты сосредоточились на двух конкретных мерах продуктивности — интенсивности и частоте. В будущем исследователи могут применять более подробные меры, разделив интенсивность и частоту по двум отдельным вопросам.

Мы проверили получившийся вариант на практике, попросив трёх руководителей в Google разослать его своим командам с вопросом: «Что вы учитывали при ответе на утверждение о продуктивности?». Мы получили ответы от 23 разработчиков (Рис. 1, внизу в центре). Вариант сочли приемлемым для наших целей, потому что соображения респондентов совпали с нашими ожиданиями относительно значения продуктивности. Эти соображения охватывали проблемы с рабочим процессом, результаты работы, пребывание в зоне или в потоке, счастье, достигнутые цели, эффективность программирования, прогресс и минимизацию пустых усилий. В этой работе мы не анализировали эти ответы, однако в исследование включены четыре дополнительные, уточнённые меры продуктивности, взятые из предыдущих работ [2], [4], [5].

Мы выбрали две удобные меры продуктивности, чтобы добавить объективные данные для контекстуализации самооценки, а затем коррелировали их друг с другом в Google. Первой объективной мерой было количество изменённых разработчиком строк кода в неделю — популярная, но непростая оценка продуктивности [6], [7]. Второй мерой было количество сделанных разработчиком изменений в основной кодовой базе Google за единицу времени. Она практически эквивалентна мере пул-реквестов в месяц, которую использовал коллектив под руководством Василешку (Vasilescu) [8]. Для оценки своей продуктивности мы использовали ответы на аналогичное исследование в Google (n = 3344 ответа). Мы не могли использовать для этого анализа данные из нашего исследования, потому что ответы не содержали идентификаторы участников, по которым можно было бы сопоставить объективные меры продуктивности. В том исследовании задавали аналогичный вопрос: «Как часто вы ощущаете, что достигли высокой продуктивности на работе?». Участники могли отвечать «Редко или никогда», «Иногда», «Примерно половину времени», «Большую часть времени» и «Всегда или почти всегда». Затем мы создали линейную регрессию с самооценкой продуктивности в качестве порядковой зависимой переменной (ordinal dependent variable) (закодировав 1, 2, 3, 4 и 5 соответственно). Линейная регрессия подразумевает равное расстояние между рейтингами продуктивности. Учитывая использованные в вопросе слова, мы считаем это предположение оправданным. Для упорядоченной логистической регрессии такого предположения не требуется. Применение здесь этой методики даёт надёжные результаты: одни и те же коэффициенты значимы и в линейной, и в упорядоченной модели.

В качестве независимых переменных мы используем логарифмированные объективные меры, потому что они обе имеют положительную асимметрию (positively skewed). Для контроля мы взяли код работы (например, программный инженер, инженер-исследователь и т.д.) в виде категориальной переменной, а также ранг (junior, middle, senior и т.п.) в виде числа (например, 3 для программного инженера начального уровня в Google). Код работы был статистически значимым для двух рабочих ролей в каждой линейной модели. Всего моделей было три: две с одной из объективных мер и одна с обеими объективными.

Рис. 2: Модели, прогнозирующие субъективную оценку продуктивности на основании двух объективных мер. n.s. означает статистически незначимый фактор с p > 0,05, ** означает p < 0,01, *** означает p < 0,001. Полное описание моделей дано в Дополнительных материалах.

Результаты контекстуализации приведены на рис. 2. Каждая модель демонстрирует статистически значимый уровень с отрицательной оценкой, что мы интерпретировали так: разработчики более высокого ранга склонны оценивать себя немного менее продуктивными. Это сильный аргумент в пользу контроля за рангом (раздел 3.7.). Первые две модели демонстрируют важную позитивную взаимосвязь между объективной и субъективной мерой продуктивности. То есть чем больше написано строк кода или сделано изменений, тем более продуктивным считает себя разработчик. Итоговая объединённая модель и оценки по двум первым моделям позволяют предположить, что количество сделанных изменений является более важным признаком продуктивности, чем количество написанных строк. Но обратите внимание, что во всех моделях параметр R2, представляющий долю объяснённой дисперсии, довольно низок — менее 3% для каждой модели.

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

3.2. Факторы продуктивности

Затем в ходе исследования мы расспросили участников о факторах, которые в других работах считаются связанными с продуктивностью. Мы собрали вопросы из четырёх источников (рис. 1, слева посередине). Эти источники взяты потому, что, насколько нам известно, они представляют собой наиболее полные обзоры отдельных факторов продуктивности исследованиях программистов и других работников умственного труда.

Первый источник — инструмент, созданный коллективом под руководством Палвалин (Palvalin) для обзора мер продуктивности работников умственного труда [4]. Инструмент под названием SmartWoW применялся в четырёх компаниях и охватывает аспекты физического, виртуального и социального рабочего пространства, личных рабочих методик, а также благополучия на работе. Мы изменили некоторые вопросы, чтобы они лучше отражали современную терминологию разработчиков и больше соответствовали американскому английскому. Например, в SmartWoW спрашивается:

I often telework for carrying out tasks that require uninterrupted concentration.

Мы перефразировали:

I often work remotely for carrying out tasks that require uninterrupted concentration.

Из SmartWoW мы сначала подобрали для нашего исследования 38 вопросов.

Второй источник — обзор Хернаусом (Hernaus) и Микуличем (Mikulić) влияния характеристик условий работы на продуктивность работников умственного труда [9]. Их проверенная работа является отражением предыдущих исследований продуктивности: опросника для проектирования рабочей среды [10], диагностического исследования рабочей среды [11], оценки группового сотрудничества [12] оценки «природы задач» [13]. Мы изменили вопросы, чтобы они были краткими и последовательными. С той же целью мы взяли вопросы напрямую из работы [12], которая посвящена рабочим группам с небольшими соображениями о личной продуктивности.

Третий источник — структурированный обзор Вагнера (Wagner) и Руэ (Ruhe) факторов продуктивности в разработке ПО [14]. В отличие от других источников, эта работа не была тщательно проверена научным сообществом и не содержит оригинального эмпирического исследования. Но насколько нам известно, это наиболее полный обзор исследований продуктивности в программировании. Сформулированные Вагнером и Руэ факторы разделены на технические и не поддающиеся количественной оценке, а затем дополнительно выделены факторы окружения, корпоративной культуры, проекта, продукта и среды разработки, возможностей и опыта.

Четвёртый источник — исследование разработчиков Microsoft, проведённое коллективом под руководством Майера (Meyer). Из него мы почерпнули пять главных причин продуктивных рабочих дней, в том числе постановку целей, рабочие встречи и отрывы от работы [15].

Также мы добавили три фактора, которые, по нашему мнению, не были должным образом учтены в предыдущих работах, но которые оказались важны в условиях Google. Один из них — оценка продуктивности работников умственного труда [16], неопубликованный предшественник SmartWoW. Мы адаптировали его так:

Предоставленная мне информация (отчёты об ошибках, пользовательские сценарии и т.д.) точна.

Второй фактор взят из опросника для проектирования рабочей среды и адаптирован так:

Я получаю полезную обратную связь о моей рабочей продуктивности.

И мы создали третий фактор, который был важен в условиях ABB:

Мне требуется прямой доступ к определённому оборудованию для тестирования моего ПО.

Сначала мы подобрали 127 факторов. Чтобы свести их к такому количеству вопросов, на которые респонденты смогут ответить без значительного утомления [17], мы воспользовались критериями, изображёнными в центре рис. 1:

Убрали дубли. Например, в SmartWoW [4] и работе Майер с коллегами [15] важным фактором продуктивности считается постановка целей.
Объединили близкие факторы. Например, Хернаус и Микулич описывают разные аспекты взаимодействия между рабочими группами, повышающие продуктивность, но мы свели их к одному фактору [9].
Предпочтение отдавалась факторам с очевидной полезностью. Например, в SmartWoW [4] есть такой фактор:

У работников есть возможность видеть календари друг друга.

В Google это везде верно и вряд ли изменится, поэтому у фактора низкая полезность.

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

В наше исследование вошли 48 факторов в форме утверждений (рис. 4, левая колонка). Респонденты указывали степень своего согласия с этими утверждениями по пятибалльной шкале, от «Полностью не согласен» до «Полностью согласен». Факторы можно объединить в блоки, относящиеся к методикам, нацеленности, опыту, работе, возможностям, людям, проекту, ПО и контексту. Также мы задавали один открытый вопрос о факторах, которые, по мнению респондентов, мы могли упустить. Полный опросник из нашего исследования приведён в Дополнительных материалах.

Рис. 3: Пример вопроса из исследования.

3.3. Демография

Мы задавали вопросы о нескольких демографических факторах, как показано на рис. 1:

Пол.
Должность.
Ранг.

Авторы предыдущих работ предположили, что пол связан с факторами продуктивности разработчиков ПО, например, с успешностью отладки [18]. Поэтому в исследовании был опциональный вопрос о поле (мужской, женский, отказываюсь отвечать, своё). Респонденты, не ответившие на вопрос, были отнесены к группе «отказываюсь отвечать» (Google n = 26 [6%], ABB n = 4 [3%], National Instruments n = 5 [6%]). Мы обращались с этим данными как с категориальными.

Что касается должности, то стаж работы в Google мы взяли у отдела кадров. С ABB и National Instruments такой возможности не было, так что мы добавили в исследование опциональный вопрос. В ABB при отсутствии ответов (n = 4 [3%]) мы брали 12 лет опыта, это среднее значение по собранным данным. В National Instruments мы по той же причине мы взяли 9 лет (n = 1 [1%]). Можно делать сложнее [19], например, с помощью подстановок прогнозировать отсутствующие значения на основе имеющихся данных. Скажем, отсутствующую информацию о ранге можно достаточно точно заполнить на основе должности и пола. Однако мы подставляли просто среднестатистические значения, поскольку демографические факторы не были для нас первоочередными, они лишь были сопутствующей информацией для контроля. Эти данные мы обрабатывали как числа.

Что касается ранга, то в Google мы просили участников указать их уровень в виде числа. Отсутствующие ответы (n = 26 [6%]) мы относили к наиболее распространённому значению.

В ABB участники могли по желанию указать «младший или «старший разработчик ПО», хотя многие указывали «другую» должность. Если в ответе были слова:

старший
ведущий
менеджер
архитектор
исследователь
основной
учёный

то мы относили такие ответы к «старшим». Остальных относили к «младшим». Отсутствующие ответы (n = 4 [3%]) мы относили к наиболее распространённому значению — «старший».

В National Instruments были варианты:

претендент
штатный
старший
основной архитектор/инженер
главный архитектор/инженер
заслуженный инженер
участник
другое

Единственный «другой» оказался стажёром, которого мы перенесли к «претендентам». Отсутствующие ответы (n = 3 [4%]) мы относили к наиболее распространённому значению — «старший».

Ранги во всех компаниях мы кодировали числами.

3.4. Сравнение с неразработчиками

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

Чтобы ответить на этот вопрос, мы выбрали профессии, сравнимые с разработчиками ПО. Сначала попробовали подбирать на основе должностей в Google. Хотя часть должностей говорила о том, что это работники умственного труда, однако самым распространённым и, по нашему мнению, самым надёжным индикатором подходящего неразработчика было наличие в должности слова «аналитик». Мы решили сравнить аналитиков и разработчиков Google, а не сравнивать аналитиков Google с разработчиками всех трёх компаний. Мы решили, что это позволит нам контролировать характерные для компании особенности (например, если вдруг сотрудники Google статистически более или менее чувствительны к отрыву от работы, чем сотрудники других компаний).

Затем мы адаптировали наше исследование к аналитикам. Убрали вопросы, явно относящиеся к разработке ПО, например, «Требования к моему ПО часто меняются». Другие вопросы мы переделали специально под аналитиков. Например, вместо «Для разработки ПО я использую лучшие инструменты и методики» мы написали «Для выполнения моей работы я использую лучшие инструменты и подходы».

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

3.5. Контрольный вопрос

Чтобы исключить ответы, которые даны необдуманно, примерно через 70% от начала исследования мы вставили вопрос на внимательность [20]: «Ответьте на это «Скорее не согласен». Те бланки, в которых не было такого ответа на этот вопрос, мы не учитывали.

3.6. Доля ответов

В Google мы на основе данных из отдела кадров выбрали 1000 случайных сотрудников, работающих на полную ставку, у которых были должности, относившиеся к разработке ПО. Мы получили от них 436 заполненных бланков, то есть доля ответов составила 44%, это очень высокий показатель для исследований среди разработчиков [21]. После удаления бланков с неправильным ответом на контрольный вопрос (n = 29 [7%]) осталось 407 ответов.

Для опроса работников умственного труда мы выбрали 200 случайных сотрудников Google на полную ставку, в должностях которых было слово «аналитик». Мы решили не исследовать слишком много аналитиков, потому что нашей целью были разработчики ПО. На наши вопросы ответили 94 человека, 47%. После удаления анкет с ошибочным ответом на контрольный вопрос (n = 6 [6%]) осталось 88.

Мы разослали свои анкеты примерно 2200 случайно выбранным разработчикам ПО в ABB и получили 176 ответов. Это 8%, по нижней границе для подобных исследований [21]. После удаления ошибочных анкет (n = 39 [22%]) осталось 137.

Наконец, мы разослали анкеты примерно 350 разработчикам ПО в National Instruments и получили 91 ответ (26%). После удаления ошибочных анкет (n = 13 [14%]) осталось 78.

3.7. Анализ

По каждому фактору в каждой компании мы применили индивидуальные линейные регрессионные модели, используя фактор в качестве независимой переменной (например, «Сроки по моему проекту сжатые»), а оценку своей продуктивности — в качестве зависимой переменной. Мы прогоняли отдельные модели по каждой компании ради сохранения приватности, чтобы исходные данные разных компаний не смешивались. Для уменьшения влияния сопутствующих переменных мы добавили в каждую регрессионную модель имеющиеся демографические переменные. При интерпретации результатов мы сосредоточились на трёх аспектах коэффициента фактора продуктивности:

Оценка. Означает степень влияния каждого фактора при сохранении демографической постоянной. Чем больше значение, тем выше влияние.
Стандартная ошибка. Означает вариативность прогноза. Чем ниже значение, тем меньше вариативность.
Значимость. Также мы проанализировали статистическую значимость при пороговом значении p < 0,05. По каждой компании мы прогнали 48 статистических тестов и могли случайно обнаружить ряд взаимосвязей, поэтому для каждой компании мы скорректировали значения p по методу Бенджамини-Хохберга, созданному для исправления ложного обнаружения [22].

При интерпретации результатов мы сосредоточились больше на степени влияния (оценке) и меньше на статистической значимости, потому что её можно извлечь из достаточно больших наборов данных, даже если практическая значимость низкая. Как мы увидим ниже, статистически значимые результаты чаще всего были получены в Google, с максимальной долей ответов; реже всего — в National Instruments, где доля ответов была ниже. Мы сочли, что это различие по большей части связано со статистической мощность. Призываем вас быть более уверенными в результатах со статистической значимостью.

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

3.8. О причинности

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

Корректность зависит в основном от силы доказательств причинно-следственной связи в предыдущих работах. И эта сила разная для разных факторов. Например, коллектив под руководством Гуццо (Guzzo) провёл мета-анализ 26 статей об оценке и обратной связи, и его результаты прекрасно доказывают, что обратная связь действительно повышает продуктивность на рабочем месте [23]. Однако определение силы доказательств по каждому исследованному фактору требует большой работы, которая выходит за рамки этой статьи.

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

4. Результаты

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

4.1. Факторы продуктивности

На рис. 4 показаны результаты нашего анализа, описанного в разделе 3.7. В первой колонке приведены факторы, которые были предложены участникам в форме утверждений; затем идут метки факторов (F1, F2 и т.д.), которые мы присвоили после завершения анализа. Отсутствие данных означает, что эти факторы характерны для разработчиков и не предлагались аналитикам (например, F10).

Рис. 4: Взаимосвязи между 48 факторами и оценкой своей продуктивности разработчиками и аналитиками в трёх компаниях:

Далее в трёх колонках представлены данные, полученные в трёх компаниях, а также данные по аналитикам Google. Каждая из этих колонок разделена на две подколонки.

Подколонка estimate (оценка) содержит коэффициенты регрессии, количественно определяющие силу ассоциации фактора с оценкой своей продуктивности. Чем больше число, тем сильнее ассоциация. Например, в первой колонке Google estimate равно 0,414. В данном случае это означает, что на каждый пункт усиления согласия с утверждением о энтузиазме в работе (F1) модель прогнозирует увеличение рейтинга продуктивности респондента на 0,414 пункта с контролем демографических переменных. Оценки могут быть и отрицательными. Например, во всех трёх компаниях чем больше текучка кадров в команде (F48), тем ниже оценка своей продуктивности. Рядом с каждым значением оценки находится индикатор, наглядно отражающий величину оценки.

Обратите внимание, что оценки означают не более высокие рейтинги факторов, а более высокую корреляцию между фактором и оценкой своей продуктивности. Например, оценка энтузиазма в работе в National Instruments (F1) выше, чем в других компаниях. Это не означает, что там разработчики испытывают больше энтузиазма: в этой компании он является более сильным фактором прогнозирования оценки своей продуктивности. Мы не приводим сами рейтинги, потому что это запрещено по условиям сотрудничества. Без полного контекста рейтинги могут быть интерпретированы неверно. Например, если мы сообщим, что разработчики в одной компании испытывают меньший энтузиазм в работе, чем разработчики другой компании, у вас может возникнуть впечатление, что в этой другой компании лучше не работать.

Вторая подколонка error (погрешность) содержит стандартные ошибки модели по каждому фактору. Чем ниже значение, тем лучше. Интуитивно кажется, что более низкие значения говорят о том, что при изменении факторов модель надёжнее прогнозирует оценку своей продуктивности. Общие значения погрешностей довольно стабильны от фактора к фактору, особенно в Google с большим количеством респондентов.

Звёздочка (*) говорит о том, что этот фактор был статистически значимым в модели. Например, энтузиазм в работе (F1) статистически значим во всех трёх компаниях, а подготовка ко встречам (F17) значима только в Google.

Следующая колонка содержит среднюю (µ) оценку по всем трём компаниям со стандартным отклонением в скобках (σ). Первый индикатор наглядно показывает величину средней оценки, второй индикатор — величину стандартного отклонения. Например, средняя оценка для энтузиазма в работе (F1) была равна 0,43, стандартное отклонение — 0,051. Таблица отсортирована по средней оценке.

В последней колонке содержатся значения разницы (diff) между оценками для разработчиков ПО и аналитиков в Google. Положительные значения говорят о том, что оценки для разрабо