OKR: инструкция по применению — как внедрить в команде

TL;DR: Егор Толстой из Авито разбирает внедрение OKR на практике — не по книге, а через реальные ошибки и решения одной из крупнейших российских продуктовых компаний. 130 команд, 3 года опыта, честно о том, что не работало.

О видео

Егор Толстой — Head of Product в Авито. В видео он рассказывает, как Авито внедряли OKR: с чего начинали, что шло не так и как переработали процесс.

Материал включён в базу знаний RuForge, потому что это один из редких русскоязычных кейсов внедрения OKR в крупной компании с конкретными деталями — не пересказ Джона Дорра, а живой опыт масштабирования на 130 команд.

Смотреть

Что разбирается в видео

• Как Авито запускали OKR и почему первая итерация не сработала
• Разница между «OKR как отчётность» и «OKR как фокус» — и почему это принципиально
• Как устроены OKR на уровне команды vs уровне компании
• Что происходит с мотивацией, когда KR становятся слишком амбициозными
• Почему OKR нельзя привязывать к финансовой мотивации
• Практика ретроспективы OKR и как Авито её проводят

Почему этот материал в базе знаний

Домен 1 «Стратегия и видение» включает подкомпетенцию «Постановка целей через OKR». Опыт Авито ценен тем, что показывает: инструмент работает не сам по себе, а только в связке с культурой обратной связи и ритмом команды.

Содержание видео (текстовая версия)

Ниже — причёсанный транскрипт выступления. Для тех, кто предпочитает читать.

Введение: организационные проблемы, которые решают OKR

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

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

Для решения всех этих проблем мы в Авито используем методологию OKR — Objectives and Key Results. Она позволяет установить дерево понятных, легко измеримых целей по всей организации, связать результаты различных команд друг с другом и добиться достижения желаемых результатов.

С OKR мы живём уже около трёх лет, и за это время к этой системе подключилось около 130 разных структур — отдельные команды, вертикали, функции, другие объединения. Медианное значение результатов команд — 0,6. Может показаться, что это не очень много, но, как разберём дальше, это на самом деле и есть самый сок.

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

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

Как устроены OKR: краткий обзор методологии

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

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

Цель определяет ключевую ценность для бизнеса и отвечает на вопрос «что» и иногда «зачем». Ключевой результат — это уже ответ на вопрос «как». Если цель — это какой-то красивый, часто абстрактный лозунг, то ключевой результат — это максимальная конкретика, которая не терпит никакой воды.

Давайте посмотрим, как это выглядит на примере. Вот одна из целей абстрактной доски объявлений, разложенная по методологии OKR. Это довольно высокоуровневая цель, заданная на самом верхнем уровне компании — она напрямую отражает одну из важнейших стратегических задач по росту. Ключевые результаты дают чёткий и понятный способ измерения этой верхней ценности. Иначе — если такие результаты не задать — под «устойчивый рост» можно подогнать вообще что угодно, вплоть до увеличения веса JavaScript на главной странице. Вот поэтому это важно.

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

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

Ключевые принципы OKR

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

Результаты OKR должны быть полностью отрезаны от финансовой мотивации. Хоть это и контринтуитивно — я понимаю стремление взять максимально возможный размер премии сотрудника, перемножить на цифру достижения результатов и получить профит — но это так не работает. Как только появится какая-то прямая корреляция между результатами работы команды и суммой на счету, сразу появятся микроменеджмент, культура подозрительности и всё то, чего нужно в компании избегать. Это не значит, что в компаниях, которые работают по OKR, премии запрещены — у нас в Авито они есть, но они просто напрямую к OKR не привязаны.

Цели должны быть одновременно амбициозными и достижимыми. Амбициозность заключается в том, что в качестве ключевых результатов выбираются такие показатели, в выполнении которых команда не совсем уверена. Вся система формируется так, чтобы если команда поработает на максимум и ей немного повезёт, она смогла достичь около 60–80% того, на что нацелилась. Такой подход гарантирует постоянный челлендж, наличие фокуса на выбранных целях и рост компетенций и изобретательности команды. Важно понимать: речь идёт не об изнурительной работе, а именно о хорошей, здоровой, развивающей сложности.

