Создающие ценность. Как превратить команду в экспертов, которые меняют рынок

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

В моем понимании это объясняется тремя главными причинами.

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

Методика OKR пришла из компаний, где возможности продуктовых команд, наделенных широкими полномочиями, «заложены в ДНК». OKR — это прежде всего методика, расширяющая права и возможности.

Главная идея — поставить перед продуктовыми командами реальные проблемы, которые они должны решить, а затем дать им свободу и возможность выбора решения.

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

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

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

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

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

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

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

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

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

Стоит ли удивляться, что огромное количество компаний получают мало пользы от этой методики?

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

Тем не менее люди путают корреляцию с причинно-следственной связью.

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

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

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

Итак, чтобы получить реальные выгоды от использования OKR, нужно учитывать три важнейших предварительных условия:

1. Нужно перейти от модели функциональных команд к модели наделенных полномочиями продуктовых команд.

2. Не заниматься задачами менеджера и индивидуальными задачами, а сосредоточиться на командных целях.

3. Лидеры должны активно вмешиваться и вносить свой вклад в реализацию продуктовой стратегии.

Большая часть этой книги посвящена обсуждению первого условия.

Что касается второго пункта, то это вопрос образования, и я надеюсь, что книга также просветит людей на этот счет.

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

Во-первых, мы остановимся на том, как расширить полномочия команд с помощью командных целей. Это самая главная выгода командных целей, хотя часто наименее понятная.

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

Мы также обсудим, как лидеры управляют портфелем рисков, объясняя командам, насколько амбициозными они хотели бы их видеть в процессе решения порученных задач.

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

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

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

Широкие полномочия идут рука об руку с ответственностью и подотчетностью, и мы обсудим, что это означает на практике.

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

Глава 53. Расширение прав и возможностей

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

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

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

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

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

Но в нашей отрасли хорошо усвоили один из важнейших уроков: то, как поручают работу, имеет большое значение.

Есть много причин, почему предпочтительнее поручать решение проблемы. Вот самые важные из них:

• Люди, которые могут предложить самое подходящее решение, — это те, кто ближе всего к проблеме и кто обладает необходимыми навыками, то есть продуктовая команда.

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

• Если мы диктуем командам, какую функцию хотим от них получить, а эта функция не дает желаемого результата, мы не сможем возлагать на них за это ответственность.

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

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

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

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

Задачи, или подцели

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

• Уменьшить количество посылок, доставленных по неверному адресу.

• Увеличить процент отправлений, которые доставляются на следующий день.

• Уменьшить процент изображений, помеченных как неуместные.

• Уменьшить коэффициент оттока подписчиков.

• Продемонстрировать соответствие продукта рынку, чтобы вывести существующий продукт на новый рынок.

• Сократить время, которое тратит соискатель на поиск новой работы.

• Уменьшить операционные затраты на оформление и доставку заказа (фулфилмент).

• Сократить затраты на приобретение нового клиента.

• Увеличить показатель пожизненной ценности клиента.

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

• Сократить среднее время, затраченное на обработку звонков в службу поддержки клиентов.

• Увеличить процент новых клиентов, которые успешно создают учетную запись (аккаунт).

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

• Уменьшить время, необходимое, чтобы запустить новый или обновленный сервис.

• Улучшить доступность сайта.

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

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

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

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

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

Это не только нормально, но и крайне желательно, хотя на практике все зависит от того, есть ли в продуктовой команде менеджер по продукту, хорошо разбирающийся в бизнесе.

Ключевые результаты

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

Важно делать это по бизнес-результату (то есть по конечному результату), а не просто по проделанной работе или по промежуточным итогам.

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

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

Например, рассмотрим следующую задачу: уменьшить частоту доставки посылок по неправильному адресу.

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

• Уменьшить процент неадресных доставок.

• Проследить, чтобы общее количество доставок продолжало расти.

• Проследить, чтобы не росла стоимость доставки.

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

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

Важно также отметить, что иногда наиболее подходящие метрики успеха или KPI еще неясны, особенно когда речь идет о проблеме, над которой мы раньше не работали. В таком случае команде может потребоваться время, чтобы понять динамику и определить наиболее подходящие метрики.

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

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

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

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

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

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

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

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

Ознакомившись с данными принципами, мы готовы ставить цели конкретным продуктовым командам.

Глава 54. Распределение целей

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

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

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

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

Распределение заданий представляет собой процесс по принципу «сверху вниз» и «снизу вверх» и часто требует нескольких итераций.

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

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

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

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

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

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

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

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

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

В этом случае лидеры могут попросить команду взяться лишь за одну цель или обратиться к другой команде с просьбой о сотрудничестве в работе над одной из проблем.

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

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

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

Мы должны обеспечить согласованность усилий платформенной команды, которые направлены на поддержку работы продуктовых команд по пользовательскому опыту.

