Текст книги "MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям"

Отличным примером для вышесказанного является история, связанная с появлением флип-камеры. Выпущенное компанией Pure Digital в 2006 году устройство, которое разработчики презентовали как «видеокамеру для точечной съемки», многие пользователи посчитали превосходящим традиционные видеокамеры, поскольку оно было проще в использовании, компактнее и доступнее по цене. Успех флип-камеры привел к тому, что в 2009 году компания Pure Digital была куплена корпорацией Cisco за 590 млн $.

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

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

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

Читатели, имеющие опыт Agile-разработки, вероятно, знакомы с принципом дробления функций на более мелкие фрагменты. После создания пользовательских историй команда разработчиков обсуждает каждую из них, оценивая при этом объем усилий, требуемых для реализации. Для этого часто используется балльная система оценки масштаба рассматриваемых пользовательских историй. Например, самая «мелкая» история может быть оценена в один балл, в то время как история среднего масштаба наберет, скажем, три балла, а крупномасштабная история – все восемь баллов. Я более подробно рассматриваю эту тему в главе 12.

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

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

Приведу простой пример, иллюстрирующий понятие рентабельности инвестиций. Представим, что я покупаю некие акции на сумму 100$. Через несколько месяцев цена акций поднимается до 200$, и я решаю их продать. Доход – или чистая прибыль – от этой операции составляет 100$ (200$ – 100$ = 100$). Объем инвестиций составил 100$. Показатель рентабельности моей инвестиции составляет 100$ ÷ 100$ = 1, или 100 %. Общая формула для расчета рентабельности инвестиций выглядит следующим образом:

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

Аналогичным образом, в контексте разработки нового продукта такая присутствующая в формуле переменная как «доход» зачастую также не измеряется денежной суммой. Это, скорее, некоторая относительная мера потребительской ценности, которую, как вы ожидаете, способна произвести разрабатываемая функция. Таким образом, для расчета рентабельности инвестиций в отношении разработки новых продуктов следует применять числовые оценки потребительской ценности. Для этого подойдет так называемая «шкала коэффициентов», которая просто передает пропорции величин, используемых для оценки. Например, предположим, что вы используете шкалу от 0 до 10 баллов для указания величины потребительской ценности каждого из фрагментов разрабатываемых вами функций. Если один из фрагментов имеет оценку 10 баллов (по вашей шкале коэффициентов), а другой фрагмент – оценку 5 баллов, это должно означать для вас, что первый фрагмент имеет вдвое большую потребительскую ценность, чем второй.

Рисунок 6.1, где по вертикальной оси показана созданная ценность (этот термин здесь используется вместо термина «доход» из приведенной выше формулы для расчета ROI, – прим. пер.), или созданная потребительская ценность (в относительных единицах), а по горизонтальной оси – объем инвестиций, или трудозатраты (в неделях работы в расчете на одного разработчика), иллюстрирует концепцию рентабельности инвестиций применительно к разработке новых продуктов. Давайте начнем с идей функций A и B, каждая из которых, согласно примененной оценочной шкале, создает шесть единиц потребительской ценности. При этом для реализации идеи B требуется четыре недели разработки, в то время как для реализации идеи A потребуется всего две недели. Таким образом, показатель рентабельности инвестиций для идеи A составляет: 6 ÷ 2 = 3, в то время как рентабельность инвестиций для идеи B составляет: 6 ÷ 4 = 1.5. Соответственно, идея функции A является более приоритетной по отношению к идее функции B.

Иногда две разные функции обеспечивают примерно одинаковую рентабельность инвестиций. Обратите внимание на идеи функций C и D. Идея C способна принести четыре единицы потребительской ценности в ответ на потраченные на ее разработку 4 недели, что соответствует показателю рентабельности инвестиций: 4 ÷ 4 = 1. Идея D предлагает восемь единиц потребительской ценности при затратах, равных восьми неделям разработки, и в этом случае рентабельность инвестиций также составит: 8 ÷ 8 = 1. Когда у вас есть две идеи функций с одинаковой рентабельностью инвестиций, приоритет разумнее отдать идее меньшего масштаба, поскольку ее реализация займет меньше времени. В этом случае вы сможете быстрее донести ценность до потребителей и, соответственно, раньше получите от них обратную связь.

Рисунок 6.1. Рентабельность инвестиций

На рисунке представлены также примеры плохих идей. Например, идея F, которая предполагает получение дохода в размере двух единиц потребительской ценности при затратах восьми недель на разработку, имеет показатель рентабельности инвестиций: 2 ÷ 8 = 0.25. Увеличение затрат на реализацию идеи, приводящее к снижению рентабельности инвестиций, часто становится очевидным уже на ранних этапах разработки; однако низкая потребительская ценность обычно выявляется только после запуска продукта. Google Buzz и Google Wave являются реальными примерами проектов с низкой рентабельностью инвестиций. На реализацию каждого из них разработчик потратил много часов, но оба проекта были закрыты вскоре после запуска, когда по реакции пользователей стало понятно, что они не несут в себе ожидаемой потребительской ценности.

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

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

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

В качестве параметра «доход», участвующего в расчете ROI, может выступать показатель не только потребительской ценности, но ценности для вашего бизнеса. В этом случае вы можете использовать значение, выраженное в реальных деньгах. Оно будет отражать ожидаемый прирост выручки или ожидаемое снижение затрат. Предположим, например, что у вас есть действующий продукт и вы пытаетесь повысить коэффициент конверсии бесплатных пользователей в платных. При заданном уровне повышения коэффициента конверсии вы должны иметь представление об ожидаемом увеличении объема выручки. Это дает вам возможность связать каждую имеющуюся идею функции с ее ценностью, представленной уже в денежном выражении. В главах 13 и 14 обсуждаются способы повышения рентабельности инвестиций по мере улучшения показателей бизнеса и продукта.