Любые ключевые результаты должны поддаваться измерению. Никаких абстрактных «работает хорошо» — всё по SMART. Цели и ключевые результаты обозначают проблематику и описывают её в каких-то показателях, но не должны диктовать конкретных решений. Это даёт команде простор для манёвра: если одна из гипотез для достижения результата не сработала, они всегда могут успеть реализовать что-то ещё.

Цели должны быть связаны. Эта связь может быть вертикальной — от уровня компании до конкретных команд, когда по сути происходит наследование целей. Она может быть и горизонтальной — когда несколько команд тянут какой-то общий кросс-командный проект.

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

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

Всё это — красивая теория, которая, как и любая другая, в чистом виде работает довольно-таки хреново. За три года, что мы работаем по OKR в Авито, мы успели пошатать все эти принципы. В каких-то случаях сильно обжигались, в каких-то — наоборот, начинали работать лучше. Всё, что следует за этим разделом — это уже не чистая теория, а именно то, как мы работаем с OKR в Авито и как с ними можете работать вы.

Как внедрять OKR: с чего начать

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

К примеру, мы так и сделали. Жека Емельянов, который сейчас наш CPO, три года назад был продуктом в одной из команд, которая делала инструменты для профессиональных пользователей. Он как раз и стал первопроходцем. Чтобы разобраться, как вообще работают OKR, и получить максимально релевантные советы по внедрению, он поехал в Google, который активно использует OKR во всех своих подразделениях. Используя полученные инсайты, он вернулся и начал внедрять OKR на примере одной команды. Стали хорошо видны все плюсы использования OKR как метода операционного целеполагания: команда, которую до этого довольно сильно штормило, научилась измерять результаты своей работы, удерживать фокус и работать над тем, что важно.

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

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

Как выбрать первую команду для OKR

К выбору команды нужно подходить с умом.

• Это должны быть достаточно зрелые ребята, которые хорошо понимают смысл своей работы и цели бизнеса. Им не придётся объяснять важность фокуса на outcomes и кайфа от выполнения бизнесовых целей — такая команда получит от OKR существенно больше.
• Команда должна быть сыгранной. Они должны быть способны не просто решать задачки, которые на них кто-то спускает сверху, а сами находить важные проблемы и вкладываться в их решение. Это качество поможет им занять активную роль на этапе целеполагания и самостоятельно выбрать и сформулировать свои OKR — это будет хорошей пробой того самого принципа bottom-up.
• Команда должна быть способна контрибьютить в любые части системы, от которых зависит достижение их целей. Плохая идея подключать сюда чисто функциональные команды — скажем, только бэкендеров или только фронтов — потому что вряд ли они будут способны самостоятельно затащить какую-то цель. Чем больше у команды зависимостей от других, тем меньше вероятность того, что они достигнут своих целей.
• Команда должна понимать, какие проблемы решает внедрение OKR. Идеально, если они уже страдают от расфокусировки, отсутствия внятных целей, размывания ответственности или других похожих проблем. Это поможет им ещё больше оценить результат, когда OKR заработают как надо.
• Вся команда должна загореться идеей. Если они воспринимают OKR как бюрократию и формализм — типа «вы пришли с конференции, услышали и сразу побежали внедрять» — то ничего не выйдет. Поэтому готовьтесь их продавать.

Чтобы упростить вам жизнь, я решил поделиться нашим шаблоном для OKR. Сразу предупреждаю: в отличие от того же performance review, про который я рассказывал год назад, здесь мы так и остались на Google-таблицах, не используем никакой сторонний инструмент. И на самом деле это нормально, потому что тот же Google, про который рассказывал, тоже внутри себя до сих пор использует таблицы. Помимо шаблона, есть ещё инструкция по тому, как с ним работать — смело забирайте и пользуйтесь.

Перед тем как перейти дальше — общий чек-лист, как внедрять OKR в свою команду:

• Определитесь, каких целей вы хотите достичь, когда внедряете OKR.
• Выберите команду, которая соответствует критериям зрелости, и «продайте» им OKR.
• Спустя квартал подключите ещё несколько соседних команд.
• Затем добавьте верхушку пирамиды OKR компании и проведите связку целей.
• Дальше по необходимости подключайте другие соседние или промежуточные звенья.

Где лучше всего работают OKR

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

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

Поиск идентичности команды

Давайте представим, что вы тимлид команды. Чтобы внятно подойти к вопросу OKR, вам нужно сначала чётко понять своё место в компании и понять, чего команда должна добиться в долгосрочной перспективе. Этот процесс я называю поиском собственной идентичности, а отсутствие этого понимания — идентичностным кризисом команды.

