В январе 2021 года я закончил работу с Хабром по формированию их новой стратегии. Мы описали стратегию в формате Х-матрицы, дальше ребята сказали, что сами декомпозируют X-матрицы на департаменты, и спросили, с помощью какой системы лучше реализовывать стратегию. Я ответил, что на сегодняшний день не знаю ничего лучше OKR (Objectives and Key Results): она гибкая, не требует особых знаний и понятна всем, кто так или иначе сталкивался с Agile. Мы ударили по рукам и разошлись.

Однако уже в мае ко мне постучались Денискин и Баксли с просьбой посмотреть, что не так. Ребята попытались сами внедрить ОКR, но что-то пошло не так, и система не приживалась. После небольшого анализа был выявлен ряд ошибок, основной из которых у Хабра, на мой взгляд, стала попытка внедрения сразу во всей компании.

Ниже перечень этой и прочих ошибок, которые были обнаружены мною в Хабре, а также в других компаниях, где я наблюдал или внедрял OKR

⚠️ Предупреждение!

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

Ошибки при внедрении OKR

Некоторые, но не все перечисленные ошибки мы попытались обсудить на совместном вебинаре с ФРИИ. Получилось сумбурно, но, возможно, кому-то будет удобнее просмотреть основной материал так. Однако в видео разобраны 6 ошибок. А ниже будут описаны все 13.

Ошибка 1. OKR — это не MBO

MBO (Management by Objectives) — прародительница OKR, система исполнения целей.

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

Однако зачастую: 1) мы сами не знаем, как и когда сможем действительно реализовать цель, мы видим лишь ближайшие возможные шаги и основные вехи; 2) планы выбиваются из графика практически на следующий день после их составления. Плюс нередко меняются сами цели, тем более люди, границы ответственности и сроки.

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

А мы с вами живём в эпоху неопределённости, и эта неопределённость только нарастает. Но нас в ней жить не учили. Наше сознание протестует и просит чётких назначений. У тревожных ещё и повышается (и терзает) тревога от осознания возрастания энтропии — надо же, не все действия приводят к результату, и иногда надо что-то поделать впустую для понимания, что же на самом деле стоит сделать. Но пустое действие и кажется пустым, не ценным, его не пощупать, никуда не вписать, им не получится гордиться. То есть оно не успокаивает.

OKR же сосредоточен на коротком отрезке, на ближайшем месяце или квартале. Тебе нужно заработать 100 рублей к концу года, и ты не знаешь как. Ок. А что ты можешь сделать для этого сегодня или в ближайший месяц? Всего лишь поговорить с Петей и Машей? Отлично. Итак, пишем:

Январь 2022 года.

Цель — заработать 100 рублей к декабрю 2022.

Ключевой результат января — проведены интервью с Машей и Петей.

Еще раз сакцентирую - OKR это про короткий план действий и результатов, про actions, а не про декомпозицию.

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

Ошибка 2. Нет мониторинга

Я не раз видел, как ставились ОКРы на квартал, а то и на полгода, и... забывались. Потом, ближе к делу, оказывалось, что никто ничего не сделал, и появляется фраза «Мы уже пробовали ОКР — не работает».

Нужно ли объяснять, почему не сработало?

Нужна СИСТЕМА, помогающая достигать цели. А декомпозировать и поставить цель на квартал не есть ОКР, не есть система.

С каждым управленцем, у которого стоят ОКРы, нужно проводить часовую сессию раз в спринт (раз в месяц или в квартал), где обсуждаются вопросы «что было» и «что будет». 

А потом надо мониторить исполнение. С каждым из управленцев я созваниваюсь ещё и еженедельно, но ровно на 5–10 минут, спрашиваю, как дела (см. картинку ниже), какова динамика, и заношу данные в табличку (как на картинке выше). Такие еженедельные чекапы.

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

Ошибка 3. В качестве и Целей, и Ключевых результатов ставятся деньги

