Вдохновленные

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

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

Мы упорно трудились больше года, жертвуя вечерами, ночами и выходными. По ходу дела наша команда пополнила портфель Hewlett-Packard несколькими отличными патентами. Мы разработали софт, соответствующий чрезвычайно высоким стандартам качества HP. Мы сделали продукт доступным для международных пользователей и адаптировали его для нескольких языков. Мы обучили и подготовили команду продаж. Разместили предварительную информацию о новой технологии в СМИ и получили отличные отзывы. Мы были готовы. И вывели продукт на рынок. И отпраздновали релиз.

Только вот проблема: продукт никто не покупал.

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

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

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

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

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

За следующие тридцать лет мне посчастливилось поработать над некоторыми самыми успешными высокотехнологичными продуктами современности. Я работал в HP на заре эры персональных компьютеров; в Netscape Communications – во время появления интернета (вице-президентом по платформам и инструментам); в eBay – в период становления электронной торговли и электронных рынков (сначала старшим вице-президентом по продуктам и проектированию, а затем в качестве консультанта по вопросам стартапов сотрудничал со многими из тех, кто сегодня добился огромного успеха в сфере выпуска высокотехнологичных продуктов).

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

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

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

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

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

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

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

Глава 1. Кто стоит за каждым отличным продуктом

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

Обычно такого человека называют менеджером продукта, но он может быть соучредителем стартапа или СЕО[3]. Бывает также, что он играет в своей команде другую роль, а на первый план вышел потому, что сумел уловить подлинную потребность рынка (и своей компании).

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

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

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

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

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

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

Глава 2. Высокотехнологичные продукты и сервисы

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

Конечно, кое-что из того, о чем мы с вами поговорим далее, пригодится и тем, кто занимается другими видами продуктов, но в этом случае я никаких гарантий не даю. Да и, честно говоря, менеджерам большинства нетехнологичных продуктов, таких как товары широкого потребления, и так доступны отличные источники знаний. Я же сосредоточился на уникальных проблемах и вызовах исключительно высокотехнологичных продуктов и сервисов. Если точнее, мы будем говорить о таких продуктах, как интернет-магазины или маркетплейсы (например, Netflix, Airbnb, Etsy), социальные сети (Facebook, LinkedIn, Twitter), бизнес-сервисы (Salesforce.com, Workday, Workiva), устройства (Apple, Sonos, Tesla) и мобильные приложения (Uber, Audible, Instagram).

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

Глава 3. Стартапы: как достичь соответствия «продукт – рынок»

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

В целом я определяю стартап как компанию, которая очень молода и ее продукт пока еще не соответствует ожиданиям рынка. Соответствие «продукт – рынок» (product-market fit) – чрезвычайно важная концепция; далее мы дадим ее определение, а пока просто заметим, что стартап – это компания, которая еще только пытается придумать продукт, способный положить начало жизнеспособному бизнесу.

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

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

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

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

Глава 4. Компании на стадии роста: успешное масштабирование

Оказавшись достаточно компетентным и удачливым (обычно требуется и то и другое), для того чтобы обеспечить соответствие «продукт – рынок», стартап приступает к решению очередной не менее сложной задачи – эффективно расти.

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

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

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

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

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

Зато для этой стадии характерна очень высокая мотивация к преодолению подобных проблем. Компания может провести IPO или стать бизнес-подразделением какой-нибудь крупной корпорации. Не менее мотивирующий фактор, безусловно, и вполне реальная возможность оказать на мир позитивное влияние.

Глава 5. Корпорации: непрерывные продуктовые инновации

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

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

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

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

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

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

А еще в компании постоянно ведутся разговоры о том, как же так получается, что такие крупные корпорации, как Adobe, Amazon, Apple, Facebook, Google и Netflix, смогли избежать этой печальной участи. Руководство ломает голову над вопросом, почему же им не удается сделать то же самое. Но факт остается фактом: они смогли. И чтобы и мы смогли, нужно внести серьезные изменения, о которых и рассказывается в этой книге.

Глава 6. Фундаментальные причины неудач в работе над продуктом

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

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

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

Рис. 6.1. Основные этапы создания продукта

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

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

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

К этому моменту у организации, выпускающей высокотехнологичные продукты, все идеи и замыслы описаны и распределены в порядке приоритетности. Если идея попала в верхнюю часть списка, менеджер продукта первым делом проводит беседу с заинтересованными сторонами, в результате чего замысел, так сказать, обрастает плотью, и «вырисовывается» ряд основных «требований», или технических условий. Иногда эти требования представлены в виде пользовательских историй (user stories), а иногда больше напоминают по форме техническое задание или функциональное описание. Их цель – донести до дизайнеров и инженеров, что именно им нужно создать.

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

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

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

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

