В предыдущих публикациях (часть 1, часть 2) эксперты Кент Бек и Гергелий Орош начали рассматривать ставший актуальным вопрос необходимости оценки эффективности разработчиков и пришли к пониманию особенностей и сложностей этой задачи. Разработанные консалтинговыми компаниями системы оценки подходят не всегда.
Третья часть посвящена размышлениям о плюсах и минусах часто применяющихся подходов к измерению эффективности сотрудников, а также тому, как понять, какой бюджет выделить на разработку.
1. Опасность измерения только результатов и их итогового влияния
До сих пор продажи и подбор персонала были в некотором роде лучшими образцами отчетности, поскольку и те, и другие фиксировали результаты работы команды и отдельных сотрудников с помощью неоспоримых показателей. Однако мы увидели темную сторону сосредоточения внимания только на измерении — и вознаграждении — результатов и влияния: люди играют с системой в своих интересах, что противоречит цели измерения и, в конечном счете, наносит ущерб бизнесу, генерируя некачественные данные.
Ниже Кент рассказывает о том, что происходит, когда единственное, что имеет значение, — это квоты продаж:
«Индивидуальные цели мешают людям работать вместе, поскольку каждый гонится за своей квотой. А это может привести к упущенным возможностям.
Например, можно заключить мегасделку, охватывающую несколько регионов. Для этого необходимо, чтобы несколько торговых представителей работали вместе, и продажа будет засчитана тому представителю, который открыл эту возможность. Но у других торговых представителей нет стимула помогать. Компания теряет привлекательную перспективу, даже не подозревая об этом. Индивидуальные стимулы могут работать против долгосрочных целей прибыльности компании.
Я на собственном опыте убедился, как работают „звездные“ продавцы. Они всегда выполняли свою квоту и получали солидную премию. Как они это делали? Они знали, что продажи могут сорваться в любой момент, поэтому у них всегда было в запасе несколько перспективных клиентов, которых они могли конвертировать в любой момент, и они откладывали их до конца каждого квартала. Они обращались к ним только в том случае, если им нужно было выполнить свою квоту. Стремясь максимизировать личную выгоду, они не максимизировали выгоду компании».
В области подбора персонала Гергелий на собственном опыте убедился, что поощрение рекрутеров за «закрытых» кандидатов впоследствии может привести к обратному результату:
«Однажды я работал с рекрутером, о котором с восторгом отзывались другие менеджеры по подбору персонала. У этого рекрутера был 100-процентный показатель закрытия вакансий. Закрытие означает, что когда кандидат получает предложение, мы добиваемся его подписания. В то время управляемая мной часть организации была настолько крупной, что рекрутеры сами проводили большую часть заключительных бесед и заботились о деталях. Большинство рекрутеров закрывали не более 70-80% предложений. Мне сказали, что этот рекрутер — „рок-звезда“ среди своих коллег.
Я очень болезненно узнал, как они это делали. Примерно через 6 месяцев после ухода этого рекрутера наступило время оценки работы и премирования. Несколько инженеров из нашей группы жаловались на размер бонусов, утверждая, что им „гарантировали“ в 10 раз больше, чем они получили на самом деле. После некоторого анализа все признаки указывали на рекрутера-»рок-звезду": он давал инженерам устные обещания в частной обстановке, которые оказались вопиющей неправдой.
Этот рекрутер ориентировался на результат и игнорировал несколько неписаных, а также писаных правил. У наших менеджеров ушло несколько месяцев на то, чтобы разобраться в этой неразберихе, а инженеры чувствовали себя обманутыми и теряли веру в компанию".
Измерение результатов и их итогового влияния очень важно, но при этом должны существовать системы сдерживания и противовесов, обеспечивающие достижение результатов правильным путем. В конечном счете, именно в этом и заключается здоровая культура компании. Напротив, в «жестокой» или токсичной культуре важны только легко измеряемые результаты и влияние, а цель всегда оправдывает средства. Более здоровая культура учитывает результаты и итоговое влияние, и будет ограничивать вознаграждение за результаты, достигнутые непрофессиональными способами, или способами, не учитывающими сотрудничество и общую картину.
2. Командная и индивидуальная производительность
Что важнее — командные или индивидуальные результаты? Спорт, как область, в которой индивидуальные результаты могут быть измерены достаточно точно, является ориентиром.
Возьмем, к примеру, футбол. Существует множество примеров, доказывающих, что командная игра важнее индивидуальной. Команда с объективно худшими игроками может победить соперника с более талантливыми игроками за счет командной игры. Это было убедительно доказано, когда Греция выиграла международный футбольный турнир Евро-2004, имея в своем составе команду, занявшую 15-е место по вероятности победы из 16 участвовавших в турнире сборных. В чем секрет такого успеха? В документальном фильме «Король Отто» показано, что все дело в командной работе, игре на силу игроков и выдающемся немецком тренере Отто Рехагеле.
Часто бывает так, что команды, укомплектованные звездными игроками, не могут добиться успеха, несмотря на наличие в них игроков, объективно обладающих более высоким уровнем мастерства. Испанский клуб «Реал Мадрид» доказал это своей кадровой политикой «галактикос» в начале-середине 2000-х годов, когда были подписаны контракты с суперзвездными игроками, но команда регулярно не выигрывала трофеев.
Похожую динамику мы наблюдаем и в программной инженерии: команды значительно превосходят уровень квалификации и опыта отдельных сотрудников благодаря совместной работе, высокому моральному духу и руководителю, обладающему правильной интуицией. Я также видел команды, состоящие из инженеров старшего или высшего звена, которые с трудом достигают ожидаемых результатов, страдают от низкого морального духа, путаницы в направлениях, а также плохого управления и руководства.
Рассмотрим другой вид спорта — хоккей. Здесь используется интересная статистика «плюс-минус», которая измеряет разницу забитых и пропущенных игроком шайб, т.е. показывает, насколько больше голов забивает команда и насколько меньше пропускает, когда этот игрок находится на льду. Это своего рода показатель «вклада в успех команды», который полезен для выявления игроков, делающих команду более эффективной.
Можем ли мы найти подобный показатель «плюс-минус» для инженеров-программистов? Если бы такой показатель существовал, его стоило бы измерить. Однако хоккейный матч «пять на пять» и проект по разработке программного обеспечения, состоящий из 5-10 инженеров, дизайнеров, тестировщиков и специалистов по продуктам, — это совершенно разные вещи. Хоккейные команды играют еженедельно, время игры строго ограничено, а условия победы предельно ясны: забить больше. В отличие от этого, программные проекты длятся гораздо дольше, могут не иметь временных ограничений и простой системы подсчета очков.
Индивидуальные результаты не могут напрямую предсказать результаты работы команды. И если в такой легко измеряемой области, как спорт, невозможно вывести командную эффективность из индивидуальной, то в программной инженерии можно ожидать еще меньшего успеха.
Командную производительность легче измерить, чем индивидуальную. Инженерные команды отслеживают результаты работы по выполненным проектам, влиянию на бизнес (например, выручка, прибыль, снижение оттока и т.д.) и другим показателям, подобно тому, как спортивные команды отслеживают результаты по количеству побед, поражений и другим статистическим показателям.
3. Почему разработка ПО стоит так дорого?
Вопрос «почему программная инженерия стоит так дорого» возникает на удивление часто. Вот предложение, как решить этот специфический вопрос:
— Представьте себе мир, в котором компания тратит 0% своего бюджета на инженерные разработки. Я знаю: это абсурд. Но сделайте это. Что это будет означать для компании? Что почувствуют заказчики? Как будет развиваться бизнес?
— А теперь представьте, что компания тратит 100% средств на инженерные разработки и 0% — на все остальное. Что произойдет?
Теперь, когда мы знаем две крайности: какой процент от общего бюджета компания тратит на проектирование? Как определиться с этим числом: решение заключается в том, чтобы оценить, что произойдет, если мы уменьшим это число на несколько процентов или увеличим на несколько процентов. Какой подход принесет бизнесу больше пользы и почему?
Это упражнение превращает вопрос «почему инженерные работы стоят так дорого» в сравнение, в ходе которого принимается решение о сокращении или увеличении расходов на инженерные работы на $X, а не о том, чтобы сделать эти инвестиции — или сокращение — за счет другой области.
4. Как вы решаете, сколько инвестировать в разработку?
Другая распространенная причина, по которой руководители высшего звена хотят измерить производительность разработчиков, заключается в том, что они хотят получить представление о том, насколько целесообразно вкладывать дополнительные средства в разработку, а не направлять запланированные инвестиции, скажем, в продажи или маркетинг.
Однако на самом деле руководитель задает вопрос не о производительности. Вопрос звучит так: «Сколько мы должны инвестировать в инженерию?».
Чтобы ответить на этот вопрос, подумайте о том, что результаты программной инженерии непредсказуемы, особенно если измерять их в небольших масштабах. Конечно, есть отрасли, где вы точно знаете, что хотите построить, и инженерия — это всего лишь игра в исполнение. Но в компаниях, где программная инженерия способствует внедрению инноваций, решение о том, во что вкладывать деньги, больше похоже на то, как нефтяные компании решают, куда и во что вкладывать деньги.
Нефтяные компании не знают наверняка, сколько прибыли принесет бурение скважины. Поэтому они делают разумные инвестиции. Невозможно сказать, откроет ли одно разведочное бурение новое и прибыльное нефтяное месторождение, поэтому они финансируют сразу несколько таких буровых, ожидая, что некоторые из них в конечном итоге принесут многообещающие результаты. Вооружившись большим количеством данных, принимаются более серьезные инвестиционные решения.
Прагматичный подход к инвестированию в программную инженерию, как вид деятельности, связанный с исследованиями и разработками, должен быть аналогичным. Делать небольшие, но недорогие ставки и удваивать те, которые показывают ощутимые перспективы.
Оригинал статьи здесь