Я люблю ставить своим подчинённым цели в деньгах, как они их добиваются, мне неважно, это уже их зона ответственности, — услышал я однажды, когда рассказывал про OKR.
Сколько вам лет? 
40
Вы уже долларовый миллионер? Нет? Так возьмите ответственность в свои руки и станьте. Хватит быть безответственным и бесцельным! Как? Вы уже давно ставите себе такую цель и не можете себя назвать безответственным? Видите, дело не в наличии денежной цели и ответственности.

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

Ошибка 4. Нет «спонсора»

Когда мы начали внедрять ОКР для команды акселератора ФРИИ, то первые два месяца у Гаджи (Гаджимурад Алиев — руководитель акселерационных программ в ФРИИ) не было времени участвовать во встречах. ОКРы сильно хромали.

– Гаджи, ты там нужен, иначе не заработает.

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

В общем, как родители у детей-спортсменов. Есть тренер, но без родительской воли ребёнок предпочёл бы шастать по дворам или играть дома. Я называю такого человека спонсором — вы называйте как хотите )

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

Странно, но именно молодых управленцев до и около 30 тяжелее всего убедить в необходимости перемен. Их типовые паттерны работы привели к успеху, сделали их директорами и ведущими спецами ещё до 30 лет. А вот с теми, кому за 40, но они ещё хотят надрать всем задницы, легко залетают и реализуются новые фишки.

Ошибка 5. Внедряют по всей компании

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

В Хабре как раз попытались внедрить сразу везде.

Но:

  1.  Сразу у всех возникли вопросы, а как правильно? ОКР это или нет? Как правильно сформулировать OKR? Все сразу всполошились, заволновались, кинулись спрашивать друг у друга. Энтропия очень высока. Проще проговорить, обучить, настроить 5–6 человек, чем 50, а тем более 500.

  2. Сопротивление будет. Но проще проработать сопротивление небольшого отдела или топов, но не когда это сопротивление рассеяно по всей компании сразу, да ещё и не всегда очевидно, у кого именно и почему. В команде из 5-6 человек проще определить и проанализировать сложности.

  3. Будут ломаться типовые, принятые модели управления, а это не всегда необходимо. Одним из частых вопросов является:

    – Гай, как внедрить ОКР у разработчиков?
    – А зачем?
    – Ну мы внедряем ОКР в компании, как правильно поставить ОКР айтишникам?
    – Не надо им ничего ставить, ломать, менять. Работает — не трожь! Они и так хрустальные. Тронешь — грозятся уволиться и жалуются на невыносимые условия работы. А тут вы со своими суперидеями про OKR.

    Как ИТ привыкли работать, пусть так и работают, используют свой любимый тип «срамбан». Но можно поставить ОКР для IT департамента, а как они его реализуют — с помощью внедрения ОКР в своих командах или Scram — неважно.

  4. Слушайте, у оператора колл-центра не может быть ОКР. Его задача — принимать звонки, идти по скрипту. Выдумывать OKR для каждого сотрудника — бессмысленное занятие. Многие из них должны просто делать свою работу. Как и многие программисты должны просто писать код. ОКР ставятся там, где нужны изменения. Какие изменения у оператора колл-центра? Да нет их. У оператора колл-центра есть KPI: количество звонков и т.п. Разделяйте KPI и OKR. Но изменения могут быть у руководителя колл-центра: поменять скрипты, ит-систему, добиться большего прохода или большей конверсии или снизить затраты.

  5. Если делать ОКР грамотно, то у одного сотрудника уйдёт около 9 часов (а то и больше) в месяц на «поговорить и послушать других». На ежемесячных ретроспективах, в команде из 6 человек, уйдёт по часу на каждого, при этом остальные должны присутствовать и слушать, а не убегать. Это, по сути, стратегическая сессия, а не индивидуальное интервью. Сессия, направленная на месячные стратегические задачи. Да, всем хочется отбрехаться и убежать делать свою работу. Только не в этом смысл. Смысл также в коллективной работе: синхронизация, дополнение, совместные идеи и проекты. Итого сессия в команде из 6 человек = 6 часов. Добавьте ещё еженедельные чекапы по 30 минут. Итого минимум 9 часов на поговорить и послушать. Вы готовы тратить столько времени каждого сотрудника? Это недёшево. Посчитайте КПД. 

  6. В качестве альтернативы, чтобы не тратить столько времени предлагают использовать то, что называют "Вернисаж", то есть демонстрация друг-другу уже проработанных OKR. То есть коллеги не присутствуют при анализе прошлого цикла и постановке новых, но могу посмотреть на итог, у кого какие цели и предполагаемые результаты. Много ли из этого запомнится?
    Одна из основных проблем удаленной работы - это отсутствие коллективного опыта. Это очень больно, просто эта проблема руководителями небольших компаний и коллективов не осознается в полной мере. Функцию сбора, обработки и передачи коллективного опыта, в офлайне, выполнял средний менеджмент - разговорами за кофе и в курилке. И мы 50% своего роста, опыта и мыслей, черпали из этих разговоров у кулера. Так вот, с моей точки зрения, пусть лучше вся команда слушает как анализируются и ставятся окры команды/департамента, чем будут тратить время на свои частные окры и вернисаж.

