В части II мы обсуждали персонал, в частности структуру сильных продуктовых команд и распределение в них ролей. В части III мы подробно поговорим о том, как понять, над каким продуктом стоит работать продуктовой команде.
Дорожные карты продукта
Итак, у нас имеется несколько сильных продуктовых команд, и теперь нам нужно ответить на основополагающий вопрос: над чем они должны работать? В большинстве компаний (особенно тех, о которых шла речь в главе 6) командам не приходится ломать над этим голову, ведь ответ обычно «спускается» сверху в форме так называемой дорожной карты продукта.
Одна из ключевых идей книги состоит в том, что при разработке программного продукта нужно фокусироваться на результате, а не на процессе. Так вот, типичные дорожные карты имеют отношение к процессу, и только к нему. А от эффективных команд ждут тех или иных бизнес-результатов.
Нужно сказать, в мире продуктов используется, по сути, одно и то же определение дорожной карты продукта, только в нескольких разных вариациях. Я определяю ее как список приоритетных функций и проектов, над которыми будет работать ваша команда. Такие карты, или планы, обычно составляют ежеквартально, но иногда на полгода, а иногда даже на целый год.
В некоторых случаях дорожные карты поступают от менеджмента (это дорожные карты, составленные под давлением той или иной заинтересованной стороны), а иногда их автором становится менеджер продукта. Такие планы обычно не включают в себя деталей вроде работы над дефектами программного кода или оптимизации продукта; как правило, это перечень запрошенных пользователями фич, проектов и больших многопрофильных усилий, часто называемых инициативами. А еще в них по каждому пункту указаны сроки исполнения или по крайней мере ожидаемые временные рамки.
Менеджмент знает, что многим отделам компании нужно от продуктового подразделения что-то свое, но мы, к сожалению, очень редко укомплектованы персоналом настолько хорошо, чтобы обеспечить все эти потребности. Поэтому руководство становится посредником в битвах за эти ограниченные ресурсы, обычно используя для этого дорожные карты, составленные под давлением заинтересованных сторон.
Справедливости ради нужно признать, что для использования таких карт у менеджеров есть весьма веские причины:
1. Они хотят получить гарантии, что команды работают в первую очередь над тем, что имеет наибольшую ценность.
2. Они пытаются управлять бизнесом, а это означает необходимость планирования работы. Для чего нужно хотя бы приблизительно знать, когда будут готовы те или иные ключевые возможности продукта, чтобы соответственно скоординировать маркетинговые программы, наем и подготовку торгового персонала, взаимоотношения с партнерами и так далее и тому подобное.
Все это, безусловно, разумные и обоснованные желания. Проблема в том, что типичные дорожные карты — главная причина большинства зря потраченных и неудачных усилий продуктовых подразделений.
Предлагаю сначала обсудить причины такой ситуации, а затем рассмотреть возможные альтернативы дорожным картам.
Глава 22. Проблемы дорожных карт продукта
Приходится признать, что продуктовые дорожные карты, даже составляемые с самыми благими намерениями, обычно приводят к весьма жалким бизнес-результатам. Я объясняю это тем, что назвал двумя неприятными истинами о продукте. И первая состоит в том, что как минимум половина наших идей относительно продуктов просто не срабатывает. Происходит это по самым разным причинам.
Иногда потребители не приходят от идеи в такой же восторг, как мы, и предпочитают не использовать наш продукт или не покупать его (короче говоря, не видят в нем ценности). Это самая распространенная причина. Иногда они хотят его использовать и даже пробуют это сделать, но это оказывается так сложно, что усилия просто не оправдывают себя. Результат тот же: люди перестают его использовать (не выполняется требование юзабилити, то есть удобства применения). Бывает, проблема в том, что покупателям продукт вроде и понравился, но разработать его гораздо сложнее, чем мы думали, и мы просто не можем себе позволить потратить столько времени и денег, сколько требуется для его поставки на рынок (продукт не отвечает критерию реализуемости).
В некоторых случаях проблема связана с серьезными правовыми, финансовыми или бизнес-ограничениями, которые не позволяют нам реализовать замысел (критерий бизнес-жизнеспособности).
Впрочем, будто всего этого недостаточно, есть еще и вторая неприятная истина: даже если ценность, юзабилити, выполнимость и бизнес-жизнеспособность идеи доказаны, для ее реализации до того момента, когда она будет обеспечивать бизнес-ценность, на которую рассчитывает менеджмент, обычно требуется несколько итераций. Это соотношение часто называют «время — деньги».
Мой опыт показывает, что избежать двух неприятных истин просто невозможно. Но я имел счастье работать со многими исключительно прекрасными продуктовыми командами, и их успех был в значительной мере обусловлен уникальным подходом к этим двум трудностям.
Слабые команды просто месяц за месяцем движутся по спущенной им сверху дорожной карте. А когда что-то не работает — что, надо сказать, случается часто, — они сначала обвиняют в этом заинтересованную сторону, которая запросила или затребовала фичу, а затем пытаются включить в карту дополнительную итерацию или предлагают изменить проект или набор фич, надеясь таким образом решить проблему. Если им дадут достаточно времени и денег, они в итоге могут выполнить поставленную задачу — при условии, конечно, что у менеджмента раньше не лопнет терпение (что вряд ли вероятно).
Сильные продуктовые команды, напротив, понимают и принимают неприятную правду, вместо того чтобы ее упрямо отрицать. Они мастерски расправляются с рисками (независимо от источника идеи) и итерация за итерацией быстро идут к эффективному решению. В этом и заключается вся суть исследования продукта, и потому я считаю этот вид деятельности важнейшей ключевой компетенцией любой продуктовой компании.
Если мы способны создать прототип и протестировать идею на пользователях, клиентах, инженерах и заинтересованных сторонах за часы и дни, а не за недели и месяцы, динамика в корне меняется, и, главное, мы получаем другой результат.
Стоит отметить, что проблема дорожных карт отнюдь не перечень идей. Если бы это были просто идеи, большого вреда не было бы. Дело в том, что, как только вы оформите этот список как официальный документ под названием Дорожная карта, сколько бы оговорок вы в него ни включили, персонал будет воспринимать каждый пункт этого списка как обязательный для исполнения. Это-то и плохо, потому что теперь вы твердо нацелены на разработку и поставку данного продукта, даже если он не решает проблему, которую вам нужно решить.
Не поймите меня неправильно. Иногда нам действительно нужно быть четко нацеленными на непременное выполнение задачи в установленный срок. Мы, конечно, стараемся, чтобы таких ситуаций было как можно меньше, но они все равно возникают. И нам всегда нужно принимать на себя обязательства с высокими требованиями. Мы подробно обсудим эту тему позже, а пока вам нужно понять, что наша задача — решить фундаментальную проблему, а не просто предложить новую фичу.
Глава 23. Альтернатива дорожным картам
В этой главе описывается альтернатива дорожным картам продуктов. Эта важная и обширная тема затрагивает многие вопросы, выходящие за рамки продуктовых дорожных карт, такие как продуктовая культура, моральный настрой, наделение команд широкими полномочиями, самоорганизация и инновации. Так что в этой главе я намерен заложить фундамент, а детали обсудим в последующих.
Но прежде чем перейти к обсуждению альтернативы, стоит напомнить себе о том, что дорожные карты так долго пользуются популярностью потому, что служат достижению двух очень важных целей:
1. Менеджмент компании хочет быть уверенным, что команды в первую очередь занимаются тем, что обладает наивысшей ценностью для бизнеса.
2. Поскольку менеджеры пытаются управлять компанией, в некоторых ситуациях им необходимо, чтобы люди соблюдали сроки и брали на себя обязательства, и дорожная карта — тот самый инструмент, который позволяет им видеть и отслеживать, как эти обязательства выполняются (хотя, нужно признать, в большинстве современных компаний полагаются на сроки).
Иными словами, чтобы альтернатива дорожным картам была принята в большинстве компаний, она должна выполнять эти два условия как минимум не менее эффективно.
В модели продуктовой команды с широкими полномочиями, на которой построена книга, команды сами по себе оснащены всем необходимым для того, чтобы находить наилучшие способы решения бизнес-задач, которые перед ними ставятся. Но для этого недостаточно иметь высококлассных профессионалов с арсеналом современных инструментов и методик. Продуктовым командам нужен также бизнес-контекст. Они должны четко понимать, к чему стремится компания, и знать, каким образом их команда будет способствовать достижению общей бизнес-цели.
В технологических компаниях такой бизнес-контекст обеспечивается двумя основными компонентами:
1. Видение и стратегия продукта. Видение описывает общую картину того, чего пытается достичь компания в целом. Стратегия — план реализации. Каждая продуктовая команда может иметь свой фокус (например, покупатели и продавцы), но все они должны работать сообща над реализацией общего видения продукта.
2. Бизнес-цели. Конкретные бизнес-цели с учетом их приоритетности для каждой продуктовой команды.
Идея, лежащая в основе бизнес-целей, довольно проста: вы говорите команде, что вам нужно и как будут измеряться результаты, и позволяете ей самой определять наилучший способ решения проблем.
Рассмотрим пример бизнес-цели и измеримого основного результата. Предположим, клиенту-новичку для освоения вашего продукта в настоящий момент требуется тридцать дней. Но, по мнению менеджеров, для эффективного масштабирования это время нужно сократить до трех часов, а то и меньше. Вот хороший пример формулировки бизнес-цели для одной или нескольких продуктовых команд: «Существенно сократить время, уходящее на изучение продукта новым пользователем». А одним из измеримых ключевых результатов будет, скажем: «Среднее время адаптации нового клиента не должно превышать трех часов».
В следующих главах мы подробнее поговорим о видении продукта, стратегии и бизнес-целях, а сейчас мне хотелось бы подчеркнуть огромную важность того, что каждая продуктовая команда должна четко знать, как ее работа способствует достижению общей цели и на чем она должна сфокусироваться в данный момент в интересах своей компании.
Ранее я уже говорил, что нам нужно признать две веские причины упорного интереса компаний к устаревшим дорожным картам, и первая, как вы помните, — это желание менеджмента обеспечить первоочередную работу над тем, что несет в себе наивысшую ценность для бизнеса.
В описываемой мной модели обеспечение каждой продуктовой команды конкретными бизнес-целями тоже входит в сферу ответственности менеджмента. Разница в том, что в этом случае определяются приоритеты бизнес-результатов, а не продуктовых идей. И да, как ни парадоксально это звучит, иногда нам приходится убеждать менеджмент нацелиться на бизнес-результаты.
Вторая причина любви менеджеров к дорожным картам, как мы помним, — это возникающая время от времени потребность в строгом соблюдении сроков. Эта проблема решается с помощью концепции обязательств с высокими требованиями, которая используется в случаях, когда результат необходимо получить к определенной дате.
У такого подхода к работе есть несколько серьезных преимуществ:
1. Когда команды сами определяют и выбирают наилучший способ решения проблемы, они гораздо сильнее мотивированы. Тут опять стоит упомянуть об огромной пропасти между командами «миссионеров» и «наемников». Кроме того, команды изначально комплектуются в расчете на максимально эффективное решение конкретных задач.
2. Команда не может, так сказать, умыть руки, просто выдав запрошенную фичу или проект, поскольку этот продукт должен решать конкретную бизнес-проблему (что измеряется по ключевым результатам); в противном случае придется искать другой подход к ее решению.
3. Независимо от источника идеи для решения проблемы и того, насколько умен предложивший ее человек, первоначальный подход очень часто не оказывается неэффективным. И вместо того чтобы притворяться, что это не так, наша модель признает и учитывает вероятность такого развития событий.
При ее использовании во главу угла ставится результат, а не процесс.
В мире, конечно, найдется совсем немного продуктовых команд, которые изменили свои дорожные карты продукта так, чтобы каждый их пункт формулировался как бизнес-проблема, обязательно требующая решения, а не как фича или проект, которые, возможно, решат эту проблему, а может быть, и нет. Такие документы называют дорожными картами, базирующимся на результате. При виде таких карт я обычно бываю безмерно счастлив, потому что, насколько я знаю, в этом случае продуктовые команды нацелены на решение бизнес-проблем, а не на предложение новых фич. Дорожные карты, базирующиеся на результате, можно считать эквивалентом систем, в основе которых лежат бизнес-цели, например системы OKR (Objectives and Key Results — «цели и ключевые результаты»)[11]. Форма разная, а содержание практически одинаковое.
Однако сегодня наблюдается новая тревожная тенденция: в базирующихся на результатах дорожных картах часто устанавливается крайний срок исполнения для каждого пункта, а не только для тех, для которых это действительно необходимо. И эта практика может привести к весьма серьезным негативным последствиям для культуры и мотивации команды.
В большинстве команд, использующих agile-методы, стоит лишь произнести слово «обязательства» (например, сказать, что точно знаешь, что и когда нужно создать), тут же получишь негативные реакции, от простого напряжения до полного отторжения. Здесь ведется постоянная борьба между высшим руководством компании и заинтересованными сторонами, которые пытаются управлять бизнесом (с помощью программ найма и маркетинговых расходов, поддержания партнерских отношений и выполнения контрактов, и все это зависит от конкретных дат и реальных результатов), и продуктовой командой, которая по понятным причинам крайне неохотно берет на себя обязательства по соблюдению сроков и выдаче таких результатов. Команды всегда этому сопротивляются, особенно на этапе, когда еще не понимают, что от них требуется и обеспечат ли они нужные бизнес-результаты, не говоря уже о незнании того, во сколько фактически обойдется их решение, поскольку пока даже не представляют, каким именно оно будет.
Надо сказать, в основе такого сопротивления лежат трудные уроки, усвоенные продуктовыми командами; они горьким опытом научены, что многие идеи не сработают так, как они на то рассчитывают, а те, что сработают, как правило, потребуют нескольких итераций, чтобы добраться до точки, где их смогут рассматривать как успех.
При разработке заказного программного обеспечения разработчики могут повторять итерации до тех пор, пока заказчика не удовлетворит полученный результат (иначе они просто отказались бы от этой работы). В продуктовой компании все не так.
Не поймите меня неправильно: я только что рассказывал о своем негативном отношении к традиционным дорожным картам. И хорошие продуктовые компании всегда стараются свести обязательства с высокими требованиями к минимуму. Но всегда находятся реальные обязательства, которые команды должны на себя взять, чтобы менеджмент имел возможность эффективно управлять компанией.
Так что же делать?
Главное — понять, что нервотрепка с такими обязательствами обусловлена прежде всего тем, когда их принимают. Беда в том, что чаще всего они принимаются слишком рано — еще до того, как мы узнаем, способны ли выполнить данное обязательство и, что еще важнее, решит ли то, что мы в итоге создадим, проблему потребителя.
В модели непрерывного исследования и поставки продукта на рынок деятельность в рамках первой фазы всецело направлена на поиск ответов на эти вопросы. Только после этого можно тратить время и деньги на создание готового программного продукта.
Таким образом, к управлению обязательствами команд нужно подходить с готовностью идти на компромисс. Мы просим высшее руководство и другие заинтересованные лица дать нам немного времени на исследование продукта и поиск нужного решения. Нам нужно проверить его на потребителях — чтобы подтвердить его ценность и юзабилити; на разработчиках — чтобы гарантировать его выполнимость; на заинтересованных лицах — чтобы быть уверенными в его бизнес-жизнеспособности. И только найдя решение, соответствующее всем этим критериям, мы можем взять на себя обоснованное обязательство с высокими требованиями относительно того, когда мы сможем выдать конечный продукт и на какие именно бизнес-результаты можем рассчитывать.
Отметьте: наши менеджеры по поставке продукта на рынок играют ключевую роль в установлении любых сроков в рамках этих обязательств. Предположим, инженеры-программисты уверены, что на создание и поставку продукта уйдет всего две недели. Но что, если эта команда уже занята другой работой и не сможет начать новую еще месяц? А проектные менеджеры отслеживают все обязательства и взаимозависимости.
Компромисс в этом случае довольно прост. Продуктовая команда, прежде чем взять на себя обязательства, просит дать ей немного времени на исследование продукта, и только после этого называет даты и фактические результаты, чтобы и другие коллеги могли эффективно выполнять свою работу.
Повторюсь, в эффективных компаниях подобные обязательства сводятся к минимуму, но они всегда есть. Очень важно, чтобы продуктовая команда не испытывала дискомфорта, беря на себя обязательства с высокими требованиями, и могла объяснить компании, что, хоть она и нечасто их принимает, но когда это делает, все могут быть уверены, что они будут выполнены.