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

Это перевод статьи pragmatic engineer, которая критикует подход McKinsey к измерению продуктивности разработчиков и предлагает другое видение, опираясь на 4 ключевых составляющих процесса создания ПО. Мы перевели материал pragmatic engineer, состоящий в оригинале из двух частей и постарались оставить только самое важное – так получилась эта статья. Авторы, основоположник Agile и TDD Кент Бек и популярный автор Гергели Ороз, возмутились предложенными подходами McKinsey и написали развернутый ответ в двух частях:
Оригинал первой части.
Оригинал второй части.

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

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

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

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

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

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

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

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

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

Ментальная карта цикла разработки ПО

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

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

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

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

Будем ссылаться на эту модель на протяжении всей статьи.

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

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

Кто и зачем хочет это делать?

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

#1: Технический директор решает, кого уволить. 

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

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

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

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

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

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

#2: Управление производительностью

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

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

#3: Программист, жаждущий развития

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

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

• Поставьте перед собой цель ежедневно мерджить pull request и отслеживайте достижение этой цели в течение недели. Так получится делать меньшие коммиты, которые легче просматривать и быстрее подписывать. 

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

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

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

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

«Цель команды продаж на квартал составляла 60 миллионов, но получилось сделать только 52 миллиона. Я беру на себя ответственность за промах. Вот причины, по которым это произошло, и вот мой план того, что я изменю, чтобы достичь цели в 60 миллионов в следующем квартале. Кроме того, вот инициатива, которую я реализую в течение двух кварталов и которая, как я ожидаю, после завершения принесет дополнительные 10 миллионов в каждом квартале. Есть вопросы?»

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

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

«Итак, в этом квартале мы отгрузили такую-то функциональность, немного отстаем от графика миграции, но быстро разгребаем техдолг, а в следующем квартале отгрузим еще блок функциональности и наверстаем миграцию. Есть вопросы?»

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

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

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

Так почему же у инженеров не получается отчитываться так же прицельно?

Давайте вернемся к нашей ментальной карте. Применим прежнюю модель и к продажам, и к HR. Вот, например, схема работы продаж:

А вот такая же для HR департамента:

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

Что не так с методологией измерения McKinsey

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

Все метрики DORA относятся к эффекту или результату.

Есть и другой способ измерения продуктивности разработчиков – система SPACE, которую также упоминает McKinsey в своем материале. Она стремится охватить удовлетворенность (satisfaction), производительность (performance), активность (activity), коммуникацию (communication) и эффективность (efficiency). 

Одно из критических замечаний в адрес системы McKinsey заключается в том, что почти каждая из ее пользовательских метрик, отличающихся от метрик DORA и SPACE, измеряет усилия или производные:

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

Почему McKinsey предлагает такие метрики? Одна из причин – их проще всего измерить. Подход McKinsey при этом не учитывает, что как только такие показатели начнут регулярно измеряться, все больше сотрудников компании начнут подстраиваться под такую систему.  

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

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

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

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

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

Тут наши голоса с Кентом Беком расходятся. Вы можете прочитать мысли Кента в его статье.

Разработка как спорт

Что важнее – командная или индивидуальная эффективность? Чтобы ответить на этот вопрос, проведем несколько спортивных аналогий. 

Возьмем, к примеру, футбол. Существует множество примеров, доказывающих, что командная игра важнее индивидуальной. Команда с объективно слабыми игроками может победить соперника с более талантливыми игроками, если будет играть слаженно. Так Греция выиграла Евро-2004 с составом, который был на 15-м месте по вероятности победы из 16 возможных. Все дело в командной работе и выдающемся немецком тренере Отто Рехагеле.

Часто бывает, что командам, в которых играют звезды, приходится прямо-таки бороться за победу. Так «Реал Мадрид» в начале и середине 2000-х набирал суперзвезд, но регулярно проигрывал.

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

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

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

Личные результаты против командных

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

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

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

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

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

Известно, что результаты разработки часто не очень предсказуемы. Да, в некоторых индустриях понятно, что мы создаем и какие результаты гарантированно принесем, и разработка тогда – лишь выполнение этого плана.

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

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

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

Так как оценивать разработчиков?

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

Настоящий запрос будет звучать примерно так:

• «Мне нужно решить, куда добавить сотрудников. Какое распределение даст бизнесу наибольшую отдачу?»

• «Я хочу выявить низкоэффективных и высокоэффективных сотрудников».

• «Я хочу понять, какие команды испытывают проблемы в работе, чтобы помочь им работать лучше».

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

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

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

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

Если вы измеряете количество запросов на доработку: люди будут создавать меньше запросов на доработку, не обращая внимание на связанные с таким подходом проблемы. 

Когда вы проводите открытые измерения, ориентируйтесь на командные результаты и влияние, а не на усилия и артефакты Люди придумают, как «играть» с метриками, и вот что произойдет. 

• Измеряем усилия = создадим «имитацию бурной деятельности»

• Измеряем артефакты = увеличим количество легких к созданию артефактов, никак не влияющих на конечный результат

• Измеряем результаты = срежем углы, лишь бы достичь целей

• Измеряем влияние = креативно подойдем к достижению целей с меньшими усилиями и не создавая лишнего

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

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

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

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

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

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

• Инженеры в команде работают эффективно настолько, насколько эта конкретная команда сама понимает свою «эффективность».

• Лидер (или лидеры) в команде достаточно глубоко погружен, вовлечен, чтобы заметить проблемы в реализации и коде проектов и оперативно их решить.

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

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

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

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