И если в отдельных командах или у топов КПД зашкаливает вверх, то при распространении на всю компанию КПД может активно стремиться к нулю.

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

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

Но историю про «давай придумывай себе ОКР на этот цикл, какие, с-ка, амбициозные цели ты собираешься достигать в нашей великой компании по торговле семечками?».

– Мы не семечками торгуем.
– А чем?
– Услуги перфоманс маркетинга!
– Сидишь объявления в Директ.Коммандере клепаешь?

Сотрудники тужатся, выдумывают эти «семечные» OKR, а потом ещё устраивают «вернисаж» окров. У кого-то эго тешится и происходит наслаждение сей бурной деятельностью.

Ещё раз — на мой взгляд, персональные ОКРы применимы, когда они логично вытекают из командных.

– Как же, Гай, у меня вот есть личные OKR. 

Я подозреваю, если копнуть глубже окажется, что это ОКР компании (если вы директор), а не ваш личный. Или ОКР департамента, если вы топ-менеджер. Или ОКР команды… 

Просто вы отвечаете за реализацию этих целей, это ваша зона ответственности или зона исполнения.

У человека могут быть ОКРы в личной жизни, направленные на его изменения в его жизни, но на работе делаем работу для компании. Ну если только вы не готовы позволить сотрудникам тратить 1–2 дня в неделю на личные проекты, как в известной компании, которая и популязировала эту систему целей и ключевых результатов.

Ошибка 6. Путают цели, KPI и задачи

То, что денежные цели не рекомендуется ставить в ОКР, мы обсудили выше. То, что задача типа «выслать презентацию Валере» — надеюсь, тоже очевидно, что это не цель и не ключевой результат. (Но тут надо с оговоркой. Бывало, в Хабре всплывали вроде бы простые быстрые задачи, но они были стратегически важными, и чтобы не забыть и удержать внимание коллектива, такая задача заносилась в ключевые результаты).

Что касается KPI и ОКР. 

KPI ставится на что-то привычное, понятное, то, что вы уже делали. Обычно это улучшение типового процесса или типового проекта.

ОКР — про изменения, про то, что вы ещё не делали, про новое. Ставить тут KPI сложно, нет опыта. Если вы никогда не бегали 10 км, нет смысла ставить себе KPI, можно поставить цель (ОКР) — пробежать 10 км. КРом тут может быть и просто покупка формы, ознакомление с техникой бега, поиск 3-х школ бега.

Но если вы регулярно бегаете 10 км, можно ставить всё более высокие KPI.

