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

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

Я написал:
«На прошлой неделе компания опубликовала статью под названием «Да, вы можете измерить продуктивность разработчиков программного обеспечения». Эта статья вызвала настоящий переполох в сообществе разработчиков ПО. Кент Бек — инженер-программист и создатель экстремального программирования —написал что «Отчет настолько абсурден и наивен, что нет смысла подробно его критиковать».

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

Но что-то было не так. Через несколько часов после публикации этой статьи я уже созванивался с Кентом, поскольку мы пытались определитьточно почему мы оба были разочарованы этим отчетом. Мы почти сразу оказались на одной волне и решили, что можем помочь сообществу разработчиков программного обеспечения, изложив словами то, что мы обсуждали. Ниже приведен наш ответ, написанный мной и Кентом Беком, одним "общим голосом".

Что происходит, когда вы начинаете что-то измерять? Кент Бек проработал в Facebook 7 лет и имеет непосредственный опыт решения подобной ситуации, он поделился:

«В Facebook мы ввели опросы, которые рекомендует McKinsey. Это было хорошо около года. Опросы предоставили ценную информацию о текущем состоянии настроений разработчиков.

Затем люди решили, что они хотят сделать результаты опроса более разборчивыми, чтобы можно было отслеживать тенденции с течением времени. По итогам опроса они подсчитали общий балл. Очень разумный поступок. Это было хорошо еще на один год. 4,5 стало 4. Что случилось?

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

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

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

Ситуация изменилась с «мы хотели бы знать, как идут дела» на «мы знаем еще меньше о том, как идут дела». Но дела определенно идут хуже, потому что люди теперь обманывают систему». Как это произошло?  Ну, потому что мы начали измерять и стимулировать (деньгами и статусом) изменения в показателях!  А измерение приводит к изменению поведения – изменению поведения, включая поиск творческих способов улучшить результаты измерений, даже за счет результатов, которые, по общему мнению, имеют значение.

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

• Kent Beck имеет 40-летний опыт разработки программного обеспечения и почти все это время пытался, терпел неудачу и снова пытался измерить продуктивность разработчиков.

• Gergely Orosz -  имеет 15-летний опыт разработки программного обеспечения, включая 5-летний опыт управления инженерными командами.

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

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

Реальность такова, что руководители разработчиков не могут избежать вопроса о том, как сегодня измерить продуктивность разработчиков. Если они попытаются это сделать, они рискуют, что генеральный директор или финансовый директор вместо этого обратятся к McKinsey, которая принесет свой собственный ферймворк, внедрит его (даже несмотря на протесты технического директора) и начать составлять отчеты по специальным показателям McKinsey, таким как «Индекс скорости разработки» (Developer Velocity Benchmark Index), «Анализ вклада» (Contribution Analysis)  и «Возможности талантов» (Talent Capability).

Мы считаем, что применение такого фреймворка является ошибочным и наверняка приведет к обратным результатам. Фреймворк McKinsey, скорее всего, принесет гораздо больше вреда, чем пользы организациям – и инженерной культуре компаний. На устранение такого ущерба могут уйти годы. Итак, давайте ответим на этот вопрос без уклонений и дадим требовательным генеральным и финансовым директорам то, что они хотят.

Мы охватываем:

1. Ментальная модель цикла разработки программного обеспечения

2. Откуда возникает необходимость измерения производительности?

3. Как продажи и подбор персонала так точно измеряют производительность?

4. Компромиссы измерений в разработке программного обеспечения

И в части 2 , мы завершим эту тему:

• Опасность только измерение результатов (outcomes) и влияния (impact)

• Командная и индивидуальная производительность

• Почему разработка стоит так дорого?

• Как вы решаете, сколько инвестировать в разработку?

• Как вы оцениваете разработчиков?

Для кого эта статья?

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

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

1. Ментальная модель цикла разработки программного обеспечения

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

Мы начинаем с решения, что делать дальше, а затем делаем это. Это усилие например, планирование, написание кода и так далее. Благодаря этим усилиям мы создаем осязаемые вещи, такие как сама функция, код, проектная документация и т. д. выход (output). В результате этих результатов клиенты будут вести себя по-другому, что является нашим результатом (outcome). Например, благодаря этой функции они могут меньше застревать во время процесса онбординга. В результате этого изменения поведения мы увидим, как к нам возвращается ценность в виде отзывов, доходов, рекомендаций. Это влияние.

Итак, давайте обновим нашу ментальную модель следующими терминами:

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

В этой статье мы ссылаемся на эту модель.

2. Откуда возникает необходимость измерения производительности?

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

Кто хочет измерять производительность и почему?

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

№1: технический директор, который хочет определить, каких инженеров уволить.«Как мне измерить продуктивность инженеров в организации, выявить 10% наименее продуктивных и убрать их?»

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

• Определите участников с самыми низкими показателями на основе последних оценок производительности. Этот подход использует исторические данные, которые, вероятно, несколько устарели.

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

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

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

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

№2: Сравнить две инвестиционные возможности.«Как я могу измерить продуктивность команд и выделить дополнительную численность той команде, которая будет наиболее эффективно использовать дополнительную численность?»

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

№3: Для управления производительностью. «Как я могу измерить продуктивность инженеров, чтобы выявить и вознаградить 10% лучших, а также определить четверть худших, чтобы отладить и улучшить их производительность?»

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

