Всем привет! Меня зовут Егор, я руковожу кластером 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 с одной команды. В Авито, к примеру, мы так и сделали. Евгений Емельянов, наш CPO, три года назад был продактом команды, разрабатывавшей инструменты для профессиональных пользователей — автодилеров и риэлторов. Он как раз и стал первопроходцем. Чтобы получить максимально релевантные советы, он поехал в Google, который активно использует OKR во всех своих подразделениях. Используя полученные инсайты, Женя вернулся к нам внедрять OKR. Вот его пост о методе на Медиуме.  На примере его команды стали хорошо видны плюсы использования OKR как метода операционного целеполагания. Команда, которую до этого довольно сильно штормило, научилась измерять результаты своей работы, понимать их важность и удерживать фокус. Спустя несколько кварталов началось масштабирование на соседние команды, которым по возможности ставились связанные цели. И еще позже, когда у нас появилось несколько полноценно работающих по OKR команд, мы начали работать над вертикальной связанностью, определять цели на уровне компании, департаментов, функций и других сущностей. У себя вы можете повторить тот же путь. Начните с того, что выберите одну структурную единицу, которая максимально приближена к полю боя. Начинать сразу с уровня компании не стоит — цели-то вы сможете выставить, а вот выполнять их будет некому. Ваша задача на этом этапе — протестировать методологию во «враждебном» окружении, поэтому к выбору пилотной команды подойдите с умом. Чтобы упростить вам жизнь, я решил пошарить наш шаблон OKR. Гугл таблицы до сих пор закрывают большую часть потребностей. По ссылке рядом с шаблоном лежит пдфка с инструкцией по работе с ним, пользуйтесь.  Перед тем, как перейти дальше, напомню общий чек-лист по внедрению OKR.  Не важно, на каком уровне организации или этапе внедрения вы находитесь. Но очень важно научиться правильно формулировать цели и ключевые результаты и работать с ними. Методология OKR больше всего подходит для продуктовых команд. Под ними я подразумеваю автономные кроссфункциональные команды, которые объединены вокруг какого-то определенного value-stream. И успех в этой части продукта зависит целиком и полностью от них. Когда я дальше пишу про постановку целей, я ориентируюсь именно на такой тип. Рассматривать все возможные комбинации оргструктур и методологий я не буду, но верю, что многие из практик будут применимы и к ситуациям, отличным от нашей. Давайте представим, что вы — тимлид команды. Чтобы внятно подойти к вопросу постановки OKR, вам нужно сперва четко определить свое место в компании и понять, а чего вообще ваша команда должна добиться в долгосрочной перспективе. Этот процесс я называю поиском собственной идентичности, а отсутствие ее понимания — экзистенциальным кризисом. Помочь в этом вам могут несколько инструментов.  Понимание хотя бы одного, а лучше нескольких из этих аспектов обязательно для того, чтобы подойти к процессу постановки OKR. Без наличия такого компаса вы не сможете понять, насколько выбранное командой направление движения отвечает потребностям бизнеса — вы можете быть бесконечно эффективны внутри, достигать на первый взгляд классных результатов, но не приносить в итоге никакой пользы. Допустим, с этим разобрались и проблем нет. Переходим к следующему — формулируем сами OKR. Начнём с целей. При формулировке цели нужно придерживаться нескольких простых правил. Они должны быть связаны с тем, что мы только что обсудили: миссией, стратегией, направлениями работ.         Следующий — шаг формулировка ключевых результатов. По сравнению с постановкой целей, это более сложная задача. Практически все практики их формулировки допускают большие отклонения в сторону.        Самая большая ошибка, которую можно совершить — это упороться по чистоте соблюдения всех этих принципов. В реальной жизни, к сожалению, нужно часто идти на компромисс и в каких-то случаях жертвовать одним из принципов ради другого. Если так не делать, то вы получите просто синтетику, которая хорошо выглядит на бумаге, но мало чем полезна в операционном управлении. Вообще, работая над постановкой целей в разных командах, я встречал много разных мифов и когнитивных искажений, которые в итоге получилось побороть. Один из них — уверенность команды в том, что цели должны меняться квартал к кварталу, иначе их сочтут слабой командой. Это вырождалось в то, что ряд направлений забрасывался, будучи не доведенным до конца. На самом деле, это все-таки не правда.   Преемственность целей в ОКР приветствуется. Нет ничего страшного в том, когда цель держится несколько кварталов, важно всегда достигать ощутимого прогресса по ней. Ещё пример. Команда уже точно решила ЧТО конкретно она хочет сделать и какой проект запилить, а дальше уже пытается подогнать под него цель и метрики.  Не могу сказать, что это прямо антипаттерн. Действительно бывает так, что у команды есть отличная идея того, как им продвинуться дальше по их глобальным направлениям работы. Не учитывать её только потому, что это не очень укладывается в методологию — глупо. Но с другой стороны, если такой проект все-таки не очень ложится на цели и метрики команды то, возможно, это оффтоп. Часто встречаю убеждение в том, что OKR должен описать вообще все, чем занимается команда, вплоть до саппортских историй и борьбы с багами.  Я с этим не согласен. Имеет смысл разделять операционку и создание новой ценности, движение по пути к цели. В OKR нужно выносить то, на чем мы хотим держать фокус, те цели, достижение которых действительно важно для бизнеса. А вот смешной пример. Первые кварталы, когда Авито только учился жить по OKR, из команды в команду ходила замечательная цель «Научиться мерить что-то». В ее рамках строились метрики, дэшборды, подключалась аналитика и делались другие подобные штуки.  Не могу сказать, что это очень плохо. Если команда никогда не задумывалась о каких-либо метриках и измерениях своей работы, то учиться мерить она и правда может целый квартал. Другой вопрос — стоит ли выносить это на уровень OKR или оставить за рамками. Однозначного ответа у меня нет, надо смотреть по обстоятельствам. А вот действительно антипаттерн. Цель по какой-то причине стала неактуальной в середине квартала, но команда по инерции продолжает ее тянуть.  Нельзя так делать. Если результат деятельности бесполезен, не нужен ни команде, ни ее заказчикам, то глупо тратить на это время. Нужно пересмотреть свой коммит, оповестить об этом заинтересованных лиц, и двигаться дальше по другим целям.  А вот история про те самые 0.6-0.8, которые многим не дают покоя. Довольно сложно смириться с тем, что ты изначально подписываешься под неудачей.  На это надо просто по-другому смотреть. Во-первых, цели все-таки должны быть достижимыми. Если вы заранее берете что-то, с чем прямо точно не справитесь, то не нужно так делать. Во-вторых, нужно настраивать себя на успех в любом случае, и пытаться придумать, как своей цели все-таки достичь. Именно тогда и проявится тот замечательный эффект развития сотрудников и команды, который даёт OKR.  Продакт здесь термин нарицательный. Под ним можно иметь в виду любое руководство, которое спускает на команду придуманные им цели. OKR так не работают. OKR — это общий коммитмент всей команды, под которым они подписываются. Если члены команды не участвуют в их составлении, они этот коммит на себя принимать и не будут. Цели будут чужими, мотивации достигать их — сильно меньше. Пропадает вся сопричастность. Процесс постановки OKR не такой легкий и простой, как хотелось бы. В среднем у нас уходит на это порядка месяца на стыке двух кварталов. Понятно, что это не фулл-тайм работа, но несколько часов в неделю у команды съедает. У нас в Авито процесс постановки OKR организован плюс-минус следующим образом. Где-то за три недели до конца квартала команда собирается на первую встречу. Она проходит следующим образом.  Далее начинается самый сложный этап — цикличная работа над черновиком OKR. Результаты брейншторма оформляются в виде целей и ключевых результатов. И каждый пункт из списка команда начинает челленджить с разных позиций — и исполнителей, и стейкхолдеров. Задаются вопросы про приоритеты целей, правильность выбранного пути, корректность подобранных метрик и многие другие. Основная цель этой части — сделать так, чтобы все члены команды подписались под выбранными целями и были уверены, что идти нужно именно этим выбранным путем. Параллельно с этим проходит процесс синхронизации с другими командами, либо на уровне общих черновиков, либо на отдельных встречах. Здесь появляются договоренности о кросскомандных проектах.  И последняя часть — это предварительные груминги целей и составление роадмапов. Да, по методике команда не знает, как будет достигать цель, но это не мешает ей здраво подойти к оценке и составить бэклог ключевых инициатив. В конце концов черновик финализируется и заносится в общий файл, где одновременно с остальными командами замораживается. К этому моменту уже должны быть финально выбраны метрики, способы их измерения и достигнуто согласие в команде.  И несколько дополнительных советов по процессу. Переходим к следующему разделу.  Хоть основная активность, связанная с OKR, и происходит на стыке кварталов, нельзя обойти стороной и сам вопрос достижения целей. Здесь как раз подвергаются проверке выбранные ранее метрики и способ их измерения, ведь встает вопрос об их регулярном трекинге. Вообще, высокоуровнево весь цикл жизни по OKR выглядит примерно так. Месяц на планирование находится ровно на стыке кварталов, а между ним — тихая заводь достижения целей. В какой-то момент мы решили посмотреть, насколько равномерно распределена разработка фичей вот по этому интервалу.  Конечно, наивно было ожидать увидеть что-то близкое к прямой линии. Объяснения этому у каждой команды обычно свои — где-то операционка зашкаливает, где-то не все эксперименты еще прошли. Но результат все равно получался один: достижение OKR у нас было размазано не очень равномерно, и конец квартала становился довольно рискованным. Чтобы уменьшить влияние этого, мы используем несколько разных инструментов.   К примеру, на уровне всех платформенных команд два раза в квартал мы проводим OKR Review. Случайным образом выбирается до 5-6 команд, которые за 10 минут рассказывают свой текущий статус: как продвинулись по целям, что получается хорошо, что мешает, какие прогнозы на конец квартала. Основная цель этого процесса — следить за здоровьем методологии, за тем, что мы умеем правильно ставить цели и планировать свои усилия. Мы не пользуемся никакими общими триггерами с напоминаниями об обновлении файла с OKR, это задача каждого конкретного руководителя. Чтобы облегчить анализ, в файле с OKR трекаются даты последнего обновления для каждой из страниц, плюс есть сводный дэшборд по результатам всех команд. Подавляющее большинство команд у нас работает по скраму. И мы тесно интегрируем OKR со скрамовой рутиной. В моих командах, к примеру, есть важное правило: не может быть ни одного спринта, в котором не присутствуют цели, взятые из OKR. Допустимо брать операционку, техдолг и прочее в разумных количествах, но OKRный инкремент обязательно должен быть. Контроль этого работает через демо, где команды всегда рассказывают, как взятые ими цели спринта влияют на OKR, и почему они взяли что-то сверх этого. Результаты предыдущего квартала обычно подводятся в начале следующего. И здесь у команд есть четыре типичных сценария: вообще ноль, сделали плохо, сделали норм, сделали слишком хорошо. И вне зависимости от того, какой из них произошел, главное, что нужно сделать (тут сейчас капитанство будет) — провести детальную ретроспективу и выработать список Action Items, которые помогут ситуации не повторяться. Проблемы бывают разные, но есть несколько повторяющихся паттернов. Есть ещё несколько очень важных советов, которые надо набить себе на видном месте, если вы собираетесь внедрить OKR.  Я построил этот пост как инструкцию для тех, кто хочет притащить OKR себе в компанию для решения конкретных проблем. Но в конце я хочу немного поделиться тем, что OKR дали лично мне как руководителю. Для понимания контекста: исторически сложилось, что в платформенных командах очень много крутых и опытных сеньоров. Они все прекрасно знают свои технологии, предметную область, понимают бизнес. Но есть один нюанс: они очень склонны к R&D историям, в которых основной фокус уходит именно на рисерч. Это может выливаться в построение космолётов, решение проблем не первостепенной важности и другие неприятные штуки. OKR для меня стал отличным фреймворком, который помог справиться с этими историями и дать этим командам очень чёткий фокус и ощущение постоянного челленджа. Мы очень много думаем о метриках. Многие вещи, связанные с архитектурой и инструментами для разработчиков, традиционно не принято пытаться глубоко оценивать. OKR постоянно провоцируют нас думать об этом и развивать умение измерять свою работу. Авито — большая компания со многими десятками независимых команд со своими продуктами и целями. Со временем, конечно, начинаешь в этом разбираться, но когда ты новый человек, это может быть серьёзным блокером. Ко мне буквально пару месяцев назад вышла новая руководитель в одну из команд. И наличие у нас системы OKR, описанной в одном файле для всех команд, сильно упростило знакомство её с нашими оргструктурой и целями. OKR — это хорошая методология, которая позволяет эффективно управлять кучей децентрализованных структур. Но это определённо не серебряная пуля, потому что в реальном мире все выглядит не так гладко, как в книжках и статьях. Но мы в Авито живем с OKR уже три года, немного дотюнили стандартный подход для себя и довольны им. На графике показано, как часть из наших команд в течение последних 4 кварталов достигают своих OKR. Дисперсия довольно большая, но в среднем все выглядит хорошо.   Короче говоря, попробуйте затащить OKR к себе хотя бы для одной команды и посмотрите, как изменится их работа. Я уверен, что эти перемены будут только к лучшему.