КР в формате «позвонить 30 клиентам» или «разослать 55 коммерческих предложений… можно брать как OKR только если это делается впервые, если в этом есть новизна и изменения. А если это про сотрудника отдела продаж, который до этого высылал 54 предложения, или совершал 29 звонков, а теперь решил взять цель поамбициозней — это не ОКР, это KPI.

Иногда, редко, можно увязать KPI с ОКР следующим способом. Пусть KPI станет целью, обжективсом. Тогда вопрос звучит примерно так:

  • Что мы готовы сделать в этом цикле, чтобы к концу года реализовать KPI? Давайте определим КР, которые можем попробовать достичь за этот месяц.

Если я, например, никогда не открывал филиалов компании, не выводил новых моделей продуктов — это всё ОКР. Я не знаю, как это делать, сколько займёт времени и бюджета. Да, я предполагаю, но не знаю, надо пробовать — это ОКР.

А если я опытный управленец — это типовые вещи для меня — можно ставить передо мной KPI.

Это как строить дом. Вроде всё понятно, но на свои грабли наступишь, если ты не построил уже десяток домов до того.

Поэтому к KPI привязывается финансовая мотивация, а к ОКР нет. Если к ОКРам привязать финансовую мотивацию, то войдём в треугольник Сроки-Бюджет-Объём. Тогда человек выверит всё с точностью до метра, чтобы получить премию, он не будет прыгать выше головы, стараться завершить проект раньше или сделать больше объёма. Он будет получать премию, а не пробовать, а не опыт и результат. Он не будет рисковать, не будет пробовать новое — тем более там, где вообще нет опыта.

Он не будет стремиться к прорыву. А мы же помним, что в ОКР принято ставить амбициозные цели. Однако...

Ошибка 7. Ставят амбициозные цели с самого начала

Во-первых, куча времени и разговоров уходит на «это амбициозно или нет?». Достаточно амбициозно, может, ещё добавить? 

Во-вторых. В действительности вы сами ещё не знаете, что амбициозно, а что нет. Провести 30 встреч за месяц — это амбициозно или нет? Не знаю, если не проводил.

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

Именно цели, а не задачи. Закрыть 100% задач не так сложно.

В общем, моя рекомендация — начните с таких целей, которые вы считаете реалистичными. Не тратьте время на лишнюю оценку.

Через 2–3 месяца у вас будет опыт в постановке и реализации собственных ОКРов — тогда и начнёте ставить амбициозные цели.

Ошибка 8. Обесценивают сделанное

Это зачастую проблема людей с хорошим, но техническим образованием. У них бинарное мышление: сделано/не сделано. Причина — следствие. 

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

– Лендинг готов?
– Нет, написали техническое задание и передали дизайнерам.
– Ок. На сколько баллов ты бы оценил результат за неделю по 10-балльной шкале?
– На ноль.
– Почему?
– Так лендинг-то не готов.

Если приглядеться, то выживать и добиваться успеха нам больше помогает негативный опыт. За одного битого двух небитых дают. 

Даже если тебе надо запустить проект, а ты за неделю успел только провести два проблемных интервью, да пусть одно интервью — это уже результат! Оцени его. Пусть будет 1 балл, но добавь его.

Не обесценивай того, что сделано!

Если ты делал, но результата нет, или он отрицательный, добавь себе баллов! Ты же получил классный опыт! Ты двигался, пробовал, делал!

Не обесценивай того, что ты сделал.

Ошибка 9. Создают кросс-функциональные команды

Если вы создали отдельную команду под проект, и у неё есть ОКРы, вы, по сути, внедрили матричную систему управления в компании, но ещё не поняли этого. Часто менеджеры и специалисты даже не знают, что такое матричная система и в чём её минусы.

Это когда у человека одновременно двойное подчинение: и руководителю своего департамента, и проектному руководителю. То есть расфокусировка = КПД идёт вниз.

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

Я против и стараюсь избегать матричного подхода (но не всегда это возможно). Лучше в таких ситуациях...

