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