Разберем финальную часть размышлений экспертов Гергелия Ошера и Кента Бека на тему, как измерять эффективность работы при разработке ПО. Три предыдущие части, подводящие нас к выводам, можно найти по ссылкам: часть 1, часть 2, часть 3. Заключительные мнения Кента и Гергелия несколько разнятся.  Мы собрали в одну статью ответы и одного, и второго, чтобы каждый имел возможность найти наиболее подходящий для себя вариант.

5. Как вы измеряете разработчиков? – мнение Гергелия Ошера

Как же измерить производительность разработчика? Вот предлагаемая Гергелием схема.

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

• “Мне нужно решить, в какие области инвестировать большее количество сотрудников. Какое распределение даст бизнесу наибольшую отдачу?”
• “Я хочу заниматься управлением эффективностью работы и выявлять низкоэффективных и высокоэффективных сотрудников”.
• “Я хочу выявить проблемные команды, отладить и устранить их”.
• “Наши инвесторы хотят, чтобы мы сократили расходы, и мне нужно выяснить, сколько я могу сократить без существенного ущерба для бизнеса”.
• “Мне нужно обосновать стоимость инженерных работ для генерального директора, который считает, что мы слишком дорогие”.

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

Вот что предлагает для этого Аби Нода – соучредитель компании DX, автор бюллетеня Engineering Enablement и соавтор статьи “Новый способ измерения производительности разработчиков”:

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

• влияние на бизнес
• производительность системы (быстро ли работают наши системы, надежны ли они и т.д.)
• и эффективность разработчиков (скорость, простота, качество, удовлетворенность)”.

Знайте, что люди оптимизируют то, что измеряется. Сотрудники достаточно умны, чтобы понять, что если для их оценки используется какой-то показатель, то они должны оптимизировать этот показатель. Это отражено в законе Гудхарта: “Когда мера становится целью, она перестает быть хорошей мерой”.

В качестве примера Гергелий вспоминает, что произошло, когда команда, использующая Scrum, начала оценивать, достигли ли они целей спринта, ориентируясь на скорость.

Наши PM и EM стали называть команды, достигшие целей спринта, “завершившими спринт”, а команды, не сделавшие этого, – “провалившими спринт”. Мы определяли цели спринта в стори пойтнах (story points, условное обозначение, которое команда присваивает задаче, обозначая ее объем, сложность и продолжительность), а не как выполненную работу.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Влияние результатов команды на бизнес соответствует или превышает ожидания. Посмотрите на такие показатели влияния, как полученный доход, вклад в прибыль, снижение затрат или другие показатели, которые связаны с рентабельностью, ростом или другими ключевыми показателями бизнеса.
• Инженеры в команде работают эффективно – в том смысле, в котором “эффективность” применима по отношению к данной команде.
• Лидер (или лидеры) команды достаточно оперативен, чтобы заметить проблемы с исполнением и оперативно их решить

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

Да, производительность разработчиков можно измерить, но какой ценой? McKinsey не ошибается, утверждая, что производительность разработчиков можно измерить. Однако они обходят стороной вопрос о том, какова цена этих измерений.

Можно измерить влияние команды разработчиков и организации, занимающейся разработкой. И вы должны это делать, если еще не делаете! Например, когда Гергелий работал в Uber, у его команды была вики-страница, где они перечисляли наши текущие и завершенные проекты, а также их влияние с разбивкой по кварталам. Вот как это выглядело:

И Гергелию кажется любопытным, что относительно немногие команды фиксируют свое влияние в таком формате, как это делала его команда: наличие “твердых данных о влиянии” значительно облегчает обсуждение всех вопросов: приоритетов, перераспределения численности и т.д.

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

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

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

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

5. Как вы измеряете разработчиков? – Подход к вопросу от Кента Бека.

1. Четко определите, зачем вы спрашиваете и каковы ваши полномочия по отношению к человеку или людям, которых измеряют. Когда человек, обладающий властью, измеряет человека, не обладающего властью, получаются искажения.
2. Самоизмерение для самосовершенствования – это здорово! Кент обнаружил это на практике, когда проводил анализ задержки между прогонами тестов, создавая книгу о разработке с использованием тестов.
3. Чтобы избежать порочных стимулов, анализируйте данные на том же уровне, на котором вы их собираете: я могу анализировать свои собственные данные; моя команда может анализировать свои собственные агрегированные данные.
4. Если вы решили создать стимулы (в широком смысле – деньги, статус, продвижение по службе, автономия) на основе показателей, знайте, что вы больше никогда не получите точных данных.
5. При этом мотивировать Red team (команда экспертов, которые имитируют реальную кибератаку) – можно любыми стимулами. Что может сделать умные (вы наняли его, конечно, он умный), мотивированные люди, чтобы их цифры выглядели лучше? Они будут стараться нанести максимальный ущерб для достижения поставленной цели (что от них и требуется).
6. Станьте более уверенными в своих собственных оценках. Руководители, неоправданно полагающиеся на “данные”, похоже, бегут от ответственности. Возьмитесь за эту крапиву. Попросите объяснений, которые имеют для вас смысл. Затем сделайте собственные выводы.
7. Измерить производительность разработчика? Невозможно. Существует слишком много сбивающих факторов, сетевых эффектов, дисперсий, эффектов наблюдения и контуров обратной связи, чтобы получить разумные ответы на вопросы типа: “Во сколько раз больше прибыли создал Джоан, чем Гарри?” или “Насколько лучше (или хуже) Гарри работает в этом квартале, чем в прошлом?”. Вы можете измерить активность, но не без того, чтобы не соотнести эту активность с достижением целей, о которых вы заботитесь. И с целями ваших заказчиков. И ваших инвесторов.
8. С подозрением относитесь к тем, кто утверждает, что измеряет производительность разработчиков. Спросите, кто и зачем это делает. Спросите, в каких единицах они измеряют производительность и как эти единицы связаны с прибылью.
9. Кент Бек на 100% поддерживаю подотчетность. Еженедельная поставка ценностей, которые ценят заказчики, – это лучшая подотчетность, наиболее согласована и наименее искажена.

Оригинал статьи с мнением Гергелия Ошера

Оригинал статьи с мнением Кента Бека