10. Используйте наглядные и последовательные способы для указания на то, что тот или иной ключевой результат относится к категории обязательств с высокими требованиями (мы говорили об этом ранее), а не является обычной целью. Другими словами, если за достижение большинства ключевых результатов сотрудник получает, скажем, 0,7, то за выполнение обязательства с высокими требованиями балл будет двузначным. Этот человек либо выполнил свое обещание, либо нет, — это сразу всем ясно.

11. (В рамках всего продуктового и технического подразделения) крайне прозрачно определите, над какими целями работает каждая продуктовая команда, и так же подходите к отслеживанию их прогресса.

12. Ответственность за цели и ключевые результаты компании несет высшее руководство (СЕО и другие менеджеры высшего звена). Директор по продукту и технический директор отвечают за цели продуктовой команды (и гарантию достижения целей своего подразделения). Отдельные продуктовые команды несут ответственность за предложения, касающиеся ключевых результатов для каждой поставленной перед ними цели. Во многих компаниях принято ежеквартально по итогам OKR обсуждать компромиссы для каждой команды и подразделения.

Метод OKR весьма эффективен, особенно в компаниях, которые специализируются на выпуске высокотехнологичных продуктов, независимо от их размера. Работая над развитием своей способности исполнять задуманное, и команды, и подразделения извлекли очень ценные уроки. OKR, по сути, универсальный инструмент, и его может использовать любая организация, любой руководитель; более того, его можно использовать даже в личной жизни. Однако, как в случае со всеми управленческими инструментами, одни способы применения OKR эффективнее других.

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

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

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

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

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

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

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

В такой ситуации очень часто случается следующее: люди из продуктовых команд не сходятся в том, на что им нужно тратить рабочее время. А это ведет к путанице и разочарованию; и руководство, и отдельные сотрудники отнюдь не вдохновлены результатами. К счастью, этого легко избежать.

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

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

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

ОБЗОР