Помочь в этом могут несколько инструментов:

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

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

Как формулировать цели

Допустим, с идентичностью разобрались, проблем нет. Переходим к следующему: формулируем сами OKR. Начнём разбираться с целями.

Цели должны быть связаны с тем, что мы только что обсудили — миссией, стратегией, направлениями работы. Цель не должна появляться у команды из ниоткуда. Вопрос «а почему этим занимаетесь именно вы?» вообще не должен подниматься — иначе вы сделали что-то не так.

Вот, к примеру, есть команда, которая в той же абстрактной доске объявлений отвечает за опыт покупателей. Цель «повысить качество объявлений» — вполне понятная: лучший контент, лучший пользовательский опыт. А вот цель «сделать нашу библиотеку самой популярной на GitHub» — уже какая-то странная, есть вопрос «а зачем вообще этим заниматься?»

Формулировки должны быть качественными, а не количественными. Никакого «повысить конверсию на полпроцента» — цель задаёт направление движения, а не длину пути. Хорошая цель: «уменьшить присутствие в монолите» — она не указывает, на сколько конкретно уменьшить, не задаёт шкалу измерения, не даёт конкретных решений. Она просто говорит, куда надо идти. А вот «запилить 5 микросервисов» — уже жёстко флеймит команду и говорит именно что конкретно она должна делать.

Цели должны быть хорошо запоминающимися. Это ещё один инструмент фокуса, который позволяет команде не распылять усилия и держать в голове то, ради чего они делают свою работу. Чтобы запоминаться, цель должна быть лаконичной и сформулированной на понятном команде языке. Скажем, «порвать Craigslist» — запоминается, громко, мотивирует, классно. А «обеспечить значимое опережение по всем автопоказателям» — беззубо, такая цель в афоризмы явно не войдёт. Используйте тот же язык, те же обороты, которые вы используете в обычной речи, меньше воды и расплывчатых слов.

Цель должна быть поставлена так, чтобы в конце квартала вы могли гордиться прогрессом по ней. К примеру, если вы объективно можете выбиться в лидеры рынка только через два года — не нужно ставить такую цель команде в самом начале. Иначе к концу квартала ощутимого прогресса не будет, команда демотивируется, исчезнет любое положительное подкрепление. Пример: «выйти на рынок всех стран мира за квартал» кажется довольно нереальным — если за это время вы покорите одну-две страны, это будет казаться маленьким достижением, хотя результат на самом деле довольно неплохой.

Тест «Поймёт ли это Владимир Правдивый?» Это наш CEO. Такой подход помогает упрощать цели до варианта, который понимают все — любой, кто зайдёт на эту страницу. Если такого не сделать, теряется весь эффект прозрачности: вроде бы цели лежат рядом в одном файлике, но понять их всё равно никто не может. Например, «надёжность бизнес-процессов» считывается довольно легко, а «Patroni-based микросервисная архитектура» — уже не очень, тем более для CEO компании.

Целей не должно быть много. Две-три на команду максимум, ну штук 5–6 в крайнем случае. Понятно, что всё сильно зависит от контекста, но не забывайте: OKR — это история про фокус.

Как формулировать ключевые результаты

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

Ключевая идея ключевых результатов (Key Results) — они переводят качественное в количественное: ту самую вдохновляющую цель — в конкретные, понятные, достижимые и измеримые величины. Важный момент: ключевые результаты должны не просто каким-то боком относиться к общей цели, а реально её раскрывать — показывать, как вы будете достигать, как считаете результат.

Например, у моих команд сейчас есть цель «повысить скорость доставки ценности пользователю» — она живёт с нами уже несколько кварталов. Хороший KR, который её описывает, — это, скажем, частотность релизов. Тем не менее туда часто попадают и ключевые результаты вроде «повысить стабильность тестового стенда» или «процент flaky-релизов» — потому что, опять же, правило можно нарушать.

Представим, что у команды есть цель «повысить длину сессии». Хороший KR раскрывает цель: показывает, на сколько конкретно нам надо увеличить длину сессии и по какой формуле считается результат. А вот в плохом примере указана сторонняя инициатива — скажем, «улучшить качество изображений». Вероятно, качество изображений тоже положительно влияет на пользовательский опыт и длину сессии, но непонятно, действительно ли это то, что нужно.

