Тема OKR (Objectives and Key Results) сейчас становится все более популярной в бизнесе. Во многих компаниях рассматривают возможность внедрить у себя эту методологию. Мы в Wrike перешли на OKR в 2015 году, и на тот момент это была достаточно новая и малоизученная тема, по крайней мере в нашей стране. Теперь по прошествии нескольких лет кажется полезным рассказать о нашем опыте работы с OKR. И о наших ошибках, которых можно было бы избежать. Оценить общий результат, который мы получили от внедрения OKR в компании. Возможно, наш опыт окажется полезным для тех, кто задумывается о том, стоит ли переходить на OKR.
Методология OKR строится на принципе управления по целям (какой результат мы хотим получить), что существенно отличается от менеджмента на основе плана (кто, что и когда должен сделать). В развитии OKR-подхода можно выделить три ключевых этапа:
Активное продвижение OKR на широкую аудиторию, по всей видимости, происходит с 2012 года, когда Google начал пропагандировать OKR, см. видео. Так что для широкого круга менеджмента это все еще достаточно новая тема, пусть ее корни и уходят вглубь 1950-х.
В 2015 году мы в Wrike сделали первый подход к OKR. К тому моменту у нас уже работало квартальное планирование, но организовано оно было достаточно хаотично. Часто квартальные планы включали излишне-мелкие подробности, а самих квартальных проектов оказывалось слишком много. Как следствие, сами планы часто получались несогласованными и нереалистичными. Начать использовать OKR как инструмент квартального планирования на тот момент было вполне логичным шагом, так мы и поступили.
Первое внедрение OKR прошло просто, слишком просто. Посыл был следующий: второй квартал нужно спланировать по OKR, точка. Сказано — сделано. О том, что такое OKR, каждый был волен узнавать самостоятельно. «Хорошим» источником информации на эту тему была Wikipedia. Предсказуемо, что первый подход получился не вполне успешным. Мы взяли форму OKR, но не поняли сути. Пожалуй, процесс квартального планирования стал чуть более организованным, но и только. Следующие два года тема OKR у нас не развивалась, мы были заняты другими, более важными для нас организационными изменениями.
В 2016 году мы активно расширяли штат разработки, тогда же внедрили Scrum. См. статьи: «Scrum: Правила Игры» и «Худой Scrum лучше доброго Agile». Scrum дал нам возможность масштабировать разработку, сделать ее организованной, управляемой и предсказуемой. Сейчас более чем очевидно, что это был самый правильный шаг, и хорошо, что мы тогда не стали вопреки всему развивать тему OKR. Наивно пытаться спланировать квартал, если ты не можешь спланировать работу даже на ближайшие две недели. А именно в этой ситуации мы и находились. То, что мы наладили краткосрочное планирование по спринтам, в конечном счете дало нам возможность осмысленно планировать квартал, а затем и год.
В 2017 мы перезапустили OKR. На этот раз мы начали всерьез и глубоко изучать вопросы: «Что такое OKR?» и «Как работают OKR?». На эту тему у меня вышла хорошая статья: «OKR: Как поставить цели и выполнить их на 70%». Любопытно, что статью продолжают читать и спустя три года после публикации, такое редко бывает. Кроме того, нас волновал вопрос: «Как совместить OKR и Scrum?». Ответ на него мы нашли в концепции, о которой я рассказывал на одном из Wrike-митапов: «OKR: Стратегическое планирование поверх Scrum» (видео, слайды).
Суть концепции в том, чтобы ограничить использование OKR только стратегическим уровнем, а Scrum применять на тактическом. Мы ставим OKR только на уровне всего инжиниринга и продуктовых юнитов (групп Scrum-команд под общим управлением Sr. Product Manager). Ниже этого уровня мы OKR не применяем, там работает либо Scrum, либо менеджмент руководителей подразделений разработки. Это наша специфика. Оригинальный подход OKR подразумевает сквозные цели, вплоть до OKR конкретного разработчика. Но наш опыт показал, что совместно со Scrum эта концепция жить не может. Мы от нее отказались, оставив OKR только как высокоуровневое планирование. Кроме того, у нас появились OKR компании на год. Казалось бы, это ключевая вещь, и как мы могли два года работать по OKR без этого?.. Но вот, могли.
Были и другие трудности, преодоление которых потребовало времени. И хотя сейчас ситуация во многом наладилась, периодически мы продолжаем с ними сталкиваться:
Стоит заметить что многие из этих проблем решаются достаточно просто, за счет лучшей организации работы. Для того чтобы квартальные OKR появились вовремя, их нужно начать планировать заранее. Несмотря на всю банальность и самоочевидность такого решения, бывали случаи, когда мы его упускали. Тем не менее, со временем процесс работы по OKR у нас наладился, и перечисленные проблемы во многом являются скорее исключением, чем правилом.
Однако для решения ситуации с тем, что «некоторые менеджеры не умеют правильно формулировать цели по OKR», потребовался другой подход. Умение делать что-либо не приходит само по себе, даже если все шаги работы организуются своевременно. Правильно формулировать цели по OKR — это действительно сложно, тут нужен навык. И для его приобретения важна как теория, так и практика. Последняя — совершенно необходима. В этом вопросе нам помог внутренний тренинг по формулированию OKR. Он включал теорию, практику и разбор ошибок. Я как автор тренинга проводил его в 2017 году около 10 раз, с различными группами уровня от менеджеров команд до старших менеджеров компании. Во многом это принесло пользу.
Сейчас, в 2020 году, если сравнивать Wrike до и после OKR, можно сказать, что внедрение OKR было однозначно полезным. И тут хочется отметить не только позитивное влияние OKR на продуктивность работы компании в целом, но и на те культурные изменения, которые принесли OKR для каждого сотрудника. С OKR глобальные цели компании стали понятны и доступны всем, а работа каждого — более осмысленной и значимой. OKR позволяют понять, как отдельная задача, выполненная лично тобой, влияет на цели компании и ведет к развитию бизнеса. Конечно, не для всех, но для многих это важно.
Тем не менее, если бы сейчас можно было отмотать время назад и поменять что-то в истории с OKR, это точно стоило бы сделать. Многих проблем можно было избежать, многое можно было сделать лучше, а главное, гораздо быстрее. Если бы у нас была такая возможность, то еще в 2015 году стоило подробно разобраться в подходе OKR, донести его до всех вовлеченных сотрудников, спланировать внедрение OKR и организовать исполнение. Но тогда информации оказалось мало, или мы недостаточно усердно ее искали. Что совершенно точно — не у кого было спросить совета. Хорошо, что сейчас такая возможность есть.
20 Апреля 2020 года, уже совсем скоро, пройдет Online-конференция «OKR Russia», на которой можно будет услышать экспертов из многих российских компаний, внедривших OKR. Там будет и мой маленький доклад: «OKR: Как правильно формулировать цели». Изначально конференция планировалась вживую, но в связи с COVID-19 была перенесена в Online. Но это и хорошо, новый формат позволил расширить аудиторию до 500 участников, так что сейчас все еще есть возможность зарегистрироваться. Не упустите её, если тема OKR вам интересна.
—
Дмитрий Мамонов,
Wrike
P.S. В связи с COVID-19 многие компании перешли на удаленный формат работы, для организации которой отлично подходит Wrike. Кроме того, в Wrike помогает эффективно работать по OKR (см. шаблон), совмещая планирование и Execution.
Методология OKR строится на принципе управления по целям (какой результат мы хотим получить), что существенно отличается от менеджмента на основе плана (кто, что и когда должен сделать). В развитии OKR-подхода можно выделить три ключевых этапа:
- 1954 год — Peter Drucker предлагает подход Management by objectives в своей книге «The Practice of Management».
- 1983 год — Andy Grove, сооснователь Intel, развивает эту идею в своей книге «High Output Management», сс. 50, 112-113.
- 1999 год — John Doerr, работавший в Intel с 1974 года, инвестирует в Google и приносит туда идеи OKR выработанные в Intel. Google быстро адаптирует этот подход и, позже, начинает продвигать его и вне компании.
Активное продвижение OKR на широкую аудиторию, по всей видимости, происходит с 2012 года, когда Google начал пропагандировать OKR, см. видео. Так что для широкого круга менеджмента это все еще достаточно новая тема, пусть ее корни и уходят вглубь 1950-х.
В 2015 году мы в Wrike сделали первый подход к OKR. К тому моменту у нас уже работало квартальное планирование, но организовано оно было достаточно хаотично. Часто квартальные планы включали излишне-мелкие подробности, а самих квартальных проектов оказывалось слишком много. Как следствие, сами планы часто получались несогласованными и нереалистичными. Начать использовать OKR как инструмент квартального планирования на тот момент было вполне логичным шагом, так мы и поступили.
Первое внедрение OKR прошло просто, слишком просто. Посыл был следующий: второй квартал нужно спланировать по OKR, точка. Сказано — сделано. О том, что такое OKR, каждый был волен узнавать самостоятельно. «Хорошим» источником информации на эту тему была Wikipedia. Предсказуемо, что первый подход получился не вполне успешным. Мы взяли форму OKR, но не поняли сути. Пожалуй, процесс квартального планирования стал чуть более организованным, но и только. Следующие два года тема OKR у нас не развивалась, мы были заняты другими, более важными для нас организационными изменениями.
В 2016 году мы активно расширяли штат разработки, тогда же внедрили Scrum. См. статьи: «Scrum: Правила Игры» и «Худой Scrum лучше доброго Agile». Scrum дал нам возможность масштабировать разработку, сделать ее организованной, управляемой и предсказуемой. Сейчас более чем очевидно, что это был самый правильный шаг, и хорошо, что мы тогда не стали вопреки всему развивать тему OKR. Наивно пытаться спланировать квартал, если ты не можешь спланировать работу даже на ближайшие две недели. А именно в этой ситуации мы и находились. То, что мы наладили краткосрочное планирование по спринтам, в конечном счете дало нам возможность осмысленно планировать квартал, а затем и год.
В 2017 мы перезапустили OKR. На этот раз мы начали всерьез и глубоко изучать вопросы: «Что такое OKR?» и «Как работают OKR?». На эту тему у меня вышла хорошая статья: «OKR: Как поставить цели и выполнить их на 70%». Любопытно, что статью продолжают читать и спустя три года после публикации, такое редко бывает. Кроме того, нас волновал вопрос: «Как совместить OKR и Scrum?». Ответ на него мы нашли в концепции, о которой я рассказывал на одном из Wrike-митапов: «OKR: Стратегическое планирование поверх Scrum» (видео, слайды).
Суть концепции в том, чтобы ограничить использование OKR только стратегическим уровнем, а Scrum применять на тактическом. Мы ставим OKR только на уровне всего инжиниринга и продуктовых юнитов (групп Scrum-команд под общим управлением Sr. Product Manager). Ниже этого уровня мы OKR не применяем, там работает либо Scrum, либо менеджмент руководителей подразделений разработки. Это наша специфика. Оригинальный подход OKR подразумевает сквозные цели, вплоть до OKR конкретного разработчика. Но наш опыт показал, что совместно со Scrum эта концепция жить не может. Мы от нее отказались, оставив OKR только как высокоуровневое планирование. Кроме того, у нас появились OKR компании на год. Казалось бы, это ключевая вещь, и как мы могли два года работать по OKR без этого?.. Но вот, могли.
Были и другие трудности, преодоление которых потребовало времени. И хотя сейчас ситуация во многом наладилась, периодически мы продолжаем с ними сталкиваться:
- Бывает, что квартальные OKR у нас появляются лишь спустя пару недель после начала квартала.
- Случается, что мы финализируем планы на следующий квартал, еще не оценив результаты предыдущего.
- Оценки достижения Key Results во многих случая выставляются субъективно.
- Постановка совместных Objectives между двумя функциональными подразделениями дается нам с трудом.
- Также работе по совместным целям зачастую выделяется меньший приоритет, чем работам по целям внутри направления и подразделения. Это часто приводит к провалу совместных целей.
- Некоторые менеджеры не умеют правильно формулировать цели по OKR. Вместо этого они продолжают стоить квартальные планы, выдавая их за OKR.
Стоит заметить что многие из этих проблем решаются достаточно просто, за счет лучшей организации работы. Для того чтобы квартальные OKR появились вовремя, их нужно начать планировать заранее. Несмотря на всю банальность и самоочевидность такого решения, бывали случаи, когда мы его упускали. Тем не менее, со временем процесс работы по OKR у нас наладился, и перечисленные проблемы во многом являются скорее исключением, чем правилом.
Однако для решения ситуации с тем, что «некоторые менеджеры не умеют правильно формулировать цели по OKR», потребовался другой подход. Умение делать что-либо не приходит само по себе, даже если все шаги работы организуются своевременно. Правильно формулировать цели по OKR — это действительно сложно, тут нужен навык. И для его приобретения важна как теория, так и практика. Последняя — совершенно необходима. В этом вопросе нам помог внутренний тренинг по формулированию OKR. Он включал теорию, практику и разбор ошибок. Я как автор тренинга проводил его в 2017 году около 10 раз, с различными группами уровня от менеджеров команд до старших менеджеров компании. Во многом это принесло пользу.
Сейчас, в 2020 году, если сравнивать Wrike до и после OKR, можно сказать, что внедрение OKR было однозначно полезным. И тут хочется отметить не только позитивное влияние OKR на продуктивность работы компании в целом, но и на те культурные изменения, которые принесли OKR для каждого сотрудника. С OKR глобальные цели компании стали понятны и доступны всем, а работа каждого — более осмысленной и значимой. OKR позволяют понять, как отдельная задача, выполненная лично тобой, влияет на цели компании и ведет к развитию бизнеса. Конечно, не для всех, но для многих это важно.
Тем не менее, если бы сейчас можно было отмотать время назад и поменять что-то в истории с OKR, это точно стоило бы сделать. Многих проблем можно было избежать, многое можно было сделать лучше, а главное, гораздо быстрее. Если бы у нас была такая возможность, то еще в 2015 году стоило подробно разобраться в подходе OKR, донести его до всех вовлеченных сотрудников, спланировать внедрение OKR и организовать исполнение. Но тогда информации оказалось мало, или мы недостаточно усердно ее искали. Что совершенно точно — не у кого было спросить совета. Хорошо, что сейчас такая возможность есть.
20 Апреля 2020 года, уже совсем скоро, пройдет Online-конференция «OKR Russia», на которой можно будет услышать экспертов из многих российских компаний, внедривших OKR. Там будет и мой маленький доклад: «OKR: Как правильно формулировать цели». Изначально конференция планировалась вживую, но в связи с COVID-19 была перенесена в Online. Но это и хорошо, новый формат позволил расширить аудиторию до 500 участников, так что сейчас все еще есть возможность зарегистрироваться. Не упустите её, если тема OKR вам интересна.
—
Дмитрий Мамонов,
Wrike
P.S. В связи с COVID-19 многие компании перешли на удаленный формат работы, для организации которой отлично подходит Wrike. Кроме того, в Wrike помогает эффективно работать по OKR (см. шаблон), совмещая планирование и Execution.
mudriyjo
Вы пишите что внедрение OKR было однозначно полезным, подскажите как сравнивали эффективность предыдущего планирования и через OKR? Не могли бы привести примеры метрик по которым работа с помощью OKR дала наибольший эффект. Спасибо
dm_wrike Автор
Спасибо за комментарий, очень рациональный вопрос)))
Увы, пример метрики, на которые в наибольшей степени повлиял переход на OKR
я привести не могу. Просто потому что введение таких метрик у нас стало
следствием перехода на OKR.
dm_wrike Автор
Думаю, будет не лишним раскрыть мой ответ в предыдущем комментарии.
Эффективность планирования можно оценивать на трех уровнях:
1. На уровне итогового влияния на конечный продукт и его интегральные метрики, такие как NPS (Net Promoter Score) — выполнение проекта это средство, цель — повышение ценности продукта
2. На уровне портфеля проектов — стали ли мы выполнять в квартал больше проектов и стала ли выше доля успешных проектов.
3. На уровне индивидуальных задач и SDLC (Software Development Life Cycle) — стали ли задачи проворачиваться быстрее (время от начала работы до ее завершения) за счет введения нового подхода к планированию.
Разберем все эти три уровня, один за другим.
1. Оценить эффект от внедрения OKR на уровне итогового влияния на весь продукт на уровне
объективных метрик (таких как NPS) действительно нет возможности. Систематическое
внедрение подобных метрик как раз и было следствием перехода на OKR,
о чем и говорилось в предыдущем комментарии.
2. Оценить эффект от внедрения OKR на уровне портфеля проектов можно,
но это в бОльшей степени будет субъективная оценка. И внедрение OKR (2015),
и перезапуск OKR (2017), это были длительные процессы и в тот же период
в компании происходили другие изменения: внедрение Scrum,
существенное расширение Engineering и так далее. Позитивные улучшения в
работе с портфелем проектов явно наблюдалось
(как в плане количества так и в плане доли успешно завершенных проектов),
но приписывать эти изменения только переходу на OKR было бы недобросовестно.
В статье указано что
да это в определенной степени субъективная оценка, связанная с личным опытом
планирования работы в инжиниринге на квартал без OKR и с их использованием.
В поддержку этой позиции, следует заметить, что ни один менеджер ни разу не предложил вернуться к старой схеме. Для тех кто понимает, думаю это будет показателем.
3. Оценить эффект от внедрения OKR на уровне SDLC — тут, теоретически можно
было бы опереться на формальные метрики. SDCL мы измеряли и до внедрения OKR.
Однако, тут играют два фактора:
а) внедрение OKR (как уже говорилось) было длительным, и другие организационные изменения могли повлиять на объективные метрики по SDLC
б) OKR влияют на стратегическое планирование, а большинство частных задач разработки от него не зависят (из тех которые начаты)
Таким образом, достоверно говорить о влиянии OKR непосредственно на процесс разработки также было бы не корректным.
Была ли польза (повысилась ли эффективность планирования) от внедрения OKR — субъективно в этом нет сомнений.
Можно ли достоверно подтвердить это утверждение объективными метриками — увы, такой возможности нет, по описанным выше причинам.