Поздравляем! Вас попросили написать несколько OKR. Чувствуете себя так, будто выиграли приз? Не торопитесь.

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

Одна из самых больших проблем, с которой сталкиваются люди при написании хороших OKR, - это их правильное структурирование, чтобы они действительно обеспечивали те преимущества, которые обещают энтузиасты OKR: согласованность, автономия, прозрачность.

По моему опыту, лучшие OKR написаны вокруг результатов. Точнее, они используют результаты для части OKR, посвященной KR.

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

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

Лидеры мыслят высокоуровневыми терминами - соответствующими их позиции в организации. Назовем их "Воздействие" (Impact). Исполнители думают в гораздо более конкретных терминах - опять же, отражающих их видение со своего места в команде.
Другими словами, лидеры думают о воздействии (Impact), а исполнители, как правило, думают о ресурсах, действиях и результатах действий (resources, activities, and outputs).

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

Бизнес-результаты (outcomes) - это активные действия, которые создают бизнес-ценность (Impact).

Например, руководитель хочет снизить затраты. Это - воздействие (Impact). Команда исполнителей знает, что затраты на службу поддержки высоки, потому что клиенты часто звонят в техподдержку. Это - бизнес-результат (outcome). Они считают, что могут уменьшить количество обращений в техподдержку, если исправят непонятные функции продукта. Это - результат действий (output). В этом случае простая логическая модель будет выглядеть следующим образом:

• Воздействие (impact): снижение затрат
  
  
• Бизнес-Результат (outcome): меньше людей обращается в техподдержку
  
  
• Результат действий (output): улучшение удобства использования запутанных функций

Когда команды работают с четко определенными бизнес-результатами (outcomes), отслеживать прогресс становится проще - лидеры и команды могут проанализировать гипотезы, над которыми работают команды, они могут проанализировать свой прогресс в достижении результатов, к которым они стремятся, и они могут посмотреть на конкретный показатель: изменилось ли поведение людей? В данном случае команда должна иметь возможность измерять и сообщать о прогрессе своей работы, просто отчитываясь о количестве звонков в службу технической поддержки относительно продуктов, над которыми они работают.

Часто бывает так, что команды работают над улучшением функций на основе интуитивного ощущения правильности того или иного решения, но это интуитивное ощущение трудно передать, и оно редко бывает убедительным для руководителей.

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

Начало работы с бизнес-результатами (outcomes)

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

Для руководителей в такой ситуации есть простой вопрос, который они могут использовать, чтобы начать разговор о бизнес-результатах: "Какие модели поведения (пользователей/клиентов/сотрудников), созданные в рамках этой инициативы, способствуют достижению бизнес-результатов?".

Этот вопрос является ключом к отслеживанию прогресса, поскольку он переводит разговор от функций и направляет его вектор на создание ценности.

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

Но другие инициативы, как правило, не имеют такой наглядной шкалы измерения. Особенно плохо обстоят дела с внутренними технологическими инициативами. Например, когда команды переписывают внутренние системы, они часто сообщают о прогрессе с точки зрения того, сколько функций системы они завершили. Вместо этого эффективнее было бы измерять прогресс с точки зрения новых организационных моделей поведения, созданных в результате их работы. Например, каково соотношение пользователей новой и старой системы? Сколько из этих пользователей могут использовать новый бизнес-процесс в результате инициативы? Являются ли новые бизнес-процессы, открытые этой инициативой, теми, которые в свою очередь генерируют положительные бизнес-результаты (outcomes)?

Технари иногда возражают тем, что не могут перевести пользователей из одной системы в другую, пока не будет завершена работа над новой системой. Но именно здесь проявляется сила бизнес-результатов (outcomes): ни одна цифровая система никогда не является действительно завершенной, и наоборот, даже очень маленькие фрагменты новой цифровой системы могут начать приносить пользу еще до того, как будет готова вся остальная система.

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

Итак, мы можем измерить прогресс с помощью бизнес-результатов (outcomes). Настаивайте на том, чтобы команды планировали свои цели с позиции бизнес-результатов (outcomes), а затем постоянно спрашивайте: "Какие новые модели поведения, созданные вашей работой, создают ценность для бизнеса?".