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

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

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

С OKR мы живем вот уже почти три года. Начав с одной команды, мы масштабировали процесс до 130 разных структур — отдельных юнитов, вертикалей, кластеров, функций. В этой статье я сфокусируюсь на практических приемах того, как можно использовать 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, три года назад был продактом команды, разрабатывавшей инструменты для профессиональных пользователей — автодилеров и риэлторов. Он как раз и стал первопроходцем. Чтобы получить максимально релевантные советы, он поехал в Google, который активно использует OKR во всех своих подразделениях. Используя полученные инсайты, Женя вернулся к нам внедрять OKR. Вот его пост о методе на Медиуме.

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

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

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

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

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

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

Ставим цели и формулируем результаты

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

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

Давайте представим, что вы — тимлид команды. Чтобы внятно подойти к вопросу постановки 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 или оставить за рамками. Однозначного ответа у меня нет, надо смотреть по обстоятельствам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Достигаем цели

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

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

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

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

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

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

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

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

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

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

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

Что дали OKR мне?

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

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

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

Data-driven

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

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

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

Итого

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

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