В предыдущих публикациях (часть 1, часть 2) эксперты Кент Бек и Гергелий Орош начали рассматривать ставший актуальным вопрос необходимости оценки эффективности разработчиков и пришли к пониманию особенностей и сложностей этой задачи. Разработанные консалтинговыми компаниями системы оценки подходят не всегда.

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

 1. Опасность измерения только результатов и их итогового влияния

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

Ниже Кент рассказывает о том, что происходит, когда единственное, что имеет значение, – это квоты продаж:

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

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

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

В области подбора персонала Гергелий на собственном опыте убедился, что поощрение рекрутеров за «закрытых» кандидатов впоследствии может привести к обратному результату:

“Однажды я работал с рекрутером, о котором с восторгом отзывались другие менеджеры по подбору персонала. У этого рекрутера был 100-процентный показатель закрытия вакансий. Закрытие означает, что когда кандидат получает предложение, мы добиваемся его подписания. В то время управляемая мной часть организации была настолько крупной, что рекрутеры сами проводили большую часть заключительных бесед и заботились о деталях. Большинство рекрутеров закрывали не более 70-80% предложений. Мне сказали, что этот рекрутер – “рок-звезда” среди своих коллег.

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

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

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

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

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

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

Часто бывает так, что команды, укомплектованные звездными игроками, не могут добиться успеха, несмотря на наличие в них игроков, объективно обладающих более высоким уровнем мастерства. Испанский клуб “Реал Мадрид” доказал это своей кадровой политикой “галактикос” в начале-середине 2000-х годов, когда были подписаны контракты с суперзвездными игроками, но команда регулярно не выигрывала трофеев.

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

Рассмотрим другой вид спорта – хоккей. Здесь используется интересная статистика “плюс-минус”, которая измеряет разницу забитых и пропущенных игроком шайб, т.е. показывает, насколько больше голов забивает команда и насколько меньше пропускает, когда этот игрок находится на льду. Это своего рода показатель “вклада в успех команды”, который полезен для выявления игроков, делающих команду более эффективной.

Можем ли мы найти подобный показатель “плюс-минус” для инженеров-программистов? Если бы такой показатель существовал, его стоило бы измерить. Однако хоккейный матч “пять на пять” и проект по разработке программного обеспечения, состоящий из 5-10 инженеров, дизайнеров, тестировщиков и специалистов по продуктам, – это совершенно разные вещи. Хоккейные команды играют еженедельно, время игры строго ограничено, а условия победы предельно ясны: забить больше. В отличие от этого, программные проекты длятся гораздо дольше, могут не иметь временных ограничений и простой системы подсчета очков.

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

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

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

Вопрос “почему программная инженерия стоит так дорого” возникает на удивление часто. Вот предложение, как решить этот специфический вопрос:

– Представьте себе мир, в котором компания тратит 0% своего бюджета на инженерные разработки. Я знаю: это абсурд. Но сделайте это. Что это будет означать для компании? Что почувствуют заказчики? Как будет развиваться бизнес?

– А теперь представьте, что компания тратит 100% средств на инженерные разработки и 0% – на все остальное. Что произойдет?

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

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

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

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

Однако на самом деле руководитель задает вопрос не о производительности. Вопрос звучит так: “Сколько мы должны инвестировать в инженерию?”.

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

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

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

Оригинал статьи здесь