Один из примеров плохого KR — бинарный: 0, если проект не запущен, 1, если запущен. Основная беда такого подхода к измерению в том, что в течение квартала вообще не видно прогресса. У команды может быть как всё отлично, так и ужасно — а метрики этого не покажут. В реальном мире таких вещей избегать получается не всегда, но мы хотя бы пытаемся декомпозировать такой результат на набор более мелких шажков, которые помогают оценивать промежуточные результаты. Идеальный случай — когда метрика непрерывна: то самое количество релизов, показатели конверсии или что-то ещё.

Вне зависимости от выбранных ключевых результатов важно, чтобы их можно было измерять максимально часто. Для цели «повысить скорость релизов» ключевой результат, указывающий, сколько конкретно релизов мы хотим — это хорошо. А вот зашивать туда конкретную инициативу, тем более такую объёмную, как «переработать CI/CD» — это плохо.

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

Классический пример NPS. Мы поняли, что NPS использовать в OKR — очень плохая идея, потому что это крайне инерционный параметр. В течение квартала вы делаете кучу крутых фич, улучшаете опыт пользователя, а NPS — потому что он инерционный — изменится, допустим, только через квартал. А вот, скажем, тот же retention гораздо более легко измеряемый параметр.

Совокупность ключевых результатов должна быть выбрана так, чтобы выполнить их на 100% можно было бы только при счастливом стечении обстоятельств. Проще всего это достигается тем, что каждый KR задирается чуть выше планки уверенности команды. В итоге обычно в результате получаются те самые 0,6–0,8. Представим, что мы работаем в команде с крупным финансовым прогнозированием: 100% выполнения бюджета — значит, команда поработала хорошо. KR выбираются так, что 0,6 от бюджета — это и будет те самые «нормально». А если они поработают лучше, выстрелят новые гипотезы — тогда будет то самое перевыполнение до единички. Плохая идея — задирать планку и сразу 100% бюджета ставить в нолик, потому что это явно будет команду демотивировать: весь квартал пашут, а результата никакого.

Выбранная шкала измерения должна показывать именно результат, а не шаги его достижения. Это важное и полезное правило, но оно часто разбивается о тот факт, что для того чтобы вообще начать получать результаты, нужно сначала разработать какой-то крупный проект. И опять получается, что прошло полквартала, а у команды всё ещё ни о чём не говорящий нолик. Поэтому мы сейчас разбиваем такие KR на две составляющих: первая показывает прогресс реализации какого-то проекта, вторая — уже выхлоп от него. Выглядеть это может примерно так: не нужно рассказывать, сколько конкретно продуктов вы хотите запустить, но можно разбить на две части: первое — факт запуска проекта, второе — конкретная линейная формула по измерению его результата.

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

Мифы и когнитивные искажения при постановке OKR

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

Миф первый: «Если цели не будут меняться каждый квартал, нас сочтут слабаками и неудачниками». На самом деле это не правда. Преемственность целей важна, поэтому нет ничего страшного, когда одна и та же цель переходит из квартала в квартал — если только команда действительно достигает каких-то внятных результатов и движется по пути к её достижению.

Миф второй: «Команда уже точно решила, что конкретно они хотят сделать, и пытается подобрать метрики именно под эту инициативу». Не могу сказать, что это прям лютый антипаттерн. Действительно бывает так, что у команды есть отличные идеи, что конкретно нужно сделать, чтобы продвинуться по своему направлению, и отметать их только потому что это не соответствует методологии — абсолютно глупо. С другой стороны, надо всё-таки смотреть, насколько такой проект действительно ложится на глобальные цели команды. Может быть, не стоит за него и браться. Или может быть, вы так зашьёте метрики именно на выбранную инициативу, что не сможете в середине квартала поменять своё направление движения.

Миф третий: «В OKR должно быть описано вообще всё, чем занимается команда» — вплоть до историй по саппорту, борьбы с багами и прочего. С этим я не согласен. Имеет смысл разделять операционку и создание новой ценности. В OKR нужно выносить то, на чём мы действительно хотим сделать фокус, — то, что мы считаем реально самыми значимыми результатами работы команды.

