До сих пор мы обсуждали методики исследования продуктов. Надо отметить, что заставить продуктовые команды и компании применять их на практике и работать иначе — это совсем другая задача, выполнить которую очень сложно. Отчасти это объясняется просто человеческой природой, но в первую очередь необходимостью менять организационную культуру.
Приведу в высшей степени наглядный пример. Превратить команды «наемников», использующих дорожные карты продуктов и ориентированных на процесс, в по-настоящему вдохновленные, наделенные широкими полномочиями и ответственные продуктовые команды, которые измеряют свои достижения по конечным бизнес-результатам, — это огромный культурный сдвиг, который требует от менеджмента передачи значительной части своей власти и контроля этим людям. Такие изменения не происходят легко и просто, уж поверьте!
К счастью, в нашем распоряжении есть методики, весьма эффективно помогающие преодолеть все преграды.
Глава 58. Спринт на этапе исследования продукта
Судя по моему опыту, многие команды, особенно те, что только начинают знакомиться с современными методами разработки продуктов, находятся в поиске структурированного введения в современное исследование продукта. В этой главе я опишу спринт на этапе исследования.
Спринт на этапе исследования продукта — это недельный интервал в ходе исследования, в течение которого вам предстоит решить важную проблему или снизить риск, с которым в настоящий момент столкнулась команда. Безусловно, такой метод полезен не только для введения преобразований в командах и компаниях, его можно считать отличным инструментом планирования или прототипирования на этапе исследования. Но, по моему убеждению, полезнее всего объединить все эти способы применения, поэтому я и решил поговорить об этом здесь.
Некоторые специалисты используют термин дизайн-спринт, а не спринт-исследование, но, поскольку цель этой деятельности — при условии, что все сделано как надо, — выходит за рамки дизайна, я предпочитаю использовать обобщающий термин.
Если у вашей компании возникают трудности с использованием минимально жизнеспособного продукта (MVP), то спринт позволит вам начать извлекать ценность из этой важнейшей методики.
С командой Google Ventures (GV) я познакомился много лет назад, в самом начале ее деятельности. Команда входит в инвестиционное подразделение Google и снабжает деньгами стартапы, но гораздо больше она помогает им тем, что обучает правильно подходить к разработке продуктов. В рамках используемой в GV модели ее сотрудники обычно проводят в стартапе неделю: засучив рукава, они показывают своим подопечным, как нужно исследовать продукт, бок о бок с ними выполняя все необходимые действия. (Я знаком с несколькими надежными людьми из этой сферы, работающими индивидуально; они коучи по исследованию продукта и делают для команд то же самое.) За неделю такой интенсивной работы вы со своей командой изучите и проанализируете десятки различных идей и подходов, чтобы решить ту или иную бизнес-задачу. Заканчивается неделя проверкой потенциального решения на реальных пользователях и клиентах. И, как показывает мой опыт, результатом неизменно становится последовательное и очень важное обучение и более глубокое понимание дела; эти знания могут в корне изменить дальнейший курс развития продукта и даже всей компании.
В рамках описанной общей структуры коучи по исследованию продукта пропагандируют множество методик в помощь продуктовой команде, чтобы она прошла весь процесс работы над продуктом и приобрела важные новые знания всего за пять дней.
Поработав с более чем сотней продуктовых команд и на практике отточив свои методы и определив эффективнейшие из них, команда GV решила поделиться этими знаниями в книге Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days[15]. Ее авторы Джейк Кнапп, Джон Зерацки и Браден Ковиц.
В книге описана типичная пятидневка. Все начинается с формулировки проблемы путем определения области ее решения, выбора проблемы и целевого клиента, после чего используются несколько разных подходов к ее решению. Далее команда сужает фокус и конкретизирует потенциальные решения, затем создается пользовательский прототип с высокой степенью детализации, и наконец его представляют реальным целевым пользователям, наблюдая за их реакцией. И разумеется, все это делается за неделю — даже за пять дней.
В упомянутой книге описаны любимые методики авторов для преодоления каждого из этапов, и если вы все еще читаете мою книгу, то без труда их узнаете. Больше всего эта книга нравится мне тем, что на ее трехстах страницах представлен пошаговый рецепт (с десятками примеров отличных продуктов и команд — вы их тоже непременно узнаете), который, насколько мне известно, желают иметь все команды, начинающие заниматься этой работой. Эту книгу должен прочитать каждый продакт-менеджер, и я советую вам сделать это как можно скорее.
В нескольких ситуациях, начиная с больших задач и проблем, которые команде очень важно и (или) трудно решить, я настоятельно рекомендую использовать спринт на этапе исследования продукта. Эта методика также полезна тогда, когда команда только учится проводить исследование или когда очевидно, что все движется слишком медленно и команде необходимо ускорить темп.
По мере перехода команд к использованию agile-методов (обычно они начинают с управления проектами Scrum) многие компании решили подписать контракт или нанять agile-коуча. Эти специалисты помогают командам — особенно инженерам-программистам, контролерам качества, продакт-менеджерам и дизайнерам продукта — обучаться методам и образу мышления, без которых применение agile-методологии невозможно.
К сожалению, такое обучение порождает множество проблем, поскольку большинство этих agile-коучей не имеют опыта работы с компаниями по выпуску технологичных продуктов — их опыт ограничивается поставкой продукта на рынок. Следовательно, было бы правильнее называть их agile-коучами по поставке. Они отлично разбираются в инженерно-техническом аспекте разработки новых продуктов и релизах, но не в исследовании продукта.
С этой проблемой столкнулось так много компаний, что вскоре всем стала очевидна острая нужда в коучах с большим опытом работы в компаниях по выпуску технологичных продуктов и в исполнении ключевых ролей, связанных с разработкой новых продуктов, особенно в сфере менеджмента и дизайна продукта. Сегодня таких специалистов часто называют коучами по исследованию продукта.
Коучи по исследованию продукта, как правило, бывшие менеджеры или дизайнеры продукта; они имеют опыт работы или тесного сотрудничества с ведущими компаниями по производству технологичных продуктов. Иными словами, они умеют работать в тандеме с реальными продакт-менеджерами и дизайнерами, а не просто повторять уже практически всем известные факты о методологии Agile и показывать команде, как нужно работать, чтобы работать эффективно.
У каждого такого коуча есть свой любимый способ взаимодействия с командой; обычно в течение недели или около того они занимаются одной или двумя продуктовыми командами. За это время они помогают ее членам пройти от начала до конца один или несколько циклов выработки идей на этапе исследования; создают вместе с ними прототипы и проверяют их на пользователях, чтобы оценить их реакцию; на инженерах, чтобы подтвердить техническую выполнимость идей; на заинтересованных лицах в компании, чтобы определить, будет ли решение выгодным для этого бизнеса.
Признаться, мне трудно представить эффективного коуча по исследованию продукта, не имеющего опыта работы менеджером продукта или дизайнером продукта в современной продуктовой компании. Вероятно, это одна из главных причин того, почему нам сегодня остро не хватает таких специалистов. Кроме того, очень важно, чтобы коуч по исследованию продукта знал, как включить в это уравнение инженеров-программистов. Ему следует с трезвым расчетом подходить к их времени, но понимать, какую огромную роль они играют в инновациях.
Коучи по исследованию продукта чем-то напоминают lean startup-коучей (коучей по вопросам бережливых стартапов). Различие между ними заключается в том, что вторые часто сосредоточивают свои усилия на помощи команде не только в исследовании продукта, но и в разработке бизнес-модели, а также стратегии продаж и маркетинга. После того как молодая компания завоевывает некоторую популярность, ее деятельность по исследованию продукта больше касается непрерывных улучшений уже существующего продукта, а не создания принципиально нового направления бизнеса. По этой причине многие lean startup-коучи не имеют необходимого опыта в области разработки новых продуктов. На мой же взгляд, исследование продукта — важнейшая компетенция любого нового стартапа, поэтому я убежден, что эффективный lean startup-коуч непременно должен быть силен и в этом.
Глава 59. Пилотные команды
Ранее я уже упоминал о кривой внедрения технологий и говорил о том, что, согласно этой теории, разные люди принимают перемены по-разному. Оказывается, то же самое свойственно и нашим организациям, в частности по отношению к изменению подхода к работе.
Одни сотрудники компании или подразделения ждут перемен с нетерпением; другие предпочитают сначала увидеть пример успешного использования нововведения своими глазами; третьим просто нужно больше времени, чтобы «переварить» новшества; четвертые от природы ненавидят что-либо менять и делают это только вынужденно. Если вы очень решительно и радикально меняете что-то сразу для всех, то отстающие (те самые четвертые) гарантированно будут сопротивляться или даже саботировать ваши старания.
Вместо того чтобы бороться с неприятной реальностью, мы можем ее понять и принять. Облегчает переход компании к новым способам работы метод пилотных команд.
Пилотные команды позволяют внедрять изменения в ограниченной части организации и, образно говоря, «откатывать» их, прежде чем они распространятся на всю компанию. Однако для этого вам придется найти продуктовую команду, которая добровольно испытает новые методики. Вы позволяете ее членам некоторое время (один или два квартала) использовать новый способ и наблюдаете за тем, как идут дела.
Используемые критерии успеха зависят от ваших целей, но в конечном счете вы должны оценить эффективность пилотной команды в обеспечении бизнес-результатов, то есть узнать, насколько успешнее она достигает поставленных целей по сравнению с другими командами или собственными показателями в прошлом. Конечно же, учитывая природу эксперимента, такая оценка будет носить качественный характер, но это не умаляет ее важности и убедительности.
Если дела в пилотной команде идут хорошо, скорее всего, со временем найдется еще несколько команд, готовых попробовать новые способы работы. В противном случае вы можете решить, что это вам не подходит или требует внести коррективы.
Чтобы повысить шансы пилотных команд на хороший результат, следует тщательно отбирать в них людей, а также продумывать, где они будут работать и насколько широкие полномочия им будут предоставлены. В идеале нужно стремиться к тому, чтобы это были сотрудники более других склонные к переменам и новым способам работы; чтобы ключевые игроки трудились рука об руку, а команда в значительной степени контролировала свою работу и не слишком сильно зависела от команд, все еще работающих по старинке.
Глава 60. Отказ от дорожных карт
Многие продуктовые команды с радостью бы отказались от ежеквартальных дорожных карт продуктов, но их организации старомодны и привыкли к этим безнадежно устаревшим рабочим инструментам. И новаторские команды не знают, как переломить ситуацию и заставить компанию идти вперед.
В этом случае я предлагаю сделать следующее. Запланируйте продолжать использование действующего процесса с дорожными картами еще год или полгода, но с этого дня каждый раз, при ссылке на тот или иной пункт дорожной карты продукта или в обсуждении ее на презентации или собрании, напоминайте людям о фактическом бизнес-результате, получению которого призвано способствовать данное усовершенствование.
Если, скажем, вы работаете над включением в продукт PayPal как метода платежа (ради улучшения показателя конверсии), непременно укажите текущий коэффициент конверсии и результат, которого надеетесь достичь в конце. И главное, после того как новый набор функций будет полностью готов к использованию, обязательно подчеркните, как это сказалось на коэффициенте конверсии. Если результат хороший, отпразднуйте достижение. Если влияние не столь значительное, как вы надеялись, обратите внимание всех на то, что, хоть обновление и разработано, результат нельзя считать успешным. Укажите, какие полезные знания команда приобрела за прошедший период, но объясните, что у вас есть и другие идеи о том, как получить желаемый результат.
Со временем (на это может уйти около года) организация должна сместить фокус с запуска конкретных обновлений к определенной дате на достижение намеченных бизнес-результатов.
Но если вы хотите, чтобы этот подход сработал, помните о причинах того, почему заинтересованные стороны наших компаний так любят дорожные карты.
1. Они хотят ясно видеть, над чем вы работаете, и быть уверенными в том, что вы работаете над самыми важными задачами.
2. Они хотят иметь возможность планировать бизнес-деятельность, а для этого им нужно знать, когда будут происходить важнейшие события.
Современная альтернатива дорожным картам позволяет избавить этих людей от поводов для беспокойства по обоим пунктам. Команды работают над бизнес-целями, приоритетность которых определена лидерами. Мы честно и открыто рассказываем о достигнутых ключевых результатах и в случаях, когда действительно важно выдержать сроки поставки продукта на рынок, берем на себя повышенные обязательства.