Плюс к этому мы должны надлежащим образом увязать усилия отделов продаж и маркетинга.

Но если бы команды по продажам и маркетингу осваивали другой рынок или не готовились выйти на новый, то это было бы примером несогласованности действий.

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

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

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

Глава 55. Амбициозность

Итак, мы поручили каждой продуктовой команде решить одну конкретную задачу или более, но не полностью предоставили им необходимый контекст.

Когда лидеры просят команду решить ту или иную проблему, важно разъяснить, какую степень амбициозности команде следует проявить в процессе продуктового исследования.

Должна ли команда концентрироваться на «верных вещах» — с низким уровнем риска, но малоприбыльных — или стремиться к более существенным и впечатляющим улучшениям?

Можно представить командные цели как серию ставок, которые делают руководители. Одни ставки — с низким уровнем риска, другие — с высоким, третьи — со средним.

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

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

Важно не путать степень амбициозности с уровнем затраченных усилий или ощущением неотложности.

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

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

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

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

Некоторые различают уровни амбициозности, называя их «выход на крышу» и «полет на Луну».

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

С другой стороны, «полет на Луну» означает, что от команды ожидают высокой степени амбициозности, нацеленности на десятикратное улучшение. Предполагается, что это сопряжено с высоким риском, но мы также уверены, что в этом нет ничего невозможного и что команда вполне способна предпринять серьезную попытку. Да, риск высок, но и награда потенциально высока.

Суть «полета на Луну» в том, чтобы стимулировать команду выйти за рамки небольших и безопасных оптимизаций и переосмыслить сегодняшние способы решения проблемы в надежде найти прорывное решение.

Существуют также компании, которые предпочитают с определенной степенью уверенности относиться к поставленной цели: например, иметь 80%-ю уверенность в достижении консервативного результата или 20%-ю уверенность в достижении результата высокорискового.

Эти методы полезны для информирования команд о желаемом уровне амбициозности. Но нужно понимать — с точки зрения управления портфелем рисков может и должен быть некий средний уровень амбициозности между двумя крайностями.

Представьте, что профессиональному игроку в покер в Лас-Вегасе сказали, будто он может делать ставки только в 1 доллар или только в 10 000 долларов. Это серьезно повлияет на его способность принимать решения, так как он предпочел бы иметь возможность делать ставки на разные суммы в зависимости от обстоятельств.

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

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

Глава 56. Обязательства

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

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

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

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

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

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

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

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

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

Большая часть незначительных зависимостей от изменений, исходящих от команды разработчиков платформы, рассматриваются как необходимая работа по «поддержанию на плаву», но время от времени возникают более серьезные требования. И мы будем относиться к ним как к обязательству по обеспечению высокой добросовестности.

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

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

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

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

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

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

Если команда пользовательского опыта зависит от команды разработчиков платформы, которая, например, должна обеспечить API или новый сервис, где команда пользовательского опыта будет строить свою работу, платформенная команда может «унаследовать» от команды пользовательского опыта ее цель и ключевые результаты.

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

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

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

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

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

Глава 57. Сотрудничество

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

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

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

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

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

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

В определенных ситуациях команды «съезжаются» на несколько дней или на неделю, осуществляя так называемый сворминг. Это интенсивный метод совместной деятельности, позволяющий глубоко погрузиться в работу по исследованию или выпуску продукта либо одновременно по обоим направлениям для решения особо сложной проблемы.

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

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

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

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

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

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

При работе над общими целями часто возникают вопросы насчет того, как соотнести прогресс с какой-то конкретной командой, ведь изменения вносятся многими командами, которые действуют параллельно. Это так называемая проблема атрибуции продукта. Существуют два широко распространенных подхода к этой проблеме, которые мы обсудим в главе 59 («Ответственность и подотчетность»).

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

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

Глава 58. Менеджмент

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

Как реализация продуктовой стратегии требует постоянного отслеживания и управления со стороны лидеров продукта, так и процесс достижения командных целей требует постоянного отслеживания и управления со стороны продуктовой команды.

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

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

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

Такие контрольные встречи могут проходить сами по себе, или подобную проверку можно включать в еженедельные летучки.

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

В плане устранения возникших проблем нужно отметить два момента.

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

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

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

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

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

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

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

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

Глава 59. Ответственность и подотчетность

Расширение прав и возможностей неразрывно связано с ответственностью.

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

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

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

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

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

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

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

Возможно, если бы они при первых неблагоприятных признаках поделились своими проблемами с руководством, им бы вовремя помогли? Или, возможно, продуктовая команда, которая от них зависела, по-другому организовала бы свою работу или даже сделала все сама?

