Это не конспект и даже не попытка как-то целостно описать практику OKR (Objectives and Key Results), а просто заметки о том, что показалось интересным и новым лично мне, плюс немного связанных с темой мыслей.

Фокусировка

OKR-ов не должно быть много, иначе погонишься за всем и не сделаешь ничего. 2-3 ключевых фокуса на самом верхнем уровне. Дальше цели будут декомпозироваться по кварталам и командам и их может стать много (особенно в крупных организациях), но в фокусе каждой конкретной команды их должно быть все равно не больше 2-3 штук. Удавливание мультитаскинга всегда работает как из пушки).

Синхронизация всех подразделений компании вокруг выбранных целей

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

Эмоциональная составляющая

В цели (objective) важна эмоциональная составляющая, она должна нравиться, вызывать положительную реакцию, зажигать. Даже если по формальным признакам цель выглядит криво (не измеримая, субъективная и пр), но от нее «прёт» — это как раз то что надо. При этом просто взять и подсмотреть цель в каком-то примере не получится — важен именно наш собственный контекст: цель, которая вдохновляет людей в одной компании, может показаться бредовой для людей из другой компании (даже если это компании работают в одой сфере). У них другая культура, другой контекст и пр.

В этом плане «O»[bjective] из OKR похожа на «зеленые задачи» у Дорофеева (задачи, от которых в животе бабочки). А «красные задачи» (которые по Дорофееву помогают удерживаться на месте, но при этом не факт, что они приятные) похожи KPI (Алексей описывал KPI как способ удерживать текущий уровень чего-либо: SLA, скорость выполнения задач и пр). При этом одно не отменяет другое и оба подхода могут использоваться одновременно (главное, не завязывать на выполнение KPI премии/зарплаты, иначе этим показателям больше нельзя будет доверять).

Не усложнять

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

Можно менять на ходу, ничего не прибито гвоздями

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

Материалы по смежным темам:

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

Выводы

Выводы исключительно субъективные, основаны на том что понял (или недопонял) на тренинге и том, что раньше знал про OKR. Скорее всего, всё сильно более многогранно и требует более детального изучения темы.

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

Но точно это не серебрянная пуля (как и SCRUM/Agile и прочие buzzword). Всё как всегда: важно содержательное погружение в конкретную ситуацию, вовлеченность команд (особенно трансформационной), их кругозор, владение фундаментальным знаниями, любознательность и пр. Взять пример, который Алексей приводил про цель с красотой и здоровьем («хорошо выглядеть к летнему сезону»): как без кругозора и опыта правильно декомпозировать это в KeyResults? И вообще, а правильная ли это Objective? Как узнать, что нужно поставить целью восстановление пищевого поведения и использование правильного рациона, вместо бездумного (и часто вредного) ограничения потребляемых калорий или многочасовых изнурительных занятий в спортзале? Это на таком бытовом примере всё кажется более-менее очевидным, а в более сложных областях (та же разработка более-менее сложного софта) — всё сильно сложнее и нужны те самые фундаментальные знания, кругозор и пр.