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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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