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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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