Бен Ламорт – Цели и ключевые результаты. Полное руководство по внедрению OKR (страница 21)
Могут ли OKR меняться в течение квартала?
В целом OKR на уровне всей компании не корректируются в течение квартала. Однако не забывайте: все зависит от контекста. Могут возникнуть обстоятельства, требующие изменения OKR.
Несколько лет назад Пол работал с одной государственной организацией из штата Нью-Джерси. Ураган «Сэнди», который пронесся по территории штата, принес значительные разрушения. На протяжении недель и месяцев после катастрофы в системы мониторинга эффективности этой организации вносились существенные изменения, отражавшие новую реальность, с которой столкнулись многие правительственные учреждения, занятые ликвидацией последствий стихийного бедствия.
Мы не считаем, что изменение OKR (на любом уровне) в течение квартала может спровоцировать только природный катаклизм. Найдется множество других причин. Например, у вас появился крупный клиент, который с самого начала претендует на существенные ресурсы ваших команд. Это вполне может послужить основанием скорректировать текущие OKR. Или вы решили резко изменить стратегию. Однако нельзя менять цели или ключевые результаты только потому, что они кажутся вам слишком сложными, либо потому, что у вас появились сомнения в их эффективности.
С каждым кварталом использования OKR вы наращиваете мышечную массу, которая укрепляется по мере того, как вы внедряете практику постановки, мониторинга и оценки OKR. Самое главное — вы учитесь, наблюдая за ключевыми результатами и интерпретируя эти данные.
Многократные изменения OKR в течение квартала могут восприниматься как «гибкость» или адаптивное поведение. Иногда так и есть. Но в большинстве случаев это просто нежелание соблюдать строгость и дисциплину, необходимые для достижения лучших OKR.
Процесс постановки OKR
Итак, мы привели много идей, рекомендаций и советов, касающихся характеристик эффективных OKR. Мы уверены: на данном этапе вы стремитесь внедрить OKR, разрабатывая свой первый набор целей и ключевых результатов. В этом разделе мы расскажем о механизме создания OKR. Этот процесс представлен в виде удачной аббревиатуры CRAFT, которая расшифровывается так: Create — создание, Refine — доработка, Align — согласование, Finalize — финализация, Transmit — распространение (см. рисунок 3.5).
Рисунок 3.5. CRAFT-процесс создания OKR на уровне команды. Алгоритм CRAFT также можно использовать для разработки OKR на уровне компании
Некоторые эксперты скажут: для этого шага соберите команду вместе — будь это топ-менеджеры, если вы создаете OKR на уровне всей компании, или ваша команда, если речь идет о целях на ее уровне. Достаньте новую коробку маркеров, встаньте у флипчарта и, крикнув «Начинаем!», приступайте к классическому мозговому штурму. На вас обрушится вал блестящих идей, и вы едва будете успевать их записывать.
Но мы не советуем так поступать.
Мозговой штурм в расширенном составе — распространенное явление. Однако недавнее исследование выявило недостатки этого процесса. Начнем с количества участников. Логическое обоснование звучит убедительно: вовлечение большого числа людей повышает вероятность того, что они заинтересуются и поддержат то, в чем участвуют. Каким бы разумным ни казался этот тезис, он противоречит выводам ученых-социологов: чем больше группа, тем хуже результативность. Сьюзан Кейн описывает это явление в своей книге «Интроверты»[71]:
Исследование, проводившееся на протяжении сорока лет, показало те же результаты. Согласно полученным данным производительность снижается по мере разрастания группы: команды из девяти человек генерируют меньше идей (причем более низкого качества), чем команды из шести человек, которые, в свою очередь, справляются хуже команд из четырех участников. Бизнесмены, применяющие коллективный мозговой штурм, поступают неразумно. Таковы научные данные[72].
По мнению психологов, есть несколько причин, объясняющих, почему большие группы не способны добиваться значимых результатов. Например, социальная лень: в коллективе всегда найдутся те, кто откинутся на спинку кресла и не будут ничего делать, в то время как другие проведут всю необходимую работу. Наверняка вы отчетливо представили таких ребят: не поднимая головы, они сидят, уткнувшись в смартфоны и ноутбуки, полностью отрешенные от процесса обсуждения.
Поскольку мозговые штурмы в больших группах не всегда эффективны, мы советуем применять подход «барной стойки» для старта работы с OKR. Используйте малочисленную команду, например из двух человек. Сьюзан Кейн и многие другие исследователи отмечают: чтобы найти креативное решение, необходима глубокая, длительная по времени концентрация на задаче. Не ждите, что двадцать (или более) человек отложат все дела и потратят время на разработку проекта OKR. Два человека с большей вероятностью выполнят эту задачу, хотя им и потребуется время. Небольшая группа может изучить бэкграунд, необходимый для создания ваших OKR: определить место компании на рынке и среди конкурентов, изучить стратегию, выявить ключевые компетенции и т. д. Это исходный материал, который позволит создать эффективные OKR, и он должен быть тщательно проанализирован. Если вы хотите вовлечь больше сотрудников на начальной стадии, попросите их прислать свои идеи команде разработчиков по электронной почте или через онлайн-форму. Затем команда разработчиков OKR пропустит полученный список через фильтр вопросов, отмеченных выше (стратегия, конкурентная среда и т. д.), что поможет отобрать лучшие идеи.
Мы считаем, что и на уровне всей компании, и на уровне небольшой команды разработчики должны зафиксировать 2–3 цели и для каждой установить от 1 до 3 ключевых результатов. Они должны быть прописаны на «растяжку» (оценку в 1,0 балла), чтобы вдохновлять на действия.
Маленькая команда разработчиков (например, из двух человек) представит проект OKR более крупной команде на рассмотрение к первому рабочему совещанию. Здесь есть один нюанс, который легко упустить, поэтому мы остановимся ненадолго и рассмотрим ключевые слова этого тезиса:
На встречу следует пригласить топ-менеджеров, если вы работаете над OKR на уровне всей компании, или лидеров команд, если это разработка OKR на уровне команды. Цель сессии — критически изучить проект: команда разработчиков должна объяснить свой выбор, провести обсуждение (мы надеемся, это будут бурные дебаты) и прийти к соглашению по набору OKR, которые вы планируете использовать.
В рамках этого процесса каждый ключевой результат следует оценивать по шкале, которую мы описали выше. Необходимо убедиться, что ваш итоговый набор OKR соответствует характеристикам, которые мы представили, и действительно отражает вашу уникальную стратегию. Что касается планирования и тайминга, мы советуем забронировать для обсуждения OKR целый день. Но если вы договоритесь за меньшее время, значит, исследование и обсуждение были проведены на высоком уровне. Если получится закончить раньше, не засиживайтесь только для того, чтобы соблюсти регламент. Ничто так не обрадует участников встречи, как возможность закруглиться побыстрее.
Наше последнее предостережение родилось из сотен встреч с клиентами по всему миру: не стоит рассчитывать на достижение полного консенсуса по OKR. Уверяем вас: это практически невозможно. Почему? Потому что окружающие вас люди не роботы и не зомби, а живые люди с уникальным жизненным опытом, формирующим их взгляды и паттерны поведения. Наивно ожидать, что группа достигнет полного согласия по любой теме. Наличие несогласных может оказаться полезным: вы убедитесь, что принятые OKR были рассмотрены со всех сторон. Единственное, на чем вы должны настоять, — это поддержка разработанных OKR. Даже если некоторые члены команды не на 100% согласны с целью или ключевым результатом, они должны открыто поддержать принятые OKR. В противном случае есть риск, что их скептицизм распространится среди команды, отравит атмосферу и породит недоверие ко всему подходу. Поощряйте разнообразие мнений, но действуйте как команда, поддерживая то, что создаете, и взаимодействуя друг с другом.
В современных компаниях значительная часть работы носит кросс-функциональный характер: команды совместно решают задачи или ищут новые способы работы, которые принесут пользу разным направлениям бизнеса. OKR на уровне команды следует создавать с учетом данного обстоятельства.
Маленькая команда, которую мы описывали выше, отправляет ваш проект OKR в путешествие по всей компании, при этом обсуждая зависимые OKR с другими лидерами команд. Вам предстоит взаимодействовать с коллегами, чтобы узнать, как некоторые из ваших OKR зависят от их стараний. Одновременно вам придется рассказать другим командам о вашем функционале и о том, как вы будете помогать коллегам в достижении их целей.
Степень зависимости между вами и другой командой можно определить с помощью оценки. Вспомните, 0,3 балла — достижимый минимум, к которому команде по силам прийти самостоятельно. Если между целевыми уровнями 0,3 и 0,7 существует значительный разрыв, скорее всего, это указывает на сильную зависимость. Ваша задача — совместно с другими лидерами команд скорректировать цели, чтобы продемонстрировать необходимый уровень поддержки. Например, один из ваших ключевых результатов в значительной степени зависит от помощи другой команды. В таком случае на встрече с членами этой команды вы должны убедиться, что они признают зависимость и обещают помощь. Это позволит вам постепенно выполнять ваши цели, зная, что в нужный момент вы получите поддержку коллег. И наоборот, другие команды могут полагаться на вас при достижении своих целей.