Первый квартал OKR в Авито: когда мы только учились жить по OKR, из команды в команду ходила одна и та же цель — «научиться измерять». В её рамках строились метрики, мы учились измерять результаты своей работы. Не могу сказать, что это тоже плохо, — если команда никогда не задумывалась о том, как измерить то, что она делает, о метриках, показателях качества и скорости своей работы, — то она и правда может делать это квартал или даже дольше. Вопрос стоит ли выносить такие цели в OKR или это должно остаться где-то за рамками — однозначного ответа у меня нет, надо реально смотреть по обстоятельствам.

Антипаттерн: цель стала неактуальной, но команда по инерции продолжает её тянуть. По какой-то причине в течение квартала цель команды стала уже неактуальной, но они продолжают её тянуть — потому что «как же так, мы ведь OKR написали, мы же не можем от неё отказаться». Так делать нельзя. Если результат деятельности бесполезен и не нужен ни команде, ни её заказчикам — глупо тратить на это время. Нужно пересмотреть свои OKR, оповестить об этом всех заинтересованных лиц и двигаться дальше по другим целям.

Синдром отличника и цифры 0,6–0,8. Для некоторых довольно сложно смириться с тем, что ты изначально как будто бы «подписываешься под неудачей» — говоришь, что на единичку не выполнил. Включается синдром отличника. На это просто надо смотреть по-другому. Во-первых, цели всё-таки должны быть достижимыми: если вы реально берёте что-то, в достижение чего команда абсолютно не верит — вы что-то сделали не так. Во-вторых, нужно настраивать себя на успех в любом случае и пытаться придумывать, как такой цели всё-таки достичь. Именно тогда проявляется замечательный эффект включения изобретательности команды — когда она придумывает нестандартные пути решения поставленных целей.

«Protect» как нарицательный термин. Под этим я понимаю вообще любое руководство, которое спускает задачи на команду сверху. OKR так не работают. OKR — это общий commitment всей команды, под которым они подписываются. Если члены команды не участвуют в их составлении, они могут не принять эти цели — цели будут чужими, мотивации достигать их будет сильно меньше, пропадает вся сопричастность. чаще всего команда всё-таки лучше, чем какое-то вышестоящее руководство, понимает свою зону ответственности и свои возможности — и не учитывать это глупо.

Процесс постановки OKR: как это устроено в Авито

Процесс постановки OKR не такой лёгкий и простой, как хотелось бы. В среднем у нас уходит на это порядка месяца на стыке двух кварталов. Понятно, что это не поминутная работа, но несколько часов в неделю у команды съедает.

Вот как у нас в Авито организован этот процесс:

• За 3 недели до конца квартала команда собирается на первую встречу. Основная задача: вспомнить свои долгосрочные цели, стратегию компании, цели связанных команд.
• Брейншторм новых целей, новых метрик, новых инициатив. Команда генерирует идеи того, чем должна заниматься дальше. По классике — результаты брейншторма кластеризуются и оцифровываются.
• Циклическая работа над черновиком. Результаты брейншторма оформляются в виде целей и ключевых результатов. Каждый пункт из списка команда начинает челленджить с разных позиций — и исполнителей, и стейкхолдеров. Задаются вопросы про приоритетность, правильность выбранного пути, корректность метрик. Основная цель этой части — сделать так, чтобы все члены команды подписались под выбранными OKR. Параллельно с этим происходит процесс синхронизации команд по связанным проектам и связанным целям.
• Очень важный этап, о котором многие не говорят: по выбранным целям составляется бэклог, команда оценивает, может ли с ними справиться.
• В конце черновик финализируется и заносится в общий файл, где одновременно с остальными командами замораживается. К этому моменту уже должны быть финально выбраны метрики, способ их измерения, и должно быть достигнуто согласие в команде.

Несколько дополнительных советов по процессу:

• Все команды должны работать в едином ритме, придерживаясь одинаковых дат начала и окончания планирования. Это обеспечивает нужный уровень прозрачности и не позволяет случиться закону Паркинсона — работе, занимающей всё отведённое для неё время.
• Обязательно работайте над синхронизацией между командами. Как минимум во время постановки нужно регулярно смотреть на OKR друг друга и сильно-сильно их челленджить: «Чуваки, что это такое? Зачем вы это берёте? А почему вы не берёте что-то ещё?»
• Обязательно проводите хотя бы грубую оценку того, как вы будете достигать того, на что замахнулись. Звучит по-капитански, но у многих OKR ассоциируются с тем, что мы вслепую метимся в результаты, а как их достигнем — придумаем потом. Это довольно опасный паттерн. Вы всё-таки должны понимать хотя бы примерные пути развития событий и насколько вы можете их затащить.