Ошибка 10. Не осознают разницу в зоне контроля и в зоне ответственности

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

Ставится цель — презентовать новую бизнес-модель целевой аудитории. КР на текущий месяц = лендинг готов.

– Лендинг готов?
– Нет
– Почему?
– Мы написали техзадание и передали дизайнерам, но дальше всё зависло.
– На сколько баллов оцениваешь динамику?
– На ноль. Лендинга-то нет.
– Знаешь, в чём проблема?
– В чём?
– Ты поставил КР вне зоны своего контроля. Да, лендинг и его вывод — твоя зона ответственности. Но сам КР, как он сформулирован — вне зоны контроля в рамках ограниченного времени.
– И какой КР лучше было ставить?
– А ты как думаешь? Что ты реально со своей стороны можешь сделать для того, чтобы лендинг появился?
– Только написать техзадание и пушить процесс.
– Давай так и запишем:

  • КР 1. Написать техзадание по лендингу.

  • КР 2. Пушить раз в неделю ИТ-департамент (4 пуша в месяц).

– Идёт так?
– Идёт
Дизайнеры, какой КР вы возьмёте себе по данной цели?

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

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

Ошибка 11. Не хотят тратить время на болтовню

Я с улыбкой наблюдаю желание управленцев больше делать и меньше болтать. Причём желательно делать в своём уголке свою работу, да так, чтобы тебя никто не трогал.

Только пара вопросов:

  1. Причём тут слово «компания»? Компания = много людей. Если все по углам, и каждый в своём — это не компания.

  2. Вы точно управленец? Скорее всего, специалист. Специалист, назначенный на управленческую должность, который продолжает оставаться специалистом, ставить рекорды в своей работе, да ещё дорабатывать за так называемыми подчинёнными.

Послушайте старика, задача у управленца одна — болтать!

Давайте немного отвлечёмся. Представьте себе картину, образ: врач оперирует.

Есть картинка?

Представьте себе картину, образ: пекарь печёт хлеб.

Представьте себе картину, образ: программист пишет код.

Во всех этих случаях картинка понятна, и вы все её более-менее одинаково можете накидать. А теперь суперзадача:

Представьте себе картину, образ: управленец управляет. Или директор руководит.

Что выдаёт ваше воображение? Разговор!

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

Но это долгий разговор.

Ошибка 12. Начинают с квартальных циклов

Начните с месячных спринтов. Тогда за 3–4 месяца вы получите 3–4 обсуждения на ретроспективе, 3–4 набора косяков, достижений, 3–4 опыта. И где-то после 4-го месяца система заработает.

Через 6 месяцев можете переходить на квартальное планирование.

Но не начинайте с квартального. Так система не войдёт «в кровь». К 3-му месяцу все могут забыть. Так вы получите достаточный опыт только к концу года. Да и то вам будет его сложно осознать и оценить из-за того, что он был растянут во времени, не сконцентрирован.

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

  • с отлаженным регулярным менеджментом, а это важно;

  • опытными управленцами;

  • работающими с более определёнными продуктами;

  • живущими на более определённых рынках.

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

Ошибка 13. Самая спорная. Ставят только измеримые результаты

Ох, самый сложный блок.

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

А когда вы начинаете заниматься взрослым маркетингом и управлением, а не трафиком и воронками по лидам, то очень сложно (да и нет смысла) определять цифры.

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

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

Так что пока меня вполне устроит КР в виде:

  1. Проведён брейншторм

  2. Создан мануал для кураторов

Если углубиться в тему классификации типов целей и ключевых результатов, то вы найдёте с пару десятков, если не больше, типов целей и результатов. Могу порекомендовать книгу Коптелова по OKR, там их немало. Рекомендую конкурента — пользуйтесь, сравнивайте, оценивайте, давайте обратную связь, повышайте уровень консалтинга в России.

