Мы продолжаем знакомить читателей со сложной, но интересной и актуальной темой измерения производительности разработчиков ПО, раскрытой экспертами Кентом Беком и Гергелием Орошем в цикле их статей. (читать часть 1)
2. Откуда берется потребность в измерении производительности?
Прежде чем ответить на вопрос, как измерять, давайте начнем с более важного вопроса:
Кто и зачем хочет измерять производительность?
Это очень важный вопрос, с которого следует начать. Ответ на него будет кардинально отличаться в зависимости от того, кто задает вопрос и какова его цель. Вот несколько распространенных примеров:
#1: Технический директор, который хочет определить, каких инженеров следует уволить. “Как я могу измерить производительность инженеров в организации, чтобы определить наименее продуктивные 10% и уволить их?”
К сожалению, этот случай часто является актуальным в технологической отрасли. Вот несколько способов отреагировать на него:
– Выявить самых низкоэффективных сотрудников, основываясь на последних результатах аттестации. При таком подходе используются исторические данные, которые, скорее всего, несколько устарели.
– Принимать решения на основе стажа работы и увольнять по методу “последний пришел – первый ушел”. В этом случае не используются данные о результатах работы, а просто предполагается, что уход недавно пришедших сотрудников будет меньше влиять на производительность.
– Принять решение на основе нескольких легко измеряемых показателей, таких как количество запросов на исправление, количество закрытых тикетов и т.д. В основном, решение принимается по усилиям и выходам.
– Попросите менеджеров определить количество инженеров, которых необходимо уволить. Такой подход позволяет использовать динамику коллектива и такую не поддающуюся количественной оценке информацию, как знание менеджером того, кто из инженеров вот-вот подаст заявление об уходе, что не учитывается количественными показателями.
Увольнения влияют на динамику коллектива, и любой подход, не учитывающий этого фактора, скорее всего, приведет к не лучшим результатам. В то же время увольнение часто сопряжено с ограничениями, например, высшее руководство не желает вовлекать в процесс линейных менеджеров. В результате решения часто принимаются на основе заведомо неверных показателей.
#2: Сравнение двух инвестиционных возможностей. “Как я могу измерить продуктивность команд и выделить дополнительный персонал той команде, которая будет наиболее эффективно использовать дополнительную численность?”
Чтобы ответить на этот вопрос, необходимо сравнить отдачу от инвестиций. Речь идет не о производительности, а о том, как влияет выделение дополнительных сотрудников в ту или иную команду.
#3: Для управления производительностью. “Как я могу измерить производительность инженеров, чтобы выявить и поощрить 10% лучших, а также определить четверть отстающих, чтобы отладить и улучшить их работу?”
Существует множество способов измерения производительности, и делать это с помощью метрик вполне возможно, хотя и чревато ошибками. Практикующий менеджер может сразу же назвать самых низко- и самых высокопродуктивных исполнителей, а затем изучить и отладить результаты их работы, более внимательно присмотреться к тому, как инженеры выполняют свою работу (к их усилиям). Стандартным способом для этого является калибровка производительности.
#4: Инженер-программист, желающий развиваться в своем деле. Вопрос может звучать следующим образом: “Как я могу измерить свою производительность и какие показатели я могу улучшить, чтобы стать лучшим инженером?”. Этот вопрос должны задавать себе все инженеры! Вот два полезных подхода:
– При использовании разработки, управляемой тестами (TDD), старайтесь одновременно проводить только один “красный” тест. Такой подход позволяет измерить как усилия, так и выход. Добейтесь того, чтобы уверенно, сознательно и последовательно получать один “красный” тест, когда ожидается один “красный” тест.
– Поставьте перед собой цель ежедневно сливать запрос на вытягивание и отслеживайте выполнение этой цели в течение недели. Этот показатель включает в себя как усилия, так и результат. Эта цель заставит вас делать меньшие коммиты, которые легче просматривать и быстрее подписывать. Кроме того, это подтолкнет вас к написанию корректного кода, соответствующего стандартам команды.
Если вы будете отслеживать эти “показатели” и работать над их улучшением, то почти наверняка повысите свою эффективность как инженера-программиста.
Но что произойдет, если вы покажете эти показатели своему руководителю и по ним будут оценивать вашу работу? Это будет катастрофа: вас будут оценивать не по результатам или влиянию, а по выходам. Когда вы экспериментируете с подходами – например, изучаете новый язык, чтобы помочь команде, нуждающейся в помощи, – ваша производительность может упасть, даже если вы помогаете команде достичь лучшего результата!
3. Почему продажи и подбор персонала могут так точно измерять производительность?
Как представители отрасли разработки программного обеспечения, мы должны коллективно признать, что мы гораздо хуже справляемся с измерением производительности на индивидуальном уровне, чем другие функции. Возьмем для примера отдел продаж. Вот рассказ Кента Бека об уровне подотчетности, который был использован отделом продаж, на совещании руководителей отдела продаж и инженерной службы в одной из его прошлых компаний:
“Я отчетливо помню это совещание, на котором инженерное руководство и руководство отдела продаж отчитывались о проделанной работе. Каждый представитель отдела продаж выступал и давал информацию, которая выглядела примерно
так:‘Целевой показатель моей команды на квартал составлял $600 тысяч, а мы получили $520 тысяч. Я беру на себя ответственность за промах. Вот причины, по которым это произошло, и вот мой план того, что я изменю, чтобы в следующем квартале достичь цели в $650 тыс. Кроме того, вот инициатива, которую я реализую в течение двух кварталов и которая, как я ожидаю, после завершения принесет дополнительные $100 тыс. в каждом квартале. Есть вопросы?
Если у кого-то возникали вопросы, руководитель отдела продаж подробно рассказывал о том, какие торговые представители превышают квоту, а какие – нет, и на сколько, причем делал это так, чтобы всем присутствующим было понятно.
А затем настала очередь инженеров. Боже мой, контраст был разительным. Типичный отчет инженера выглядел примерно так:
“Итак, в этом квартале мы отгрузили фичу А, немного отстаем от графика миграции технического долга, а в следующем квартале отгрузим фичу Б и наверстаем миграцию. Есть вопросы?
Если у кого-то возникали вопросы по поводу задержки, ответ никогда не касался конкретных лиц – как в случае с продажами – и обычно включал такие факторы, как непредвиденные трудности, технический долг, API; все то, что не-инженеры в комнате не очень понимали”.
Уровень подотчетности, с которым работают отделы продаж и поддержки заказчиков, находится на совершенно ином уровне, чем тот, который генеральный директор наблюдает у отдела разработки. Но когда генеральный директор рассматривает общие затраты по отделам, то, вероятно, инженерный отдел обходится дороже отдела продаж!
Не только отдел продаж демонстрирует более высокий уровень подотчетности. Команды по подбору персонала аналогичным образом имеют целевые показатели по “заполненным вакансиям”. Команда рекрутеров может без колебаний ответить на вопрос, какой процент целевых показателей выполнен, сколько еще рекрутеров им необходимо для достижения агрессивных целей найма, а также определить лучших и худших рекрутеров, основываясь исключительно на метриках.
Давайте поставим себя на место генерального директора. В отделе продаж есть способы четкого измерения производительности, как и в отделе подбора персонала. Так почему же не в сфере инжиниринга?
Давайте вернемся к нашей мысленной модели “усилия-выход-результат-влияние”, описывающей работу программной инженерии. Мы можем применить эту модель к продажам и подбору персонала. Отдел продаж оценивает себя по количеству заключенных сделок, так где же в модели находится эта метрика? Она попадает в раздел “результат” или “влияние”.
А как насчет главного показателя команды по подбору персонала – количества заполненных вакансий? Он тоже относится к категории “влияние”.
Мы можем повторить это упражнение и для других функций с возможностью высокой степени контроля их работы. Например, работу службы поддержки можно оценивать по количеству закрытых заявок (результат), по времени, затраченному на закрытие заявки (также результат), и по показателям удовлетворенности заказчиков (влияние).
Ни Кент, ни Гергелий не видели команд в технологических компаниях, которые не измерялись бы по результатам и воздействию. Для того чтобы сделать программную инженерию более подотчетной, нам необходимо разобраться с тем, как это сделать.
4. Компромиссы в области измерений в программной инженерии
Одной из популярных схем измерения эффективности работы команды разработчиков программного обеспечения является схема DORA. Давайте определим, на что направлены измерения в рамках этой системы:
Все метрики DORA измеряют результаты или влияние.
Рассмотрим другой способ измерения продуктивности разработчиков – систему SPACE. Она направлена на измерение удовлетворенности (satisfaction), производительности (performance), активности (activity), коммуникации (communication) и эффективности (efficiency) – SPACE. Это не только результаты и влияние, как в случае с DORA. Рамки SPACE не содержат конкретных метрик, но приводят их примеры. Некоторые метрики сопровождаются предупреждением, такие как измерение количества строк кода. Метрики, о которых авторы концепции SPACE предупреждают, например, метрика “строк кода”, обычно измеряют усилия или выходы.
Одно из замечаний к системе от консалтинговой компании McKinsey, послужившей поводом к разбору данной темы, заключается в том, что почти каждая из ее пользовательских метрик, отличающихся от метрик DORA и SPACE, измеряет усилия или результат:
Что не так с этим подходом? Во-первых, эти показатели волнуют только тех, кто их собирает. Заказчикам это безразлично. Руководителям это безразлично. Инвесторам это безразлично. Во-вторых, что особенно важно, сбор и оценка этих показателей мешают тем показателям, которые действительно волнуют нижестоящие уровни, – например прибыльности.
Почему в этом подходе добавлены способы измерения усилий? Одна из причин заключается в том, что это самая простая вещь, которую можно измерить! Но подход игнорирует важную истину: сам акт измерения изменяет работу разработчиков, поскольку они пытаются “играть” с системой.
Чем раньше в цикле вы проводите измерения, тем легче их проводить. И тем больше вероятность возникновения непредвиденных последствий. Возьмем крайний вариант – измерение только прибыли. Хорошая новость заключается в том, что все в компании согласованы! Плохая новость: определить, кто и сколько внес в прибыль, практически невозможно! Вы можете “решить” проблему распределения, измеряя выходы, или усилия. Но это будет стоить того, что вы измените поведение людей, поскольку это будет стимулировать их к игре с системой, чтобы “набрать” больше баллов по этим показателям:
Рассмотрим пример компании, которая является достаточно прибыльной и находится в верхнем квартиле по отрасли. Руководству компании не нравится, что оно не может оценить вклад отдельных сотрудников в прибыльность.
Возникнет ли у вас соблазн испортить бизнес своей компании, внедрив микроизмерения? Ни в коем случае!
Мы призываем руководителей инженерных подразделений обратиться к измерениям результатов и влияния, чтобы определить, что измерять. Действительно, заманчиво измерять усилия. Но не зря же отделы продаж и подбора персонала оцениваются не по тому, как они работают, находясь в офисе ровно в 9 утра, и не по количеству отправленных электронных писем – это тоже усилия или выходы.
Так какие же результаты и влияние могут быть измерены для инженерных команд? DORA и SPACE дают несколько рекомендаций, а мы предлагаем еще две:
- Создание как минимум одного объекта, ориентированного на заказчика, командой в неделю. Этот выход может показаться не таким уж впечатляющим, но на практике его очень трудно достичь. Однако наиболее продуктивные команды – и проворные компании – могут добиться этого. Если задуматься о том, почему стартапы двигаются так быстро и работают так хорошо, то это потому, что они вынуждены делать это в силу необходимости, даже если они не измеряют это.
- Достижение того влияния на бизнес, к которому стремится команда. Не зря слово “влияние” так распространено в таких компаниях, как Meta, Uber и других быстро развивающихся технологических компаниях. Вознаграждая за влияние (impact), бизнес стимулирует инженеров-программистов понимать бизнес и уделять приоритетное внимание помощи в достижении его целей. Является ли доставка решения, позволяющего сэкономить 2 млн долл. в год за счет изменения конфигурации, менее ценной, чем доставка решения, позволяющего сэкономить 500 тыс. долл. в год и занимающего 5 инженерных месяцев? Нет! Не стоит концентрироваться исключительно на влиянии, но и не концентрироваться на конечной цели – обеспечении ценности для бизнеса – плохой выбор.
Выводы
Несомненно, бизнес испытывает растущее давление, желая количественно оценить производительность команд разработчиков программного обеспечения. Такие компании, как McKinsey, отвечают на этот очевидный спрос, предлагая системы, которые обещают сделать именно это.
Мы не считаем, что измерение усилий и выхода обязательно является решением проблемы, так как это связано с компромиссами, которые могут негативно повлиять на культуру разработки. Будучи руководителями инженерных подразделений, обязательно учитывайте этот компромисс и то, как он может изменить стимулы разработчиков.
***
Интересно поразмыслить над тем, как Uber измеряет производительность труда разработчиков: известно, что гигант рынка поездок построил панель мониторинга для визуализации статистических данных, измеряющих производительность, таких как количество изменений и отзывы на одного инженера-программиста. Эти показатели измеряют выход ы работы. В то же время компания также измеряет такие показатели, как время от создания до закрытия проекта и часы концентрации внимания каждого инженера-программиста.
Вполне вероятно, что после внедрения этих показателей Uber учитывала изменения в поведении: инженеры стали создавать более мелкие изменения, стремиться быстрее их закрывать и более внимательно относиться к своим задачам.
Гергелий Орош поинтересовался у инженеров, как введение панели показателей Eng Metrics изменило культуру работы. Он услышал, что большинство команд используют эту панель для отладки проблем, хотя были и такие команды и группы, где менеджеры или директора устанавливали цели по количеству изменений в месяц (эти показатели достигаются с легкостью: ведь вы просто создаете более мелкие исправления). Спустя год после введения панели показателей разговор, похоже, пошел дальше, и теперь это просто еще одна метрика.
Интересный анекдот из Uber: после внедрения панели Eng Metrics количество строк кода не изменилось, но загрузка систем CI (continius integration, непрерывной интеграции) заметно возросла. По сути, люди стали создавать гораздо больше изменений, что увеличило нагрузку на системы непрерывной интеграции (CI) и повысило ее стоимость. Таким образом, после измерения результатов последовало изменение поведения людей, которые стали прилагать больше усилий для улучшения измеряемых показателей.
В продолжении публикаций будет рассказано об опасностях измерения только результатов и влияния, о командной и индивидуальной эффективности, а также дан ответ на вопрос, как измерять разработчиков.
