Дэн Олсен – MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям (страница 19)
Однако спустя два года Cisco объявила, что в рамках пересмотра операционной деятельности она свернет некоторые проекты, связанные с производством потребительских товаров, включая бизнес по производству флип-камер. Что произошло? На протяжении нескольких лет флип-камера вполне соответствовала требованиям рынка, однако затем конкурентная среда резко изменилась. В 2009 году Apple выпустила iPhone 3GS – первый iPhone со встроенной функцией видеозаписи. По сравнению с флип-камерой смартфоны предлагали еще более портативное решение, которое избавляло пользователя от необходимости иметь отдельное устройство для съемок. Кроме того, наличие функции беспроводного подключения позволяло мгновенно выкладывать снятое видео в сеть без предварительной его пересылки на компьютер. Оставляя в стороне вопросы, связанные с корпоративной стратегией Cisco, причину ухода флип-камер с рынка можно смело описать следующим образом: время сделало очевидным для всех вывод, что именно смартфоны являются будущим портативной видеозаписи.
Учет прогнозов при формировании ценностных предложений
Возвращаясь к табличному шаблону для формирования ценностного предложения, в целях учета имеющихся прогнозов вы можете использовать отдельные столбцы для описания ситуаций по состоянию на «сейчас» и на «потом» в отношении каждого из конкурентов, а также вашего собственного продукта. Под «потом» понимается любой промежуток времени, наиболее подходящий для целей вашей продуктовой стратегии.
В Таблице 5.6 показан пример того, как мог бы выглядеть результат заполнения шаблона. В этой версии таблицы добавлены столбцы «Сейчас» и «Через год», в которые внесены оценки вашего и конкурирующего продукта. Конкурент А на данный момент является лучшим по показателю «Преимущество в производительности 1». Вы ожидаете, что он будет вкладывать ресурсы в развитие производительного «Преимущества 3», но так и не сможет сравняться с вашим продуктом по этому параметру. Вы также ожидаете, что конкурент А сосредоточится на укреплении своего лидерства в производительном «Преимуществе 2». При этом, по вашему мнению, это преимущество является для целевого рынка менее важным. Вместо того чтобы тратить ресурсы на погоню за лидером в этом направлении, вы планируете оставаться лучшим по показателю «Преимущество в производительности 3» и сократить отставание по показателю «Преимущество в производительности 1». Что касается «фишек» продуктов, то у каждого из вас в настоящее время имеется собственная уникальная функция, вызывающая восторг пользователей. Заглядывая вперед, вы ожидаете, что ваш конкурент снабдит свой продукт новой «Фишкой 3». В свою очередь, вы планируете приятно удивить пользователей своей «Фишкой 4».
Таблица 5.6 Пример ценностного предложения продукта с учетом прогнозных ожиданий
Такой подход к анализу продуктовой стратегии гарантирует, что вы принимаете решения, основываясь не только на текущих рыночных условиях, но с учетом предстоящих изменений. Это снижает риск того, что выбранный вами путь через некоторое время может оказаться неоптимальным.
Использование инструментов, описанных в этой главе, должно помочь в формировании ясного понимания ценностного предложения вашего продукта. Далее необходимо будет определить набор функций, которые вы планируете задействовать при реализации своего ценностного предложения. Таким образом, следующим шагом в процессе создания бережливого продукта является определение функционала минимально жизнеспособного продукта.
Глава 6
Определение функционала минимально жизнеспособного продукта (MVP) (Шаг 4)
Теперь, когда у вас есть четкое представление о ценностном предложении, следующим шагом в процессе создания бережливого продукта является определение набора функций для кандидата на роль минимально жизнеспособного продукта (MVP). Начинать сразу с разработки нового продукта, который полностью соответствует ценностному предложению, не является хорошей идеей, поскольку это заняло бы слишком много времени и было бы слишком рискованно. Поэтому на данном этапе будет разумно определить минимальный функционал, необходимый для подтверждения того, что вы движетесь в правильном направлении. Я называю полученный на этой стадии результат не MVP, а кандидатом в MVP, потому что он основан лишь на имеющихся у вас гипотезах. Вы еще не получили от пользователей никаких подтверждений того, что созданное вами – это действительно жизнеспособный продукт.
В отношении каждого преимущества, содержащегося в ценностном предложении продукта, вы должны провести мозговой штурм с участием всех членов команды, чтобы сгенерировать как можно больше идей о том, каким образом ваш продукт мог бы обеспечить рассматриваемое преимущество. Вы проделали огромную интеллектуальную работу в пространстве проблем и теперь переходите в пространство решений. На этом этапе должны активно применяться правила проведения мозгового штурма. Вам следует практиковать дивергентное мышление, то есть пытаться генерировать как можно больше идей, не допуская на этом этапе какого-либо их обсуждения или высказывания оценочных мнений. Позже у вас будет достаточно времени для конвергентного мышления, когда вы обсудите выдвинутые идеи и решите, какие из них кажутся вам наиболее перспективными. Во время командного мозгового штурма старайтесь всячески поощрять и подталкивать друг друга к генерации еще более креативных и необычных идей.
По результатам мозгового штурма у вас должен появиться список всех идей, выдвинутых в отношении набора функций, направленных на реализацию каждого из рассмотренных преимуществ вашего ценностного предложения. Затем список предложенных функций для каждого из преимуществ должен быть ранжирован, исходя из их приоритетности. Вы можете оценивать каждую идею на основе ожидаемой потребительской ценности. Цель состоит в том, чтобы определить три-пять основных функций для каждого из преимуществ. На данном этапе нет смысла выходить за рамки небольшого количества приоритетных функций, потому что все изменится – и очень сильно – после того, как вы предъявите свой прототип пользователям.
Истории пользователей
Истории пользователей (используемые в Agile-разработке) – отличный способ формулировки идей для создания функций. Он позволяет убедиться в наличии в них явной выгоды для пользователей. История пользователя – это, по сути, краткое описание преимуществ, которые должна обеспечивать конкретная функция, включая указание на то, для кого она предназначена (целевой потребитель) и для чего будет использоваться. Хорошо написанные истории пользователей обычно соответствуют следующему шаблону:
Я как [тип пользователя]
хочу [что-то сделать],
чтобы [получить желаемую пользу].
Вот пример истории пользователя, которая соответствует этому шаблону:
Я как профессиональный фотограф
хочу без проблем загружать фотографии со своей камеры на веб-сайт,
чтобы оперативно показывать их клиентам.
Этот шаблон обеспечивает хорошую стартовую позицию, но написание действительно полезных пользовательских историй требует определенных навыков. Билл Уэйк – один из пионеров Agile-разработки создал набор рекомендаций (атрибутов) для написания хороших пользовательских историй. Чтобы их было легче запомнить, он придумал акроним INVEST:
1. [I]ndependent – Независимость: Хорошая история должна быть независима от других историй. Истории не должны пересекаться по концепции и могут быть реализованы в любом порядке.
2. [N]egotiable – Обсуждаемость: Хорошая история – это не готовое описание функции. Детали того, как именно должно быть реализовано заложенное в пользовательской истории преимущество, должны быть открыты для обсуждения.
3. [V]aluable – Ценность: Хорошая история должна содержать в себе пользовательскую ценность.
4. [E]stimable – Оцениваемость: Хорошая история должна поддаваться разумной оценке ее масштаба.
5. [S]mall – Лаконичность: Хорошие истории, как правило, невелики по объему. Более пространные истории содержат в себе больше неопределенности, поэтому их следует разбить на части.
6. [T]estable – Тестируемость: Хорошая история должна содержать достаточно информации для того, чтобы она могла быть проверена на «достоверность» (на основе так называемых критериев приемлемости).
Фрагментация функций
После того как вы напишете пользовательские истории, описывающие верхний уровень для основных функций, следующим шагом будет определение способов дробления каждой из них на более мелкие функциональные элементы. Я называю этот процесс «фрагментацией». Цель состоит в том, чтобы найти способы сократить их масштаб до такого уровня, чтобы создавать на начальном этапе только самые ценные элементы каждой функции. Примерно также, как при создании фильма режиссер находит способы вырезать наименее важные фрагменты, чтобы уложиться в хронометраж без потери качества. Я намеренно использую термин «фрагмент функции» вместо просто «функции», чтобы акцентировать ваше внимание на том, что на данном этапе работать следует не с крупными объектами, а с их более мелкими атомарными компонентами.
Давайте проиллюстрируем идею разбиения пользовательской истории верхнего уровня на фрагменты. Допустим, вы работаете над приложением, предназначенным для обмена фотографиями, и начинаете с создания следующей истории пользователя: «Я как пользователь хочу иметь легкий способ делиться фотографиями с друзьями, чтобы они могли их рассматривать». Эту историю можно разделить по возможным каналам передачи фотографий: Facebook, Twitter, Pinterest, электронная почта, текстовые сообщения и так далее. В этом случае каждый из них является как бы отдельным фрагментом функции или историей пользователя более низкого уровня по сравнению с ее первоначальным, более общим вариантом. Возможно, для вашего MVP не требуется создавать возможности использования всех перечисленных каналов передачи. Но это в любом случае позволяет разбить историю пользователя на более конкретные компоненты, что способствует обеспечению более точного определения области разработки и правильной расстановке приоритетов при создании отдельных фрагментов. Вы также можете ограничить область действия функции на уровне MVP, например, позволив пользователю делиться только фотографиями и ничем больше. В будущем у вас могут появиться идеи для расширения функционала, такие как возможность добавлять текстовые комментарии к каждому изображению или отмечать друзей на фотографиях. В этом случае каждая из перечисленных опций являлась бы отдельным фрагментом функции.