Хабрахабр

Objectives and Key Results: инструкция по применению

Меня зовут Егор, я руковожу кластером App Platform в Авито. Всем привет! Мои команды в основном занимаются разработкой внутренних продуктов, инструментов и процессов — тем, что принято называть платформенной разработкой.

Тогда я упоминал, что мы смотрим на него как на индикатор пользы, которую приносит компании каждый отдельный человек. Год назад я рассказывал в этом блоге, как мы внедрили и используем performance review. Это помогает ответить на вопрос «насколько Вася молодец по сравнению с Петей?» и определить, какую премию кому выплатить. Понимать это важно и полезно. Здесь важно оценить конкретный результат команды и его влияние на успех компании. Но когда мы переходим на уровень команд, всё становится сильно интереснее. Какая-то корреляция точно присутствует, но для оценки фактического вклада команды в успех компании этот инструмент использовать нельзя. Высокое среднее значение перфоманса всех членов команды совсем необязательно значит, что команда достигла крутых результатов.

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

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

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

Они отвечают на вопрос «Что?» и иногда «Зачем?». Цели (Objectives) определяют ключевую ценность для бизнеса. Если цель — это часто абстрактный лозунг, то ключевой результат — это максимальная конкретика, которая не терпит никакой воды. Ключевые результаты (Key Results) — это уже ответ на вопрос «Как?». Давайте смотреть на примеры.

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

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

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

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

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

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

Принципы OKR

  • Результаты OKR должны быть полностью отвязаны от финансовой мотивации, хоть это и контринтуитивно. Я понимаю стремление умножить максимальную премию на процент достижения целей командой, но так делать ни в коем случае не надо. OKR — про честность. Как только появится прямая корреляция между показателем достижения цели и балансом на счету, эти показатели тут же начнут занижаться командой, появится читинг и попытки сломать методологию. Вместо честности в дело начнут вступать микроменеджмент и культура подозрительности. Это не значит, что в компании, работающей по OKR, премии запрещены. Они просто не привязаны к целям напрямую.
  • Цели должны быть одновременно амбициозными и достижимыми. Амбициозность заключается в том, что в качестве ключевых результатов выбираются такие показатели, в выполнении которых команда не совсем уверена. Вся система формируется так, чтобы если команда поработает на полный максимум и супер-выложится, то сможет достигнуть около 60-70% заложенных ею показателей. Такой подход гарантирует постоянный челлендж, наличие фокуса на выбранные цели, рост компетенций и изобретательности команды. Речь здесь идет не столько о постоянной работе на изнурение, сколько про здоровую сложность.
  • Как я показывал на примерах, любые ключевые результаты должны поддаваться измерению. Никаких абстрактных «работает хорошо», всё по знакомой вам методике SMART.
  • Цели и ключевые результаты обозначают проблематику и описывают ее в каких-то показателях, но не должны диктовать определенных решений. Это дает команде простор для маневра — если одна из гипотез плохо себя показала, они всегда могут успеть реализовать какое-то другое решение.
  • Как я уже показал, цели должны быть связаны. Эта связанность может быть вертикальной — от уровня компании до конкретных команд. Она может быть и горизонтальной, когда для достижения крупных кросскомандных результатов в разных командах ставятся созависимые цели.
  • OKR предназначены в первую очередь для децентрализованной организационной структуры. — Несмотря на вертикальную связанность, большинство целей выставляются командами самостоятельно, основываясь на их понимании их зоны ответственности, ключевых фокусов и болей пользователей. Короче говоря, команды сами определяют, чем они должны заниматься, и формулируют это в виде таких же OKR.
  • И последний важный принцип — это публичность. Каждый должен видеть OKR любого участка компании, иметь возможность задать вопрос и почелленджить совершённые выборы. Есть исключения для секретных проектов, но это уже детали. Точно так же и результаты тоже доступны всем.

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

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

В Авито, к примеру, мы так и сделали. Лучше всего начать внедрять OKR с одной команды. Он как раз и стал первопроходцем. Евгений Емельянов, наш CPO, три года назад был продактом команды, разрабатывавшей инструменты для профессиональных пользователей — автодилеров и риэлторов. Используя полученные инсайты, Женя вернулся к нам внедрять OKR. Чтобы получить максимально релевантные советы, он поехал в Google, который активно использует OKR во всех своих подразделениях. Вот его пост о методе на Медиуме.

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

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

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

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

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

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

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

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

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

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

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

