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

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

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

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

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

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

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

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

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

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

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

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

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

ПРОДУКТ В ЦЕЛОМ

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

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

Если вы разрабатываете сайты для e-commerce, то ваш продукт включает в себя опыт выполнения и возврата заказа. В общем продукт такой компании представляет собой все, кроме реального, фактического товара, который продается. Аналогично продуктом медиакомпании будет все, кроме предлагаемого потребителям контента.

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

НЕПРЕРЫВНОЕ ИССЛЕДОВАНИЕ И ВЫВЕДЕНИЕ ПРОДУКТА НА РЫНОК

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

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

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

Осмыслить и визуализировать это можно несколькими способами, но, по сути, все довольно просто. Главное – все в команде всегда должны работать параллельно, стараясь определить, какой продукт нужно создать; над этим в основном изо дня в день работают менеджер продукта и дизайнер, в то время как инженеры-программисты трудятся над реализацией замысла и созданием готового программного продукта.

Рис. 8.1. Непрерывный процесс исследования продукта и его поставки на рынок

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

ИССЛЕДОВАНИЕ ПРОДУКТА

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

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

1. Будет ли пользователь это покупать (или использовать)?

2. Сможет ли он понять, как это использовать?

3. Смогут ли инженеры это построить?

4. Станут ли заинтересованные стороны это поддерживать?

ПРОТОТИПИРОВАНИЕ

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

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

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

ПОСТАВКА ПРОДУКТА НА РЫНОК

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

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

СООТВЕТСТВИЕ ПРОДУКТА ОЖИДАНИЯМ РЫНКА

Тот факт, что мы потратили время и силы на создание работающего продукта, еще не означает, что кто-то захочет его купить. Вот почему в мире продуктов мы всегда стремимся достичь важнейшего соответствия «продукт – рынок». Речь идет о минимально жизнеспособном продукте, обеспечивающем потребности целевого рынка. Заслугу популяризации этой исключительно важной концепции (соответствие продукта ожиданиям рынка) приписывают Марку Андриссену; это центральная концепция всей книги.

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

ВИДЕНИЕ ПРОДУКТА

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

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

Кстати, если суть какого-либо из этих понятий вам пока не полностью ясна, не стоит беспокоиться. Я знаю, что сейчас у вас в голове, скорее всего, вертится куча вопросов, но все станет ясно, когда мы глубже погрузимся в каждую тему. Кроме того, немного здорового скептицизма еще никому не повредило: «Да разве такое возможно – проводить по пятнадцать экспериментов в неделю?»

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

Минимально жизнеспособный продукт

Минимально жизнеспособный продукт (minimum viable product, MVP)^[4] – одна из самых важных концепций в нашей отрасли, предложенная много лет назад. Термин придумал Фрэнк Робинсон (в 2001 году), а я писал об этой концепции в первом издании книги (в 2008 году). Но заслуга ее популяризации принадлежит Эрику Рису, в частности его работе The Lean Startup^[5] (2011 года).

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

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

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

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

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

Часть II. Правильные люди

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

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

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

Продуктовые команды

ОБЗОР

Возможно, это самая важная идея во всей книге: все зависит от продуктовой команды.

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

Глава 9. Принципы сильных продуктовых команд

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

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

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

Продуктовые команды формируются разными способами (мы обсудим их позже в разделе «Масштабирование: сотрудники»). Но в хороших компаниях подобного рода вы обнаружите, что, несмотря на различия, обусловленные уникальностью продуктов и обстоятельств, все продуктовые команды имеют важные сходства.

КОМАНДА «МИССИОНЕРОВ»

Продуктовые команды создают для компании множество преимуществ, но главную их цель лучше всего выражают слова Джона Дорра, известного венчурного инвестора из Кремниевой долины: «Нам нужны команды “миссионеров”, а не “наемников”».

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

СОСТАВ КОМАНДЫ

Типичная продуктовая команда состоит из продакт-менеджера, продуктового дизайнера и от двух до 10–12 инженеров-программистов.

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

Команды могут включать и других членов, таких как продуктовый маркетолог, один или несколько инженеров по автоматизации тестирования, исследователя, аналитика данных, а в более крупных продуктовых организациях еще и операционного менеджера с техническими навыками (delivery manager)^[6].

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

ПОЛНОМОЧИЯ И ОТВЕТСТВЕННОСТЬ В КОМАНДЕ

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

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

РАЗМЕР КОМАНДЫ

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

Определен и «потолок» размеров продуктовой команды: обычно это от восьми до двенадцати человек. Вам, наверное, приходилось слышать о правиле двух пицц^[7], которое призвано помочь командам удерживаться в этих рамках.

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

ПОДОТЧЕТНОСТЬ В ПРОДУКТОВОЙ КОМАНДЕ

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

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

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

СОТРУДНИЧЕСТВО В КОМАНДЕ

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

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

РАСПОЛОЖЕНИЕ КОМАНДЫ

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

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

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

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

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

ЗАДАЧИ И КОМПЕТЕНЦИИ КОМАНДЫ

Итак, мы перечислили основные характеристики продуктовой команды, после чего встает следующий важный вопрос: каковы ее задачи и компетенции? За что именно несет ответственность та или иная продуктовая команда?

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

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

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

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

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

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

ВРЕМЯ РАБОТЫ КОМАНДЫ

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

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

Добавлю, что продуктовые команды создаются не только ради реализации проектов. Практически невозможно создать команду «миссионеров», если люди собираются на несколько месяцев, а потом группа расформировывается.

САМОСТОЯТЕЛЬНОСТЬ КОМАНДЫ

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

Кроме того, нужно стараться минимизировать зависимость команд друг от друга. Обратите внимание: я говорю «минимизировать», а не «ликвидировать». Полностью устранить их взаимозависимость невозможно, но неуклонно и упорно работать над ее ослаблением мы можем и обязаны.

ПОЧЕМУ ЭТО РАБОТАЕТ

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

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

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

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

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

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

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

Принципы и методики

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

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

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