Обратите внимание: эти уроки актуальны и для руководителя команды. Возможно, были какие-то сигналы, которые остались незамеченными? Возможно, были какие-то темы, которые нужно было раньше затронуть в процессе коучинга? Какие-либо вопросы, которые руководитель должен был задать, но не задал?

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

Глава 60. Цели в перспективе

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

Исходя из того, что вы приняли модель продуктовой команды с широкими полномочиями и у вас есть способные лидеры (по крайней мере, допустим, что так), это довольно просто.

Вот 10 наиболее важных условий для эффективного достижения командных целей и выполнения задач:

1. Самое главное — расширить права и возможности команд, поручив им найти решение проблем, а затем предоставив свободу действий в поиске решения. Чтобы сделать верный выбор, вы должны поделиться с ними стратегическим контекстом, в особенности разъяснить им продуктовую стратегию.

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

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

4. Естественно, что этот процесс является предметом для обсуждения обеими сторонами. И дело не в том, что лидеры сомневаются в ключевых результатах, предложенных командами. Скорее речь идет об оценке инвестиций, о стоимости затраченных усилий и сопутствующем риске. Предположим, команда считает, что, учитывая другие цели, она может осуществить лишь минимальные улучшения в плане конкретных и значимых KPI. Лидеры могут поручить команде сосредоточиться исключительно на одной цели или попросить другую команду заняться данной задачей либо как-то помочь первой команде.

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

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

7. Чтобы продуктовая команда смогла выдать ключевые результаты, она должна понимать, какого уровня амбициозности вы от нее ожидаете. Мы должны быть откровенны с командой, когда требуем от них проявить большие амбиции («полет на Луну»), когда хотим, чтобы они оставались консервативными («выход на крышу»), и когда нам нужно, чтобы они взяли на себя обязательство по обеспечению высокой добросовестности.

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

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

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

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

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

Глава 61. Профиль лидера: Кристина Водтке

Впервые я встретил Кристину в 2003 году, когда она руководила командой дизайнеров в молодой компании Yahoo. Кристина изучала искусство фотографии в художественной школе и училась промышленному дизайну, сотрудничая с рядом первых интернет-команд.

Я следил за ее карьерой, по мере того как она занимала должности лидера по продукту и дизайну в таких компаниях, как LinkedIn, MySpace и Zynga.

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

Вот почему я понял, что она нашла свое истинное призвание, когда Кристина пришла в Стэнфорд и начала преподавать человеко-компьютерное взаимодействие (human-computer interaction — HCI) и продуктовый дизайн.

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

Вот почему я всегда считал, что мы с ней — родственные души.

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

Вот история Кристины, рассказанная ею самой:

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

Я была первым дизайнером в поисковой команде, и мне сильно повезло работать с Айрин Ау.

Айрин трудилась продуктовым дизайнером в компании Netscape, затем создала команды дизайнеров в Yahoo, а позднее в Google.

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

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

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

Джефф Вайнер руководил бизнесом поисковых систем в Yahoo, позднее перешел в LinkedIn (по стечению обстоятельств, когда я работала там менеджером по продукту) и около 12 лет занимал в этой компании пост генерального директора.

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

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

Я никогда не забуду этот момент. Мы сидели в кафе, и я сказала Джеффу, что ему следует найти кого-нибудь другого. Он ответил: «Я знаю, что ты справишься». Он так верил в меня, что мне тоже пришлось в себя поверить.

В тот период стремительного роста Yahoo и особенно развития поисковой системы я быстро превратилась не просто в менеджера, а в руководителя менеджеров для довольно большой группы сотрудников. Всего в ней было 80 человек, которые подчинялись 9 менеджерам, а те подчинялись мне.

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

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

Во время первого совещания с подчиненными мне менеджерами один из них спросил меня, как решить какую-то проблему. Я уже не помню, в чем там было дело, но помню, что спросила его о том, что, по его мнению, мы должны предпринять. Он высказал какое-то предложение, и я ответила: «Отлично. Давайте так и сделаем». Именно в тот момент власть перешла от меня к коллективному «мы». С этого дня подобные совещания стали тем местом, где каждый мог предложить любую проблему, и мы начинали работать над ее решением как одна команда.

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

Наконец, с моей стороны было бы упущением не сказать еще об одном человеке, который изменил мое отношение к командам в Yahoo. Кен Нортон также работал с Джеффом, он занимался продуктовым менеджментом для интернет-аукциона Yahoo Shopping. Кен прошел долгий и успешный путь в создании продукта в компании Google, а затем в Google Ventures.

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

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

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

Я искренне благодарна за навыки лидерства, которые я переняла от Айрин, Джеффа и Кена. Усвоенные уроки сослужили хорошую службу в моей карьере, начиная с работы в Yahoo. Самое главное — я всегда старалась вернуть добро, вкладывая свои знания и энергию в улучшение жизни и развитие карьеры других людей.