Формулируем цели

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

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

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

  • Цели должны быть хорошо запоминающимися. Это еще один инструмент фокуса, который позволяет команде не распылять свои усилия и держать в голове то, ради чего они делают свою работу. А чтобы запоминаться, цель должна быть выражена лаконично, использовать привычный предметный язык, давить на что-то важное для команды. «Порвать крэйгслист» — запоминается, громко, мотивирует. «Добиться значимого опережения» — беззубо, такая цель в афоризмы явно не войдет. Она что есть, что её нет.

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

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

  • Цель должна быть понятна всем: от разработчика до CEO. Если оставлять цели слишком сложными и опирающимися на какие-то малоизвестные детали, теряется фактор прозрачности. С одной стороны, все ОКРы лежат в одном файле, с другой — всё равно никто ничего не понимает.

  • Целей не должно быть много. Идеал — две-три на команду. Адекватный максимум — штук пять. Понятно, что все сильно зависит от фактуры, но, опять же, не забывайте про необходимость фокуса и выделения важного.

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

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

  • Ключевая идея KR — они переводят качественное в количественное, ту самую вдохновляющую цель в конкретные измеримые величины. И вот тут важный момент: ключевые результаты должны не просто каким-то боком относиться к общей цели, а переводить ее в разряд измеримого. На деле, конечно, получается по-разному, иногда какая-то цель может выступать как зонтичное направление, которое объединяет внутри себя несколько отдельных стримов. Например, у моих команд сейчас есть цель «Повысить скорость доставки фичей до пользователя». Эта цель с нами живет уже несколько кварталов, и помимо напрямую описывающих ее KRов (частота релизов), туда попадают метрики вроде количества канареечных релизов или стабилизации тестовых стендов. Напрямую они не ведут к повышению скорости доставки, но опосредованно влияют. Вот представим, что у команды есть цель — повысить длину сессии. Хороший KR раскрывает цель и показывает, на сколько конкретно нам надо увеличить длину сессии и по какой формуле считается результат. А вот в плохом примере указана сторонняя инициатива — качество изображений в объявлении определенно влияет на длину сессии положительно, но совсем не напрямую.

  • Один из примеров плохого key result — «Запущен проект»: 0 если не запущен, 1 — если запущен. Основная беда такого подхода к измерению в том, что в течение квартала вообще не видно, становится ли команда ближе к цели. У нее может быть как всё хорошо, так и ужасно. Но метрики этого не показывают. В реальном мире таких вещей избегать получается не всегда, и иногда их принимают как необходимое зло. В таком случае мы пытаемся декомпозировать такой результат на набор более мелких шагов, которые тем не менее отражают промежуточные результаты. Ну а вообще идеальный случай — это когда метрика непрерывна (скажем, то же самое количество релизов, показатели конверсии или что-то еще. Ну и вне зависимости от выбранной шкалы, важно, чтобы ключевые результаты можно было измерять максимально часто. Для цели «Повысить скорость релизов» ключевой результат, указывающий, сколько релизов конкретно мы хотим — это хорошо. А вот зашиваться на какую-то конкретную инициативу, к тому же слабо описанную, точно плохо.

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

  • Совокупность ключевых результатов должна быть выбрана так, чтобы на 100% выполнить их можно было только при максимально счастливом стечении обстоятельств. Проще всего это достижимо тем, что каждый отдельный KR задирается чуть выше планочки уверенности команды. Таким образом обычно в результате получается, что хорошие результаты колеблются между 0.6-0.8. Представим, что мы работаем в компании с крутым финансовым прогнозированием. Шкала между 97 и 102 процентами выполнения бюджета выглядит неплохо. Если выполним на 100%, это как раз 0.6. А для единички нужен здоровый челлендж. Плохая идея — задирать планку слишком высоко и делать цель нереально амбициозной: она будет демотивировать команду.

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

Не упарывайтесь!

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

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

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

Команда уже точно решила ЧТО конкретно она хочет сделать и какой проект запилить, а дальше уже пытается подогнать под него цель и метрики. Ещё пример.

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

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

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

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

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

Цель по какой-то причине стала неактуальной в середине квартала, но команда по инерции продолжает ее тянуть. А вот действительно антипаттерн.

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

6-0. А вот история про те самые 0. Довольно сложно смириться с тем, что ты изначально подписываешься под неудачей. 8, которые многим не дают покоя.

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

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

Строим ритмичный процесс постановки целей

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

Она проходит следующим образом. Где-то за три недели до конца квартала команда собирается на первую встречу.

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

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

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

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

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

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

Переходим к следующему разделу.

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

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

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

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

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

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

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

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

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

Есть ещё несколько очень важных советов, которые надо набить себе на видном месте, если вы собираетесь внедрить OKR.

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

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

Фокус и челлендж для сеньоров

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

Data-driven

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

Обзор компании

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»