А мне некогда, и я туповат, да и оперативка загружена вопросами более сложного порядка, чем обязательное определение классификации данного типа целей (или просто обязательное определение оцифрованного результата). Я использую три типа:

  1. Сделано — не сделано (там, где задача действительно бинарна).
    Встреча проведена или нет.

  2. Цифра — там, где очевиден цифровой результат.
    Конверсия — 3%. Прототип проехал 100 км.

  3. Регулярные — там, где что-то важно делать регулярно.
    3 пробежки за неделю. Провести 4 еженедельные проверки.

На картинке ниже есть числовые (N) и шкалирование, сейчас я убрал тип шкалирование — всё равно это числовое (N).

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

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

Прошлым летом я работал с рекламных холдингом Dentsu. Одна из болей была, что в R&D департаменте сложновато с оценкой результатов. В R&D результаты можно увидеть очень не скоро или не увидеть совсем. Проще перестать искать цифры, actions тоже хорошо, а зачастую даже лучше.


OKRA

Вышеописанные подходы привели нас в итоге в Хабре к тому, что мы, дабы не вступать в споры с ярыми апологетами функционально-оцифрованного подхода, стали называть это не OKR, а OKRA (Objectives, Key Results and Actions).

Что ты готов сделать сейчас (actions) для достижения цели — стало основным вопросом. А можем ли мы измерить результат — вторичным и необязательным.

На мой взгляд, определять действия и действовать важнее, чем пытаться всюду искать и определять цифровые метрики. Если такая метрика не на поверхности (а так будет в 99%, если вы берёте управленческие вопросы и короткие сроки), то не стоит тратить время на её поиск и определение.

Оппоненты говорят о том, что нужно ставить измеримые результаты и не тратить время на расписывание действий.

Приводится классический пример из Гугла с Хромом. Мол, поставьте КР, допустим, в 1 000 000 пользователей, и пусть команда или руководитель внутри определяет, что делать.

Коллеги!

  • Это не российская действительность, не наше управление.

  • Что ни говори, а Гугл — компания с поставленным управлением и исполнением.

  • Люди там работают совсем другого уровня, да и по-другому мотивированные.

Хотите парадокс?

Как правильно заметил однажды Святослав Бирюлин (ещё один конкурент — берите, пользуйтесь), наши управленцы прекрасно умеют декомпозировать цели, но не превращать их в действия. Ибо далее оно или само реализуется, или, видимо, шах сдохнет или ишак — что-то да будет.

Позовите своих управленцев, поставьте перед ними годовую цель и попросите их написать план действий (action plan) для достижения цели.

В 80% случаях вы получите декомпозицию цели, но не план действий.

В 80% случаев, это означает, что они ничем не управляют, значит, нет фрейма управления.

Я не раз видел историю, когда управленец берёт на себя амбициозный результат: сделаю 1000, нет надо амбициозней, сделаю 2000 (неважно, чего).

Цель — отобрать 20% рынка у конкурента Z.

КР — у нас в системе 2000 штук.

А приходит через цикл ни с чем — с 200 или вообще 50. Спрашиваешь, а что ты думал, когда заявлял такой результат?

Ну у меня была идея одна, но она не сработала.
Ок, а что дальше? Цель-то стоит.
Не знаю. Надо подумать.

Отпускать с такой целью, без чёткого плана действий я своего сотрудника не готов. Я хочу получить результат, а значит, как руководитель, как коуч, как помощник, должен помочь превратить достижение цели в план действий, в action plan, чтобы это была системная работа по заданному фрейму.

  • Я что-то посоветую.

  • Что-то посоветуют коллеги из своего и других отделов.

  • Может, мы проведём дополнительный брейншторм и наберём в беклог список идей (провести шторм, создать беклог идей, протестировать идеи беклога — отличный начальный план).

Надеюсь, вы помните, что я считаю создание фреймов (в глобальном смысле) и их реализацию единственной задачей управленца.

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