Хорошо, пусть большинство команд работают так, но почему это обязательно становится причиной стольких проблем? Давайте-ка расставим все точки над «и» прямо сейчас, чтобы ясно понять, почему этот распространенный повсеместно метод приводит к неудачам при создании софта.

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

1. Начнем с первой проблемы в списке – источник идей. Использование этой модели приводит к созданию заказных продуктов, обусловленных потребностями отдела продаж, и продуктов по требованию заинтересованных сторон. Мы еще обсудим эту важную тему, а пока позвольте заметить, что это нельзя считать источником удачных замыслов продукта. Еще одно очевидное негативное следствие такого подхода – отсутствие самостоятельности и широких полномочий у команд. Работая по этой модели, люди просто реализуют чужие идеи; они трудятся как наемный персонал.

2. Далее следует упомянуть о фатальной ошибке во время оценки идей. На самом деле я ничего не имею против этого подхода, по крайней мере для идей, требующих больших инвестиций. Но то, как большинство компаний используют его на этом этапе для разработки дорожной карты приоритетов идей, просто нелепо. Объясню почему. Помните два ключевых вопроса, на которые должна дать ответ наша оценка? Сколько денег вы заработаете на этой идее и во что вам обойдется ее реализация? Так вот, в действительности на этом этапе мы понятия не имеем ни о том ни о другом. В сущности, мы просто не можем это знать.

Мы не можем знать, сколько денег заработаем, потому что это всецело зависит от того, насколько правильным и удачным будет наше решение. Если команда проделает отличную работу, она может оказаться невероятно успешной и изменит весь дальнейший ход деятельности компании. Но, к сожалению, многие замыслы продуктов в конечном счете не приносят компании ровным счетом ничего. И это вовсе не преувеличение! Буквально ничего (это определяется в результате A/B-тестирования).

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

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

3. К еще большим проблемам приводит то, что происходит после, когда компании возлагают на составленные таким образом дорожные карты слишком уж большие надежды. За годы работы я видел множество таких «карт», и подавляющее большинство из них были, по сути, не чем иным, как списками функций и проектов с учетом их приоритетности. Маркетингу нужна эта функция для проведения успешной маркетинговой кампании. Подразделение продаж настаивает на той функции, которая позволила бы ему привлечь нового перспективного клиента. Кто-то мечтает об интеграции продукта с PayPal. Ну, в общем, вы меня поняли…

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

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

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

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

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

4. Далее рассмотрим роль продакт-менеджера в этой модели. В сущности, ее даже не следовало бы так называть; на самом деле менеджер здесь является скорее менеджером проекта, чем продукта, потому что речь идет фактически о сборе требований и документировании их для инженеров-программистов. А это не имеет никакого отношения к реалиям современного менеджмента высокотехнологичных продуктов.

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

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

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

8. Весь этот процесс в высшей мере ориентирован на проект. Обычно компания финансирует проекты, подбирает для них людей, «проталкивает» через разные уровни организации и наконец запускает. Увы, в проекте главное – процесс, а в продукте – результат, поэтому он предсказуемо оказывается неприглядным. В конце концов что-то создается, но оно не соответствует целям и задачам. В чем же тогда смысл? В любом случае это серьезная проблема; совсем не так нужно подходить к созданию продуктов.

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

Как известно, ключевой принцип Lean-системы (системы бережливого производства) – это сокращение потерь (отходов), а одной из худших форм таких потерь считается проведение проектирования, изготовления, тестирования и развертывания функции или продукта с тем, чтобы в конце этого долгого пути узнать, что это совсем не то, что нужно пользователю. И вот парадокс: многие команды убеждены, что применяют Lean-принципы, а между тем используют описанный мной базовый процесс. И тут я указываю им на то, что они проверяют свои идеи одним из самых дорогих и самых медленных способов из всех известных.

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

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

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

Глава 7. Lean и Agile и не только

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

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

Но, как я уже сказал, их тоже нельзя считать волшебными средствами, и, как и в случае с любым инструментом, нужно подходить к их использованию с умом. Множество команд утверждают, что придерживаются принципов Lean, а сами месяцами работают над тем, что называют «минимально жизнеспособным продуктом» (minimum viable product, MVP). На самом деле они не знают, что у них получилось и будет ли это продаваться, до тех пор, пока не потратят массу времени и денег. Вряд ли такая стратегия в духе Lean. Или же они бросаются в другую крайность: считают, что должны тестировать и перепроверять каждую мелочь, и, соответственно, не слишком быстро продвигаются вперед.

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

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

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

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

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

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

Глава 8. Ключевые идеи

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

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