Придя на работу в свою первую технологическую компанию, я тут же столкнулся с методикой OKR (Objectives & Key Results). Оказалось, а позже и подтвердилось разговором с экспертом, знакомым с многими стартапами из Кремниевой долины, что эта методика - норма для стартапов.

Довольно понятно, почему она так популярна. OKR (а для тех, кто с методикой не знаком, рекомендую просмотреть сайт whatmatters.com) обещают несколько заманчивых преимуществ:

• фокусировку всех нужных команд вокруг одного перечня важных направлений,

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

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

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

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

Первым инсайтом было то, что под одним и тем же термином - OKR - разные компании подразумевают ОЧЕНЬ разные вещи. Например, в одной компании существовало два документа - собственно OKR и Операционный план. Первый содержал Цели (Objectives), сформулированные по всем заветам методологи, то есть громкие и не обязательно конкретные намерения, вроде “быть образцом в управлении запасами”. Там же, в OKR, были и Ключевые результаты (Key Results). В этой конкретной компании, KR имели строго определенный вид: перечень показателей, соответствующих каждой Цели, с указанием текущего значения и желаемого значения. То есть выглядело это примерно так:

• Цель: стать иконой качества сервиса в электронной торговле

• Ключевые показатели:

  • Доля заказов, доставленных на следующий день: 60% —> 95%

  • Удовлетворенность клиентов доставкой: 85% —> 98%

  • Доля возвратов средств, выполненных в течение трех часов: 60% —> 90%

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

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

В принципе, оба варианта устраивали те компании, в которых они применялись. И это не противоречило методологии - “по духу”, то как работали компании c OKR, было очень похожим. Однако далее я нашел огромное белое пятно - вопрос, на который мне никак не удавалось найти простой ответ. В этой заметке я решил поделиться своими находками для тех, кто этот вопрос встретит после меня.

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

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

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

2. Желая отчитаться о прекрасной работе, сотрудники превратят OKR в “задозагродительный комплект” (прекрасный термин, подслушанный у одного из коллег, с которым я обсуждал проблему). То есть KR потеряют свою амбициозность, и станут, по сути, тем, что предлагает другая методика - Management by Objectives, MBO.

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

Итак, какие способы оценки работы сотрудников хорошо сочетаются с OKR?

1. Мотивация напрямую от общего результата. Например, часть компенсации каждого сотрудника (или хотя бы тех, что нужны для достижения KR) состоит из доли в компании в той или иной форме. В дополнение к этому, капитализация или оценка компании быстро растет, а что более важно - напрямую определяется тем, удается ли достичь целей, обозначенных в OKR. В таком случае, оптимальная стратегия сотрудников в части OKR - стараться включаться в них то, что больше всего поможет вырастить капитализацию, и работать на достижение этих Ключевых результатов в первую очередь.

2. Мотивация от соответствия “ролевой модели” (role model). Здесь предполагается, что есть свод характеристик, соответствия которым желает от своих сотрудников компания, и также есть более-менее объективный процесс оценки того, насколько каждый сотрудник соответствует этим характеристикам. Так работают, например, Amazon, Google, Zalando, а также все компании большой консалтинговой тройки (который, впрочем, OKR не используют, насколько мне известно). Идея в том, что работа над тем, что приведено в OKR, ровно как и другая - это лишь источник кейсов, на примере которых можно решить, демонстрирует ли сотрудник то, чего от него хотят. И поэтому не так страшно, если какая-то цель не была достигнута. Если тому были объективные причины, плюс одна из целевых характеристик “лезть из своей шкуры для достижения результата”, и сотрудник правда делал невозможное, чтобы все получилось, то его можно оценить высоко вопреки не достигнутой цели. И наоборот - достижение некоторой цели напрямую не означает, что оценка причастного к ней сотрудника будет высокой. Если он был “пассажиром”, а обеспечивали успех другие, то и оценка его будет не высокой.

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

   1. Если все “голосующие” считают А лучше В, то А не может быть оценена в результате работы механизма ниже, чем В.

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

   3. Не существует такого участника “голосования”, что результат работы механизма всегда такой, как считает этот участник (именно такого участника Эрроу называл “диктатором”).

   Возвращаясь из теории в практику, речь может идти о следующей ситуации. Компания - стартап. Механизм - правило, по которому определяются бонусы и продвижения всех сотрудников. В стартапе есть СЕО или основатель, который лично знает всех сотрудников. Если СЕО принимает решение единолично (то есть он - диктатор в смысле Эрроу), то OKR будут работать так, как должны.

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

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