Я уже говорил, что мне несказанно повезло начать карьерный путь инженером-программистом в Hewlett-Packard в годы ее расцвета, когда эта компания считалась самым успешным и долгосрочным примером последовательных инноваций и качества в нашей отрасли. Именно там в рамках внутренней тренинговой программы в области технического руководства — она называлась The HP Way («Путь HP») — меня познакомили с системой, известной как MBO (management by objectives — управление по целям).
Дэйв Паккард в свое время говорил о ней так: «Ни один [инструмент] не внес в успех Hewlett-Packard большего вклада, чем эта система. [MBO] антитеза управления на базе контроля».
Впоследствии за много лет использования MBO была существенно усовершенствована и улучшена рядом компаний, особенно легендарным Энди Гроувом из Intel. Сегодня основная система управления бизнес-целями, которую мы используем, известна под названием OKR (objectives and key results — управление по целям и ключевым результатам).
В свое время Джон Дорр принес OKR из Intel в тогда еще совсем молодую Google, и через двадцать лет после того, как Дэйв Паккард объяснил успех своей компании системой MBO, Ларри Пейдж столь же уверено заявил о неоценимой роли OKR в успехе Google.
Концепция OKR проста и основывается на двух принципах:
1. Первый легко подытожить знаменитыми словами генерала Джорджа Паттона: «Никогда не говори людям, как надо делать. Скажи им, что делать, и они удивят тебя своей изобретательностью».
2. Второй принцип стал лозунгом HP: «Когда производительность измеряется результатами». Иными словами, вы можете предложить любую функциональность, но, если она не решает основополагающих бизнес-проблем, считайте, что вы ничего не решили.
Первый принцип, по сути, касается расширения полномочий и мотивации сотрудников с тем, чтобы убедить их работать в полную силу, а второй — способов достоверного и информативного измерения их прогресса.
За прошедшие годы в нашей индустрии многое изменилось, но эти два принципа управления по-прежнему лежат в основе подходов к работе всех лучших технологических компаний и продуктовых команд.
Мне известно несколько вполне работоспособных систем и инструментов для управления по бизнес-целям, но в этой книге я сосредоточусь на системе OKR. Большинство крупных и преуспевающих технологических компаний уже не первый год пользуются ею. Судя по всему, после некоего переломного момента OKR уверенно завоевывает мир.
На первый взгляд, в концепции командных целей нет ничего сложного, однако внедрить ее во всех продуктовых командах компании можно разными способами, а в поиске своего пути может пролететь не один квартал.
Глава 28. Метод OKR
Метод управления по целям и ключевым результатам (OKR) — это инструмент для управления, фокусировки и корректировки. Как и любой управленческий инструмент, использовать его можно разными способами. Далее перечислены важнейшие моменты, о которых нужно помнить при использовании OKR в продуктовых командах компаний по производству программного обеспечения.
1. Цели должны быть качественными, а ключевые результаты — количественными/измеримыми.
2. Ключевые результаты используются для оценки бизнес-результатов, а не процесса (промежуточных результатов) или отдельных задач.
3. Остальная часть компании применяет методы OKR немного иначе, но менеджменту продукта, дизайнерской группе и инженерно-техническому подразделению нужно сосредоточиться на целях своего подразделения и каждой продуктовой команды, призванных способствовать достижению общих целей компании. Не позволяйте личным целям или целям функциональной команды размывать или сбивать фокус.
4. Выберите правильную периодичность оценки целей (как правило, раз в год для целей подразделения и раз в квартал для целей команд).
5. Следите за тем, чтобы количество оцениваемых целей и ключевых результатов подразделения и каждой команды оставалось небольшим (типичное число — от одной до трех целей и столько же ключевых результатов).
6. Очень важно, чтобы каждая продуктовая команда отслеживала свой прогресс по этим целям (обычно это делается еженедельно).
7. Цели не должны касаться каждой детали и мелочи в работе команды — они охватывают то, чего она обязана достичь.
8. Важно, чтобы команды так или иначе чувствовали свою ответственность за достижение поставленных перед ними целей. Если они сильно отстают, возможно, стоит провести «разбор полетов» с кем-нибудь из членов команды или менеджеров.
9. В рамках всего подразделения согласуйте, как будут оцениваться ключевые результаты. Как уже говорилось, это можно делать по-разному, и выбор подхода в значительной мере отражает культуру компании. Здесь важна четкая согласованность во всей организации, все команды должны знать, в чем и когда они могут положиться друг на друга. Обычно 0 (по шкале от 0 до 1,0) означает отсутствие прогресса; 0,3 — минимальный прогресс (вы достигли того, что вам точно по плечу); 0,7 — прогресс больше минимума (вы сделали то, на что надеялись); и 1,0 — исключительный прогресс (результат превзошел ваши ожидания; вы удивили себя и других).
10. Используйте наглядные и последовательные способы для указания на то, что тот или иной ключевой результат относится к категории обязательств с высокими требованиями (мы говорили об этом ранее), а не является обычной целью. Другими словами, если за достижение большинства ключевых результатов сотрудник получает, скажем, 0,7, то за выполнение обязательства с высокими требованиями балл будет двузначным. Этот человек либо выполнил свое обещание, либо нет, — это сразу всем ясно.
11. (В рамках всего продуктового и технического подразделения) крайне прозрачно определите, над какими целями работает каждая продуктовая команда, и так же подходите к отслеживанию их прогресса.
12. Ответственность за цели и ключевые результаты компании несет высшее руководство (СЕО и другие менеджеры высшего звена). Директор по продукту и технический директор отвечают за цели продуктовой команды (и гарантию достижения целей своего подразделения). Отдельные продуктовые команды несут ответственность за предложения, касающиеся ключевых результатов для каждой поставленной перед ними цели. Во многих компаниях принято ежеквартально по итогам OKR обсуждать компромиссы для каждой команды и подразделения.
Глава 29. Цели продуктовой команды
Метод OKR весьма эффективен, особенно в компаниях, которые специализируются на выпуске высокотехнологичных продуктов, независимо от их размера. Работая над развитием своей способности исполнять задуманное, и команды, и подразделения извлекли очень ценные уроки. OKR, по сути, универсальный инструмент, и его может использовать любая организация, любой руководитель; более того, его можно использовать даже в личной жизни. Однако, как в случае со всеми управленческими инструментами, одни способы применения OKR эффективнее других.
Как вы уже, наверное, заметили, я постоянно подчеркиваю важность продуктовой команды. Напомню, что это кросс-функциональная группа специалистов, обычно состоящая из продакт-менеджера, дизайнера продукта и нескольких инженеров-программистов. Иногда в нее входят также дополнительные сотрудники со специальными навыками, такие как аналитик данных, исследователь, тестировщик.
Помните также, что каждая продуктовая команда обычно отвечает за ту или иную значимую часть продукта или технологии, предлагаемой компанией. Например, одна команда может отвечать за мобильные приложения для водителей, другая — за безопасную обработку платежей и так далее. Суть в том, что люди с различными профессиональными навыками обычно относятся к разным функциональным подразделениям, но весь день — ежедневно — плечом к плечу работают в составе межфункциональной группы над решением сложных бизнес- и технологических проблем.
В крупных организациях нередко бывает 20–50 кросс-функциональных продуктовых команд, и каждая из них отвечает за свое направление и работает над достижением собственных целей.
Как вы, очевидно, догадываетесь, в компаниях, использующих систему OKR, задачи, которые просят решать продуктовые команды, доносятся до людей через цели и ключевые результаты, которые также применяются и для оценки их прогресса. А еще эта система позволяет гарантировать, что цели и ключевые результаты каждой команды согласуются с общими целями компании.
По мере увеличения размеров и сложности компании значение системы OKR для понимания продуктовыми командами того, как они вносят вклад в общее дело, как координируется деятельность разных команд и как избегать дублирования задач и работы, повышается. Это чрезвычайно важно понимать из-за весьма распространенной тенденции: когда компания впервые начинает использовать OKR, каждый функциональный отдел определяет собственные цели и ключевые результаты. Например, дизайнеры формулируют цели, связанные с переходом на адаптивный дизайн; инженерный отдел — цели, связанные с масштабируемостью и производительностью архитектуры; а отдел качества — цели, касающиеся автоматизации тестирования и выпуска продукта.
Проблема в том, что некоторые члены каждого функционального отдела фактически являются членами кросс-функциональной продуктовой команды, а у нее есть свои бизнес-цели (например, снизить стоимость привлечения потребителей или увеличить количество ежедневных активных пользователей); к тому же каждый человек в ней может иметь собственные цели, которые «спускаются» ему через менеджера его функционального подразделения.
Представьте, что инженеров-программистов попросили заняться изменением платформы, дизайнеров — переходом на адаптивный дизайн, а персоналу отдела технического контроля сказали сосредоточиться на технологической модернизации. Хотя каждое из этих направлений само по себе, безусловно, стоящее, шансы решить бизнес-проблемы, ради которых создаются кросс-функциональные команды, в этом случае не слишком высоки.
В такой ситуации очень часто случается следующее: люди из продуктовых команд не сходятся в том, на что им нужно тратить рабочее время. А это ведет к путанице и разочарованию; и руководство, и отдельные сотрудники отнюдь не вдохновлены результатами. К счастью, этого легко избежать.
Если вы внедряете систему OKR в своей продуктовой компании, непременно ставьте цели и ключевые результаты на уровне продуктовой команды. Иными словами, вы не должны позволять целям и ключевым результатам отдельных сотрудников или функциональной команды запутывать ситуацию. Сосредоточьте людей на их целях в рамках продуктовых команд. Если разные функциональные подразделения (дизайнерское, инженерно-техническое или по контролю качества) ставят перед собой более широкие цели — скажем, разработка адаптивного дизайна, управление техническим долгом и автоматизация тестирования, — руководство должно их обсудить и определить приоритеты наряду с другими бизнес-целями, а затем интегрировать в соответствующие цели продуктовой команды.
Обратите внимание, что менеджерам функциональных подразделений совсем несложно добиться того, чтобы их индивидуальные цели согласовывались с целями подразделений. Они ведь не сталкиваются ни с какими конфликтами, поскольку обычно не включаются в продуктовые команды. Например, руководитель отдела UX-дизайна может отвечать за стратегию перехода на адаптивный дизайн; глава технического отдела — за реализацию стратегии по управлению техническим долгом; глава подразделения менеджмента продуктов — за реализацию видения продукта; а глава отдела по контролю качества — за выбор инструмента автоматизации тестирования программного продукта. Кроме того, если некоторые сотрудники — скажем, инженер, дизайнер или продакт, — имеют меньше целей, связанных с личным профессиональным развитием (приобретением знаний какой-нибудь технологии), это тоже не большая проблема. Просто этот человек не берет на себя ношу, которая могла бы мешать ему вносить должный вклад в работу своей продуктовой команды, что, конечно же, его первостепенная обязанность.
Распространение целей и ключевых результатов в продуктовой компании должно идти снизу вверх — от кросс-функциональных продуктовых команд на уровень компании или бизнес-единицы.