Текст книги "Создающие ценность. Как превратить команду в экспертов, которые меняют рынок"
Автор книги: Крис Джонс
Соавторы: Марти Каган
Жанр:
Экономика
сообщить о нарушении
Текущая страница: 20 (всего у книги 28 страниц)
Глава 50. Действия
Продолжая обсуждение продуктовой стратегии, в этой главе мы остановимся на том, как воплотить наши инсайты в действие.
К этому моменту мы сфокусировались на очень небольшом количестве значимых проблем, мы проделали серьезную работу, чтобы выявить ключевые инсайты, которые приведут в действие нашу продуктовую стратегию. Теперь мы должны воплотить наши идеи, и для этого есть два способа.
Это место развилки, и здесь мы имеем возможность определить, относится ли компания серьезно к продуктовым командам с широкими полномочиями или все еще предпочитает использовать функциональные команды.
Я должен признать: даже если компания сохраняет пристрастие к дорожным картам и функциональным командам, дела у нее идут гораздо лучше при наличии сильной продуктовой стратегии. Безусловно, намного лучше, чем у большинства организаций с функциональными командами, не имеющими продуктовой стратегии.
В конечном счете все сводится к вашим взаимоотношениям с продуктовыми командами – поручаете вы им создавать функции или решать проблемы.
В большинстве случаев различие очевидно («Добавить видео к нашему предложению онлайн-справки» и «Улучшить показатель успешности адаптации нового пользователя»). Но иногда различие оказывается более тонким («Нам нужно приложение» и «Нашим пользователям нужно иметь возможность доступа к сервисам из любого места»).
В первом примере добавление видео – это лишь одно из сотен возможных улучшений для адаптации нового пользователя к продукту.
Во втором примере добавление приложения, скорее всего, будет основным способом обеспечения доступа из любого места, поэтому разница здесь едва заметна. Тем не менее существует много других способов достижения этой цели, и мы хотим дать команде как можно больше свободы действий, чтобы они предложили оптимальное решение.
Если руководители считают, что знают, какие функции и проекты нужно реализовать в соответствии с продуктовой стратегией, то, скорее всего, они занесут эту информацию в дорожную карту продукта и поручат работу соответствующим командам.
Однако если руководители хотят, чтобы команды ощущали способность решить проблему и брали на себя ответственность за продуктовое исследование и реализацию готового решения, которое позволяет получить желаемые результаты, тогда они должны дать соответствующим командам как можно больше свободы для разработки эффективного решения.
Заметьте, что наделение команды расширенными полномочиями не означает, что ей дают карт-бланш. Всегда есть определенные ограничения и контекст: например, решение не должно нарушать имеющийся контракт или ограничения, налагаемые необходимостью соблюдать требования и нормы законодательства.
Стоит подчеркнуть, что первый подход означает, что мы говорим о команде из наемников, а второй означает, что речь идет о команде из миссионеров.
Разумеется, не секрет, что я всецело поддерживаю модель команды с широкими полномочиями, поскольку убежден, что она стабильно генерирует более высокие результаты, особенно в плане инноваций и получения нужных конечных результатов.
В модели уполномоченной команды наше намерение состоит в том, чтобы поручить каждой команде решить некоторый набор конкретных проблем, а затем дать им возможность самим выбрать оптимальный способ решения этих проблем.
Существуют разные методы управления процессом решения проблем, но наиболее популярна система постановки целей OKR (цели и ключевые результаты). Цели – это проблемы клиента или бизнеса, требующие решения, а ключевые результаты – это показатели, по которым можно судить о достижении цели.
Мы уже обсуждали цели компании как ключевую составляющую стратегического контекста. Но чтобы начать действовать, мы должны ознакомить каждую продуктовую команду с ее конкретными целями, которые называют командными целями.
В предстоящем разделе о командных целях (часть VII) мы подробно поговорим, как эффективно использовать методику OKR в модели команд с широкими полномочиями.
Прежде чем мы начнем обсуждать методику OKR, важно подчеркнуть, что на самом деле вам для этого не нужна ни эта, ни какая-либо другая методика.
Все, что реально требуется умному и компетентному лидеру, – это собраться вместе с соответствующими продуктовыми командами, объяснить стратегический контекст, включая продуктовую стратегию, а затем рассказать каждой команде, над какими проблемами им нужно работать и какие бизнес-результаты они должны брать во внимание.
Если команда обладает нужными знаниями и навыками, она приступает к работе.
Система OKR – это метод, предназначенный для формализации таких дискуссий, но она полезна лишь тогда, когда вы укомплектовали персоналом команды с широкими полномочиями, а лидеры выполнили свою работу по созданию эффективной продуктовой стратегии, готовы и хотят доверить своим продуктовым командам работу с проблемами, которые нуждаются в решении.
В любом случае факт, что вы наделяете ваши команды широкими полномочиями, совсем не означает, что вы предоставляете их самим себе и надеетесь на лучшее. Все равно требуется активный менеджмент, чтобы успешно реализовать продуктовую стратегию, и об этом мы порассуждаем дальше.
Глава 51. Менеджмент
К этому моменту мы убедили организацию сосредоточиться на решении небольшого количества действительно значимых проблем, выявили ключевые инсайты, которые будем использовать с максимальной выгодой, и воплотили эти инсайты в действия – в форме целей, поставленных перед каждой продуктовой командой.
Эта подготовка нужна для того, чтобы выполнить необходимую работу, но я могу сказать по собственному опыту, что если лидеры на этом остановятся, то в конце квартала вас ждет разочарование.
Дело в том, что ни одна продуктовая стратегия не выдерживает первой встречи с реальной жизнью.
Обязательно возникнет какое-то количество вопросов и препятствий, и, хотя каждая продуктовая команда справляется с ними и большинство решений принимает самостоятельно, во многих случаях понадобится ваше участие – чтобы устранить препятствия и барьеры или оказать помощь иным образом.
• Продуктовая команда понимает, что упустила фактор зависимости во время планирования, и теперь оказалось, что они зависимы от другой команды, а та команда занята решением собственных задач.
• В процессе продуктового исследования команда понимает, что ей нужна технология, к которой у нее нет доступа или для освоения которой не хватает соответствующих знаний, поэтому может возникнуть задача быстро приобрести данную технологию и освоить.
• Возникает серьезная проблема клиента, и организация изо всех сил старается найти оптимальный способ позаботиться о клиенте и одновременно продвигаться к достижению командных целей.
• Ключевой стейкхолдер выражает серьезную озабоченность по поводу основной цели, и продуктовой команде нужно быстро принимать решение.
Надеюсь, вы уловили мою мысль. Ничего из этого не является чем-то необычным, но, пока лидеры не будут вовлечены в определение, отслеживание и устранение такого типа препятствий, не стоит ожидать особого прогресса.
Главный источник информации для лидеров продукта – еженедельные встречи один на один с менеджером по продукту. Конечно, если происходит что-то чрезвычайное, нужно научить менеджеров по продукту связываться с вами немедленно, а не ждать очередной встречи, чтобы это обсудить.
Во время этой коуч-сессии вы узнаете о возникших вопросах и препятствиях и расскажете об оптимальных способах справиться с ними. В некоторых случаях вам придется оказать помощь – поговорить с ключевым стейкхолдером, или найти еще одного инженера, или пообщаться с другой командой о том, что нужна их помощь в решении проблемы. Или использовать еще какой-нибудь способ из сотни возможных.
Пожалуйста, не путайте это с административно-командным управлением. Вы не берете все под свой контроль и не диктуете командам, что им нужно делать. Вы реагируете на их просьбу о помощи. Для этого есть более точный термин «лидерство как служение», вас просто просят помочь устранить возникшую помеху.
Учитывая все безотлагательные задачи, помехи или сбои, которые составляют обычную жизнь компании, очень легко обнаружить в середине квартала, что вы довольно мало продвинулись по пути к достижению командных целей. Вот почему так важны еженедельный мониторинг процесса работы и коучинг. Как руководитель, вы должны следить за тем, чтобы продуктовая команда добивалась успехов в решении своих задач. Кроме того, по мере накопления важных знаний и инсайтов или обнаружения серьезных проблем вся эта информация стекается к вам, а ваша задача – донести ее до соответствующих команд.
Коучинг и управление реализацией стратегии являются не столько разными обязанностями, сколько двумя сторонами одного и того же предмета дискуссий.
Повторю: при работе с уполномоченными продуктовыми командами вам не нужно меньше управления, вам нужно более эффективное управление.
Глава 52. Профиль лидера: Шан-Лин Ма
ПУТЬ К ЛИДЕРСТВУ
Я впервые встретил Шан-Лин Ма, когда она была единственным менеджером по продукту в быстро растущей компании Gilt Group в Нью-Йорке. Но в ней легко угадывался большой потенциал.
Шан-Лин изучала маркетинг и экономику, получила степень MBA в Стэнфордском университете, пришла в компанию Yahoo, проработала там два года, а затем решила попробовать себя в создании стартапа.
В течение четырех лет она выстраивала продуктовую команду в Gilt Group, после чего была готова основать собственный стартап Zola – компанию, занимающуюся регистрацией и планированием свадеб онлайн. Уже семь лет ее бизнес постоянно развивается и предоставляет услуги, которые пользуются успехом и широко востребованы парами, вступающими в брак.
Более того, Zola считается одной из наиболее перспективных нью-йоркских компаний на стадии роста, а также одной из лучших технологических компаний, в которых престижно работать.
ЛИДЕРСТВО В ДЕЙСТВИИ
Вот как рассказывает о себе сама Шан-Лин:
Ничто не доставляет мне больше удовольствия, чем создание вещей, которых мир еще не видел, но как только люди видят их, то удивляются: «Как мы без этого жили раньше?» Продукты, которые приносят искреннюю радость. Это то, что я хочу делать вечно.
Когда мы с моим сооснователем Нобу Накагучи решили создать Zola, у нас была концепция не только помощи парам с организацией их свадьбы, но и того, в какого рода компании мы бы хотели работать.
Я руководила продуктом на предыдущем месте, когда один из лидеров компании высказал в мой адрес замечание, что я не являюсь хорошим руководителем, так как меня слишком любят инженеры. Он сказал, что, если я бы я делала свою работу правильно, инженеры жаловались бы на давление с моей стороны.
Некоторое время я старалась изменить подход. Но вскоре поняла, что это путь, который ведет к разрушению сотрудничества, утрате доверия и вероятным потерям в развитии инноваций, от которых мы зависели в своей работе.
Оба мы – Нобу и я – были убеждены, что инновации генерируются командами сильных специалистов, наделенными широкими полномочиями и работающими в атмосфере доверия. Мы искренне верили, что могли обеспечить создание такой среды, где бы ценили и уважали людей, которые здесь работают, что это помогло бы нам предоставить людям, вступающим в брак, такой опыт, который они хотели получить и которого они заслуживали.
Многие основатели говорят нечто подобное, но мы были готовы идти ва-банк.
Мы понимали: для того чтобы Zola стала успешной, нам нужен инновационный подход не только к продукту и опыту, но и к нашей бизнес-модели, и к тому, как мы выстраиваем компанию и управляем ее деятельностью.
В нашей кухне вы увидите слоган «Никаких придурков».
Вы также увидите и другие слоганы: «Никаких переводов стрелок», «Никакой политики», «Никаких игр».
Мы знаем: новые идеи рождаются там, где сталкиваются разные взгляды и способы мышления. Поэтому с самого начала – и при работе над каждой новой вакансией – мы сознательно старались собирать команду из людей с разным опытом и разным взглядом на мир.
Нам было важно не только сочетание навыков и талантов, но и различия в образовании, профессиональных траекториях и подходах к решению задач.
Это оказалось полезным не только для инноваций, но и в более широком смысле, ведь наши пользователи – люди, вступающие в брак, – живут в самых разных условиях и приходят к этому решению разными путями.
Нам также нужна была корпоративная культура, в которой ценились бы и сотрудничество, и оперативность.
Как ни парадоксально, мы поняли, что сотрудничество дает не только более высокие, но и более быстрые результаты.
Поэтому, прежде чем принимать какое-либо серьезное решение, мы должны убедиться в том, что проведены консультации с другими сотрудниками компании и учтены их мнения.
Мы также выступаем за то, чтобы представлять свои идеи нашим клиентам как можно быстрее, поскольку уверены, что именно из этого источника мы черпаем знание их реальных потребностей.
Несколько лет назад я попала в серьезную аварию, и этот опыт оказал на меня большое влияние. Я научилась проживать жизнь здесь и сейчас.
Быть генеральным директором быстро растущей компании – тяжелый труд, требования высоки и все время растут, но я каждый день занимаюсь тем, что мне по душе, работаю с людьми, с которыми мне нравится взаимодействовать, и я счастлива, что имею возможность жить и делать свое дело.
Часть VII. Командные цели
Я много лет был сторонником методики OKR (цели и ключевые результаты), но не секрет, что большинство компаний, которые попробовали ее использовать, разочаровались в результатах.
В моем понимании это объясняется тремя главными причинами.
ФУНКЦИОНАЛЬНЫЕ КОМАНДЫ VS ПРОДУКТОВЫЕ КОМАНДЫ
Если компания до сих пор использует функциональные команды – а таких, к сожалению, большинство, – то методика OKR не будет соответствовать корпоративной культуре и почти наверняка окажется пустой тратой времени и сил.
Методика OKR пришла из компаний, где возможности продуктовых команд, наделенных широкими полномочиями, «заложены в ДНК». OKR – это прежде всего методика, расширяющая права и возможности.
Главная идея – поставить перед продуктовыми командами реальные проблемы, которые они должны решить, а затем дать им свободу и возможность выбора решения.
В этом и состоит суть предоставления обычным людям возможностей, для того чтобы создавать выдающиеся продукты.
Однако красноречивым признаком несоответствия является тот факт, что компании думают, будто они могут «поставить галочку» в клетке «расширение возможностей», определив цели для команды, но при этом продолжая диктовать ей решения, которые они рассчитывают получить, – почти всегда в форме дорожной карты функций и проектов с ожидаемыми сроками выпуска.
ЦЕЛИ МЕНЕДЖЕРА VS ЦЕЛИ ПРОДУКТОВОЙ КОМАНДЫ
Вторая проблема состоит в том, что цель кросс-функциональной продуктовой команды, наделенной широкими полномочиями, – слаженная работа над решением сложных проблем.
Тем не менее во многих компаниях каждый менеджер – менеджер инженеров, менеджер дизайнеров и руководитель менеджера по продукту – определяет собственные организационные цели, которые затем спускает сотрудникам.
Это кажется вполне разумным и далеко не всегда становится проблемой для других подразделений компании. Однако на практике это означает, что сотрудники, работая со своими коллегами по кросс-функциональным командам в составе продуктовой команды, трудятся над собственными целями, вместо того чтобы совместно решать общие командные задачи.
Еще хуже то, что во многих командах существует дополнительный уровень сложности и разделения, поскольку они также стараются реализовать индивидуальные цели. Поэтому инженер не только наследует цели своего менеджера, но и вынужден работать еще над реализацией личных целей.
РОЛЬ ЛИДЕРСТВА
И наконец, настоящий корень проблемы кроется в том, что в подавляющем большинстве известных мне компаний, что изо всех сил пытаются извлечь какую-либо пользу из методики OKR, роль лидерства проявляется недостаточно активно.
В понимании руководителей идея в том, чтобы позволить командам определить некий набор целей, дать им возможность добиваться реализации этих целей, а в конце квартала посмотреть, что получится.
Они думают, что наделенные полномочиями продуктовые команды и использование этой методики в особенности требуют меньше управления. Но, как я уже не раз отмечал в этой книге, на самом деле речь идет о более эффективном управлении.
Стоит ли удивляться, что огромное количество компаний получают мало пользы от этой методики?
Не секрет, что большинство ведущих технологических продуктовых компаний используют OKR или один из ее вариантов. Не секрет и то, какого успеха добились эти компании.
Тем не менее люди путают корреляцию с причинно-следственной связью.
Эти успешные компании успешны не потому, что используют OKR. Они используют OKR, так как эта методика разработана для получения преимуществ от модели продуктовых команд, наделенных широкими полномочиями.
И как я пытался объяснить в этой книге, модель наделенной полномочиями продуктовой команды представляет собой принципиально иной подход к созданию и управлению технологической продуктовой организацией.
Нельзя взять старую организацию, выстроенную на основе функциональных команд, дорожных карт и с безынициативными менеджерами, наложить на нее методику, заимствованную из совершенно иной культуры, и ожидать, что это будет работать или что-то сможет изменить.
Итак, чтобы получить реальные выгоды от использования OKR, нужно учитывать три важнейших предварительных условия:
1. Нужно перейти от модели функциональных команд к модели наделенных полномочиями продуктовых команд.
2. Не заниматься задачами менеджера и индивидуальными задачами, а сосредоточиться на командных целях.
3. Лидеры должны активно вмешиваться и вносить свой вклад в реализацию продуктовой стратегии.
Большая часть этой книги посвящена обсуждению первого условия.
Что касается второго пункта, то это вопрос образования, и я надеюсь, что книга также просветит людей на этот счет.
А вот третий пункт нуждается в более подробном обсуждении, поэтому в следующих главах, посвященных командным целям, мы рассмотрим роль лидерства в определении и достижении эффективных командных целей.
Во-первых, мы остановимся на том, как расширить полномочия команд с помощью командных целей. Это самая главная выгода командных целей, хотя часто наименее понятная.
В конечном счете суть командных целей в том, чтобы действовать в соответствии с нашей продуктовой стратегией, поскольку так мы реализуем нашу стратегию посредством действий. Мы обсудим, каким образом мы поручаем работу продуктовым командам, одновременно расширяя их полномочия и налагая на них ответственность за ее надлежащее исполнение.
Мы также обсудим, как лидеры управляют портфелем рисков, объясняя командам, насколько амбициозными они хотели бы их видеть в процессе решения порученных задач.
Важно отметить, что иногда дело не в уровне амбициозности, просто время от времени мы должны брать на себя так называемые обязательства по обеспечению высокой добросовестности. Мы обсудим, как это делается и как управлять своими обязательствами.
Одно из типичных заблуждений относительно командных целей состоит в том, что конкретной задачей должна заниматься лишь одна продуктовая команда. Наоборот, большая часть нашей лучшей работы требует сотрудничества между командами. Существует несколько форм сотрудничества, которые мы также обсудим.
Как и в любом сложном предприятии, основанном на технологиях, необходимо активно управлять этой работой и всегда помнить, что управление должно опираться на коучинг и концепцию лидерства как служения, не скатываясь к командно-административному стилю и не теряя преимуществ, которые дает расширение прав и возможностей.
Широкие полномочия идут рука об руку с ответственностью и подотчетностью, и мы обсудим, что это означает на практике.
Наконец, мы резюмируем наиболее важные моменты с точки зрения получения реальной отдачи от командных целей.
Глава 53. Расширение прав и возможностей
Теперь, зная, каких действий мы ожидаем от каждой продуктовой команды, нужно обсудить вопрос, каким образом поручать эту работу команде, чтобы дать ей широкие полномочия для ее выполнения.
Неотъемлемой составляющей командных целей является наделение команды широкими полномочиями. Это выражается в том, что а) вы поручаете ей решить проблему, а не создавать новую функцию и б) вы предоставляете необходимый стратегический контекст, чтобы члены команды осознавали, зачем они это делают, и принимали правильные решения.
Главное, что нужно понимать, – командные цели в первую очередь должны давать продуктовой команде свободу предлагать решения сложных и важных проблем.
Это резко контрастирует с типичной дорожной картой продукта, диктующей команде приоритетный список функций и проектов, которые она должна создать. Если эти функции или проекты не помогают решить основную проблему, значит, мы терпим неудачу, хотя, возможно, и выполнили то, о чем нас просили.
ПОРУЧАТЬ РЕШЕНИЕ ПРОБЛЕМ, А НЕ СОЗДАНИЕ ФУНКЦИЙ
Некоторые убеждены, что разница между этими подходами не имеет особого значения. Если вы полагаете, что ваша команда должна разработать приложение, просто скажите им сделать это, вместо того чтобы предоставить им бизнес-контекст и стратегический контекст и ждать, что они сами поймут, что нужно создать приложение.
Но в нашей отрасли хорошо усвоили один из важнейших уроков: то, как поручают работу, имеет большое значение.
Есть много причин, почему предпочтительнее поручать решение проблемы. Вот самые важные из них:
• Люди, которые могут предложить самое подходящее решение, – это те, кто ближе всего к проблеме и кто обладает необходимыми навыками, то есть продуктовая команда.
• Мы хотим, чтобы команда взяла на себя ответственность за достижение желаемого конечного результата.
• Если мы диктуем командам, какую функцию хотим от них получить, а эта функция не дает желаемого результата, мы не сможем возлагать на них за это ответственность.
• Если мы дадим команде проблему, которую нужно решить, и свободу для решения ее тем способом, который они сочтут оптимальным, продуктовая команда будет чувствовать гораздо большую ответственность за результат.
• Если первое предложенное командой решение не дает желаемого бизнес-результата, члены команды знают, что они должны продолжать работу и/или попробовать альтернативный подход, пока не получат решение, обеспечивающее нужный результат.
Таким образом, командные цели состоят из задач, или подцелей (проблема, которую нужно решить), и показателей прогресса (ключевые результаты). Давайте обсудим каждую составляющую.
Обратите внимание, что я представляю их в формате OKR, но важно отметить, что 1) необходим фокус на малом количестве значимых целей и 2) результаты измеряются на основе бизнес-результатов, а не промежуточных итогов или операций.
Задачи, или подцели
Конкретные подцели, конечно, будут зависеть от типа выпускаемого продукта и обязанностей той или иной продуктовой команды, но в качестве типичных примеров хороших подцелей можно привести следующие:
• Уменьшить количество посылок, доставленных по неверному адресу.
• Увеличить процент отправлений, которые доставляются на следующий день.
• Уменьшить процент изображений, помеченных как неуместные.
• Уменьшить коэффициент оттока подписчиков.
• Продемонстрировать соответствие продукта рынку, чтобы вывести существующий продукт на новый рынок.
• Сократить время, которое тратит соискатель на поиск новой работы.
• Уменьшить операционные затраты на оформление и доставку заказа (фулфилмент).
• Сократить затраты на приобретение нового клиента.
• Увеличить показатель пожизненной ценности клиента.
• Уменьшить процент клиентов, которым требуется помощь службы поддержки в решении проблем, связанных с продуктом или услугой.
• Сократить среднее время, затраченное на обработку звонков в службу поддержки клиентов.
• Увеличить процент новых клиентов, которые успешно создают учетную запись (аккаунт).
• Сократить время, которое нужно пользователю для создания первого ежемесячного отчета.
• Уменьшить время, необходимое, чтобы запустить новый или обновленный сервис.
• Улучшить доступность сайта.
Помните, что не нужно следовать буквально конкретной формулировке каждой подцели. Часто, когда команда понимает стратегический контекст и получает возможность обдумать задачу, она обнаруживает, что более разумно ее перефразировать, или изменить акценты, или придумать более общую формулировку. Подобное взаимодействие между лидером и продуктовой командой – нормальный и полезный процесс.
Самое важное в этих примерах – то, что они определяют проблемы, которые нужно решить, а не функции, которые нужно создать.
Некоторые проблемы – это проблемы клиентов, а есть еще бизнес-проблемы, но в каждом случае существует любое количество возможных решений. Суть в том, что продуктовые команды лучше всего подходят для того, чтобы выбрать оптимальный вариант решения.
Также обратите внимание, что во всех примерах указываются количественные подцели. Количественный аспект мы будем рассматривать в разделе о ключевых результатах.
Кроме того, здесь важно признать, что многие из важнейших задач потребуют от продуктовых команд либо сотрудничества с другими продуктовыми командами, либо, как это часто бывает, взаимодействия с разными подразделениями организации, чтобы достичь поставленной цели.
Это не только нормально, но и крайне желательно, хотя на практике все зависит от того, есть ли в продуктовой команде менеджер по продукту, хорошо разбирающийся в бизнесе.
Ключевые результаты
Если подцель представляет собой проблему, которую нужно решить, то ключевые результаты показывают нам то, как мы определяем успех.
Важно делать это по бизнес-результату (то есть по конечному результату), а не просто по проделанной работе или по промежуточным итогам.
Второй наиболее распространенной причиной, почему командам не удается достичь командных целей, является то, что они в итоге перечисляют виды операций или результаты работы в качестве своих ключевых результатов. Надеюсь, дочитав до этого места, вы уже поняли, что промежуточные результаты бьют мимо цели. В любом случае учтите: корень проблемы в том, что очень легко показать результат работы и при этом не решить основную проблему. И тогда мы возвращаемся снова к той же старой проблеме, которая возникает при использовании дорожных карт продукта.
В большинстве случаев нам нужно получить от двух до четырех ключевых результатов при выполнении каждой задачи. Первый ключевой результат является, как правило, основным показателем. Затем мы получаем еще один (или более) как критерий качества – иногда это называют ключевыми результатами ограждения или поддержки, чтобы убедиться, что первичный ключевой результат не был получен случайно, когда разработчики искали что-то другое.
Например, рассмотрим следующую задачу: уменьшить частоту доставки посылок по неправильному адресу.
Основным результатом, вероятно, должно стать выявление существующего процента неправильных доставок. Однако если бы нам нужно было получить это значение путем усложнения процесса оформления и доставки заказа, можно было бы уменьшить процент ошибок, но при этом существенно сократить абсолютное количество доставок или увеличить стоимость доставки. И то и другое не является хорошим решением. Поэтому потенциальные ключевые результаты можно оценивать по таким метрикам:
• Уменьшить процент неадресных доставок.
• Проследить, чтобы общее количество доставок продолжало расти.
• Проследить, чтобы не росла стоимость доставки.
Обратите внимание: хотя эти ключевые результаты и требуют конкретных KPI, у нас еще нет ожидаемых значений или временных рамок, так как они должны исходить от команды.
Причина в том, что, если бы мы диктовали команде точные метрики успеха, включая временные рамки, они бы не чувствовали ответственности за свои обязательства. А ответственность – это именно то, что мы хотим видеть в команде с расширенными полномочиями. Поэтому фактические количественные значения должны определяться командой.
Важно также отметить, что иногда наиболее подходящие метрики успеха или KPI еще неясны, особенно когда речь идет о проблеме, над которой мы раньше не работали. В таком случае команде может потребоваться время, чтобы понять динамику и определить наиболее подходящие метрики.
Здесь важнее то, что лучшая командная цель рождается из взаимодействия и обмена мнениями между лидером и командой. В процессе изучения и обсуждения возможных вариантов они часто обнаруживают новые и более эффективные подходы, которые могут предполагать другие ключевые результаты или даже смену задачи. Более того, именно лидер по своей должности обязан обеспечить подобный обмен мнениями. Как лидеру, вам не нужна безынициативная команда: если люди не вовлечены в процесс обсуждения разных точек зрения, вы должны прямо спросить их, что они думают и почему.
В этой связи возникает еще одна проблема: вы должны быть уверены в том, что команда не позволяет «хвосту вилять собакой». Это значит, что иногда команда поддается соблазну оценивать свои ключевые результаты чем-то, что легко измерить, а не тем, что важнее всего измерить.
ПРЕДОСТАВЛЕНИЕ СТРАТЕГИЧЕСКОГО КОНТЕКСТА
Если мы намерены предоставить продуктовым командам свободу действий для решения сложных проблем, то должны также снабдить их контекстом – чтобы они могли принимать правильные решения.
Четыре основные причины, по которым мы должны делиться с продуктовыми командами стратегическим контекстом, особенно видением продукта и продуктовой стратегией, таковы.
Во-первых, важно, чтобы команда хорошо понимала конечную цель и то, почему эту проблему необходимо решить.
Во-вторых, мы хотим, чтобы команды начали обдумывать инсайты и обсуждать, как они могут способствовать решению ключевых проблем.
В-третьих, мы хотим, чтобы команды начали продумывать последствия предстоящей работы. Возможно, существуют зависимости, которые не видны сразу, либо технологии или навыки, которые нам придется приобрести.
В-четвертых, нам нравится, когда команды проявляют особую заинтересованность в работе над конкретными проблемами. Мы не всегда можем предоставить каждой команде возможность работать над теми проблемами, над которыми они хотят, но мы, безусловно, к этому стремимся.
Ознакомившись с данными принципами, мы готовы ставить цели конкретным продуктовым командам.