№ 4: инженер-программист, который хочет развиваться в своем ремесле. Вопрос мог бы звучать так: «Как я могу измерить свою собственную продуктивность и какие показатели я могу улучшить, чтобы стать лучшим инженером?» Это вопрос, который должны задать себе больше инженеров! Вот два полезных подхода:

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

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

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

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

3. Почему продажи и подбор персонала могут так точно измерять производительность?

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

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

«Цель моей команды на квартал составляла 600 тысяч долларов, а мы выполнили 520 тысяч долларов. Я беру на себя ответственность за промах. Вот причины, по которым это произошло, и вот мой план того, что я меняю, чтобы достичь цели в следующем квартале — 650 тысяч долларов. Кроме того, я реализую инициативу, рассчитанную на два квартала, которая, как я ожидаю, после завершения принесет дополнительные 100 тысяч долларов за каждый квартал. Любые вопросы?'

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

И вот настала очередь инженеров. Боже мой, контраст был разительный. Типичное инженерное обновление выглядело примерно так:

«Итак, в этом квартале мы выпустили функцию A, и мы немного отстаем по миграции технологического долга, а в следующем квартале мы выпустим функцию B и догоним миграцию. Любые вопросы?'

Если у кого-то возникали вопросы о какой-либо задержке, ответ никогда не касался отдельных лиц (как в случае с продажами) и обычно включал такие факторы, как непредвиденные трудности, технологический долг, API; все вещи, которые неинженеры в комнате на самом деле не понимали».

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

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

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

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

А как насчет основного показателя рекрутинговой команды: количества заполненных руководителей? Это также классифицируется как «воздействие»:

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

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

4. Компромиссы в измерениях в разработке программного обеспечения

Одной из популярных схем измерения эффективности команды разработчиков программного обеспечения является фреймворк DORA . Давайте наметим фокус измерения этого фреймворка:

Все показатели DORA измеряют результаты или влияние..

Давайте рассмотрим другой способ измерения продуктивности разработчиков: фреймворк SPACE. Он стремится отразить удовлетворенность, производительность, активность, общение и эффективность (SPACE). Это не только результаты и влияние, как в случае с DORA. В рамках SPACE не описываются определенные показатели, а приводятся примеры. Некоторые показатели сопровождаются предупреждением, например, измерение строк кода. Метрики, о которых предупреждают авторы структуры SPACE, такие как метрика «строк кода», как правило, измеряют усилия или результаты.

Критика системы McKinsey заключается в том, что почти все ее специализированные метрики, которые отличаются от метрик DORA и SPACE, измеряют усилия или выходы:

Что не так с этим подходом? Во-первых, единственные люди, которых волнуют эти показатели, — это люди, которые их собирают. Клиентов это не волнует. Руководителей это не волнует. Инвесторов это не волнует. Во-вторых, и это наиболее важно, сбор и оценка этих показателей препятствует измерению показателей, которые действительно волнуют людей, работающих на последующих этапах, например, рентабельности.

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

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

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

Возникнет ли у вас соблазн испортить бизнес вашей компании, внедрив микроизмерения? Конечно нет!

Мы призываем руководителей инженеров обратить внимание на измерение результатов и влияния, чтобы определить, что именно измерять.Это правда, что возникает соблазн измерить усилия. Но есть причина, по которой команды по продажам и подбору персонала не оцениваются по их работе в офисе ровно в 9 утра или по количеству отправленных электронных писем, которые одновременно являются усилиями или выходом.

Итак, какие результаты и влияние можно измерить для инженерных команд? DORA и SPACE дают несколько советов, а мы предлагаем еще два:

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

• Обеспечение бизнес-эффекта, которого придерживается команда. Есть веская причина, почему «влияние» так распространено в таких быстро развивающихся технологических компаниях, как Meta, Uber и другие. Вознаграждая влияние, бизнес стимулирует инженеров-программистов понимать бизнес и расставлять приоритеты, помогая ему достичь своих целей. Является ли реализация упражнения по экономии затрат на 2 миллиона долларов в год за счет изменения конфигурации менее ценным, чем реализация упражнения по экономии затрат на 500 тысяч долларов в год, которое занимает 5 месяцев разработки? Нет! Вы не хотите сосредотачиваться исключительно на влиянии, но не сосредотачиваться на конечной цели — создании ценности для бизнеса — плохой выбор.

Выводы

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

Мы не думаем, что измерение усилий и результатов обязательно является ответом: поскольку они сопряжены с компромиссами, которые негативно повлияют на инженерную культуру. Как руководители разработчиков: обязательно рассмотрите этот компромисс и то, как он может изменить стимулы разработчиков.

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

Во второй части статьи эта статья расходится с нашим общим голосом на отдельные:

Кент Бек выскажет свое откровенное мнение по этой теме.

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

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

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

Интересный анекдот от Uber: после внедрения дашборда Eng Metrics: строки кода кардинально не изменились, но у CI-систем наблюдался видимый рост использования. По сути, люди начали создавать гораздо больше диффов, что создавало гораздо большую нагрузку на системы непрерывной интеграции (CI) и увеличивало затраты на CI. Таким образом, после измерения результатов последовало изменение поведения, что привело к увеличению усилий по улучшению измеряемых показателей.

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

p.s. вторая часть будет в понедельник, сначала хотел написать сразу две, но оказалось все не так быстро переводится, особенно картинки, решил не ждать.

p.p.s. Еще немного пишу в тг-канал Inspired Product Manager.