Некоторые специалисты используют термин дизайн-спринт, а не спринт-исследование, но, поскольку цель этой деятельности — при условии, что все сделано как надо, — выходит за рамки дизайна, я предпочитаю использовать обобщающий термин.
Если у вашей компании возникают трудности с использованием минимально жизнеспособного продукта (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-коуч непременно должен быть силен и в этом.