Денис (deniskin) Крючков

Издатель Хабра

«OKR помог научиться ставить амбициозные цели и синхронизировал команды для достижения общего результата. Теперь все знают, куда мы идём и какова роль каждого. За счёт OKR появилась ритмичность работы команд, улучшилась фокусировка на задачах. Люди стали смелее брать инициативу и проявлять больше ответственности за результат. Также улучшилось понимание внутренних процессов во всех командах. С тех пор как мы внедрили OKR компания стала более прокачанной в умении планировать свою стратегию и тактику для достижения реалистичных целей. В этом году продолжим работать с OKR и в конце года получим улучшенный и комфортный для всех в компании фреймворк, с которым мы совершенно точно надолго.»

А так подходы в OKR, как я вижу, у каждого всё же свои и зависят от того, кто управляет внедрением и где внедряется.

Комментарии (4)


  1. bugy
    20.01.2022 13:28
    +3

    У нас уже который год в компании пытаются использовать ОКР для разработки (для каждой команды). По мне это не очень адекватно, т.к.:

    • Заставляет разработчиков придумывать! ключевые результаты. Что чаще всего выливается в лучшем случае в "сделать x задач в модуле Y", в худшем в абстрактных попугаев в вакууме

    • Многие результаты зависят от других команд (например, увеличить количество покупок пользователями)

    • Размывает ответственность. По мне проджект/продакт менеджер должен держать в голове план и понимать путь развития. Т.е. ключевые результаты должны исходить из этого. А когда это делают разработчики, то это очень странно, т.к. они отвечают за реализацию и техническое развитие, а не бизнес стратегии.

    • Приводит к "одноногим" решениям и техническому долгу. "Ребята, в этом месяце квартале мы будем повышать показатели X". При том, что Y, Z могут полностью провалиться. И на качество решения тоже пофиг, главное ведь X. Не скажешь ведь потом, что мы сделали (X-5) но зато хорошо

    Ну т.е. вполне вероятно у нас его неправильно готовят. Но за 3 года работы я никакой пользы не ощутил, кроме митингов по имитации бурной деятельности (придумыванию ОКР и придумыванию, как мы будем показывать, что этот ОКР закрыт).

    Как по мне, ОКР конфликтует с законом гутхарда.

    В моём видении:

    • Компания определяет "ключевые" направления развития (чтобы не было сильной расфукосировки)

    • Определяются основные проблемы, мешающие этому развитию

    • Рабочее время на X% выделяется на устранение этих проблем, а на 100%-X% на то, что команды решают важным (другие показатели, технические улучшения, аналитику)


    1. gkarapet Автор
      20.01.2022 22:05

      Что тут сказать?

      С одной стороны остаётся удивлённо пожать плечами.

      С другой стороны, нет компаний с идеальными процессами и довольными сотрудниками, тем более в it)


  1. Koval97
    23.01.2022 08:57

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

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

    Года 3 назад я как-то консультировал администратора одного портала, известного в специфических фанатских кругах. Человек с никнеймом Random. По масштабу они чуть больше Хабра, исполнение более классическое, без костыльных привязок, перегруженных департаментов - компактный коллектив из группы энтузиастов. У них в сущности была точно такая же проблема - они долгое время не могли расставить приоритеты в ходе собственной стратегической сессии. По ходу консультирования я этим вопросом и занялся, разобрали тогда очень многое, но вот не задача - в ковидный 2020-й год ситуация зависла, а спустя ещё некоторое время закисла в том состояние, в котором мне пришлось тогда её оставить.

    А всё просто: администратор не программист и не разработчик. Менеджерские качества есть, а кадров под рукой нет. Спасибо автору за статью, жаль я не знаю его имени, она помогла мне понять очередной кусочек в пазле превентивных предрассудков российского управления. То есть стало ясно, какой следующий шаг нужно сделать непосредственно мне, чтобы помочь одному из любимых порталов решить их головоломку.