Определение функционала минимально жизнеспособного продукта (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 обсуждаются способы повышения рентабельности инвестиций по мере улучшения показателей бизнеса и продукта.
Приблизительная оценка показателя ROI
Рассмотренная выше формула позволяет получить расчетное значение показателя рентабельности инвестиций. Однако вы также можете использовать этот инструмент для расстановки приоритетов разработки менее строгим образом. Если вы затрудняетесь с получением численных оценок потребительской ценности или затрат времени на разработку, вы можете оценить каждую имеющуюся идею функции по упрощенной шкале. В этом случае потребительская ценность и затраты оцениваются как высокие, средние или низкие. В результате вы получите матрицу размером три на три, как показано на Рисунке 6.2. Каждая из ваших идей для создания функций попадет в одну из девяти ячеек, соответствующую упрощенным оценкам ее параметров. Таким образом, даже не производя расчетов, вы сможете ранжировать эти девять ячеек на основе рентабельности инвестиций, как показано на рисунке. Таким образом, все идеи, попавшие в ячейку под номером 1, которой соответствует наибольшая ценность и наименьшие затраты, будут иметь более высокий приоритет, чем идеи, попавшие в ячейку под номером 2 и которые, в свою очередь, будут иметь более высокий приоритет по сравнению с идеями, оказавшимися в ячейке под номером 3, и так далее.
Если вы не уверены в своей способности сделать точную оценку создаваемой ценности и необходимых для этого затрат, просто используйте свои лучшие предположения, чтобы на их основе поместить каждую функцию в одну из девяти ячеек. Помните, что это всего лишь исходные гипотезы; вы сможете – и, скорее всего, будете – изменять их по мере получения результатов исследований и прохождения итераций разработки.
Рисунок 6.2. Приблизительная оценка показателя рентабельности инвестиций
Выбор кандидата в MVP
Как только вы закончите с фрагментацией, оценкой трудозатрат и расстановкой приоритетов, у вас появится возможность представить полученные результаты в простой табличной форме. В такой таблице (см. Рисунок 6.3) будут перечислены все преимущества вашего ценностного предложения, и напротив каждого из них указаны соответствующие функции в виде блоков, расставленных в приоритетном порядке.
На Рисунке 6.3 я изобразил основные фрагменты (блоки) функций для каждого преимущества. Они выстроены в порядке убывания приоритета, слева направо. Чтобы не вписывать в эти блоки названия фрагментов функций, я применил буквенно-цифровое обозначение. Так вам будет легче мысленно заменить их на фрагменты функций, относящиеся именно к вашему продукту. Обозначение «M1A» расшифровывается как «функциональный блок A для преимущества “Мастхэв 1”»; «P2B» означает «функциональный блок B для “Преимущества производительности 2”»; а «F2C» означает «функциональный блок C для “Фишки 2”». Вы можете заполнить аналогичную таблицу, используя соответствующие метки для преимуществ и фрагментов функций, относящихся к вашему продукту.
Рисунок 6.3. Лист функциональных блоков, расставленных по приоритету для каждого преимущества
После того как вы распределили свои функциональные блоки по преимуществам и расставили их в порядке приоритетности, наступает время для принятия непростых решений. Вы должны определиться с минимальным набором функций, которые предъявите целевым потребителям. Для этого следует просмотреть крайний левый ряд фрагментов функций и определить, какие из них, по вашему мнению, должны войти в состав кандидата в MVP. При этом вы должны основываться на ценностном предложении продукта. Для начала необходимо убедиться, что MVP включает все функции, которые вы отнесли к числу базовых (обязательных).
После этого следует сосредоточиться на главном преимуществе производительности, по которому вы намерены превзойти конкурентов. Для этого преимущества следует выбрать тот набор функциональных блоков, который, как вы считаете, способен убедить пользователей в том, что ваш продукт превосходит рыночные аналоги.
«Фишки» также являются тем, что выделяет ваш продукт в ряду ему подобных. Поэтому лучшая из имеющихся у вас «фишек» должна быть включена в функционал кандидата в MVP. Вы можете этого не делать лишь в том случае, если ваше превосходство производительности является неоспоримым. На данном этапе главная цель состоит в том, чтобы убедиться, что кандидат в MVP включает в себя именно тот функционал, который потребители сочтут существенно и выгодно отличающимся от других представленных на рынке продуктов, а в идеале – уникальным.
Фрагменты функций, которые, как вы считаете, должны входить в состав кандидата в MVP, далее следует внести в крайний левый ряд блоков, который можно озаглавить «v1» (версия 1), как показано на Рисунке 6.4. При этом оставшиеся блоки будут отодвинуты вправо. В продолжение этого процесса вы можете создать предварительную дорожную карту продукта, добавив столбцы для каждой последующей версии продукта. В эти столбцы вы будете вносить те фрагменты функций, которые планируете добавить при выпуске соответствующих версий.
Поскольку вы собираетесь стать лучшим на рынке по показателю «Преимущество производительности 3», функционал вашего кандидата в MVP должен включать в себя соответствующий блок функций с наивысшим приоритетом – P3A. Поскольку вы также планируете убедить пользователей в уникальности своего продукта при помощи «Фишки 2», соответствующий функциональный блок – F2A – также должен присутствовать в составе функционала вашего кандидата в MVP. И, конечно, он должен включать в себя все обязательные функции («Мастхэв»).
Рисунок 6.4. Определение функциональных блоков, входящих в разные версии кандидата в MVP
Следующую версию своего продукта – v1.1 – вы планируете дополнить функциональными блоками P3B и F2B для усиления «Преимущества производительности 3» и «Фишки 2», соответственно. В версии v1.2 вы планируете решить проблему «Преимущества производительности 1» с помощью добавления приоритетного блока функций P1A.
Я не рекомендую с самого начала планировать функционал более чем одной или двух последующих версий – слишком многое может измениться, когда вы впервые представите пользователям своего кандидата в MVP. Вы узнаете, что некоторые из ключевых гипотез были не совсем точными и выдвинете новые. В конце концов, вы вообще можете изменить свое мнение о том, какое из преимуществ является наиболее важным, или же у вас могут возникнуть идеи новых функций, направленных на достижение существующих преимуществ. Поэтому, даже если вы все же составили предварительные планы, простирающиеся далее создаваемой версии MVP, вам следует быть готовыми к тому, что их придется выбросить в корзину после получения обратной связи от потребителей и засесть за разработку новых.
На Рисунке 6.4 для каждого из преимуществ кандидата в MVP в версии v1 я представил только по одному функциональному блоку. Однако на практике может оказаться, что для обеспечения соответствующего преимущества вам понадобится разработать не один, а два или три фрагмента функций. Это будет зависеть от конкретной ситуации, а также от того, насколько малы ваши фрагменты функций. Тем не менее, принцип их выбора остается прежним: приоритет должен быть отдан фрагментам функций, которые – для каждого из преимуществ – располагаются левее в составленном вами листе функциональных блоков (см. Рисунок 6.3).
Теперь давайте сделаем шаг назад и немного поразмыслим. Вы уже проделали большую работу на пути создания бережливого продукта. В вашем распоряжении имеются:
1. Сформированные гипотезы о целевых потребителях.
2. Сформированные гипотезы об их недостаточно удовлетворенных потребностях.
3. Сформулированное ценностное предложение, которое вы планируете реализовать, чтобы ваш продукт отличался от аналогов и превосходил их.
4. Сформированный перечень идей функций, которые, по вашему мнению, смогут удовлетворить потребности пользователей. Кроме того, эти идеи разбиты на достаточно мелкие фрагменты для удобства их разработки.
5. Оценка приоритетов всех фрагментов функций, полученная на основе показателя рентабельности инвестиций.
6. Перечень отобранных функций для кандидата в MVP, которые, как вы считаете, представляют для пользователей наибольшую ценность.
Вы приложили немало умственных усилий, однако то, что вам удалось создать, все еще остается лишь кандидатом в MVP, набором взаимосвязанных гипотез. Теперь нужно получить обратную связь от пользователей о вашем кандидате в MVP, чтобы проверить правильность этих гипотезы. Но прежде чем приступить к тестированию, необходимо создать в пространстве решений рабочий прототип вашего кандидата в MVP, который можно будет вынести на суд пользователей. Это и будет нашим следующим шагом в процессе создания бережливого продукта.