Подводя черту этого раздела:

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

Как достигать целей: работа с OKR внутри квартала

Хоть основная активность, связанная с OKR, и происходит на стыке кварталов, нельзя обойти стороной вопрос достижения самих целей. Здесь как раз подвергаются проверке выбранные ранее метрики и способы их измерения.

Высокоуровневый цикл жизни команды, которая работает по OKR, выглядит примерно так: месяц на стыке кварталов — между ними тихо, достижение целей.

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

Чтобы уменьшить влияние этой истории, мы используем несколько инструментов. Например, на уровне всех платформенных команд мы два раза в квартал проводим OKR review: случайным образом выбирается 5–6 юнитов, которые за 10 минут рассказывают свой текущий статус — как продвинулись по целям, что хорошо, что плохо. Довольно стандартно. Основная цель этого процесса — следить за здоровьем методологии: что мы умеем ставить правильные цели, правильные результаты и планировать свои усилия.

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

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

Ретроспектива по OKR: что делать с результатами квартала

Результаты предыдущего квартала обычно подводятся в начале текущего. Есть несколько сценариев развития событий: либо команда выдала полный ноль, либо средненько поработала, либо перевыполнила — по-разному. Но вне зависимости от того, что случилось, если есть какое-то отклонение, нужно просто садиться, проводить OKR-ретроспективу и разбирать именно почему так произошло, и вырабатывать action items, которые помогут этого не допустить.

Корневые проблемы бывают разные, но есть несколько довольно стандартных паттернов:

• Из-за большого количества операционки командам некогда было заниматься целями — по сути всё время съел саппорт предыдущих продуктов, баги и прочее. В этом случае нужно работать с долгосрочными целями команды, зоной ответственности и процессами, чтобы уменьшить количество рутины и сделать его предсказуемым.
• Команда достигла результатов, а метрики были выбраны плохо — поэтому не отражают реальную ситуацию. Такие вещи имеет смысл править в процессе самого квартала, не ожидая его окончания. Никакого криминала тут нет — научиться правильно ставить OKR — это целая наука, и знание это приходит со временем.
• Взяли слишком амбициозную цель или недостаточно амбициозную. Тут надо смотреть почему именно. Многие команды не пытаются даже планировать, как они достигнут того, чего хотят, и просто слепо верят в успех.

Нельзя наказывать или хвалить команду, только смотря на цифры. Это очень важное правило — просто запомните его. В идеальном мире OKR отражают результат команды, показывают — молодцы они или нет. Но в реальности метрика получается довольно шумной, и на неё влияют разные неочевидные вещи. Ругать или награждать нужно только за конкретный performance, конкретное достижение, влияние — или, наоборот, инциденты и просчёты. Систематическое перевыполнение или недовыполнение OKR могут быть индикатором того, что команда не учится на своих ошибках и не пытается стать лучше. Но опять же, один квартал здесь мало что показывает.

Если кратко подвести итоги раздела:

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

Итоги: что OKR дали лично мне и команде

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

Я строил доклад как инструкцию для тех, кто хочет притащить OKR к себе в компанию. Но в конце хочу немного поделиться тем, что OKR вообще дали мне лично.

Во-первых, исторически сложилось, что в платформенных командах очень много классных, крутых и мощных сеньоров. Они прекрасно знают технологии, понимают бизнес, умеют решать проблемы. Но есть маленький нюанс: они очень склонны к R&D, где буковка R занимает большую часть отведённого времени. В итоге возникают «космолёты», решаются не самые важные проблемы, делаются просто разные прикольные интересные штуки. Вот здесь OKR стали для них и для меня отличным фреймворком, который помог им фокусироваться, удерживать внимание на важном и ощущать постоянный челлендж.

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

Авито — большая компания со многими десятками команд, разобраться в которой сложно. Недавно ко мне зашла руководитель разработки из одной из команд — и она просто удивилась тому, как удобно в одном файле описано всё-всё-всё, чем команда занимается. Мне это сильно упростило, например, процедуру onboarding и погружение в то, что происходит.

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

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

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

Связанные материалы

— Agile-ритм в нетехнической команде: маркетинг со спринтами
— Стратегическое планирование в бизнесе: этапы и связь с OKR
— OKR для руководителей: как правильно поставить цели