[Перевод] Измерение продуктивности разработчиков. Ответ McKinsey (ч.2)
Это вторая и последняя часть ответа нас двоих Gergely Orosz и Kent Beck (часть 1 тут):
на статью McKinsey «Да, вы можете измерить продуктивность разработчиков программного обеспечения».
Мы считаем, что фрейморк который предлагает McKinsey является ошибочным и наверняка приведет к обратным результатам. Такой фреймворк, скорее всего, принесет гораздо больше вреда, чем пользы организациям — и инженерной культуре в компаниях, и на устранение ущерба могут потребоваться годы.
В части 1 мы рассмотрели:
Ментальная модель цикла разработки программного обеспечения
Откуда возникает необходимость измерения производительности?
Почему продажи и подбор персонала могут так точно измерять производительность?
Компромиссы измерений в разработке программного обеспечения
Теперь мы завершаем эту тему:
Опасность только измерение результатов (outcomes) и влияния (impact)
Командная и индивидуальная производительность
Почему разработка стоит так дорого?
Как вы решаете, сколько инвестировать в разработку?
Как вы оцениваете разработчиков?
1. Опасность только измерение результатов и влияния
До сих пор продажи и подбор персонала находились на своего рода пьедестале подотчетности, поскольку и эффективность работы команды, и индивидуальная эффективность фиксируются с помощью неоспоримых показателей. Однако мы увидели темную сторону сосредоточения внимания только на измерении и вознаграждении результатов и влияния: люди играют с системой ради собственной выгоды способами, которые противоречит цели измерения и в конечном итоге ставят бизнес в невыгодное положение, генерируя ненужные данные.
Ниже Кент рассказывает о том, что он видел, когда единственное, что имеет значение, — это квоты продаж:
«Индивидуальные цели отпугивают людей от совместной работы, поскольку каждый гонится за своей квотой. А это может привести к упущенным возможностям.
Например, воспользуйтесь возможностью провести мегараспродажу, охватывающую несколько регионов. Для этого несколько торговых представителей должны работать вместе, и продажа будет зачислена тому представителю, который обнаружил возможность. Но другие продавцы заинтересованы не помогать. Компания теряет привлекательную перспективу, даже не подозревая об этом. Индивидуальные стимулы могут противоречить долгосрочным целям компании по прибыльности.
Я своими глазами видел, как работает «звездный» продавец. Они всегда выполняли свою норму и получали солидную премию. Как они это делают? Ну, они знали, что продажи могут упасть в любой момент, поэтому у них всегда было несколько потенциальных клиентов «в кармане», которых они могли конвертировать в любое время, и поэтому откладывали их до конца каждого квартала. Они конвертировали их только в том случае, если им нужно было выполнить свою квоту. Чтобы максимизировать личную выгоду, они не максимизировали прибыль компании».
В сфере подбора персонала Gergely испытал на себе, как вознаграждение рекрутеров за закрытых кандидатов может иметь неприятные последствия в дальнейшем:
«Однажды я работал с рекрутером, которым восторгались другие менеджеры по найму. У этого рекрутера показатель закрытия был 100%. Закрытие означает, что, когда кандидат получает предложение, мы добиваемся, чтобы он подписал. В то время моя часть работы в организации была настолько растянута, что рекрутеры проводили большую часть заключительных переговоров и заботились о деталях. Большинство рекрутеров закрывали максимум 70–80%. Мне сказали, что этот рекрутер является «рок-звездой» среди своих коллег.
Я с болью узнал, как они это делали. Примерно через 6 месяцев после ухода этого рекрутера наступило время оценок эффективности и премий. Несколько инженеров из нашей группы жаловались на суммы бонусов, утверждая, что им «гарантировали» в 10 раз большую сумму, чем они получили на самом деле. После небольшого расследования все признаки указывали на рок-звезду рекрутера; он давал инженерам устные обещания в частной обстановке, которые оказались откровенной неправдой.
Этот рекрутер сосредоточился на результатах и проигнорировал несколько неписаных, а также писаных правил. Нам, менеджерам, потребовались месяцы, чтобы разобраться в этом беспорядке, в результате чего инженеры почувствовали себя обманутыми и потеряли веру в компанию».
Измерение результатов и влияния важно, но должны быть сдержки и противовесы, которые гарантируют правильное достижение результатов. В конце концов, именно это и есть здоровая корпоративная культура. Напротив, в «беспощадной» или токсичной культуре имеют значение только легко измеримые результаты и влияние –, а цель всегда оправдывает средства. Более здоровая культура принимает во внимание результаты и влияние и сокращает вознаграждение за результаты, достигнутые непрофессиональными способами или способами, которые не учитывают сотрудничество или более широкий взгляд.
2. Командная и индивидуальная производительность
Что важнее: командная или индивидуальная производительность? Спорт как отрасль, где индивидуальные результаты могут быть измерены достаточно точно, служит ориентиром.
Возьмем, к примеру, футбол. Есть много примеров, доказывающих, что командная производительность превосходит индивидуальную. Команда с объективно худшими игроками может победить соперника с более талантливыми игроками, действуя как команда. Это было убедительно доказано, когда Греция выиграла турнир Евро-2004, в котором ее шансы оцели на 15 месте из 16 принявших участие сборных. В чем секрет этого успеха? В документальном фильме «Король Отто» рассказывается, что все сводилось к командной работе, использованию сильных сторон игроков и выдающемуся немецкому тренеру Отто Рехагелю.
Обычно команды, укомплектованные звездными игроками, с трудом добиваются успеха, несмотря на наличие в них людей с объективно более высокими навыками. Испанская футбольная команда «Реал Мадрид» доказала это своей кадровой политикой «Галактикос» в начале-середине 2000-х годов, когда были подписаны игроки-суперзвезды, но команде регулярно не удавалось выигрывать трофеи.
Мы видим подобную динамику в разработке программного обеспечения: команды, значительно превосходят свой уровень квалификации и опыта, с помощью командной работы, высокого морального духа, и руководителя обладающего правильной интуицией. Я также видел команды, состоящие из инженеров старшего или высшего уровней, которые с трудом достигают ожидаемых результатов, страдают от низкого морального климата, путаницы в направлениях, а также плохого управления и руководства.
Давайте посмотрим на другой вид спорта — хоккей. Здесь используется интересная статистика под названием «плюс-минус», которая измеряет разницу забитых и пропущенных игроком голов, когда он находится на льду. Это своего рода показатель «вклада в успех команды», который полезен для выявления игроков, которые делают команду намного более эффективной.
Можем ли мы найти своего рода индикатор «плюс-минус» для инженеров-программистов? Если бы такой показатель существовал, его, возможно, стоило бы измерить. Однако хоккейный матч пять на пять и проект разработки программного обеспечения, состоящий из 5–10 инженеров, дизайнеров, тестировщиков и специалистов по продукту, сильно отличаются. Хоккейные команды проводят игры еженедельно, есть строгие ограничения по времени; и условия победы предельно ясны: набирайте больше очков. Напротив, программные проекты, как правило, длятся гораздо дольше, могут не иметь ограничений по времени и не имеют простой системы оценки.
Индивидуальные результаты не прогнозируют напрямую результативность команды. И если в такой области, которую так легко измерить, как спорт, невозможно вычесть командную эффективность из индивидуальных результатов, тогда мы можем ожидать еще меньшего успеха в разработке программного обеспечения.
Производительность команды легче измерить, чем индивидуальную. Инженерные команды отслеживают производительность по реализованным проектам, влиянию на бизнес (например, доход, полученная прибыль, сокращение оттока и т. д.) и другим показателям, аналогично тому, как спортивные команды отслеживают производительность по количеству побед, поражений и другим статистическим данным.
3. Почему разработка стоит так дорого?
Вопрос «почему разработка стоит так дорого» будет на удивление частым. Вот предложение о том, как решить этот конкретный вопрос:
Представьте себе мир, в котором компания тратит 0% своего бюджета на разработку. Я знаю: это абсурд. Но сделай это. Что это будет означать для компании? Что испытают клиенты? Как будет развиваться бизнес?
Теперь представьте, что компания тратит 100% на разработку и 0% на все остальное. Что случилось бы?
Теперь, когда мы знаем две крайности: какой процент от общего бюджета компания тратит на разработку? С этим числом: решение заключается в том, что произойдет, если мы уменьшим это число на несколько процентов или увеличим его на несколько процентов. Какой подход принесет больше пользы бизнесу и почему?
Это упражнение превращает вопрос «почему проектирование стоит так дорого» в сравнение, в котором принимается решение о том, следует ли сократить или увеличить затраты на проектирование на X долларов, или сделать эти инвестиции (или сокращение) в другой области.
4. Как вы решаете, сколько инвестировать в разработку?
Еще одна распространенная причина, по которой руководители высшего звена хотят измерить производительность разработки, заключается в том, что они хотят получить представление о том, сколько стоит инвестировать в инженерный отдел, в отличие от того, чтобы направить запланированные инвестиции, скажем, в продажи или маркетинг.
Однако настоящий вопрос, который задает руководитель, касается не производительности. Вопрос в следующем: «Сколько нам следует инвестировать в разработку?»
Чтобы ответить на этот вопрос, учтите, что результаты разработки программного обеспечения непредсказуемы, особенно в небольших масштабах. Конечно: есть отрасли, в которых вы точно знаете, что хотите создать, а разработку — это всего лишь игра на исполнение. Но в компаниях, где инновации в разработке: решение о том, куда инвестировать, больше похоже на то, как нефтяные компании решают, куда и во что инвестировать.
Нефтяные компании не знают наверняка, какую прибыль принесет операция по бурению нефти. Поэтому они делают разумные инвестиции. Невозможно сказать, откроет ли какое-то одно разведочное бурение новое и прибыльное нефтяное месторождение: поэтому они финансируют несколько таких бурений одновременно; ожидая, что некоторые из них в конечном итоге принесут многообещающие результаты. Затем, вооружившись дополнительными данными, принимаются более масштабные инвестиционные решения.
Это прагматичный подход для инженерных руководителей — и руководителей — подходить к инвестированию в разработку программного обеспечения как к исследовательской и опытно-конструкторской деятельности аналогичным образом. Делайте небольшие, но недорогие ставки: и удваивайте ставки на те, которые обещают ощутимые результаты.
5. Как вы оцениваете разработчиков?
В этом разделе наши голоса расходятся. Ниже изложен мой (Gergely) взгляд на этот вопрос. Посмореть Ответ Кента Бека на тот же вопрос в этой статье.
Так как вы измеряете продуктивность разработчиков? Вот фреймворк, которые я предлагаю.
Поймите, в чем реальная потребность.Когда кто-то спрашивает, как измерить продуктивность разработчиков, это неправильный вопрос. Чтобы понять, о чем на самом деле спрашивают, подумайте над следующими вещами: кто спрашивает и какова его настоящая цель? Настоящая цель будет примерно такой:
«Мне нужно решить, в какие области инвестировать больше персонала. Какое распределение принесет бизнесу максимальную отдачу?»
«Я хочу заниматься управлением производительностью и выявлять тех, кто работает с низкими и высокими показателями».
«Я хочу выявить проблемные команды, отладить и исправить их».
«Наши инвесторы хотят, чтобы мы сократили расходы, и мне нужно выяснить, сколько я могу сократить, не оказывая существенного влияния на бизнес».
«Мне нужно обосновать стоимость разработки перед генеральным директором, который считает, что мы слишком затратны.
Переформулируйте вопрос. Будучи руководителем разработки, вы часто будете получать запрос: «Мы хотим измерить продуктивность вашей команды». Вместо того, чтобы идти вперед: сделайте шаг назад.
Вот что Аби Нода (Abi Noda) — сооснователь DX, автор рассылки Engineering Enablement и соавтор статьи Новый способ измерения продуктивности разработчиков -предлагает как это сделать:
«Мой совет руководителям инженеров в этой ситуации: переформулируйте проблему. Генеральный директор хочет знать, что вы хорошо распоряжаетесь его инвестициями в разработку. Вы можете продемонстрировать эффективное управление, предоставив полную картину инженерной деятельности, в том числе:
Влияние на бизнес
Производительность системы (быстры ли наши системы, надежны и т. д.)
И эффективность разработчиков (скорость, простота, качество, удовлетворение)».
Знайте, что люди оптимизируют то, что измеряется. Сотрудники достаточно умны, чтобы знать, что если для их оценки используется какой-то показатель, им следует оптимизировать этот показатель. Это отражено в законе Гудхарта:»Когда показатель становится целью, он перестает быть хорошим показателем».
Если ты измеряешь людей по количеству произведенных гвоздей, тогда ты можешь получить 1000 крошечных гвоздиков
Если ты измеряешь людей по весу произведенных гвоздей, тогда ты можешь получить несколько гигантских гвоздей.
Закон Гудхара
Например, я помню, что произошло, когда команда, использующая Scrum, начала измерять, достигли ли они целей спринта, измеряя их в баллах скорости. Наши PM (product manager) и EM (engineering manager) начали называть команды, достигшие своих целей спринта, «завершившими спринт», а команды, которые этого не сделали, «провалившими спринт». Мы определяли цели спринта в стори поинтах, а не по мере выполнения работы.
Следующее, что я узнал, это то, что один разработчик, явно стремящийся к продвижению по службе, начал завышать оценки задач, а также «прокрадываться» в легковыполнимые задачи, у которых оценка в стори поинтах была выше. На бумаге мы сделали больше стори поинтов.
Я спросил этого разработчика, почему он это делает, на что он ответил, что не хочет, чтобы спринт провалился, поскольку это может выставить его в плохом свете. Конечным результатом стало то, что как команда мы работали гораздо менее сосредоточенно, и казалось, что людей заботят стори поинты, а не создание того, что хотят наши клиенты.
Когда вы проводите открытые измерения, ориентируйтесь на результаты и влияние команды, а не на усилия и выход. Люди поймут, как «обыграть» то, что вы измеряете, и оптимизируются для этого. Вот что происходит, когда вы измеряете каждую из областей:
Измеряете усилия: создаете трудоемкую работу сомнительной ценности.
Измеряете выход: увеличиваете объем выпуска тем, что проще всего сделать. Это может не помочь с результатами или влиянием.
Измеряете результаты: нацеливаете на достижение целей, даже если это означает сокращение пути
Измеряете влияние: получаете творческий подход к достижению этой цели с меньшими усилиями и меньшими затратами.
Однако не игнорируйте усилия и выход, которые производят люди и команды! Вместо того, чтобы измерять их, используйте это для устранения проблем с результатами или влиянием.
Например, если вы измеряете количество созданных строк кода и привязываете к ним поощрения за производительность, инженеры будут оптимизировать это число и увеличивать технический долг. Но если вы измерите результаты и заметите, что инженер почти не выпускает функции, вам захочется посмотреть, какой код он создает, его качество, как он тратит свое время и так далее.
Рекомендации: как рассматривать каждый этап модели усилие/выход/результат/влияния.
Помните, что фреймворки, измеряющие усилия и выход, меняют поведение — и не всегда очевидным образом. Если вы измерите количество пул-реквестов: люди будут создавать меньшие пул-реквесты, ничего больше не меняя. Это желанная вещь? Возможно, так и есть: и если так, то введение этого измерения сформирует инженерную культуру в этом направлении.
Однако будьте внимательны к неожиданным изменениям в поведении. Например, было бы нежелательно, если бы люди сейчас начали разделять пул реквесты, чтобы разделить изменения кода и изменения тестов: просто для того, чтобы увеличить количество своих PR: поскольку этот подход контрпродуктивен.
Проблема с измерениями, сосредоточенными на усилиях и выходе, заключается в том, что они трансформируют инженерную культуру в такую, в которой «запас времени» — свободное время между двумя частями работы — осуждается. В компаниях, которые работают как фабрики, это может не быть проблемой. Но для компаний, где разработка является источником прибыли, а спонтанное взаимодействие между коллегами во время простоя может привести к созданию прототипа и реализации новой идеи, тогда системы измерения усилий и результатов разрушат культуру.
Знайте, что измерения мешают работе системы. Каждая новая вещь, которую вы начинаете измерять, приводит к тому, что инженеры оптимизируют ее, чтобы эта мера выглядела лучше. Чем больше вы измеряете, тем больше вы формируете культуру и то, как работают люди.
Довольно легко увидеть, как высокопроизводительная команда инженеров становится гораздо менее продуктивной, когда руководство начинает измерять вещи, особенно если это усилия и выход.
Помните о рисках каждого измерения. Будьте скептичны, когда консультанты утверждают, что можно измерить без влияние на то, как люди работают. Это никогда не так. Лучшее, что вы можете сделать, — это внести изменения, которые действительно желательны.
Управление высокопроизводительной командой — это комплексный подход. Искать показатели, чтобы получить цифры, показывающие, что команда работает высокоэффективно, — это выдавать желаемое за действительное. На практике можно определить, что у вас высокоэффективная команда:
Влияние команды соответствует ожиданиям или превышает их. Посмотрите на такие показатели воздействия, как полученный доход, вклад в прибыль, снижение затрат или другие показатели, которые связаны с прибыльностью, ростом или другими ключевыми бизнес-показателями.
Инженеры в команде работают эффективно — в том смысле, в котором слово «эффективно» имеет смысл для этой команды.
Лидер (или лидеры) в команде достаточно практичны, чтобы выявлять проблемы с исполнением и оперативно их решать.
Возьмите две команды. Команда А: четко сообщает о своем влиянии и имеет в команде практикующего лидера. Команда Б: имеет причудливые показатели и невмешательство лидера. Я предпочту команду А над командой Б в любое время.
Да, вы можете измерить продуктивность разработчиков, но какой ценой? McKinsey не ошибается, заявляя «продуктивность разработчиков может быть измерена». Однако они избегают вопроса о том, какова стоимость измерений.
Можно измерить влияние инженерного коллектива и инженерной организации. И вам следует это сделать, если вы еще этого не сделали! Например, когда я работал в Uber, у моей команды была вики-страница, на которой мы перечисляли наши текущие и завершенные проекты, а также их влияние, разделенное по кварталам. Вот как это выглядело
Мой подход — улавливать влияние команды инженеров.
Мне показалось любопытным, что относительно немногие команды отражали свое влияние в том формате, в котором это сделала моя команда:, а наличие «точных данных о влиянии» значительно облегчало обсуждение всего: приоритетов, реорганизаций, распределения персонала и так далее.
Приписать это влияние отдельным инженерам тоже можно, но чем более детализированным будет атрибуция, тем сильнее это повлияет на мотивацию, и тем больше вероятность создания организации, поощряющей занятость.
Я предлагаю, если вы измеряете, то начните с влияние. Не индивидуальное влияние, а командное влияние.
И, конечно же, как инженерный лидер: будьте ближе к работе, практикуйте, когда это возможно, и, безусловно, оставайтесь техническими специалистами.
Если влиение не соответствует действительности, засучите рукава и устраните неполадки — для этого нужно посмотреть на усилия и выход. Но не стоит ограничиваться измерением усилий и выход «на всякий случай» — вдруг проблема в результатах или влиянии.
p.s. Еще немного пишу в тг-канал Inspired Product Manager.
