Дэн Олсен

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

The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback by Dan Olsen

Copyright © 2015 by Dan Olsen. All rights reserved.

© Ильин В.В., перевод на русский язык. 2024

© Оформление. ООО «Издательство «Эксмо», 2024

* * *

Моим отцу и матери, которые научили меня учиться и мечтать,

Ванессе, спутнице моей жизни, которая с каждым днем удивляет меня все больше,

Софии и Ксавьеру, которым я желаю узнавать и мечтать вдвое больше.

Введение

Почему инновационные продукты терпят крах и как бережливое производство меняет правила непростой игры – создания успешных продуктов

Создание успешных продуктов – нелегкая задача. Наверняка многие из вас знакомы с отрезвляющими данными статистики, согласно которым для огромного количества новых программных продуктов выход на рынок заканчивается провалом. На каждую широко известную историю успеха Apple, Google, Facebook[1] и некоторых других компаний приходится бесчисленное множество неудач, из-за которых разработчики вынуждены закрывать свой бизнес.

Вспомните о приложениях, которые вы использовали за последний год. Сколько из них вам нравятся? Сколько вызывают раздражение? А о скольких вы вообще не можете даже вспомнить? Если ваши предпочтения не отличаются от предпочтений большинства людей, то вам, должно быть, по-настоящему нравятся очень немногие продукты из тех, которыми вы пользуетесь.

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

Но печальная реальность такова, что все вышеописанное случается довольно редко. Типичные же истории выглядят совсем иначе. Так почему создать продукт, который понравится клиентам, сложно? И почему так много продуктов терпят неудачу?

Почему продукты терпят крах

На протяжении всей своей карьеры я занимался созданием и изучением множества различных продуктов. Анализируя первопричины неудач конкретных продуктовых решений, я вывел общую закономерность: основная причина провалов крылась в том, что новые продукты не удовлетворяли потребности клиентов лучше, чем уже имевшиеся на рынке альтернативы. В этом состоит суть соответствия продукта рынку. Марк Андреессен из Netscape ввел этот термин в обиход в 2007 году. Тогда же он написал в своем блоге (и в этом я с ним полностью согласен), что стартапы «терпят неудачу потому, что не достигают соответствия своих продуктов рынку».

Движение бережливых стартапов, родоначальником которого стал Эрик Рис, помогло популяризировать идею соответствия продукта рынку. Я тоже являюсь убежденным сторонником принципов бережливого стартапа. Одна из причин, по которой эта концепция обрела столь широкую популярность, состоит в том, что разработчики прекрасно знают, насколько сложно создавать успешные продукты.

Многие приходят в восторг, когда впервые знакомятся с идеей бережливого стартапа, и горят желанием опробовать ее на практике. Но, общаясь со многими из таких энтузиастов, я заметил, что на поверку их знания оказываются слишком поверхностными, и все их действия являются лишь тщетной попыткой понять, что именно им следует делать и как применить на практике то, что они знают.

Это подобно историям людей, которые в какой-то момент решают, что им пора улучшить свою физическую форму. В порыве энтузиазма они начинают больше тренироваться. Они записываются в тренажерный зал и покупают новую спортивную одежду. Замотивированные, они приходят в спортзал и здесь неожиданно для себя осознают, что понятия не имеют, чем именно они должны там заняться. Какие упражнения выполнять? Какие тренажеры использовать? Какой метод тренировок лучше? У этих людей есть большое желание, но не хватает знания о том, что именно им нужно делать.

Почему нужна именно эта книга?

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

Пирамида соответствия продукта рынку

Структура, которую я называю пирамидой соответствия продукта рынку, включает в себя пять компонентов. Это: целевой потребитель, его недостаточно удовлетворенные потребности, ценностное предложение, набор функций предлагаемого продукта и пользовательский опыт (user experience, или UX). При этом каждый компонент по своей сути состоит из проверяемых гипотез. Существует логическая последовательность всех пяти компонентов, основанная на их взаимосвязи, в результате чего образуется иерархия, которую я изобразил в виде пирамиды (см. Рисунок 1.1).

Рисунок 1.1. Пирамида соответствия продукта рынку

Процесс создания бережливого продукта

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

Процесс создания бережливого продукта включает в себя шесть этапов:

1. Идентификация целевых потребителей.

2. Определение недостаточно удовлетворенных потребностей.

3. Формирование ценностного предложения.

4. Определение функционала минимально жизнеспособного продукта (MVP).

5. Создание прототипа MVP.

6. Тестирование MVP на пользователях.

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

Исчерпывающее руководство

Я написал эту книгу как максимально полное руководство, охватывающее множество смежных тем, поскольку для создания успешного продукта необходимо правильно сделать очень много разных вещей. Чтобы помочь в этом, в дополнение к процессу создания бережливого продукта я освещаю в этой книге еще ряд важных тем. Так, подробно рассматриваются принципы UX-дизайна и Agile-разработки. Вы также найдете в ней раздел, посвященный аналитике, и инструкции о том, как использовать различные метрики для оптимизации вашего продукта.

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

Обо мне

Мое образование представляет собой сочетание как технических, так и бизнес-навыков, которые я начал развивать, когда родители подарили мне мой первый компьютер. Мне тогда было 10 лет. Несколько лет спустя, я организовал первый собственный бизнес. Я изучал электротехнику в Северо-Западном университете, затем начал карьеру в сфере высоких технологий, проектируя атомные подводные лодки. Без отрыва от работы я получил степень магистра промышленной инженерии в университете Вирджинии, где и узнал о принципах бережливого производства, вдохновивших движение бережливых стартапов.

Затем я перебрался в Кремниевую долину и поступил в Стэндфордскую школу бизнеса. Получив степень MBA, я присоединился к компании Intuit, которая стала для меня невероятной площадкой для обретения знаний в области управления продуктами, разработки, исследований потребителей, UX-дизайна и маркетинга. Я возглавил и расширил команду разработчиков приложения Quicken, и нам удалось добиться рекордных показателей продаж и прибыли. По мере накопления практического опыта у меня росло желание применить полученные знания к созданию стартапов. В конце концов, покинув Intuit, я потратил кучу времени на работу именно в этом направлении.

На протяжении многих лет я консультировал различные компании, помогая им применять принципы бережливого производства для создания успешных продуктов. Мои консультации всегда основываются на практическом подходе: я тесно сотрудничаю с генеральными директорами и их управленческими командами, общаюсь с менеджерами по продуктам, дизайнерами и разработчиками. Обычно на период реализации проекта я занимаю в компаниях своих клиентов должность временного вице-президента по продуктам и часто выступаю в роли главного продакт-менеджера в их командах.

Все приведенные в этой книге советы были проверены и усовершенствованы мной в ходе работы с реальными клиентами. В их числе Facebook, Box, YouSendIt (ныне Hightail), Microsoft, Epocrates, Medallia, Chartboost, XING, Financial Engines и One Medical Group. Я на практике убедился в том, что предлагаемые мной идеи оказались применимы к каждому случаю, несмотря на то что компании-клиенты различались по размерам – от небольших стартапов на ранней стадии развития до крупных корпораций, – а также к различным производственным отраслям, целевым потребителям, типам продуктов и бизнес-моделям.

Мне нравится делиться и обсуждать свои идеи в сфере бережливого производства с как можно большим количеством людей. Я регулярно читаю лекции, провожу мастер-классы и размещаю презентации на SlideShare (доступны по ссылке: http://slideshare.net/dan_o/presentations). Ежемесячно в Кремниевой долине я организую встречи, посвященные теме бережливого производства, которые можно посетить по адресу http://meetup.com/lean-product. Участники этих форумов своими вопросами, предложениями и отзывами оказали мне существенную помощь в совершенствовании данной книги.

Для кого предназначена эта книга?

Если вы интересуетесь такими темами, как бережливый стартап, исследование клиентских потребностей, создание UX, дизайн-мышление, продуктовый менеджмент, дизайн, ориентированный на пользователя, Agile-разработка или продуктовая аналитика, то эта книга для вас. Она снабдит вас необходимым руководством по использованию полезных инструментов, включая пошаговый процесс, следуя которому вы сможете обрести уверенность в том, что создаете действительно ценный для потребителей продукт.

Эта книга предназначена для:

1. Каждого, кто пытается создать новый продукт или услугу;

2. Каждого, кто пытается улучшить уже существующий продукт или услугу;

3. Предпринимателей;

4. Менеджеров по продуктам, дизайнеров и разработчиков;

5. Маркетологов, аналитиков и руководителей проектов;

6. Генеральных директоров и других руководителей верхнего уровня;

7. Каждого, кто работает в компаниях любого размера;

8. Каждого, кто увлечен идеей создания успешных продуктов.

Рекомендации, приведенные в этой книге, имеют наибольшую ценность для создания программных продуктов. Однако все написанное в ней относится и к другим категориям товаров, таким как аппаратное обеспечение, гаджеты и даже нетехнические товары и услуги. Кроме того, предлагаемые советы также применимы к широкому спектру бизнес-контекстов, включая такие взаимосвязи, как «бизнес-потребитель» (B2C) и «бизнес-бизнес» (B2B).

Как организована эта книга

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

Часть II, «Процесс создания бережливого продукта», содержит подробное описание каждого из шести этапов данного процесса. При этом каждому этапу посвящена отдельная глава. Кроме этого, вторая часть книги включает в себя разделы, посвященные:

1. Принципам проектирования превосходного UX-дизайна.

2. Итеративному повышению степени соответствия вашего продукта рынку.

3. Детальному сквозному исследованию процесса создания бережливого продукта.

Часть III, «Создание и оптимизация продукта», содержит рекомендации, следование которым будет полезным после того, как вы – с помощью прототипа минимально жизнеспособного продукта (MVP) – убедитесь в соответствии вашего продукта рынку. Там же вы найдете главу о том, как создать свой продукт с использованием принципов Agile-разработки, которая охватывает в том числе такие темы, как тестирование, непрерывная интеграция и непрерывное развертывание (CI/CD). Кроме того, две главы этой части книги посвящены аналитике. В них описывается методология использования различных метрик для оптимизации продукта и приводится подробный тематический пример из реального мира.

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

Часть I

Основные концепции

Глава 1

Достижение соответствия продукта рынку с помощью процесса создания бережливого продукта

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

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

Что понимается под соответствием продукта рынку?

Как я уже упоминал во Введении, Марк Андреессен ввел термин «соответствие продукта рынку», опубликовав ставший широко известным пост в своем блоге под названием «Единственное, что имеет значение». В этом посте он пишет: «Соответствие продукта рынку означает ваше присутствие на хорошо развитом рынке с продуктом, который способен удовлетворить потребности этого рынка». Мое собственное определение данного термина согласуется с приведенной цитатой и подразумевает продукт, который имеет значительную потребительскую ценность. То есть продукт отвечает реальным потребностям клиентов и делает это лучше, чем его аналоги.

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

В этой книге я использую приведенное выше основное определение. В бизнесе существует различие между созданием ценности и ее получением. Чтобы монетизировать ценность, ее сначала нужно создать. Понятно, что такие аспекты, как бизнес-модель, привлечение клиентов, маркетинг и ценообразование имеют для успешного бизнеса решающее значение. Каждый из них достоин отдельной книги. Я тоже затрагиваю эти темы, представляя качественные и количественные методы, которые могут быть использованы для улучшения перечисленных бизнес-аспектов – в главах 13 и 14 обсуждается, как оптимизировать бизнес-показатели. Но все же большая часть этой книги посвящена основному определению соответствия продукта рынку и содержит руководство по его достижению.

Пирамида соответствия продукта рынку

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

Рисунок 1.1. Пирамида соответствия продукта рынку

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

Рынок

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

Присутствующие на рынке клиенты выбирают разные решения для удовлетворения своих потребностей. Например, некоторые клиенты на рынке услуг по заполнению налоговых деклараций могут довериться профессиональным консультантам, таким как компания H&R Block. Другие могут заняться этой работой самостоятельно – вручную либо с использованием специализированного программного обеспечения, например, TurboTax.

В рамках конкретного рынка можно определить рыночную долю каждого конкурирующего продукта, то есть понять, какой процент рынка охватывает каждый продукт. Например, вы могли бы сравнить доли рынка смартфонов, принадлежащие компаниям Apple и Samsung. Или же сегментировать рынок смартфонов по операционным системам (iOS, Android и так далее). Интернет-браузеры – еще один сегмент, в котором рыночные доли каждого отдельного продукта внимательно отслеживаются участниками и аналитиками.

Проходя по рядам супермаркета, вы видите товары, относящиеся к самым разным категориям: зубные пасты, шампуни, стиральные порошки, хлопья, йогурты, пиво – и это далеко не полный перечень. Стадия жизненного цикла, на которой пребывает тот или иной рынок, может быть разной. Многие из продуктов, которые вы видите на магазинных полках, такие как молоко, яйца и хлеб, представлены на относительно зрелых рынках, где практически нет инноваций или изменений. Но существуют рынки, которые появились совсем недавно. Например, компания Febreze фактически создала рынок с нуля, выпустив новый продукт, который устраняет неприятные запахи с тканей без применения стирки – до этого соответствующего рынка просто не существовало. Для многих рынков характерно наличие активной конкуренции, когда компании пытаются завоевать как можно большую долю за счет применения инноваций при производстве своих продуктов.

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

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

Продукт

Продукт – это специфическое предложение, предназначенное для удовлетворения набора потребностей клиента. Из этого определения следует, что концепция соответствия продукта рынку применима как к товарам, так и к услугам. Различие между товаром и услугой заключается в том, что товар имеет физическое воплощение, в то время как услуга нематериальна. Однако с появлением продуктов, продаваемых через Интернет и мобильные устройства, различия между товаром и услугой оказались размытыми. Достаточно вспомнить хотя бы популярный ныне термин программное обеспечение как услуга (Software as a Service, или SaaS).

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

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

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

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

Соответствие продукта рынку

Соответствие продукта рынку являет собой показатель того, насколько хорошо продукт (три верхних слоя пирамиды) удовлетворяет требованиям рынка (два нижних слоя). Именно целевым клиентам предстоит определить, насколько точно предлагаемый продукт соответствует их потребностям. Не надо забывать, что оценивать ваш продукт они будут, сравнивая его с уже имеющимися аналогами, и, чтобы продукт соответствовал рынку, он должен удовлетворять потребности лучше аналогов. Давайте рассмотрим пример достижения такого успешного результата.

Взлет: с 47-го места на первое

Отличным примером соответствия потребностям рынка является приложение для ведения личных финансов Quicken, разработанное компанией Intuit. Продукт был выпущен на и без того переполненный рынок, на котором присутствовали 46 аналогов. Тем не менее, проведя исследование потребностей пользователей, учредители компании пришли к выводу, что ни один из них не отвечал потребностям клиентов в полной мере, и к тому же все они были сложны в применении. Идея нового продукта была основана на использовании дизайна, напоминающего обычную чековую книжку, – в то время каждый американец сталкивался с процедурой выписывания чеков. Гипотеза оказалась верной: созданный пользовательский опыт, основанный на концептуальном дизайне, напоминающем обычную чековую книжку, нашел отклик со стороны клиентов. В итоге приложение Quicken быстро стало ведущим программным обеспечением для ведения личных финансов.

Во многом успех Quicken был обусловлен тем, что в Intuit применялись принципы производства, которые сегодня назвали бы бережливыми. Компания одной из первых начала проводить исследования клиентских потребностей, тестирование своих продуктов на пользователях в процессе разработки программного обеспечения. Перед выпуском каждой версии своих продуктов компания обязательно проверяла ее на удобство использования и проводила публичное бета-тестирование. Все это делалось задолго до того, как подобные идеи превратились в мейнстрим. Кроме этого, компания придумала концепцию «Проводи клиента домой»: сотрудники Intuit дежурили в розничных магазинах в ожидании, пока кто-то из посетителей купит копию приложения Quicken. Когда это случалось, они просили у покупателя разрешения проводить его домой, чтобы посмотреть, как он будет использовать приобретенное ПО. Это очень помогало в оценке первого впечатления от использования продукта.

Давайте попробуем рассмотреть приложение Quicken с помощью пирамиды соответствия продукта рынку. В рыночном сегменте присутствовало довольно много клиентов, и продукт определенно был заточен под удовлетворение реально существующей потребности: людям, безусловно, требовалась помощь в подведении балансов их чековых книжек, отслеживании остатков на счетах – в общем, в понимании того, куда уходят их деньги. Компьютерное ПО хорошо для этого подходило, а представленные на рынке специализированные программы отвечали этим требованиям недостаточно полно – это показали результаты общения учредителей Intuit с клиентами компании. Применение креативных дизайнерских решений привело к созданию инновационного UX, который пользователи сочли гораздо более простым в использовании. Этот фактор, по сути, стал главной «фишкой» ценностного предложения Quicken. Добившись соответствия продукта рынку, приложение сумело выдержать жесткую конкуренцию на рынке, что дало основателям Intuit повод для шуток о преимуществах статуса 47-го первопроходца.

Процесс создания бережливого продукта

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

Такой подход поможет вам сформулировать и проверить ваши ключевые гипотезы по каждому из пяти компонентов соответствия продукта рынку.

Рисунок 1.2. Процесс создания бережливого продукта

Я подробно описываю шесть этапов процесса создания бережливого продукта во второй части этой книги. Каждому из перечисленных ниже этапов посвящена отдельная глава:

• Идентификация целевых потребителей.

• Определение недостаточно удовлетворенных потребностей клиентов.

• Формирование ценностного предложения.

• Определение функционала минимально жизнеспособного продукта (MVP).

• Создание прототипа MVP.

• Тестирование MVP на пользователях.

Последние три шага относятся к важному аспекту бережливого производства – минимально жизнеспособному продукту (MVP). Эта тема будет подробно обсуждаться в главах 6 и 7, пока же скажу лишь, что, по сути, речь идет о минимальном функционале, который обеспечивает достаточную ценность для потребителя вашего продукта. При создании нового продукта на этапе подготовки к тестированию ключевых гипотез на пользователях вы стремитесь обойтись минимально необходимым для этого набором готовых функций. Идея использования MVP применима в том случае, когда речь идет либо о совершенно новом продукте в его первой версии (сокращенно v1), либо о редизайне существующего продукта или создании его обновленной версии – v2.

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

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

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

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

Ключевой концепцией бережливого производства, вдохновившей появление понятия бережливого стартапа, является концепция переработок: необходимость тратить время на исправление того, что изначально было сделано неправильно. Сведение переделок к минимуму является ключевой тактикой устранения потерь («мудов»). Процесс создания бережливого продукта не только помогает достичь соответствия продукта рынку, но и за счет сокращения количества переделок позволяет сделать это быстрее.

Безусловно, в процессе создания бережливого продукта у вас не получится обойтись без переработок. Это итеративный процесс, который по мере продвижения вперед требует регулярного пересмотра гипотез, дизайнов и самого продукта – все это можно считать переработкой. Цель данного процесса – как можно быстрее достичь соответствия продукта рынку. Быстрое, но трезвое мышление, позволяющее избежать переработок или сократить их количество, помогает успешному ее достижению.

Процесс создания бережливого продукта можно представить как упражнения на тренировках по карате по мере того, как занимающиеся прогрессируют, достигая все новых высот мастерства. Начав с изучения основных приемов и став со временем обладателями черных поясов, бойцы могут перейти к комбинированию и модификации приемов, которые они освоили на более ранних стадиях, создавая таким образом свой собственный индивидуальный стиль. Мастер боевых искусств Брюс Ли красноречиво высказался на эту тему: «Следуй принципам, не будучи ими связанным». Ему же принадлежат другие слова: «Примеряй полезное, отвергай бесполезное и добавляй свое». Я призываю вас прислушаться к этим советам, когда будете применять на практике идеи и рекомендации, почерпнутые из этой книги.

Я был бы рад получить от вас любые вопросы или отзывы, а также описание вашего собственного опыта применения изложенных здесь идей. Пожалуйста, не стесняйтесь делиться своими мыслями и историями на веб-сайте этой книги: http://leanproductplaybook.com. Так вы внесете свой вклад в обсуждение темы создания успешных продуктов.

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

Глава 2

Пространство проблем и пространство решений

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

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

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

Космическая ручка

Моя любимая история, иллюстрирующая концепцию пространства проблем в его сравнении с пространством решений, связана с космической ручкой. Когда в NASA еще только готовились отправить астронавтов в космос, одним из вопросов, требующих решения, являлась проблема шариковых ручек, которыми, как было очевидно, невозможно писать в отсутствие гравитации. Один из подрядчиков NASA, компания Fisher Pen Company, подготовила исследовательскую программу по разработке ручки, которая работала бы в условиях невесомости. Потратив миллион долларов из личных средств, президент компании Пол Фишер в 1965 году изобрел космическую ручку – замечательную технологию, которая отлично работает на орбите.

В свою очередь, столкнувшись с той же проблемой, Российское космическое агентство просто снабдило своих космонавтов карандашами. Теперь у вас есть возможность приобрести «русскую космическую ручку» (которая представляет собой просто красиво упакованный красный карандаш).

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

В описанной ситуации, чтобы не зацикливаться на возможных решениях, связанных исключительно с авторучкой, мы могли бы перефразировать задачу в области проблемного пространства следующим образом: «нам нужен пишущий инструмент, работающий в условиях невесомости». Это позволило бы предложить карандаш в качестве допустимого решения. Ведь оно вполне соответствует поставленной задаче: получить «пишущий инструмент». Мы можем еще раз улучшить постановку задачи, указав, что «нужен простой способ создания заметок в условиях невесомости для их последующего использования». Такая формулировка позволила бы использовать более креативные решения, такие как запись голоса с возможностью последующего воспроизведения. На самом деле, само по себе рассмотрение возможных вариантов решения проблемы может помочь уточнить параметры проблемного пространства, даже если предлагаемые идеи не подходят для реализации. В рассматриваемом случае диктофон, вероятно, был бы не таким хорошим решением, как авторучка. Для него потребовался бы источник питания. Кроме того, необходимость постоянного воспроизведения голосовой записи для обращения к сделанным заметкам делает это решение менее удобным по сравнению с возможностью читать рукописный текст. Выполнение умственного упражнения в ходе поиска решения позволило бы сделать определение проблемного пространства еще более точным: «нужен такой способ создания заметок в условиях невесомости, который был бы удобен и прост как в применении, так и при последующем использовании, недорог и не требовал внешнего источника питания».

Приводя этот пример, я всегда уточняю, что он ни в коем случае не является попыткой высмеять NASA. Эта история – всего лишь иллюстрация. В действительности решение, к которому в итоге пришло NASA, оказался наилучшим. Есть веские причины не использовать карандаши в космосе: кончики грифелей могут отломиться и вызвать короткое замыкание. После трагического пожара, случившегося на «Аполлоне-1» в 1967 году, NASA потребовало, чтобы все находящиеся в кабине космического корабля предметы были негорючими, включая и письменные принадлежности. Таким образом, космическая ручка на самом деле была полезной инновацией, которую, кстати, переняло и Российское космическое агентство.

Когда я привожу пример с космической ручкой во время выступлений, часто случается, что кто-нибудь из аудитории заявляет, что это просто байка. Однако правдивость этой истории подтверждает само NASA (источник: http://history.nasa.gov/spacepen.html) и компания-разработчик Fisher Space Pen Company (источник: http://fisherspacepen.com). Ключевым моментом дебатов вокруг этой истории обычно является вопрос, чьи же все-таки деньги были потрачены на исследования и разработку космической ручки: NASA или Фишера? На самом деле, как я и указал, это были личные средства Фишера.

Проблемы, формирующие рынки

Однажды в начале моей карьеры продуктового менеджера основатель Intuit Скотт Кук, сам того не осознавая, очень помог мне в укреплении концепции сопоставления пространств проблем и решений. Выступая перед нашей группой, Скотт спросил: «Кто является главным конкурентом нашего налогового приложения TurboTax?» Взметнулось множество рук. В то время еще одним популярным ПО для заполнения налоговых деклараций было приложение TaxCut от компании H&R Block. Но, после того как кто-то уверенно ответил «TaxCut», Скотт удивил нас, заявив, что главным конкурентом TurboTax на самом деле являются бумага и ручка. Он пояснил, что американцы заполняют вручную гораздо больше бумажных форм деклараций, чем все налоговые программы вместе взятые (на тот момент времени).

Этот пример подчеркивает еще одно преимущество мышления в парадигме пространства проблем: более точное понимание того, на каком рынке в действительности конкурирует ваш продукт. Менеджеры, присутствовавшие в аудитории, мыслили слишком узко, поскольку делали это, находясь внутри пространства решений, в границах рынка «программных продуктов для заполнения налоговых деклараций». В свою очередь, Скотт мыслил в проблемном пространстве о более широком рынке «услуг по заполнению налоговых деклараций», который включал в себя в том числе налоговых бухгалтеров, которым клиенты поручают подготовку этих отчетов. Как уже было сказано в предыдущей главе, рынок представляет собой набор взаимосвязанных клиентских потребностей, которые напрямую относятся к пространству проблем. Рынок не привязан к каким-либо конкретным решениям, которые удовлетворяют эти потребности. Вот почему мы с вами наблюдаем так называемые «рыночные сбои», когда выясняется, что новый тип продукта (пространство решений) в большей степени соответствует потребностям рынка (пространство проблем). Появление новой технологии часто приводит к рыночным сбоям, предлагая все те же выгоды, но при гораздо меньших затратах. Передача голоса с использованием интернет-протокола (VOIP) – отличный пример прорывной технологии, пришедшей на смену традиционной телефонной связи. Поначалу качество звука при VOIP-звонках было заметно хуже, чем при использовании традиционных телефонных линий, но их стоимость была настолько ниже, что данное решение стало предпочтительным для большей части рынка телефонной связи.

Что и как

За время работы в компании Intuit я научился писать подробные требования к продуктам, которые оставались в области проблем, не переходя в область решений. Нас учили сначала фокусироваться на том, что продукт должен предлагать клиентам, прежде чем переходить к тому, как он может это сделать. Наверняка вы часто слышали, что действительно сильные команды разработчиков проводят четкое различие между понятиями «что» и «как». При этом к категории «Что» относят преимущества, которые разрабатываемый продукт должен дать потребителю. Под «Как» подразумеваются способы достижения и предоставления клиенту этого самого «Что». «Как» – это дизайн продукта и конкретная технология. «Что» находится в пространстве проблем, а «Как» – в пространстве решений.

Разработка продукта «снаружи – внутрь»

Неспособность получить четкое представление о пространстве проблем до перехода в пространство решений присуща компаниям и командам, которые практикуют разработку своих продуктов по схеме «изнутри наружу», где под «внутри» понимается компания-разработчик, а под «снаружи» – потребители и рынок. В таких командах идеи новых продуктов представляют собой то, что, по мнению одного или нескольких сотрудников, было бы неплохо сделать. Они не тестируют свои идеи на пользователях, чтобы убедиться, что придуманный ими продукт действительно удовлетворит реальные потребности клиентов. Лучший способ снизить риск такого мышления «наизнанку» – убедиться, что команда разработчиков общается с потребителями. Вот почему Стив Бланк[2] призывает продуктовые команды «выходить в народ»[3].

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

Нужно ли прислушиваться к потребителям?

Критики ориентированного на пользователя дизайна считают, что общение с потребителями не способно привести к появлению новых, прорывных решений. При этом они любят цитировать Генри Форда, который сказал: «Если бы я спросил людей, что им нужно, пределом полета их мысли была бы просто более быстрая лошадь». В качестве еще одного аргумента они приводят историю Стива Джобса, дескать, Apple выпустила на рынок множество успешных продуктов, используя, как они полагают, ту самую «вывернутую наизнанку» схему разработки. Действительно, в интервью Forbes в 2008 году Стив Джобс процитировал вышеприведенное высказывание Генри Форда.

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

Да, вполне вероятно, что потребители не изобретут за вас прорывной продукт. Но это не значит, что понимание их потребностей и предпочтений – пустая трата времени. Напротив, глубокое понимание нужд клиентов помогает командам разработчиков при анализе предлагаемых инновационных решений объективно оценивать, насколько востребованным окажется каждое из них.

Еще одним из аргументов, так любимых критиками дизайна, ориентированного на пользователя, является ссылка на принцип: «Apple не разговаривает с клиентами». Однако в своем выступлении на Всемирной конференции разработчиков Apple 1997 года Стив Джобс поделился с аудиторией более развернутой формулировкой, которая вполне согласуется с принципами бережливого производства:

«Вы должны начать с пользовательского опыта и лишь затем обращаться к технологиям. Вы не можете начинать с технологии, не пытаясь понять, кому вы собираетесь ее продавать… Когда мы работали над корпоративной стратегией и миссией для Apple, все началось с вопроса “Какие невероятные преимущества мы можем предложить клиенту?..” Не стоит начинать с “Давайте сядем с инженерами и выясним, какая потрясающая технология у нас есть, а потом решим, как мы будем ее продавать”».

История о двух «фишках» Apple

Несмотря на то что Apple действительно имеет репутацию компании, не тестирующей на пользователях свои продукты до их выхода на рынок, своим успехом она во многом обязана тому, что хорошо понимает потребности клиентов. Взять к примеру датчик отпечатков пальцев Touch ID, который Apple впервые представила в iPhone 5S. Эта функция работает благодаря передовой технологии: сенсор толщиной всего 170 микрон сканирует ваш палец с разрешением 500 точек на дюйм. Для защиты датчика его кнопка изготовлена из сапфирового стекла – одного из самых чистых и твердых из доступных материалов. Кроме того, кнопка выполняет функцию объектива для точной фокусировки датчика на пальце пользователя. Touch ID может распознавать несколько отпечатков пальцев в любой ориентации и при этом видит даже такие детали узоров, которые недоступны человеческому глазу.

Маловероятно, что кто-либо из пользователей iPhone самостоятельно додумался бы до такого решения. Могу предположить, что Apple не тестировала эту функцию на пользователях до ее реализации. Но, несмотря на это, я утверждаю, что команда разработчиков iPhone хорошо ориентировалась в проблемном пространстве и могла с уверенностью ожидать, что потребители сочтут Touch ID ценной инновацией. Разработчики предложили альтернативу традиционному способу разблокировки iPhone и входа в AppStore для совершения покупки. Функция Touch ID в большей степени соответствовала потребностям клиентов, для которых, несомненно, было важно, чтобы процедура аутентификации была удобной и безопасной. Особенно если учесть, что обычно эти две характеристики являются взаимоисключающими – более удобные механизмы аутентификации являются менее безопасными (и наоборот).

Большинство пользователей iPhone разблокируют свои телефоны довольно часто. Поскольку они ценят свое время, более быстрая разблокировка является очевидным преимуществом. А еще пользователи iPhone ценят безопасность. Они не хотят, чтобы посторонние люди могли получить доступ к содержимому их смартфонов, особенно в том случае если он утерян или украден. При использовании четырехзначного кода вероятность того, что кто-то угадает ваш пароль, составляет 1 к 10 000. По данным же Apple, вероятность того, что два отпечатка пальцев окажутся достаточно похожи, чтобы Touch ID посчитал их одинаковыми, составляет 1 к 50 000 (не говоря уже о том, что пытаться прикладывать к сенсору тысячи разных пальцев гораздо сложнее, чем вводить разные цифры).

Touch ID позволяет выполнить аутентификацию намного быстрее, чем это происходит при вводе цифрового кода разблокировки или пароля App Store. Он более удобен еще и потому, что пользователям больше не нужно беспокоиться о том, что они забудут свои пароли.

Итак, поскольку Touch ID явно экономит время, более удобен и безопасен, чем предыдущее решение, команда разработчиков iPhone, даже не проводя тестирования на пользователях, могла с полной уверенностью ожидать, что те сочтут эту функцию ценной. Но, как бы то ни было, если Apple действительно не проводила такого тестирования, она подвергала себя риску непредвиденных негативных последствий. Стоит отметить, что на самом деле Apple все же опробует свои новые продукты внутри компании на собственных сотрудниках (которые довольно часто являются хорошими посредниками между клиентами и компанией). Такой метод внутреннего тестирования на сотрудниках, выступающих в роли пользователей разрабатываемого продукта, называется «догфудинг».

Тем не менее, и на «солнце» Apple есть свои «пятна». Например, клиенты были явно недовольны «улучшением» продукта, которое выражалось в изменении кнопки включения на MacBook Pro 2013 года выпуска. В предыдущей версии ноутбука кнопка включения располагалась вдали от клавиш клавиатуры, имела меньший размер, отличительный цвет и была утоплена в корпус, что затрудняло ее случайное нажатие. Кроме того, когда пользователи нажимали эту кнопку, на экране появлялось диалоговое окно, предлагающее варианты перезагрузки, перехода в спящий режим или выключения ноутбука, а также возможность отмены любого действия. Для версии 2013 года в Apple предусмотрели изменение дизайна кнопки включения: они сделали ее похожей на другие клавиши и встроили в общую клавиатуру (разместив ее в правом верхнем углу, там, где раньше была клавиша для извлечения диска). Более того, «усовершенствованная» кнопка включения теперь соседствовала с клавишей «Delete» и клавишей увеличения громкости звука, которые используются довольно часто. В результате пользователи стали то и дело случайно нажимать кнопку включения и делать отмену действия.

В довершение всего последующее обновление операционной системы Apple – OS X Mavericks – привело к изменению отклика при нажатии кнопки включения. В Mavericks, нажав кнопку питания, вы уже не вызывали диалоговое окно с различными вариантами выбора; вместо этого ваш MacBook сразу переходил в спящий режим. Закономерным последствием совокупности этих двух изменений (переноса кнопки включения и изменения ее поведения) стало разочарование пользователей, чьи ноутбуки внезапно «полюбили» переходить в спящий режим. Подобные проблемы, связанные с удобством применения продукта, легко выявляются при тестировании даже на небольшом количестве пользователей.

А теперь давайте сравним два приведенных выше примера из жизни Apple. В случае с Touch ID имелись очевидные преимущества и не возникло никаких непредвиденных рисков. А в случае с изменением кнопки включения, каковы были предполагаемые преимущества для пользователей? В любом случае их нельзя назвать очевидными, верно? Возможно, новый дизайн кнопки базировался на решении неких внутренних задач компании, связанных, например, с общей эстетикой продукта или снижением его себестоимости. Как бы то ни было, непривычный вид и поведение кнопки вызвали недовольство пользователей. Таким образом, хотя клиенты и не помогут вам с созданием прорывного инновационного продукта, но их отзывы подобны свету предупреждающих фонарей, которые уберегут вас от падения со скалы, когда вы попытаетесь пойти наугад в кромешной темноте и в неизвестном направлении.

Использование пространства решений для обнаружения пространства проблем

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

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

Пространство проблем, как и пространство решений, являются неотъемлемой частью пирамиды соответствия продукта рынку, как это показано на рисунке 2.1. Набор функций продукта и пользовательский опыт (UX) находятся в пространстве решений – это то, с чем клиенты непосредственно сталкиваются и на что могут реагировать. Остальные три слоя пирамиды находятся в пространстве проблем. Важный интерфейс между двумя пространствами возникает между ценностным предложением и набором функций продукта. Вы можете менять по своему усмотрению набор функций и пользовательский интерфейс, но не в состоянии изменить клиентов и их потребности. На них вы можете только ориентироваться. Таким образом, ценностное предложение – это тот единственный слой проблемного пространства, который вы способны контролировать.

Как сказал Дэйв Макклюр, основатель стартап-акселератора 500 Startups: «Клиентам наплевать на ваше решение. Они заботятся только о своих проблемах». Разделение пространства проблем и пространства решений, а также чередование внимания к ним по мере проведения итеративного тестирования и улучшения выдвигаемых гипотез – лучший способ добиться соответствия продукта рынку. Процесс создания бережливого продукта обеспечивает вас пошаговым руководством о том, как это сделать. Давайте перейдем к первому этапу этого процесса: идентификации целевого потребителя.

Рисунок 2.1. Сопоставление пространства проблем с пространством решений

Часть II

Процесс создания бережливого продукта

Глава 3

Идентификация целевого потребителя (Шаг 1)

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

Ловля потребителя

Многие компании выпускают на рынок свои продукты без мало-мальски серьезного предварительного обсуждения со своими целевыми потребителями. Иногда компания представляет продукт, ориентируясь на одну целевую аудиторию, но в конечном итоге оказывается, что он вызвал интерес у представителей совершенно другого потребительского сегмента. Подбор продукта для целевого потребителя подобен рыбной ловле. При этом продукт, который вы выпускаете на рынок, выступает в качестве приманки; а рыба, которую пытаетесь поймать, – это ваш целевой клиент. Иногда вам удается поймать именно ту рыбу, за которой вы охотились, но в других случаях улов оказывается для вас неожиданным. Вы можете выдвигать гипотезы, описывая свою целевую аудиторию, но при этом не будете знать наверняка, кто на самом деле является вашими клиентами до тех пор, пока не забросите крючок с наживкой и не увидите, какая рыба на нее клюнет. После того как у вас появится продукт или прототип, который можно продемонстрировать потребителям, вы будете готовы к тому, чтобы получить четкое представление о своем целевом рынке.

Конечно, ваша наживка может привлечь сразу несколько типов потребителей. Например, приложение Quicken было разработано таким образом, чтобы его индивидуальные пользователи могли легко управлять своими домашними финансами. Но он оказался настолько прост в использовании, что владельцы малого бизнеса начали применять его для управления финансами своих компаний. К удивлению команды разработчиков Quicken, они поймали на одну и ту же наживку сразу двух рыб разных видов. Проведя исследование профилей клиентов, в Intuit обнаружили, что почти треть пользователей Quicken использовали приложение применительно к бизнесу, а не к домашним финансам. В итоге компания разработала новую версию приложения Quicken для дома и бизнеса, которая в еще большей степени удовлетворяла специфическим потребностям владельцев малого бизнеса. Это же открытие, изменившее представление Intuit о своем целевом рынке, побудило компанию выпустить QuickBooks – еще один бухгалтерский программный продукт, предназначенный на этот раз исключительно для управления бизнес-финансами.

Компании часто хотят расширить или изменить свой целевой рынок. При этом некоторые из них стремятся продвинуться «вверх по рынку». Например, в настоящее время они продают свою продукцию малому бизнесу, но хотели бы привлечь в качестве покупателей более крупные предприятия. Другие компании, напротив, начав работу с крупными предприятиями, предпочли затем переместиться «вниз по рынку». Компания, добившаяся успеха в узкой отраслевой нише, может захотеть выйти на смежные рынки. Скажем, если вы создали программное обеспечение для управления учебными курсами, которое отвечает потребностям преподавателей колледжей, то можно попытаться выйти на более широкий рынок профессионального обучения. Если потребности смежного рынка схожи, незначительной доработки вашего продукта может быть вполне достаточно для обеспечения необходимого соответствия.

Как сегментировать целевой рынок

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

Демографическая сегментация

Демографические атрибуты – это относящиеся к людям и поддающиеся количественной статистической оценке данные, такие как возраст, пол, семейное положение, доход и уровень образования. Допустим, вы разработали приложение для мам, чтобы они могли легко делиться фотографиями своих малышей с друзьями и родственниками. Тогда описание демографических атрибутов ваших целевых клиентов могло бы выглядеть следующим образом: женщины в возрасте от 20 до 40 лет, у которых есть один или несколько детей в возрасте до трех лет.

Если же ваше приложение ориентировано на бизнес, вы должны использовать статистические данные, относящиеся к компаниям. Это будет похоже на демографические атрибуты, применяемые к людям, но включать такие характеристики, как размер компании и ее отраслевая принадлежность. Для идентификации по последнему названному атрибуту используются коды Стандартной промышленной классификации (Standard Industrial Classification, или SIC) и Североамериканской системы отраслевой классификации (North American Industry Classification System, или NAICS).

Психографическая сегментация

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

Поведенческая сегментация

Для описания своего целевого потребителя вы также можете воспользоваться поведенческими атрибутами, позволяющими установить, совершает ли кандидат определенные действия и как часто он это делает. Например, вы можете описать свою целевую аудиторию как мам, которые публикуют в среднем три или более детских фотографий в неделю в социальных сетях. Если же разработанное вами приложение предназначено для торгующих акциями активных инвесторов, вы могли бы определить свой целевой рынок так: трейдеры, которые совершают 10 и более сделок с акциями в неделю.

Сегментация на основе потребностей

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

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

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

Пользователи и покупатели

В некоторых случаях, особенно когда речь идет о продуктах для бизнеса, клиент, который будет использовать ваш продукт (пользователь), не является тем же лицом, которое принимает решение о покупке продукта (покупателем). Например, Salesforce.com представляет собой приложение, используемое корпоративными специалистами по продажам. Покупателями программных продуктов такого рода часто выступают вице-президенты компаний, курирующие направление продаж. Но в некоторых компаниях решения о покупке могут приниматься на уровне директора по технологиям. В компании может быть и сразу несколько заинтересованных сторон, каждая из которых должна согласовать решение о покупке конкретного продукта: финансовый директор, главный менеджер бизнес-подразделения, главный юрисконсульт, глава службы безопасности и так далее. В таких случаях полезно отличать непосредственного покупателя – ответственное лицо, которое контролирует бюджет и оплачивает счет, – от других согласующих сторон, участвующих в процессе принятия решений. Вторые часто являются потенциальными «блокираторами», поскольку у них есть право наложить вето на покупку вашего продукта, если они считают, что он не удовлетворяет всем заявленным требованиям. При этом у фактического покупателя часто имеются такие требования к продукту, которые отличаются от потребностей конечного пользователя. Вместе с тем именно эти потребности должны быть удовлетворены, чтобы продукт соответствовал рынку. Поэтому в подобных случаях дополнительно к идентификации целевого потребителя, будет разумно определить и своего целевого покупателя.

Жизненный цикл внедрения новых технологий

Возможно, вы слышали о классической книге Джеффри Мура «Преодоление пропасти»[4], посвященной продвижению на рынок высокотехнологичных продуктов. В ней Мур продвигает еще одну концепцию, положения которой важно учитывать при определении целевого рынка. Это концепция жизненного цикла внедрения новых технологий. Мур делит рынок на пять различных сегментов потребителей в зависимости от степени неприятия ими рисков при внедрении новых технологий. Ниже приведены описания этих пяти потребительских сегментов:

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

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

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

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

5. Отстающие – скептики, которые очень настороженно относятся к инновациям. Они ненавидят перемены и склонны критиковать новые технологии даже после их превращения в мейнстрим.

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

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

Метод персонажей

Метод персонажей – это полезный инструмент для описания целевого потребителя. Алан Купер[5] выступал за использование метода персонажей как части разработанного им процесса «целенаправленного проектирования». В своей книге «Психбольница в руках пациентов»[6] он поясняет, что под термином «персонаж» подразумевается «точное определение нашего пользователя и того, чего он хочет достичь». И далее: «персонажи – это не реальные люди», а скорее «гипотетические архетипы реальных пользователей».

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

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

Что вы должны знать о своем персонаже?

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

• Имя;

• Репрезентативная фотография;

• Фраза (цитата), передающая главные приоритеты персонажа;

• Род занятий;

• Демографические данные;

• Потребности/цели;

• Соответствующие мотивы и установки;

• Связанные с этим задачи и модели поведения;

• Разочарования/проблемы, связанные с текущим решением;

• Уровень экспертных знаний (в соответствующей области, например, уровень компьютерной грамотности);

• Контекст/среда в которых персонаж использует ваш продукт (например, работа за ноутбуком в шумном оживленном офисе или на планшете, развалившись дома на диване);

• Сегмент жизненного цикла принятия технологии (для вашей категории продукта);

• Любые другие важные атрибуты.

Две вещи в этом списке, которые действительно оживляют личность, – это репрезентативное фото и ключевая фраза, отражающая то, что для вашего персонажа наиболее важно. Члены команды обычно лучше всего запоминают имя, фотографию и цитату. Именно эти параметры остаются в их памяти, когда они уже не смотрят на описание персонажа. Примерное описание персонажа представлено на рисунке 3.1. Я адаптировал этот пример, взяв за основу персонаж, созданный талантливым UX-дизайнером Беккой Тецлафф. Вы можете ознакомиться с другими примерами ее работ на сайте: http://beccatetzlaff.com.

Рисунок 3.1. Персонаж

«Главным приоритетом для меня является здоровье моих детей. Поскольку воспитание двоих детей отнимает массу времени, мне нужен простой способ следить за обновлением их медицинских рецептов и назначений».

Лиза – учитель начальной школы. Она живет с мужем, Дейвом, который постоянно занят на работе, 12-летней дочерью по имени Эддисон и 9-летним сыном, Калебом. Поскольку муж Лизы часто работает допоздна, она является главным воспитателем для их детей.

У Эддисон астма, и, выходя из дома, она всегда должна иметь при себе ингалятор. Лиза беспокоится о том, что может забыть вовремя заправить ингалятор и таким образом подвергнуть дочь опасности.

Жизнь бурлит вокруг Лизы, и у нее почти не остается времени на саму себя. Соответственно, ей нужен простой и надежный способ следить за здоровьем детей и выполнять медицинские предписания.

Как создавать персонажей

Каким образом можно собрать информацию для создания своего персонажа? Если у вас есть клиенты, вы можете сделать это путем проведения интервью и опросов. Общение с клиентами в формате один на один – лучший способ получить необходимые данные. Научившись формулировать правильные вопросы, вы сможете собирать нужную информацию сразу от большого числа респондентов.

Когда вы используете данные, полученные в ходе опросов, важно не использовать усредненные значения для формирования образа вашего персонажа. Вам нужно, чтобы персонаж представлял реального человека, поскольку вы не собираетесь создавать продукт для некого несуществующего «среднего» потребителя. Как тонко заметил в своей книге Алан Купер: «В среднем каждый человек из моего окружения имеет 2–3 ребенка, но ни у одного из них нет ровно 2–3 ребенка». Очевидно, что при таких вводных данных персонаж должен иметь двоих или троих детей. Вы можете использовать полученные в ходе опросов совокупные данные, чтобы убедиться, что ваш персонаж олицетворяет значительную часть представителей клиентской базы. Индивидуальные ответы тех людей, которые соответствуют профилю целевого потребителя, могут оказаться весьма ценным источником информации.

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

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

Потенциальные проблемы с персонажами

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

Разработка персонажа не должна замедлять процесс создания продукта, и вам не следует тратить слишком много времени на доведение до совершенства первоначальной версии его профиля. Ее следует воспринимать как черновик, который вы будете пересматривать по мере прохождения этапов процесса. Никто не начинает работу, имея настолько выверенные характеристики персонажа, как те, что показаны на Рисунке 3.1; это результат многочисленных итераций в ходе процесса выявления потребителей. Со временем, по мере того как вы будете получать все больший объем обновленной информации о своих потребителях, степень достоверности персонажа будет только возрастать.

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

В моей практике были случаи, когда компании, разработав набор персонажей, прекращали общение с клиентами. Потеря связи с клиентами довольно частое явление, особенно по мере того как к команде разработчиков присоединяются новые члены. Метод персонажей – отличный инструмент, однако он не должен ставиться заменой постоянному общению с потребителями.

Как было сказано ранее, опрос потенциальных пользователей на ранних стадиях процесса создания продукта бывает весьма полезным. Но как только у вас появится готовый продукт или его прототип, вы сможете получить более точное представление о своем целевом потребителе, потому что появляется возможность «закинуть наживку» и посмотреть, какая именно «рыба» на нее готова ловиться. Подобно описанным выше историям с приложениями Quicken и Dropcam, может оказаться, что ваш продукт привлечет разные типы потребителей. В этом случае вам нужно будет создать персонажей для каждой потребительской группы.

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

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

Глава 4

Выявление недостаточно удовлетворенных потребностей клиентов (Шаг 2)

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

Завуалированные потребности

Я использую слово «потребности» для обозначения того, что хотят или ценят клиенты (потребители), и термин «потребительские преимущества (выгоды)» как взаимозаменяемый с понятием «потребности». Иногда сами клиенты могут сказать вам, что именно им нужно, однако потребность вовсе не обязательно должна быть чем-то таким, о чем говорят буквально: «Мне нужно [______________]». Существуют невысказанные, но подразумеваемые потребности – те, что имеются у клиента, но они не формулируются им во время интервью. Более того, в некоторых случаях клиент даже не осознает, что некий функционал представляет для него ценность, пока вы не проведете с ним собеседование или не познакомите его с каким-нибудь новым прорывным решением. Клиенты, как правило, не умеют формулировать свои потребности в терминах проблемного пространства; у них гораздо лучше получается рассказывать о том, что им нравится и не нравится в конкретном решении. Хорошие интервьюеры отличаются тем, что умеют внимательно прислушиваться к словам потребителей, направляют их внимание в нужное русло и задают дополнительные вопросы, которые позволяют лучше осветить проблемное пространство.

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

Обсуждая такие вещи, как опыт пользователя или метод разработки персонажей, часто используют термин «пользовательская цель». Такая цель ничем не отличается от потребности клиента. В Agile-разработке для описания клиентских потребностей используется понятие истории пользователей. Хорошо написанная история пользователя соответствует следующему шаблону: «Как [тип пользователя] я хочу [что-то сделать], чтобы я мог [получить желаемую выгоду]». Например: «Как пользователь приложения Dropcam, отвечающий за обеспечение безопасности в магазине, я хочу иметь возможность быстрого просмотра подозрительных эпизодов без необходимости смотреть видео с камер наблюдения целиком, чтобы контролировать происходящее в торговом зале, не тратя на это слишком много времени». Четко прописанные истории пользователей очень хорошо отражают потребности клиентов.

Болевая точка клиента – это еще один часто используемый термин, который подпадает под понятие «клиентской потребности». Болевая точка – это потребность, которая в настоящее время не имеет адекватного решения, что приводит к неудовлетворенности клиента. Далее в этой книге понятию удовлетворенности клиентов будет посвящен специальный раздел.

Клиентские потребности на примере приложения TurboTax

Давайте обсудим клиентские потребности на конкретном примере. В Соединенных Штатах большинство работающих граждан обязаны ежегодно подавать налоговые декларации, и следует признать, что мало кому из них это нравится. Заполнение форм декларации может занимать много времени и вызывать раздражение у тех, кто не обладает глубокими познаниями в области налогового права. Поскольку налоговые правила сложны и постоянно меняются, людям часто не хватает уверенности в том, что они сделали правильные расчеты. Если Налоговая служба, проверив декларацию, обнаружит неточности, вам придется заплатить штраф; а в отдельных случаях, которые считаются налоговым мошенничеством, в качестве наказания предусмотрено даже тюремное заключение. Таким образом, у клиентов имеется явная потребность в правильном заполнении налоговых деклараций. Как обсуждалось в главе 1, они могут удовлетворить эту потребность различными способами: заполнив формы Налогового управления вручную, наняв профессионального бухгалтера-аудитора либо используя специализированное программное обеспечение для подготовки налоговых деклараций. Такое как TurboTax.

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

Функционал программных продуктов для подготовки налоговых деклараций может выходить далеко за рамки налоговых форм, которые на самом деле являются всего лишь инструкциями. Приложение может проверить точность заполнения вашей декларации. TurboTax также умеет направлять за вас заполненные формы в Налоговую службу в электронном виде, что удобнее, чем распечатывать и отправлять их по почте. Кроме того, это приложение может помочь вам максимизировать налоговые вычеты, снизить риск назначения аудиторский проверки и даже загрузить нужные для расчета налогов справки от вашего работодателя, банков и брокерских контор, чтобы вам не пришлось вводить их вручную. Каждый из этих пунктов может быть сформулирован как потребность клиента. Давайте так и сделаем:

• Помогите в заполнении моей налоговой декларации.

• Проверьте точность моей налоговой декларации.

• Уменьшите риск аудиторской проверки моей декларации.

• Сократите время ввода данных для моей налоговой декларации.

• Сократите время, которое я трачу на подачу заполненной налоговой декларации.

• Максимизируйте мои налоговые вычеты.

Это ни в коем случае не исчерпывающий перечень потребностей, которые может удовлетворить TurboTax. Мы могли бы продолжить «чистить луковицу» и выявить еще несколько преимуществ приложения. Например, декларации по налогам штата полностью отделены от деклараций по федеральным налогам. Кроме того, TurboTax предлагает услугу, которая позволяет вам быстрее получать налоговые возвраты. Но для целей данного обсуждения будет достаточно, если мы сосредоточимся на шести вышеперечисленных преимуществах.

Надеюсь, использованные мной формулировки действительно похожи на описание клиентских выгод, а не функционала приложения. Один из самых верных признаков того, что команда разработчиков продукта начинает работу с области решений, а не с области проблем, заключается в том, что вместо формулировки преимуществ для клиентов они перечисляют функции своего продукта. Как и в случае с пользовательскими историями для Agile-разработки, все будущие полезности продукта должны быть описаны с точки зрения клиента (с использованием местоимений «я» и «мое»). Вы также можете заметить, что каждый пункт в моем описании начинается с глагола: помогите, проверьте, уменьшите, сократите. Все они несут в себе ценность для клиента. Наконец, многие из перечисленных выгод связаны с увеличением желаемого (налоговые вычеты) или уменьшением нежелательного (аудиторский риск, время, необходимое для выполнения задачи). Вы должны стремиться к тому, чтобы максимально точно описывать достигаемые преимущества. Это делает их более очевидными и часто позволяет более объективно оценить степень повышения эффективности, достигаемой за счет использования вашего продукта.

Как и во всем, что связано с процессом создания бережливого продукта, составление перечня выгод для потребителей начинаются с гипотез. Вы говорите: «Я думаю, что целевой потребитель X счел бы ценным преимущество Y». Как только в вашем распоряжении окажется приемлемый первоначальный набор гипотетических клиентских выгод, настанет время для их тестирования на пользователях. Лучший способ сделать это – провести индивидуальные интервью с целевыми потребителями.

Интервью с целью идентификации потребителей

Во-первых, во время собеседования вы должны поделиться с опрашиваемым потребителем каждой из своих гипотез о тех выгодах, которые, по вашему мнению, приложение создает для клиента. Вам следует задать ряд вопросов, чтобы охватить все предлагаемые преимущества. Например, такие:

• Что означает для вас это утверждение? (Для проверки правильности понимания).

• Как это решение может вам помочь?

• Если бы продукт обеспечивал такое преимущество, насколько это было бы ценно для вас? (Возможные варианты ответа: нисколько, незначительно, средне, ценно или очень ценно).

• В случае выбора ответа «ценно» или «очень ценно»: почему это так важно для вас?

• При выборе ответа о низком уровне (или полном отсутствии) ценности: почему это не представляет для вас ценности?

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

Если бы мы опрашивали участников целевого рынка приложения TurboTax о шести перечисленных выше потребностях, их ответы и комментарии могли бы быть похожи на те, что приведены в Таблице 4.1.

Таблица 4.1 Клиентские потребности и связанные с ними комментарии

При проведении интервью вы обнаружите, что потребители могут использовать разные слова для описания одной и той же идеи. Кроме того, их утверждения могут быть как более, так и менее конкретными. Например, если вы спросите разных потребителей, почему им нравится TurboTax, один может ответить: «Потому что это приложение значительно снижает затраты на уплату налогов», в то время как другой может сказать: «Мне нравится, как приложение проверяет мою декларацию на наличие ошибок, прежде чем отправить ее по электронной почте».

Лестница потребительских преимуществ

Проводя интервью с потребителями, вы можете продолжать задавать вопрос «Почему это ценно для вас?» до тех пор, пока не придете к каким-либо новым ответам. Такой подход позволяет перевести обсуждение с более конкретных потребностей на преимущества более высокого уровня. Такой метод исследования рынка называется лестничным интервью или «лэддеринг»[7]. Задавая вопрос за вопросом, вы как бы поднимаетесь по ступенькам лестницы, представляющим соответствующие преимущества, до тех пор, пока не достигнете верхней ступени.

Давайте рассмотрим пример такого «лэддеринга» преимуществ. Допустим, мы пытаемся понять, почему некоторые водители предпочитают спортивные внедорожники минивэнам. Мы начинаем интервью с потребителем именно с этого вопроса. Он отвечает, что предпочитает внедорожники, потому что ему не нравятся раздвижные двери. Когда мы спрашиваем почему, он говорит, что предпочитает автомобили со стильным дизайном. Когда мы снова спрашиваем почему, он отвечает: «Потому что я хочу быть модным». После очередного «почему» мы, наконец, узнаем, что мотивацией верхнего уровня является то, что опрашиваемый человек хочет быть принят в своем окружении.

Когда я смотрю на шесть потребностей, перечисленных в Таблице 4.1, я вижу три различные лестницы преимуществ. Три потребности: «помогите в заполнении моей налоговой декларации», «проверьте точность моей налоговой декларации» и «уменьшите риск аудиторской проверки» – направлены на то, чтобы вы могли чувствовать себя более уверенно в отношении правильности заполнения декларации. Следующие две потребности: «сократите время ввода данных для моей налоговой декларации» и «сократите время, которое я трачу на подачу заполненной налоговой декларации» связаны с экономией времени. И наконец, пункт «максимизируйте мои налоговые вычеты» превращается на более высокой степени преимуществ в экономию денег. В Таблице 4.2 показано, как каждая конкретная потребность из нашего примерного списка иерархически соотносится со ступенями лестницы преимуществ.

Таблица 4.2 «Лестница потребительских преимуществ»

Метод лестничного интервью («лэддеринга») напоминает инструмент «Пять почему». Изначально разработанный компанией Toyota метод «Пяти почему» заключается в получении ответов на повторяющийся вопрос для выяснения первопричины изучаемой проблемы.

Иерархии потребностей

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

Иерархия человеческих потребностей по Маслоу

Давайте обсудим хорошо известный пример обсуждаемого явления: иерархию человеческих потребностей Маслоу[8], показанную на Рисунке 4.1.

Рисунок 4.1. Иерархия человеческих потребностей Маслоу

Абрахам Маслоу был известным американским психологом XX века. В его пятиуровневой иерархической пирамиде основу образуют физиологические потребности, такие как еда, питье и сон. Второй уровень составляют потребности в безопасности. Третий уровень – это потребности в любви и принадлежности к какой-либо социальной группе (семья, друзья, близкие отношения). Четвертый уровень – это потребности в признании и уважении. И наконец, верхний уровень пирамиды представлен потребностями в реализации своего внутреннего потенциала.

Смысл выстраивания потребностей в иерархическом порядке заключается в том, что потребность более высокого уровня, на самом деле, не имеет значения до тех пор, пока не будут удовлетворены более насущные потребности, находящиеся на нижестоящих уровнях. Исследуя проблемное пространство своего продукта, вы, скорее всего, столкнетесь с аналогичной иерархией. Например, с ситуацией, когда потребительская ценность B не имеет значения до тех пор, пока не достигнута выгода A, находящаяся на более низком уровне иерархии потребностей.

Моя иерархия потребностей онлайн-пользователей

Когда я руководил отделом продуктового менеджмента в компании-разработчике социальной сети Friendster, мне пришлось столкнуться с существованием иерархии потребностей на собственном горьком опыте. Friendster была первой популярной социальной сетью. Для сайтов социальных сетей (как и социальных проектов в целом) характерен взрывной рост популярности. Сеть Friendster столкнулась с настолько стремительным ростом числа пользователей, что количество интернет-запросов в определенный момент стало превышать пропускную способность серверов. Многим пользователям наш продукт понравился; однако они были недовольны тем, что сайт стал слишком медленно загружаться либо был и вовсе недоступен из-за технических проблем с производительностью. Чтобы помочь команде правильно расставить приоритеты в своей работе, я – со всем уважением к Маслоу – рискнул создать свой вариант иерархии потребностей наших онлайн-пользователей, представленный на Рисунке 4.2.

Рисунок 4.2. Иерархия потребностей онлайн-пользователей по Олсену

В левой части Рисунка 4.2 показана пятиуровневая иерархия потребностей с точки зрения пользователя. Справа от каждого уровня – что это означает для разработчика. Как предпринимателям, руководителям проектов, разработчикам и дизайнерам нам нравится тратить свое время на разработку новых интересных функций и создание отличного пользовательского опыта. Однако эти элементы находятся на двух верхних уровнях пирамиды потребностей пользователей. Прежде всего, продукт должен быть доступен тогда, когда пользователь захочет им воспользоваться. Затем время отклика должно быть достаточно быстрым, чтобы не раздражать пользователя ожиданием загрузки. Следующий уровень относится к качеству продукта: работает ли он так, как должен? Затем мы переходим на уровень функционала. На первом месте здесь находится качество разработки пользовательского опыта (UX), которое определяет, насколько простым и комфортным для пользователя будет ваш продукт. Как и в случае с иерархией Маслоу, потребности более высокого уровня обретут свое значение лишь после того, как будут удовлетворены потребности более низкого уровня.

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

Соотношение важности и удовлетворенности

После того как вы изучили проблемное пространство и определили различные потребности потенциальных клиентов, необходимо решить, какие из них вы хотите удовлетворить. Иными словами, вам нужен хороший способ расставить приоритеты внутри набора потребностей. Лучше всего делать это, опираясь на степень потребительской ценности. Напрашивается вопрос: как определить степень важности той или иной потребности для клиента? Я столкнулся с этим вопросом, когда руководил проектом по разработке приложения Quicken. Мы ежегодно выпускали новую версию Quicken, и мне нужно было составить перспективный план для подготовки следующей версии продукта. В компании Intuit исследование потребителей всегда было на высоте, поэтому у меня была возможность получать результаты как количественных, так и качественных исследований. На основе этих данных я создал систему оценки, основанную на важности и удовлетворенности. Я обнаружил, что получившаяся система предлагает прекрасный способ проектирования потребительских ценностей, опираясь исключительно на аналитические методы. Мой фреймворк хорошо зарекомендовал себя в расстановке приоритетов потребностей при создании очередной версии Quicken, которая установила рекорды по объему продаж, выручке и прибыли. Воодушевленный этим успехом, я позднее разработал еще несколько подобных систем, также основанных на важности и удовлетворенности (о них я расскажу позже).

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

Удовлетворенность – это показатель того, насколько пользователь доволен конкретным решением, предоставляющим ему определенную выгоду. Это показатель того, насколько точно предложенное решение соответствует клиентским потребностям. Разные продукты будут в разной степени удовлетворять одного и того же клиента, и, точно также один и тот же продукт может обеспечивать совершенно разный уровень удовлетворенности разных клиентов.

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

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

Рисунок 4.3. Соотношение потребительской важности и удовлетворенности

Для верхнего правого квадранта характерна и высокая важность, и высокая удовлетворенность. Это относится к продуктам, которые занимают ведущее место на своем рынке и хорошо справляются с удовлетворением потребностей клиентов. В качестве подходящего примера на ум приходит Microsoft Excel, поскольку этот программный продукт дает пользователям практически все, что они могут ожидать от приложения для работы с электронными таблицами. Недаром в «Википедии» именно этот программный продукт назван «отраслевым стандартом для электронных таблиц». Набор функций и пользовательский интерфейс в нем были отшлифованы настолько, что не требовали внесения каких-либо серьезных нововведений и на долгое время избавили Excel от конкуренции со стороны других настольных приложений для работы с электронными таблицами. Главная конкурентная угроза для этого продукта сейчас исходит от поставщиков облачных приложений, некоторые из которых бесплатно предоставляют часть функциональных возможностей Excel.

Важно отметить, что далеко не в каждой рыночной нише в верхнем правом квадранте присутствует только один доминирующий продукт. Может быть и несколько похожих продуктов. Например, многофункциональные принтеры отвечают требованиям высокой важности и удовлетворенности клиентов; однако на рынке успешно сосуществуют сопоставимые модели сразу от многих производителей, включая Hewlett Packard, Epson, Canon, Brother и Lexmark.

Если использовать структуру, представленную на Рисунке 4.3, для оценки функционала продукта, то в верхний правый квадрант попадут те функции, которые работают хорошо. Они удовлетворяют очень важную потребность, и клиенты довольны тем, как это делается. Например, при опросе пользователей одного из моих продуктов обнаружилась такая функция, которая набрала 100 % баллов по степени своей важности и 98 % по степени удовлетворенности.

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

Успех Uber: удовлетворение неудовлетворенных потребностей

Компания Uber добилась впечатляющего успеха и роста. Очевидно, что достижение таких результатов требует отличного исполнения. Кроме того, у компании имеется очень привлекательная бизнес-модель. Но взгляд на Uber через призму концепции соотношения важности и удовлетворенности позволяет понять еще одну фундаментальную причину успеха компании.

У многих людей есть важная потребность, заключающаяся в том, чтобы их перевозили из одного места в другое, как при спонтанно возникшей надобности, так и по заранее намеченному плану. Такси является традиционным и весьма распространенным решением для удовлетворения этой потребности. Но было бы большим преувеличением сказать, что удовлетворенность пользователей услугами такси находится на высоком уровне. Перечень распространенных причин для жалоб включает в себя грязные автомобили, грубость водителей, небезопасное вождение, неопределенность в отношении стоимости поездок и чаевых, а также неудобства, связанные с оплатой. Пользователи жалуются на случаи, когда заказ выполняется с опозданием или вообще отменяется по непонятным причинам. В то время как услуга такси (в общем и целом) удовлетворяет основную потребность в доставке людей из пункта А в пункт Б, количество жалоб на исполнение свидетельствует о наличии многих важных неудовлетворенных потребностей, которые явно находятся в верхнем левом квадранте представленной выше диаграммы. Сочетание высокой важности данного набора потребностей, низкой удовлетворенности существовавшими решениями (традиционное такси) и большого числа людей, имеющих такие потребности, указывало на наличие весьма перспективной рыночной возможности, которую компания Uber вовремя увидела и поспешила ей воспользоваться.

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

Помимо этого, компания Uber улучшает финансовые аспекты обслуживания клиентов. Приложение сообщает ориентировочную стоимость услуги до поездки, что позволяет избежать неприятных сюрпризов. Приложение хранит информацию о вашей банковской карте, чтобы автоматически произвести оплату в конце поездки без необходимости совершения каких-либо дополнительных действий с вашей стороны. Это ярко контрастирует с процессом оплаты услуг традиционного такси, когда вам приходилось ждать, пока водитель проверит банковскую карту и распечатает платежную квитанцию. Некоторые водители принимали только «наличку», что могло вызвать проблемы, если у вас оказывалось недостаточно денег для оплаты поездки. С Uber вы по завершении поездки просто выходите из машины, и вам не нужно ни о чем беспокоиться.

Очевидно, что Uber закрыла множество недостаточно удовлетворенных потребностей, которые находились в верхнем левом квадранте диаграммы – с высоким показателем важности и низкой удовлетворенностью. В результате компания добилась невероятного рыночного успеха с момента своего появления в 2009 году. Компания не является публичной, но утечка финансовых данных в декабре 2013 года показала, что у Uber более 400 тыс. активных клиентов, совершающих более 800 тыс. поездок в неделю. Валовый объем годовой выручки на тот момент превышал 1 млрд $, из которых Uber удерживает 20 %. В декабре 2014 года компания привлекла инвестиции в размере 1,2 млрд $, при том что оценка ее стоимости составила 40 млрд $. Возможно, вы не достигнете такого же успеха, как Uber, но если все же решите попробовать, то сектор диаграммы, указывающий на наличие высокой степени важности и низкой удовлетворенности – лучшее место для поиска самых перспективных рыночных возможностей.

Прорывные и постепенные инновации

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

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

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

Прорывные инновации: музыка на прогулке

Давайте обсудим ряд инноваций, которые привели к необратимым изменениям на рынке портативных устройств для прослушивания музыки. Клиентскую потребность верхнего уровня в этом случае можно сформулировать следующим образом: «Дайте мне возможность слушать музыку, находясь в движении». Первым продуктом, в котором было реализовано это пожелание, стал транзисторный радиоприемник, появившийся в 1950-х годах. До этого при производстве радиоприемников использовались лампы и требовали для своей работы электрической энергии. Лампы к тому же были хрупкими, что исключало возможность создания приемлемой мобильной версии. Однако даже с появлением первых портативных радиоприемников, позволяющих слушать музыку на ходу, люди все еще не имели возможности выбирать, какие именно композиции они желают слушать. Ситуация изменилась в 1979 году, когда Sony представила первый портативный кассетный аудиоплеер Walkman. Теперь пользователи могли выбирать для прослушивания любую музыку, просто вставляя нужную кассету. Walkman, безусловно, был прорывной инновацией, которая изменила шкалу удовлетворенности, вытеснив портативные радиоприемники из верхнего правого квадранта в верхний левый.

Несколько лет спустя Sony выпустила первый портативный проигрыватель компакт-дисков Discman, который предлагал дополнительные преимущества: более высокое качество звука и возможность легко и быстро переключаться с одной композиции на другую без необходимости перемотки кассеты. Одним из недостатков ранних моделей Discman (устраненным в более поздних моделях) было то, что при встряске (например, на бегу) происходило частичное «проглатывание» звука. Портативный CD-плеер добавил некоторые преимущества по сравнению с «кассетником». И хотя для некоторых целевых клиентов портативный проигрыватель компакт-дисков располагался на моей диаграмме заметно правее, чем Walkman, его появление не привело к кардинальному изменению шкалы удовлетворенности.

Следующей инновацией на рынке портативных музыкальных устройств стал MP3-плеер, выпущенный в 1998 году. Первые модели не обладали большой памятью для хранения записей, но со временем ситуация изменилась. Компания Apple вышла на рынок MP3-плееров со своим iPod в 2001 году. Поначалу их устройство не имело ошеломляющего успеха, но компании удалось внести значительные улучшения в последующие модели. Сочетание большого объема памяти, интуитивно понятного пользовательского интерфейса и интеграции с программным обеспечением iTunes, Jukebox и Digital music store позволило детищу Apple стать ведущим MP3-плеером, захватившим более 70 % рынка. В результате iPod стал прорывной инновацией, которая в очередной раз переопределила шкалу удовлетворенности любителей прослушивания музыки с использованием портативных устройств.

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

Тем не менее, на сегодняшний день iPod и другие MP3-плееры утратили свою популярность. Что же привело к вытеснению этих устройств с рынка? Появление iPhone и других смартфонов, которые включили в свой набор функций все, что умел делать MP3-плеер (и даже больше). Интересно, что одновременно с этим потребность слушать музыку на ходу превратилась из самостоятельного преимущества в составную часть целого комплекса потребностей, возникающих у людей, находящихся в пути: совершение телефонных звонков, отправка текстовых сообщений, просмотр веб-страниц, игры, использование приложений и многое другое. Все эти потребности теперь покрываются при помощи одного продукта – смартфона.

Измерение степени важности и удовлетворенности

Когда я выступаю на семинарах и рассказываю о своей диаграмме соотношения важности и удовлетворенности, одним из самых часто задаваемых вопросов является следующий: «Как можно измерить степень важности и удовлетворенности?» Самый простой способ сделать это – задать вопрос своим потенциальным клиентам. Вы можете сделать это в личном интервью или путем анкетирования. Давайте представим, что мы с вами являемся членами команды разработчиков Uber. И опрашиваем тысячу наших целевых клиентов, задавая им следующий вопрос: «Когда вы пользуетесь услугой такси, насколько для вас важно, чтобы водитель был вежлив?» При этом мы будем использовать 5-балльную шкалу из следующих вариантов ответа:

• Совсем не важно.

• Маловажно.

• Важно.

• Очень важно.

• Чрезвычайно важно.

Затем мы посчитаем среднее значение всех баллов, полученных в ходе опроса, и получим величину показателя важности. При желании, для упрощения интерпретации, оценки, полученные по пятибалльной системе, можно сопоставить со шкалой от 0 до 100 (или от 0 до 10) баллов. Затем точно таким же образом зададим респондентам другие вопросы: о важности чистоты автомобиля, комфорта, пунктуальности водителя, безопасного вождения и так далее.

Чтобы получить оценку показателя удовлетворенности, можно использовать такую формулировку вопроса: «Насколько вы удовлетворены вежливостью водителей во время поездок на такси, которые вы совершили за последние шесть месяцев?» В этом случае мы используем 7-балльную шкалу из следующих вариантов ответов:

1. Абсолютно не удовлетворен.

2. Скорее не удовлетворен.

3. Слегка не удовлетворен.

4. Нейтральная оценка.

5. Удовлетворен отчасти.

6. Скорее удовлетворен.

7. Полностью удовлетворен.

Опять же, среднее значение набранных баллов даст нам величину показателя удовлетворенности. 7-балльную шкалу ответов также можно сопоставить со шкалой от 0 до 100 (или от 0 до 10) баллов для упрощения интерпретации. Затем зададим респондентам аналогичные вопросы об их удовлетворенности: чистотой автомобиля, уровнем комфорта, пунктуальностью водителя, безопасностью вождения и так далее.

В дополнение к потенциальным клиентам мы могли бы организовать такой же опрос среди реальных пользователей Uber, задав им те же самые вопросы о важности. Затем задали бы им вопросы об удовлетворенности, но на этот раз они касались бы услуг, предоставляемых именно Uber, а не традиционными такси. Сравнение оценки удовлетворенности вашим продуктом с оценками продуктов конкурентов – это хороший способ понять, насколько лучше (или хуже) потребитель воспринимает ваше решение.

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

При опросе пользователей вы можете использовать разный масштаб шкалы, например от 1 до 10 или от 0 до 10. Использование более 11 вариантов ответов может привести респондентов в замешательство, а менее пяти вариантов не обеспечит достаточной детализации ответов. Для любой биполярной шкалы я рекомендую использовать нечетное количество вариантов ответов, чтобы ровно посередине шкалы оказалась нейтральная оценка. Согласно результатам серьезных исследований надежности и валидности различных шкал, 5-балльная система оценки лучше всего подходят для однополярных шкал, а 7-балльная – для биполярных. Это объясняет, почему я рекомендую именно вышеуказанные варианты.

Как я уже писал, для упрощения последующих расчетов и анализа вы можете сопоставить балльную систему, используемую во время опросов, с другой более удобной для вас шкалой. Например, вы могли бы приравнять оценки, полученные по 5-балльной системе, к следующим значениям 100-балльной шкалы: 0, 25, 50, 75 и 100. Или к таким значениям: 0, 2.5, 5, 7.5 для перевода на 10-балльную шкалу. Аналогично оценки, полученные по 7-балльной системе, можно преобразовать в значения: 0, 16.7, 33.3, 50, 66.7, 83.3 и 100 на 100-балльной шкале. С учетом возможности преобразования баллов при опросах потребителей следует использовать такую шкалу, которая будет для них наиболее понятна и которая не подразумевает большей точности ответов, чем вы реально можете получить.

Применение соотношения показателей важности и удовлетворенности на реальных данных

Для лучшего понимания рассматриваемой концепции давайте применим ее к данным, относящимся к реальному продукту. Работая над одним из проектов, мы периодически проводили опрос наших пользователей с целью получения их оценки предлагаемых ключевых функций. В рамках одного из опросов мы попросили пользователей оценить степень важности 13 ключевых функций продукта, а также уровень удовлетворенности их работой. Мы усреднили оценки, полученные для каждой функции, и нанесли их на график, как показано на Рисунке 4.4. Каждая из 13 точек, которые вы видите, соответствует определенной ключевой функции. Число, указанное рядом с каждой точкой, – это усредненная оценка удовлетворенности пользователей данной функцией. В правом верхнем углу вы можете видеть точку, относящуюся к функции, о которой я упоминал ранее: получившей 100 %-ную оценку по важности и 98 %-ную по удовлетворенности. Как менеджер продукта я был очень доволен таким результатом. Поскольку эта функция уже работала максимально хорошо, я не хотел тратить драгоценные ресурсы нашей команды на дальнейшие попытки ее улучшить. Вместо этого я сосредоточился на улучшении функции, точка которой (с пометкой «55») находится ближе всего к верхнему левому углу, что говорит о ее высокой важности и низком уровне потребительской удовлетворенности. Согласно данным опроса, эта функция имела 82 %-ную важность, но при этом удовлетворяла потребности пользователей лишь на 55 %. Только одна функция имела еще более низкий показатель удовлетворенности (41 %). Однако она была гораздо менее важной (всего 53 %). Стоит отметить, что клиенты способны оценить свою удовлетворенность решением только в том случае, если они им реально пользовались.

Я часто сталкиваюсь с ситуациями, когда разработчики нового продукта сетуют на то, что у них пока еще нет потребителей, которых они могли бы опросить. Они обеспокоены тем, что не могут охватить своим опросом достаточное количество клиентов для достижения статистической достоверности полученных данных. Но даже в том случае, когда у вас нет возможности опросить несколько тысяч пользователей, вы все равно можете получить значимые результаты.

Рисунок 4.4. Соотношение показателей важности и удовлетворенности на реальных данных

Нулевой размер выборки – это нормально

Давайте вернемся к Uber. Предположим, мы проводим индивидуальные интервью с каждым из 25 человек, которые часто пользуются услугами такси, и задаем им вопросы на тему важности и удовлетворенности. Как вы думаете, какой процент опрошенных, будет «полностью удовлетворен» своим опытом потребления данной услуги? Смею предположить, что немногие (если не сказать никто) из 25 опрошенных выбрали бы этот вариант ответа. В ходе интервью мы хотели бы получить больше информации о клиентских потребностях в комфорте, удобстве использования, безопасности, надежности и так далее. Представьте, что мы попросили 25 клиентов оценить важность каждого из перечисленных преимуществ, а также соответствующий уровень удовлетворенности ими, на основе личного опыта. При этом вполне вероятно, что в полученных результатах мы смогли бы увидеть значимые закономерности – даже несмотря на то что опросили далеко не тысячи пользователей. Например, если очень большой процент опрашиваемых оценивает какой-то параметр одинаково высоко или низко, есть неплохой шанс, что похожий результат будет получен и при опросе гораздо большего числа респондентов. Я называю эту технику «восполнением количества за счет качества» – количественный анализ на качественных данных. Однако должен предупредить, что использовать такой подход следует с большой осторожностью. Это редко используемый инструмент. Статистический анализ имеет массу преимуществ, но очень многие продакт-менеджеры убедили себя в том, что они нуждаются исключительно в таких доказательствах, которые не оставляют даже тени сомнения. Вместе с тем случаи бывают разными. Довольно часто, особенно на ранних стадиях работы над продуктом версии v1, применение канонических статистических методов просто невозможно. Значимость статистических показателей велика, но далеко не всегда у вас есть размер выборки, необходимый для обеспечения высокой степени их достоверности. Поэтому принцип «все или ничего» здесь не применим.

Скажу больше, вы можете использовать систему соотношения важности и удовлетворенности, не опросив предварительно ни одного потребителя. Да-да, вы можете получить значимый результат даже при нулевом размере выборки. Как? Используя фреймворк для формулирования и уточнения ваших гипотез. Бережливый подход заключается в грамотном формулировании гипотез и последующей разработке тестов для определения их достоверности. Прежде чем провести первое собеседование с потребителями, вы уже можете выдвинуть гипотезы о том, какие потребности наиболее важны для целевых клиентов. Вы также можете выдвинуть гипотезу о том, что им нравится или не нравится в существующих решениях, а также об уровне их удовлетворенности. Каждую из своих гипотез вы могли бы отразить на рассмотренной нами ранее четырехквадрантной диаграмме. Затем, по мере получения результатов исследований и прохождения итераций улучшения продукта, вы могли бы соответствующим образом изменять местоположение гипотез на диаграмме, а также пересматривать их и добавлять новые.

Другие фреймворки

Ранее я упомянул о том, что уже после создания собственного фреймворка во время работы в Intuit я был рад открыть для себя другие структурные инструменты, также основанные на показателях важности и удовлетворенности. Например, такие методы, как Gap-анализ и Работа для выполнения (Jobs-to-Be-Done, или JTBD) используют показатели важности и удовлетворенности для количественной оценки различных функций продукта и расстановки соответствующих приоритетов.

Gap-анализ

Если вы поищете описание этого метода в Интернете, то найдете сразу несколько определений. Версия, на которую я ссылаюсь, основана на расчете величины «разрыва»[9] между важностью и удовлетворенностью. То есть вы просто берете усредненное значение показателя важности и вычитаете из него значение показателя удовлетворенности.

Gap = Важность – Удовлетворенность

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

Преимущество Gap-анализа состоит в том, что результатом является единственное число, которое к тому же очень легко вычислить. Однако у этого метода есть существенный недостаток – он не позволяет делать различия между «разрывами», имеющими одинаковую величину. Например, если при использовании шкалы от 0 до 10 баллов, показатель важности потребности равен 10 баллам, а уровень удовлетворенности = 5 баллам, то величина «разрыва» составляет 5 баллов. Если бы важность другой потребности равнялась 6 баллам, а степень удовлетворенности – 1 баллу, то величина «разрыва» также составила бы 5 баллов. В итоге эти цифры не несут в себе необходимой смысловой нагрузки, поскольку разрыв в 5 баллов для потребности, имеющей важность в 10 баллов, должен быть более значимым, чем аналогичный разрыв для потребности с важностью, оцененной только в 6 баллов. Теперь давайте перейдем к другому структурному инструменту, также основанному на показателях важности и удовлетворенности, но не имеющему указанного недостатка.

Jobs-to-Be-Done («Работа для выполнения»)

В свое время мне посчастливилось открыть для себя книгу Энтони Ульвика «Чего хотят потребители»[10]. В ней он описывает свой инновационный подход, ориентированный на конечный результат, в котором также используются показатели важности и удовлетворенности для количественной оценки возможностей. Ульвик использует несколько более сложную формулу для получения своего оценочного показателя, но именно это позволяет решить описанную выше проблему Gap-анализа:

Оценка возможности = Важность + Maximum (Важность – Удовлетворенность, 0)

Его метод так же, как и формула Gap-анализа, основан на вычитании значения показателя удовлетворенности из значения показателя важности. Однако он не позволяет этой разности приобрести отрицательное значение; минимальной результирующей величиной в этом случае является ноль. К полученному в результате вычитания значению здесь добавляется значение показателя важности, что и позволяет провести различия между «разрывами» одинакового размера. Если значение каждого из используемых в формуле показателей варьируется в диапазоне от 0 до 10, то результирующий балл может изменяться от 0 (когда показатель важности равен нулю) до 20 (когда важность равна 10, а удовлетворенность равна 0). Те возможности, чья итоговая оценка превышает 15 баллов, Ульвик относит к очень привлекательным, а те, что оценены ниже 10 баллов, – к непривлекательным.

Давайте рассчитаем оценку возможностей, используя те же данные, что и в предыдущем примере. Наша первая потребность с показателем важности 10 баллов и удовлетворенностью в 5 баллов будет иметь оценку возможности, равную: 10 + Maximum (10 – 5, 0) = 10 + 5 = 15 баллов. Для второй потребности с показателем важности 6 баллов и удовлетворенностью в 1 балл оценка возможности будет равна: 6 + Maximum (6–1, 0) = 6 + 5 = 11. Таким образом, используя формулу Ульвика, даже если величина разрыва между важностью и удовлетворенностью для каждой из двух потребностей одинаковая (по 5 баллов), мы можем выяснить, что первая потребность, с более высоким показателем важности, имеет более высокую оценку возможности.

Центральное место в методологии Ульвика занимает идея о том, что клиенты приобретают продукты и услуги, которые помогают им выполнить некоторую задачу или работу. Покупатели решают, какой продукт им следует приобрести, исходя из того, насколько хорошо он обеспечивает «желаемые результаты» для «работы, которую необходимо выполнить». Этого же подхода, ставшего известным под названием Jobs-to-Be-Done («Работа для выполнения»), придерживался Клейтон Кристенсен[11] и некоторые другие исследователи.

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

По словам Ульвика, «для большинства выполняемых задач, даже тех, которые могут казаться тривиальными, обычно существует от 50 до 150 и более желаемых результатов, что явно выходит за рамки ожидаемого количества». Это утверждение явно перекликается с моей собственной убежденностью в том, что для команд разработчиков посильно – и фактически необходимо, если они рассчитывают создать успешную инновацию, – формировать подробное и точное описание проблемного пространства своего продукта. То, что Ульвик называет результатами, я бы назвал точно сформулированными потребительскими выгодами (преимуществами). Вместо того чтобы бессистемно скрести поверхность луковицы, хорошие команды разработчиков тщательно, слой за слоем, очищают лук от кожуры, получая при этом все более глубокие знания о предмете своего исследования. Стив Джобс также придерживался аналогичной точки зрения:

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

Визуализация потребительской ценности

Если идея количественной оценки возможностей продукта на основе показателей важности и удовлетворенности находит у вас отклик, рекомендую вам прочесть книгу Энтони Ульвика «Чего хотят потребители». Я же, используя свою систему сопоставления важности и удовлетворенности, разработал собственный количественный подход, который, как мне кажется, в некоторой степени более понятен на интуитивном уровне. Этот подход выходит за рамки простой количественной оценки возможностей и обеспечивает более широкое представление, которое наглядно демонстрирует потребительскую ценность, и то, как она создается.

Потребительская ценность, обеспечиваемая продуктом или функцией

Давайте вернемся к схеме соотношения важности и удовлетворенности, представленной на Рисунке 4.3, но сделаем шкалу значений по осям координат более точной. Вместо диапазона от «низкого» до «высокого» мы будем оценивать важность и удовлетворенность в диапазоне от 0 до 100 %, как показано на Рисунке 4.5. Таким образом, независимо от того, измеряете ли вы эти показатели по 5-балльной, 7-балльной, 10-балльной или 100-балльной шкале, вы всегда сможете оставаться в границах заданного масштаба.

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

Рисунок 4.5. Визуализация потребительской ценности

Чем выше важность потребности, которую удовлетворяет продукт или функция, тем большую ценность для потребителя она имеет. Аналогично, чем выше удовлетворенность продуктом, тем большую потребительскую ценность он обеспечивает. Когда продукт или функция отображаются на графике в виде точки с соответствующими координатами, величина потребительской ценности, которую они обеспечивают, равна площади прямоугольника, который создают нанесенная точка, точка начала координат и оси графика. Таким образом, вы можете рассчитать потребительскую ценность продукта или функции с помощью следующего уравнения:

Обеспечиваемая потребительская ценность = Важность * Удовлетворенность

Рассмотрим продукт, обозначенный на графике на Рисунке 4.5. Важность покрываемой потребности составляет 70 %, удовлетворенность продуктом, покрывающим эту потребность, оценивается также в 70 %. Таким образом, потребительская ценность, которую обеспечивает этот продукт, составляет: 0.7 * 0.7 = 0.49.

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

Возможность повышения потребительской ценности

На основе графика, отражающего соотношение важности и удовлетворенности, вы также можете легко оценить возможность повышения потребительской ценности своего продукта. Под такой возможностью понимается максимальная величина потребительской ценности, которая может быть добавлена к текущему значению этого показателя. Потребительскую ценность можно повысить за счет повышения уровня удовлетворенности до его максимального значения в 100 % (в формуле это значение соответствует единице). Количественно это может быть выражено следующим образом:

Возможность повышения ценности = Важность * (1 – Удовлетворенность)

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

На Рисунке 4.6 показаны два продукта с различными возможностями повышения их потребительской ценности. Продукт А (показатели которого мы взяли из предыдущего примера, показанного на Рисунке 4.5) имеет 70 %-ную важность и 70 %-ную удовлетворенность, поэтому оценка возможности повышения его потребительской ценности равна:

Возможность для продукта А = 0.7 * (1–0.7) = 0.7 * 0.3 = 0.21

Рисунок 4.6. Измерение возможности повышения потребительской ценности

Показатель важности для продукта B составляет 90 %, а удовлетворенности – 30 %, поэтому оценка возможности повышения потребительской ценности в этом случае равна:

Возможность для продукта B = 0.9 * (1–0.3) = 0.9 * 0.7 = = 0.63

Возможность, связанная с продуктом B, потенциально может привести к созданию втрое большей ценности для потребителей, чем возможность, связанная с продуктом A. При составлении планов реализации следует ориентироваться на те продукты, которые имеют наиболее высокий показатель возможности повышения потребительской ценности. Напомню, что они находятся в верхнем левом квадранте диаграммы, как это было показано на примере приложения компании Uber.

Если вы вернетесь к Рисунку 4.4, на котором представлены реальные данные, относящиеся к существующему продукту, то вспомните, что я присвоил наивысший приоритет разработке той функции, важность которой составляла 82 %, а удовлетворенность – 55 %. Давайте назовем ее «Функция X». Взгляните на все точки, нанесенные на график. Теперь, когда вы знаете, каким образом можно оценить возможности получения добавленной ценности, вы сразу заметите, что наилучшие шансы имеет именно Функция X. Количественная оценка возможности для Функции X равна:

Возможность для Функции X = 0.82 * (1–0.55) = 0.82 * 0.45 = 0.37

Другие 11 функций, отображенные на графике справа от Функции X, имеют показатель возможности, не превышающий 0.25. А возможность для функции с показателем важности 53 % и удовлетворенности – 41 % оценивается в 0.32 балла. Обратите внимание, несмотря на то что точка этой последней функции оказалась в левом нижнем углу графика, представленного на Рисунке 4.4, это произошло исключительно потому, что оси координат здесь не показаны полностью, то есть начинаются не от нулевого значения. При использовании полной шкалы эта точка оказалась бы расположена ближе к центру графика.

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

Возможность = Важность – Текущая достигнутая ценность

Потребительская ценность, создаваемая улучшениями продукта

Вы также можете визуализировать ту часть потребительской ценности, которая создается за счет произведенных улучшений продукта. Если улучшение изменяет показатель удовлетворенности с текущего уровня (Удовлетворенность_До) до более высокого уровня (Удовлетворенность_После), то создаваемая при этом потребительская ценность равна площади увеличения прямоугольника, которая вычисляется по формуле:

Потребительская ценность улучшения = Важность * (Удовлетворенность_После – Удовлетворенность_До)

Рисунок 4.7 иллюстрирует создание дополнительной потребительской ценности путем улучшения продукта, которое повышает уровень удовлетворенности (на основе данных из примера, приведенного на Рисунке 4.5). Показатель важности потребности составляет 70 %, а уровень удовлетворенности до улучшения продукта – 70 %. После улучшения продукта уровень удовлетворенности возрастает до 90 %. Применив приведенную выше формулу, мы получаем, что дополнительно созданная за счет улучшения продукта потребительская ценность составила 0.14.

Потребительская ценность улучшения = 0.7 * (0.9–0.7) = 0.7 * 0.2 = 0.14

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

Рисунок 4.7. Создание дополнительной потребительской ценности путем улучшения продукта

Модель Кано

Еще одной прекрасной концепцией для понимания клиентских потребностей и их удовлетворения является модель Кано, разработанная экспертом по управлению качеством Нориаки Кано[12]. Впервые я познакомился с этой моделью во время обучения промышленному инжинирингу в аспирантуре. Как показано на Рис. 4.8, модель Кано также основана на соотношении двух параметров, откладываемых по горизонтальной и вертикальной осям. Первый параметр отражает, насколько полно удовлетворена исследуемая потребность пользователя (горизонтальная ось). Второй параметр отражает результирующий уровень удовлетворенности (довольства) пользователей тем, как удовлетворяется их потребность (вертикальная ось). Значения на горизонтальной оси изменяются от отсутствия попыток удовлетворения клиентских потребностей (крайнее левое значение) до полного удовлетворения потребности (крайнее правое значение). Шкала вертикальной оси является биполярной и содержит диапазон значений от абсолютной неудовлетворенности клиентов (крайнее нижнее значение) до полной удовлетворенности (крайнее верхнее значение).

Рисунок 4.8. Модель Кано

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

Для потребностей производительности характерен потребительский подход: чем больше, тем лучше. По мере того как потребность, относящаяся к данной категории, удовлетворяется все более полно, довольство пользователей растет. Допустим, собравшись купить автомобиль, вы оказались перед выбором из двух разных моделей. Если бы при полной идентичности других параметров экономичность автомобиля A была в два раза выше, чем у автомобиля B (например, по дальности поездки в расчете на литр топлива), то вы отдали бы предпочтение автомобилю A. Экономичность – это одна из характеристик производительности для автомобилей.

В свою очередь базовые потребности практически не повышают довольство пользователей самим только фактом их удовлетворения. Однако если базовая потребность оказывается неудовлетворенной, это вызывает недовольство клиентов. Базовые потребности покрываются самыми необходимыми («мастхэв») функциями продукта, наличие которых обязательно для того, чтобы клиенты остались довольны вашим продуктом. Возвращаясь к примеру с автомобилем, можно сказать, что к категории таких обязательных функций относятся, например, ремни безопасности. Если бы вы узнали, что в заинтересовавшей вас модели автомобиля не предусмотрены ремни безопасности, вы бы отказались от такой покупки из-за риска серьезно пострадать в случае аварии. Ваша базовая потребность в обеспечении разумного уровня безопасности в этом случае не удовлетворяется. При этом, если бы в автомобиле А было 5 ремней безопасности, а в автомобиле В 100 ремней безопасности, это не привело бы вас к выводу о том, что автомобиль В будет в 20 раз безопаснее автомобиля А. Если в автомобиле имеется хотя бы по одному ремню безопасности для водителя и каждого пассажира, соответствующая базовая потребность может считаться удовлетворенной.

Под потребностями для восхищения подразумеваются неожиданные выгоды, своеобразные бонусы, которые превосходят ожидания клиентов, что приводит к очень высокой удовлетворенности клиентов. Отсутствие такой «вишенки на торте» не вызывает никакого недовольства, потому что пользователи и не ожидают ее появления. Снова возвращаясь к примеру с автомобилем, отметим, что появление в середине 1990-х годов первых моделей, оснащенных навигационной системой GPS, вызвало повышенный спрос. Не нужно было больше пользоваться бумажными картами или распечатками маршрута – существенно снизился риск заблудиться. Данная функция коренным образом изменила способ выбора пути из пункта А в пункт Б и вызвала восторг пользователей.

Если же вернуться в более далекое прошлое, то можно вспомнить, что в автомобилях не всегда присутствовали встроенные подстаканники. Компания Chrysler предложила эту инновацию начале 1980-х годов, выпустив минивэн, в котором имелись два подстаканника, утопленные в пластик приборной панели. Это решение доставляло пользователям удовольствие, поскольку теперь водителям не нужно было беспокоиться о том, что они прольют свои напитки во время движения.

Конечно, сейчас подстаканниками в автомобиле никого не восхитишь, и все больший процент автотранспорта оснащается GPS-навигацией в качестве стандартной функции. Это иллюстрирует важный аспект модели Кано: потребности меняются с течением времени. Вчерашняя «вишенка на торте» сегодня становится производительной характеристикой, а завтра базовой потребностью. Растущие ожидания клиентов и конкуренция постоянно повышают планку требований к продукту. Здесь мы с вами снова наблюдаем уже описанный ранее эффект, когда на диаграмме соотношения важности и удовлетворенности максимальное значение в правой части шкалы удовлетворенности со временем переопределяется, перемещая вчерашние прорывные решения в левую часть диаграммы.

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

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

Практическое использование фреймворков

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

Глава 5

Формирование ценностного предложения (Шаг 3)

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

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

Кроме того, вы ведь не хотите рисковать без необходимости и уже на начальном этапе тратить ресурсы на создание слишком обширного функционала. У вас еще нет точной информации обо всех охватываемых потребностях клиентов. Существует неопределенность как в выдвинутых вами гипотезах, так и в достоверности ваших представлений о рынке. Вот почему вы хотите начать с проектирования минимально жизнеспособного продукта (MVP). Помните, что все гипотезы о клиентских потребностях основаны на базовом предположении о целевом потребителе. Если по результатам тестирования MVP станет понятно, что исходное предположение было неверным, вам придется пересмотреть свои гипотезы в отношении тех клиентских потребностей, которые вы намерены удовлетворить.

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

Стратегия отказа

Формирование ценностного предложения продукта подразумевает определение конкретных потребностей, которым он будет соответствовать, и объяснение преимуществ, которые он будет иметь по сравнению со своими аналогами. Когда вы определяете потребности, которые будет удовлетворять ваш продукт, вы также решаете, какие другие потребности он не будет учитывать. Некоторым разработчикам трудно дается фраза: «Нет, наш продукт не может решить эту проблему», – но именно в ней и заключается суть данной стратегии. Одно из лучших определений, которые я слышал на эту тему, звучит так: «Реши, что ты не собираешься делать». А вот что об умении говорить «нет» сказал Стив Джобс:

«Люди думают, что сфокусироваться на чем-то – это значит сказать “да” тому, на чем вы сосредоточили свое внимание. Но это вовсе не так. Напротив, это означает сказать “нет” сотне других хороших идей, которые вас окружают. Этот выбор приходится делать со всей тщательностью. На самом деле я горжусь тем, что мы не стали делать, в не меньшей степени, чем тем, что нам удалось создать. Инновация – это умение сказать “нет” тысяче вещей».

Итак, вам нужно начать с выбора клиентских потребностей, которые вы планируете удовлетворить. Я покажу вам, как использовать для этой цели модель Кано. Напомню, что она подразумевает распределение потребностей на три категории: базовые, повышающие производительность и восхищающие пользователей. Поскольку вы хотите быть уверены, что ваш продукт превосходит существующие аналоги, классификацию потребностей необходимо производить в контексте присутствующих на рынке конкурентов. Учитывая, что они обычно относятся к той же товарной группе, потребительские требования, а также преимущества, которые обеспечивают параметры производительности, скорее всего, будут в значительной мере совпадать. Однако функции, отвечающие за достижение «вау-эффекта» и восхищения потребителей, у разных продуктов могут существенно различаться.

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

Ценностные предложения на примере поисковых систем

Я проиллюстрирую концепцию ценностного предложения продукта, обратившись к истокам появления поисковых систем в сети Интернет. Изначально подобных продуктов было довольно много, и все они были ориентированы на создание преимуществ производительности. Одни разработчики делали акцент на индексации наибольшего количества интернет-страниц, добиваясь того, что их продукт выдавал по поисковому запросу пользователя максимальное количество результатов. Другие сосредоточились на обеспечении максимальной «свежести» предоставляемого в ответ на поисковый запрос списка сайтов за счет более быстрого добавления новых и обновления существующих интернет-страниц. Третьи сосредотачивали усилия на достижении наивысшей релевантности результатов поиска. Таким образом, можно выделить по крайней мере три преимущества производительности, вокруг которых шла конкурентная борьба между ранними поисковыми системами: количество, свежесть и релевантность результатов поиска. Хотя на самом деле сравнительных параметров было больше, я для простоты ограничу обсуждение тремя уже названными. На этом этапе развития рынка поисковых систем относительная важность каждого из перечисленных преимуществ была еще не очевидна, поэтому компании-разработчики не были единодушны в выборе ценностных предложений для своих продуктов. Каждый сосредотачивался на тех преимуществах производительности, которые считал наиболее перспективными.

Со временем большинство поисковых систем пришло к тому, что они индексировали огромный массив интернет-страниц. В итоге количество выдаваемых результатов поиска перестало быть важным параметром. Хотя пользователям было интересно знать, сколько сайтов найдено по их запросу, обычно они не тратили время на то, чтобы заглянуть дальше первых страниц списка результатов поиска. Аналогично большинство поисковых систем в конечном счете научились относительно быстро добавлять новые интернет-страницы, чтобы результаты поиска всегда были максимально свежими. Таким образом, наиболее важным из преимуществ стал параметр релевантности результатов поиска сделанному запросу. В итоге разработчики Google благодаря уникальному алгоритму PageRank смогли обойти конкурентов, добившись гораздо более высокой релевантности своей поисковой системы. Поскольку поисковик Google оказался лучшим в том, что имело наибольшее значение, обеспечивая при этом сопоставимую или превосходящую производительность по другим параметрам, именно он вышел победителем из этой гонки.

В Таблице 5.1 показаны три сформулированных выше ценностных предложения. Из представленных данных следует, что разработчики Google сосредоточились на достижении высокой релевантности, в то время как поисковая система A была «заточена» под количество результатов поиска, а поисковая система B – под обеспечение их свежести.

Таблица 5.1 Ценностные предложения ранних поисковых систем

А что по поводу «фишек»? В эту категорию попадает функция Google Suggest, которая работает на основе совпадения поисковых запросов. Вместо того чтобы вводить текст запроса целиком – например, «сколько дюймов в ярде», – пользователям достаточно начать вводить первые несколько букв или слов – «сколько…», – и на экране появляется список предлагаемых продолжений запроса. После этого можно просто «кликнуть» на нужной строчке из выпадающего списка вариантов, что позволяет сэкономить время пользователя. Чем длиннее поисковая фраза, тем больше сэкономленного времени. Кроме того, просмотр списка наиболее подходящих формулировок запроса помогает тем пользователям, которые не совсем уверены в правильности собственного варианта. Это также приводит к более быстрому получению релевантных результатов.

Мгновенный поиск в Google – еще одна функция, способная вызвать восхищение пользователей. Она позволяет выводить на экран результаты поиска по мере ввода текста запроса, то есть еще до того, как пользователь нажмет клавишу «ввод» (или выберет подходящий вариант из автоматически предлагаемого списка). Эта функция также экономит время пользователя. В Google заметили, что люди способны считывать результаты гораздо быстрее, чем набирают текст. Обычно между нажатиями клавиш проходит 300 миллисекунд, тогда как на считывание результатов тратится всего лишь 30 миллисекунд. Разработчики подсчитали, что мгновенный поиск позволяет сэкономить от двух до пяти секунд на запрос. В Таблице 5.2 представлено более полное описание ценностного предложения Google, где к ранее рассмотренным преимуществам производительности добавлены еще два, только что рассмотренных фактора. Google Suggest и Google Instant Search представляют собой функции продукта, но не преимущества. Поэтому я указал их в характеристиках Google, но в левом столбце перечислил именно преимущества, которые они обеспечивают: экономия времени на вводе поискового запроса и экономия времени на просмотре результатов поиска соответственно.

Таблица 5.2 Ценностное предложение Google, включая преимущества, восхищающие пользователей

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

Не так уж и «круто»

Последней поисковой системой, которую нам стоит обсудить, является Cuil (созвучно слову «крутой»)[13], которая была запущена в 2008 году. К этому времени рынок поисковых систем уже находился в правом верхнем квадранте диаграммы соотношения важности и удовлетворенности. Потребность в интернет-поиске являлась очень важной, но при этом пользователи были вполне удовлетворены уже существовавшими поисковыми системами, среди которых Google занимала самую большую долю рынка (на тот момент более 60 %). С учетом сложившейся ситуации, для любого нового продукта, выходящего на этот рынок, было крайне важно иметь такое ценностное предложение, которое ясно и четко давало бы понять, чем этот продукт будет отличаться от существующих аналогов и в чем их превосходить.

Результаты работы маркетологов Cuil давали понять, что новая поисковая система будет иметь самый обширный индекс. При запуске было заявлено, что он охватывает 120 млрд веб-страниц, или, по их собственным оценкам, в три раза больше, чем Google. Иначе в Cuil было организовано и представление результатов поиска – в журнальном формате с большим количеством фотографий. Кроме того, указывалось на особое отношение к соблюдению конфиденциальности: в частности, разработчики Cuil обещали, что система не будет сохранять историю пользовательских поисковых запросов.

Каким получился итог? Не таким «крутым», как на то намекало название поисковика. Критики жаловались на долгое время отклика и низкую релевантность результатов. Эксперт по поисковым системам Дэнни Салливан из Search Engine Watch раскритиковал Cuil за то, что ее разработчики сосредоточились на размере индекса, а не на релевантности. Через два года после запуска поисковая система Cuil ушла с рынка.

Гипотезы команды разработчиков Cuil в отношении того, что могло бы стать залогом успеха новой поисковой системы, не оправдались. Чтобы иметь шанс обойти действующего лидера этого рынка, ценностное предложение нового продукта должно было как минимум не проигрывать ему по двум важным параметрам производительности – релевантности и времени отклика. Я уверен, что разработчики Cuil вовсе не планировали ухудшать эти характеристики, но это было именно то, с чем столкнулись пользователи. Даже если бы Cuil удалось сравняться с Google по двум названным преимуществам производительности, разработчикам новой системы все равно пришлось бы предложить какую-то отличительную ценность, чтобы завоевать заметную долю рынка. Совершенно не факт, что с этой ролью справились бы предполагаемые отличия нового поисковика в виде расширенного индекса и повышенной конфиденциальности.

В Таблице 5.3 представлено описание предполагаемого и фактического ценностного предложения Cuil по сравнению с аналогичным предложением Google. Изменить поведение клиентов всегда сложно – особенно при нахождении в правом верхнем квадранте диаграммы, – поэтому для того, чтобы заставить потребителей отказаться от продукта, которым они обычно пользуются, необходимо создать определенную избыточную ценность. Здесь снова приходит на ум мысль о необходимости «десятикратного повышения» производительности.

Таблица 5.3 Сравнение ценностных предложений Cuil и Google

Формирование ценностного предложения продукта

Теперь, когда на примере поисковых систем мы более подробно изучили концепцию, давайте обсудим, каким образом должно формироваться ценностное предложение продукта. Таблица 5.4 представляет собой незаполненный шаблон для ценностного предложения. В первом столбце вы перечисляете сгруппированные по категориям клиентские преимущества – по одному в строке. Необходимо включить в этот список все актуальные как для вас, так и для ваших конкурентов функции, обеспечивающие: базовые потребности (для краткости будем именовать их – «мастхэв»), преимущества производительности, а также функции, вызывающие «вау-эффект» («фишки» продукта). При этом следует предусмотреть отдельные колонки как для вашего, так и для каждого из конкурирующих продуктов. Даже если допустить, что у вашего продукта нет прямых конкурентов, что маловероятно, все равно должны существовать альтернативные решения, которые клиенты в настоящее время используют для удовлетворения своих потребностей (например, в качестве альтернативы приложению TurboTax выступали ручка и бумага).

Таблица 5.4 Шаблон для формирования ценностного предложения продукта

После того как вы определили потенциальные преимущества и конкурирующие продукты, необходимо проставить для каждой строки соответствующие оценки. При оценке существующего продукта вы должны исходить из его текущих параметров; если же вы создаете совершенно новый продукт, можно указать оценки, которых планируете достичь. В полях, относящихся к обязательным функциям, должно быть указано «Да». Для оценки преимуществ производительности следует использовать ту шкалу, которая вам больше подходит: обычно используется следующий набор оценок показателя: «Высокий», «Средний» и «Низкий». В случае, когда преимущество производительности поддается числовому измерению, вы можете использовать более точные значения. Например, если вы оцениваете приложение для бронирования столиков в ресторане, такое как OpenTable, то количество охваченных этой системой ресторанов и время, требуемое для совершения бронирования, могут быть теми преимуществами производительности, для оценки которых вполне могут быть указаны числовые значения. Восхищающие потребителя «фишки» продукта, как правило, уникальны, поэтому достаточно будет просто перечислить их в отдельных строках и поставить отметку «Да» в соответствующих полях.

Пример заполнения шаблона ценностного предложения приведен в Таблице 5.5. Я намеренно не конкретизировал описание функций, чтобы вам было легче представить, каким образом поля таблицы могут быть заполнены для вашего продукта. В приведенном примере имеются два конкурента для продукта, который вы планируете создать. Все три компании-разработчика (включая вас) ответили «Да» в отношении наличия обязательных функций. В части производительности конкурент А стремится быть лучшим по показателю «Преимущество 1», а конкурент В сфокусирован на опережающем развитии «Преимущества 2». Вы планируете обойти конкурентов по «Преимуществу 3». Возможно, вы определили новый сегмент клиентов, которые более высоко ценит именно это преимущество, или у вас есть новая технология, которая позволяет достичь более высокого уровня удовлетворенности соответствующей клиентской потребности. У продукта конкурента A есть «Фишка 1», а у вас есть собственная идея, представляющая пользователям «Фишку 2». Ключевые отличительные признаки каждого продукта выделены в таблице жирным шрифтом.

Таблица 5.5 Пример заполненного шаблона ценностного предложения продукта

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

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

Катись туда, где будет находиться шайба

Выше я описал создание ценностного предложения как статичный моментальный снимок вашего и конкурирующих продуктов. Однако, чтобы мыслить стратегически, вы должны быть способны спрогнозировать будущие изменения, предвосхищая рыночные тенденции и вероятные действия конкурентов. Это особенно важно на многих высокотехнологичных рынках, которые часто претерпевают быстрые изменения. Как сказал Уэйн Гретцки: «Я качусь туда, где должна появиться шайба, а не туда, где она была секунду назад».

Флип-камера

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

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

Глава 7

Создание прототипа MVP (шаг 5)

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

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

Чем является (и чем не является) MVP?

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

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

Рисунок 7.1. Внутреннее строение MVP

Диаграмма на Рисунке 7.1 иллюстрирует разницу между неправильным и правильным способами интерпретации MVP. Я адаптировал этот рисунок по образцу, созданному талантливым UX-дизайнером Юсси Пасаненом из Volkside (http://volkside.com).

Подобно моей иерархии потребностей веб-пользователей (см. Рисунок 4.2), на этом рисунке различные аспекты продукта представлены в виде слоев пирамиды. В данном случае для описания атрибутов продукта используется пирамида из четырех иерархических уровней: функциональность, надежность, удобство [использования] и восхитительность. Пирамида слева иллюстрирует ошибочное представление о том, что MVP представляет собой всего лишь продукт с ограниченной функциональностью, а надежностью, удобством использования и функциями, вызывающими восхищение пользователя, при его создании можно пренебречь. Правая пирамида показывает, что, хотя MVP и обладает ограниченной функциональностью, он должен быть «полноценным» в том смысле, что в нем находят свое отражение атрибуты, расположенные на всех трех более высоких уровнях.

MVP-тесты

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

Несмотря на то что термин «MVP-тест» обеспечивает удобное обобщение всех различных видов подобных тестов, между ними имеются ключевые различия. Существует два основных способа их классификации.

Продуктовые и маркетинговые MVP-тесты

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

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

Когда при помощи повторяемого тестирования прототипа кандидата в MVP вы достигнете точки, в которой почувствуете, что с достаточной долей уверенности подтвердили соответствие продукта рынку, можно будет приступить к этапу создания реального MVP.

Количественные и качественные MVP-тесты

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

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

Количественные тесты хороши для того, чтобы получить ответы на вопросы «что?» и «сколько?»: что именно сделали пользователи и сколько из них совершили то или иное действие (например, нажали на кнопку «зарегистрироваться»). Однако количественные тесты не объяснят вам, почему одни пользователи совершили то или иное действие, в то время как другие предпочли этого не делать. Напротив, качественные тесты хороши для получения ответов на вопрос «почему?». Они направлены на изучение причин, лежащих в основе решений различных пользователей.

Оба вида тестов имеют свою ценность и дополняют друг друга. Мой опыт показывает, что многие команды разработчиков излишне полагаются только на один вид тестов, обычно количественный. Принимая решение о том, каким из видов тестов следует воспользоваться, необходимо исходить из того, какую именно информацию вы хотите получить. На начальном этапе разработки продукта или маркетинговых материалов более полезными оказываются качественные тесты, позволяющие получить некоторое первоначальное представление. Использование на этом этапе количественных тестов без предварительного проведения качественных обычно не дает полезных результатов – вы получите совокупные статистические данные, но не будете знать, какие представления пользователей лежат в их основе. Во многих случаях команды, работающие над созданием продукта, чередуют раунды качественного и количественного тестирования по мере получения информации и прохождения итераций улучшения. Дополнительные советы, относящиеся к проведению качественного тестирования продукта на пользователях, вы найдете в главе 9.

Матрица MVP-тестов

На Рисунке 7.2 представлена матрица, содержащая сводную информацию о классификации различных MVP-тестов на основе сравнения продуктовых тестов с маркетинговыми и качественных тестов с количественными. В каждой из четырех ячеек матрицы я перечислил соответствующие ей MVP-тесты. Далее я коротко опишу каждый из четырех видов тестов, представленных на рисунке.

Рисунок 7.2. Классификация MVP-тестов

Качественные маркетинговые MVP-тесты

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

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

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

Количественные маркетинговые MVP-тесты

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

Целевая (лендинговая) страница / «Дымовой тест»

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

Ключевым показателем для данного вида тестов является коэффициент конверсии: процент посетителей целевой страницы, которые нажали на соответствующую кнопку, чтобы превратиться из потенциального клиента в покупателя. Например, если вы привлекли на свою лендинговую веб-страницу 1000 посетителей, из которых 250 человек нажали кнопку «Зарегистрироваться», то коэффициент конверсии составит 25 %. На величину данного показателя влияет то, какие преимущества вы выберете для демонстрации и насколько хорошо опишете свой продукт. При этом необходимо учитывать, что даже если вы выбрали для показа действительно важные для пользователей преимущества, коэффициент конверсии может оказаться низким из-за плохой проработки дизайна веб-страницы и текстового описания.

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

MVP-тест целевой страницы на примере приложения Buffer

Приложение Buffer представляет собой хороший пример MVP-теста целевой страницы. Buffer – это продукт, который помогает организовывать размещение сообщений в Twitter, публикуя выбранные твиты в заранее запланированное вами время. Генеральный директор и соучредитель Buffer Джоэл Гаскойн описал в своем блоге (https://blog.bufferapp.com/idea-to-paying-customers-in7-weeks-how-we-did-it) процесс MVP-тестирования целевой страницы этого продукта. По его словам, в случае с Buffer он решил применить иной подход, нежели к своему предыдущему стартапу: «Я начал писать код для Buffer еще до того, как проверил степень жизнеспособности проекта. Но я быстро осознал свою ошибку, остановился, глубоко вдохнул и сказал себе: “На этот раз сделай все правильно. Начни с проверки того, нужен ли людям этот продукт”».

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

Как объяснил Гаскойн: «Цель этого двухстраничного MVP состояла в том, чтобы проверить, захочет ли кто-то вообще использовать наше приложение. Я просто разместил ссылку в Twitter и спросил читателей, что они думают об этой идее. После того как несколько человек отправили мне свою электронную почту с лендинговой страницы, а некоторые даже прислали полезные отзывы на e-mail и в Twitter, я счел свою идею протестированной».

Таким образом, Гаскойн получил подтверждение востребованности задуманного им проекта. Далее следовало проверить, готовы ли люди платить за это. Поэтому он сделал дополнительную страницу (перед формой для отправки адреса электронной почты), на которой разместил описание трех тарифных планов с различными уровнями использования продукта: бесплатный, за 5$ в месяц и за 20$ в месяц. Это позволило ему увидеть, сколько кликов собрал каждый тарифный план, в дополнение к тому, сколько пользователей согласились указать свой e-mail. Тестирование прошло успешно. Несмотря на появление необходимости дополнительного перехода между страницами, посетители по-прежнему заходили на форму отправки адреса электронной почты, оставляли свои e-mail и даже выбирали платные условия использования продукта.

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

Демо-ролик

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

Рекламная кампания

Чтобы протестировать целевую страницу, вам нужно каким-то образом заманить на нее пользователей. Один из способов сделать это является проведение рекламной кампании. Например, сервис Google AdWords в тот момент, когда пользователи осуществляют поиск в сети Интернет, демонстрирует им короткую контекстную рекламу. Вы можете поэкспериментировать с различными ключевыми поисковыми словами и текстами рекламных объявлений, чтобы увеличить количество переходов. Это позволит собрать количественные статистические данные о том, какие именно ключевые слова и фразы обладают наибольшей привлекательностью для ваших потенциальных потребителей. Вы также можете использовать медийную рекламу для тестирования различных сообщений и изображений. Учитывая, что реклама в Facebook позволяет устанавливать демографические критерии, она может оказать существенную помощь в проверке ваших гипотез о целевом рынке. Поскольку рекламные объявления, как правило, невелики по своему объему, в них бывает невозможно уместить ценностное предложение целиком. Вместо этого приходится ограничиваться коротким слоганом. Соответственно, данный вид тестирования будет наиболее полезен для оптимизации усилий по привлечению клиентов, а не для проверки соответствия продукта рынку.

Например, планируя создание сайта, помогающего людям в поиске работы, вы могли бы запустить три рекламные кампании, каждую со своим слоганом: «Мы подберем вам работу вашей мечты», «У нас самая большая база вакансий в любой точке мира» и «Мы предлагаем самый быстрый способ поиска вакансий». Затем вы могли бы сравнить количественные показатели переходов по ссылкам всех трех рекламный кампаний и определить, какая из них оказалась наиболее эффективной.

Маркетинговое A/B тестирование

A/B-тестирование, также известное как сплит-тестирование, представляет собой количественный метод, при котором вы тестируете два альтернативных проекта одновременно, чтобы сравнить их эффективность по ключевому показателю, такому, например, как коэффициент конверсии. Вы можете использовать A/B-тестирование для проверки различных редакций маркетинговых материалов, чтобы понять, какая из них работает лучше. Например, провести тестирование двух разных версий целевой страницы – с различающимися описаниями продукта, ценами, изображениями, цветовыми или другими элементами дизайна, а затем сравнить их коэффициенты конверсии. Вы также можете применить A/B тесты для большинства других маркетинговых материалов, размещаемых в Интернете: рекламных объявлений, видеороликов и почтовых рассылок.

В тестах могут участвовать более двух альтернатив. Например, вы можете провести A/B/C-тест с тремя версиями материалов. Правила проведения A/B-теста предусматривают, что тестирование всех участвующих в нем версий проводится параллельно, в одно и то же время, в равных условиях. Например, 50 % трафика направляется на версию A и столько же – на версию B. Менее желательно тестировать версии последовательно (100 % трафика на версию A, затем 100 % трафика на версию B). Тестируя альтернативные варианты одновременно, вы избегаете риска, что имевшиеся в разное время различия во внешних факторах приведут к искажению полученных результатов.

Часто после проведения нескольких A/B-тестов, направленных на оптимизацию какого-либо аспекта продукта, определяется наиболее эффективный вариант, который получает звание «чемпиона». Далее вы можете проводить периодическое тестирование вновь появляющихся альтернатив, сравнивая их результаты уже не между собой, а с показателями чемпиона. Важным аспектом в этом случае является статистическая значимость, которая определяется разницей в значениях сравниваемых показателей и в размере выборки. Существуют формулы и онлайн-инструменты, которые позволяют рассчитать статистический уровень достоверности для конкретного теста. Однако важно знать, что статистическая значимость всегда выше при наличии существенных различий величины показателей и большого размера выборки. Если размер выборки слишком мал, вы не добьетесь статистически значимых результатов. Если у вас есть два варианта с очень похожими значениями сравниваемых показателей, может потребоваться очень большой размер выборки, чтобы заметить статистически значимую разницу между ними.

Список наиболее популярных инструментов для проведения A/B тестирования включает в себя следующие сервисы: Optimizely, Unbounce, KISSmetrics, Visual Website Optimizer и Google Content Experiments (входит в состав Google Analytics). Эти инструменты позволяют выбрать для тестирования несколько альтернативных версий продукта, а затем случайным образом распределить между ними пользовательский трафик. Функционал этих сервисов дает возможность отслеживать интересующие вас действия посетителей, рассчитать коэффициент конверсии и получить результаты для каждого из тестируемых вариантов с указанием уровня статистической достоверности.

Мультивариантное тестирование похоже на A/B-тестирование, но подразумевает проверку разных версий элементов веб-страницы, а не всей страницы целиком. В этом случае каждый тестируемый элемент страницы является переменной. Допустим, при разработке целевой страницы у вас возникло три разных идеи относительно заголовка и три разных идеи основного изображения. При применении мультивариантного теста будут опробованы все девять возможных комбинаций разных заголовков и изображений, чтобы определить, какая из них работает наиболее эффективно.

Краудфандинг

Краудфандинговые платформы, такие как Kickstarter и Indiegogo, могут стать отличным способом проверить, готовы ли потребители платить за ваш продукт, а также оценить этот спрос в количественном выражении. Названные платформы обеспечивают разработчикам, которые хотят производить и продавать свой продукт, возможность продвигать его и получать деньги от клиентов, желающих приобрести его сразу после выхода. Вы можете установить минимальный порог суммы собираемых средств, взяв на себя обязательство по созданию продукта только в том случае, если установленный порог будет превышен. Такой подход, при котором клиенты платят вам еще до того, как вы приступите к разработке, соответствует принципам бережливого производства, поскольку он устраняет неопределенность в отношении того, нужен ли ваш продукт потребителям.

Часы Pebble Watch – это одна из историй успеха, имевших место на платформе Kickstarter. Сначала основатель данного стартапа, Эрик Мигиковский, попытался привлечь финансирование со стороны венчурных компаний через инкубатор Y Combinator. Однако попытка оказалась безуспешной. Тогда он запустил кампанию по сбору средств на Kickstarter с первоначальной целью финансирования в размере 100000$. Подписчики получали право приобрести часы Pebble Watch по цене 115$ сразу после их выпуска, фактически получая за предзаказ скидку от полной цены в 150$. Проект собрал первоначально установленную сумму за два часа, и от желающих сделать взнос не было отбоя. В итоге Pebble прекратила сбор средств на Kickstarter после того, как более 68 тыс. человек внесли в фонд реализации этого проекта более 10 млн $.

Краудфандинговая платформа Kickstarter стала новым привлекательным каналом финансирования стартапов. Проект, предусматривающий производство гарнитур виртуальной реальности Oculus Rift, стартовал с установленной первоначальной целью сбора средств в размере 250000$ в августе 2012 года. За месяц было собрано чуть менее 2,5 млн $, что почти в 10 раз превышало целевую сумму. Менее чем через два года Facebook приобрела Oculus Rift за 2 млрд $.

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

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

Качественные продуктовые MVP-тесты

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

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

После создания продукта вы, опять же, сможете протестировать его на пользователях – преимущество этого момента заключается в том, что точность результатов такого тестирования составляет все 100 %. Возможно, вы при этом узнаете то, чего не смогли заметить на этапе тестирования артефактов дизайна. Например, во время разработки вы могли получить отзывы о макете веб-страницы, о том, насколько доходчиво изложена информация и привлекателен визуальный дизайн. Однако вы не заметили бы до момента реализации продукта, что веб-страница загружается очень медленно или того, что она не работает должным образом в определенном браузере. Тестирование готового продукта в реальных условиях не обязательно должно быть сопряжено с негативными последствиями; однако, если вы откладываете его до того момента, когда продукт будет запущен в эксплуатацию, вы точно очень сильно рискуете. Причем, этот риск ничем не оправдан и должен быть снижен путем демонстрации результатов проектирования еще на ранних стадиях процесса разработки продукта. Это позволит гарантировать, что клиенты в итоге оценят его должным образом.

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

Рисунок 7.3. Проектные артефакты, распределенные по степени их точности и интерактивности

Обратите внимание на Рисунок 7.4, который иллюстрирует различия между низкой и высокой точностью артефактов проекта. Оба представленных на рисунке результата проектирования относятся к одному и тому же приложению для iOS (источник: https://itunes.apple.com/us/app/pointedlysimple-score-keeper/id933257819). Это приложение, созданное талантливым UX-дизайнером Беном Норрисом, позволяет упростить процесс подсчета очков во время различных настольных игр (например, в Scrabble), заменяя использование для этой цели ручки и бумаги. В левой части рисунка показан вайрфрейм низкой точности. Он не использует каких-либо цветов (сделан в оттенках серого) и показывает только расположение элементов экрана без детализации визуального оформления. Высокоточный макет в правой части рисунка выглядит гораздо более похожим на реальный продукт (несмотря на то что его цветное изображение в печатной версии этой книги также представлено в оттенках серого). Элементам пользовательского интерфейса здесь уже придан близкий к реальному дизайн, использующий определенные цвета, шрифты и графику.

Рисунок 7.4. Вайрфрейм низкой точности в сравнении с высокоточным макетом

Эскизы

В левом нижнем углу Рисунка 7.3 вы можете видеть проектные артефакты, обозначенные как «Эскизы», которые характеризуются наименьшей точностью и наименьшей интерактивностью. Создание эскиза – отличный способ начать визуализировать идеи, особенно если вам нужно обсудить их с товарищами по команде и другими внутренними заинтересованными сторонами. Эскиз на доске или бумаге позволяет вносить в проект быстрые правки. Я активный сторонник использования доски для рисования, особенно на ранней стадии проектирования. На самом деле, данный метод вполне может являться идеальным инструментом бережливого производства, поскольку позволяет участникам команды осуществлять быстрые итерации своих идей. Однако, какими бы полезными ни были эскизы для внутреннего использования, слишком низкая точность не позволяет использовать их для получения обратной связи от пользователей (именно по этой причине они отсутствуют в представленной на Рисунке 7.2 матрице MVP-тестов).

Вайрфреймы

Следующим по степени точности артефактом проектирования является вайрфрейм, который с низкой или средней точностью дает представление о компонентах продукта и об их местоположении. Вайрфреймы – это не «совпадающие до пикселя» отображения; скорее, они показывают относительные размеры и расположение элементов. Обычно они не содержат каких-либо деталей визуального оформления, таких как цвета, картинки и шрифты. При их создании чаще используют оттенки серого и заполнители вместо реальных изображений, чтобы не отвлекать рецензентов элементами визуального дизайна. В некоторых случаях могут также использоваться заполнители вместо реального текста – например, «lorem ipsum»[14], – хотя это становится все менее распространенной практикой. Я рекомендую с самого начала использовать реальные текстовые элементы – даже если по содержанию это будет всего лишь черновик, – чтобы заранее выявить потенциальные проблемы с версткой.

Вайрфреймы могут быть нарисованы вручную, но обычно они представляют собой цифровые артефакты, созданные с помощью программных продуктов, предназначенных для проектирования либо специальных приложений для создания вайрфреймов. Чаще всего для создания графического дизайна используют такие приложения как Illustrator и Sketch. Приложения OmniGraffle и Visio представляют собой инструменты более общего назначения. Некоторые специалисты, не являющиеся профессиональными дизайнерами, создают вайрфреймы в PowerPoint или Keynote. Я рекомендую использовать более эффективные инструменты, специально разработанные для создания вайрфреймов, такие как Balsamiq, Axure и UXPin – для веб-продуктов.

Поскольку продукты для мобильных устройств – будь то нативные или интернет-приложения – как правило, имеют элементы пользовательского интерфейса, отличные от тех, которые используются для традиционных веб-приложений, появились специализированные инструменты для создания мобильных вайрфреймов. Дизайнерам, создающим вайрфреймы для мобильных приложений, я рекомендую такие инструменты, как Flinto и Marvel. Тем, кто не занимается дизайном, для создания мобильных вайрфреймов подойдут простые в использовании приложения POP и Dapp.

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

Вот некоторые признаки, указывающие на то, что вам, вероятно, следует изучить современные инструменты для создания вайрфреймов:

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

• Создаваемые вами вайрфреймы не реагируют на «клики» и нажатия клавиш.

• Ваши вайрфреймы трудно «расшаривать» для использования другими людьми.

• Вы создаете вайрфреймы для мобильных устройств с помощью инструмента, который не оптимизирован под соответствующие экраны.

• Создание вайрфреймов занимает больше времени, чем вам хотелось бы.

• Вы вообще не создаете вайрфреймы.

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

Общей особенностью современных инструментов для создания вайрфреймов является наличие библиотеки виджетов, содержащей наиболее распространенные элементы пользовательского интерфейса. Например, если вы хотите создать вайрфрейм приложения для iOS, вам не придется рисовать стандартные элементы управления iOS вручную – в библиотеке современного инструмента наверняка имеется набор общих элементов пользовательского интерфейса iOS.

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

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

На сегодняшний день кликабельные вайрфреймы, по сути, полностью вытеснили статичные формы. Тест статичного вайрфрейма требовал, чтобы пользователь в определенном месте говорил вам: «Я бы нажал вот на эту кнопку», – после чего вы показывали ему следующий статичный вайрфрейм. Интерактивные вайрфреймы создают для пользователя более захватывающий опыт, позволяя самостоятельно изучать ваш продукт и ориентироваться в нем. Кроме того, поскольку интерактивные вайрфреймы обычно тестируются на том же типе устройства, на котором будет использоваться готовый продукт (например, на компьютере, планшете или телефоне), пользовательский опыт оказывается еще более реалистичным.

Макеты

Как показано на Рисунке 7.3, следующим по степени точности артефактом проектирования являются макеты, которые гораздо больше похожи на конечный продукт, чем вайрфреймы. Макеты передают такие детали визуального дизайна, как цвета, шрифты и изображения. В некоторых случаях они должны «совпадать до пикселя» с конечным продуктом, однако необходимость в такой степени достоверности присутствует далеко не всегда. Макеты обычно создают с помощью приложений для графического дизайна, таких как Illustrator, Photoshop или Sketch.

Как и в случае с вайрфреймами, макеты могут быть статичными или интерактивными. С помощью приложений для графического дизайна обычно получают статичные файлы формата jpg, gif или png, которые по своей сути не является интерактивными. Чтобы создать набор интерактивных макетов, эти изображения объединяются с помощью другого приложения, которое позволяет создавать «горячие точки», при нажатии на которые происходит переход от одного макета к другому.

С этой задачей хорошо справляется веб-приложение InVision. Этот инструмент позволяет загружать изображения и связывать их воедино с помощью создания кликабельных горячих точек. Еще одним похожим по функционалу инструментом является приложение Balsamiq. При тестировании макетов также применяется сценарий «счастливый путь», когда пользователю доступны лишь некоторые элементы навигационного управления, не позволяющие отклониться от намеченного разработчиками маршрута. Как видите, интерактивные макеты и вайрфреймы похожи в том, что и те и другие позволяют осуществлять переходы между страницами, однако в случае с макетами то, что видит при этом пользователь, существенно больше похоже на конечный продукт. Именно потому, что интерактивные макеты выглядят максимально правдоподобно, они могут обеспечить очень ценную обратную связь со стороны пользователей. Некоторые команды, умеющие создавать качественные интерактивные макеты, начинают тестирование проектных артефактов на пользователях именно с этого уровня. Во многих случаях перед разработкой макетов они тоже создают вайрфреймы, но не показывают их пользователям.

Интерактивный прототип

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

Интерактивные прототипы включают в себя гораздо большее количество функционирующих элементов управления пользовательского интерфейса, нежели интерактивные макеты. Это могут быть выпадающие меню, эффекты наведения курсора, работающие формы ввода и аудио- или видеоплееры. Для создания интерактивных прототипов используются различные инструменты разработчика. Веб-прототипы обычно создаются с использованием HTML, CSS и JavaScript. Для быстрой разработки используются популярные интерфейсные фреймворки, такие как jQuery и Bootstrap. Прототипы также могут быть созданы с использованием Ruby on Rails или других фреймворков быстрой разработки, если вам требуется облегченный функционал на стороне сервера. Мощные инструменты, такие как Axure, которые умеют экспортировать прототип в HTML, CSS и JavaScript, позволяют создавать интерактивные прототипы без использования программного кода. Прототипы под операционные системы мобильных устройств, таких как iOS или Android, могут быть созданы в HTML или в машинном коде.

MVP-тесты: «Волшебник страны Оз» и «Консьерж»

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

MVP-тест «Консьерж» на примере Airbnb

Например, сайт по аренде жилья Airbnb использовал MVP-консьержа для улучшения своего сервиса. В своем выступлении на фестивале South By Southwest (SXSW) директор по продуктам Джо Заде рассказал, как команда Airbnb выдвинула гипотезу о том, что объявления о сдаче недвижимости, которые сопровождаются профессионально сделанными фотографиями, могут принести больше прибыли. Для проверки этой гипотезы они вручную отбирали арендодателей, которым предлагали провести бесплатную профессиональную фотосъемку сдаваемых помещений. Затем компания нанимала фотографов по месту нахождения сдаваемого жилья. Проведя фотосессию, фотографы загружали сделанные снимки в Dropbox, а сотрудники Airbnb – опять же, вручную – подгружали их к соответствующим объявлениям на сайте. В итоге команда Airbnb убедилась в том, что их гипотеза верна: количество бронирований по объявлениям, к которым прилагались профессионально сделанные фотографии, в два-три раза превышало средний уровень.

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

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

«Живой» продукт

Готовый MVP также может быть протестирован на пользователях. В идеале, на пути к готовому продукту вы должны были провести все необходимые качественные тесты его проектных артефактов. Только почувствовав уверенность в том, что в достаточной степени подтвердили соответствие продукта рынку, вы приступаете к созданию реального MVP. В главе 12 я расскажу, как создавать продукт с использованием методов Agile-разработки.

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

Вы можете протестировать свой «живой» продукт как в модерируемом режиме, так и без непосредственного участия модератора. При модерируемом тестировании вы находитесь рядом с пользователем в тот момент, когда он использует продукт. Соответственно, немодерируемый вариант подразумевает, что пользователь остается с продуктом один на один (при этом все его действия фиксируются для последующего анализа). Модерируемое тестирование может проводиться как лично, так и удаленно с применением программного обеспечения, обеспечивающего возможность совместного использования экрана, такого как Skype, WebEx или join.me. Я расскажу об этом подробнее в главе 9.

Количественные продуктовые MVP-тесты

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

Тесты «Фальшивая дверь» или «Страница 404» являются хорошим способом выяснить уровень спроса на новую функцию, которую вы планируете создать. Идея состоит в том, чтобы предложить пользователям ссылку или кнопку для перехода на страницу новой функции и, таким образом, на основе количества осуществленных переходов оценить ее востребованность (в %). Это позволяет понять, действительно ли клиентам нужна данная функция, прежде чем вы потратите ресурсы на ее создание. Поскольку на момент проведения теста самой функции еще не существует, при переходе по ссылке пользователи обычно попадают на веб-страницу, где размещена благодарность за проявленный интерес и сообщение о том, что функция еще не готова для использования. Вы также можете добавить на эту страницу специальную форму для заполнения, чтобы посетитель мог поделиться своим мнением о том, почему он считает эту функцию полезной.

Крайний вариант теста данного типа применяется теми разработчиками, кто не утруждает себя даже созданием простейшей целевой страницы, поскольку технически все попытки перехода по ссылке можно отслеживать и при отсутствии самой веб-страницы. В этом случае, кликнув на ссылку, пользователь попадает на «страницу 404» (где 404 – это код ошибки, означающий, что «страница не найдена»).

Компания Zynga, являющаяся разработчиком игр и имеющая большой опыт в области количественного тестирования продуктов, часто использует метод «фальшивых дверей». В своем выступлении на конференции Stanford Technology Ventures соучредитель Zynga, Марк Пинкус, рассказал, что его команда. собираясь протестировать новые игровые идеи, придумывает для каждой из них короткий питч из пяти слов. Затем эти питчи используются для создания рекламных ссылок, которые компания на некоторое время встраивает в свои уже существующие игры, чтобы увидеть, насколько большой интерес каждая из них вызвала у геймеров.

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

Аналитика продукта и A/B-тесты

Аналитика продукта сама по себе не является тестом, но она может помочь в получении представления о том, как клиенты на самом деле используют продукт. Например, вы можете узнать, какие функции используют чаще всего и на каких веб-страницах проводят больше времени. При внедрении в продукт каких-либо усовершенствований вы можете отследить соответствующие изменения ключевых метрик продукта, чтобы проверить свои гипотезы. Аналитика продукта также является основой для A/B тестирования, поскольку аналитические методы используются для расчета метрик и сравнения результатов тестирования. Наиболее востребованными решениями для анализа продуктов являются такие инструменты, как Google Analytics, KISSmetrics, Mixpanel и Flurry.

A/B-тесты продукта или сплит-тесты используются для сравнения производительности двух альтернативных пользовательских интерфейсов (A и B), являющихся составной частью продукта. Например, предположим, что вы разработали новый процесс регистрации для своего веб-приложения, который, по вашему мнению, будет иметь более высокий процент завершений, чем прежний вариант. Вместо того чтобы просто заменить существующий процесс на новый, вы могли бы провести следующий A/B-тест: случайным образом разделить напополам поток пользовательского трафика, отправив одну половину на прежнюю версию страницы регистрации (A), а другую – на новую (B), после чего сравнить количество завершенных регистраций. Существует несколько популярных инструментов для проведения A/B-тестов: Optimizely, KISSmetrics, Visual Website Optimizer и Google Content Experiments (входит в состав Google Analytics).

Для маркетингового A/B-тестирования большинство компаний используют инструменты сторонних разработчиков. Однако, когда дело доходит до A/B-тестирования продукта, многие в конечном итоге предпочитают создавать и использовать собственные решения, чтобы добиться большей гибкости за счет совместимости программного кода. Одна из основных причин такого подхода заключается в том, что большинство инструментов для проведения A/B-тестирования написаны с использованием JavaScript, что позволяет им прекрасно взаимодействовать с клиентской частью продукта. Однако эти инструменты оказываются не столь полезны в тех случаях, когда необходимо протестировать продукт в его серверной части. Стоит отметить, что ведущие инструменты для проведения A/B-тестирования, такие как KISSmetrics, предлагают способы интеграции с вашей внутренней серверной A/B-платформой.

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

Аналитика и A/B-тестирование представляют собой мощные эмпирические инструменты, которые помогают понять поведение клиентов и соответствующим образом оптимизировать ваш продукт. Свободное владение этими инструментами обеспечивает быструю итерацию и отличает успешные команды разработчиков от других. Учитывая важность таких тем, как аналитика и A/B-тестирование, я вернусь к ним для более подробного рассмотрения в главах 13 и 14.

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

Глава 8

Применение принципов превосходного UX-дизайна

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

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

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

Что отличает превосходный UX-дизайн?

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

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

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

Удобство использования

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

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

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

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

Чем больше усилий требуется для выполнения того или иного действия, тем ниже доля пользователей, которые будут выполнить это действие.

Чем меньше усилий требуется для выполнения действия, тем выше доля пользователей, выполняющих это действие.

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

В дополнение к объективным поведенческим показателям, о которых я упоминал выше, важно иметь представление о том, насколько простым или сложным в восприятии пользователей является использование вашего продукта. Например, вы можете спросить их: «Насколько прост или сложен продукт в использовании?» – и попросить дать оценку по 7-балльной биполярной шкале:

1. Очень сложен.

2. Сложен.

3. Немного сложен.

4. Не прост и не сложен.

5. Скорее прост.

6. Прост.

7. Очень прост.

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

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

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

Удовольствие от использования продукта

Вторым ключевым атрибутом отличного пользовательского опыта является удовольствие от использования продукта. Хорошее юзабилити помогает избежать плохой оценки UX, но его одного недостаточно для обеспечения отличной оценки пользовательского опыта. Если удобство использования дает ответ на вопрос «Могут ли клиенты использовать ваш продукт?», то наличие или отсутствие удовольствия от использования позволяет понять, нравится ли клиентам пользоваться вашим продуктом. Удовольствие, выходящее за рамки просто отсутствия разочарования, говорит о появлении положительных эмоций. Клиентам приятно пользоваться теми продуктами, которые их радуют.

Одним из аспектов удовольствия от использования продукта является эстетика – то есть привлекательный внешний вид продукта. Клиенты видят продукт еще до того, как начинают им пользоваться, поэтому визуальная привлекательность помогает создать положительное первое впечатление. Приятный дизайн может вызывать ощущение высокого качества продукта, большее доверие и чувство непринужденности. Положительные эмоции, которые помогает вызвать эстетика продукта, могут привести к повышению удовольствия клиентов от его использования.

Иногда удовольствие от использования достигается за счет простоты пользовательского интерфейса. В UX-дизайне меньше часто означает больше – устранение визуального беспорядка снижает когнитивную нагрузку на пользователя и помогает ему сосредоточиться на том, что действительно важно. Достаточно вспомнить минималистичный дизайн домашней страницы Google, на которой нет ничего, кроме поисковой строки.

Пользовательский опыт, при взаимодействии с которым появляется впечатление, будто он умеет читать ваши мысли, тоже доставляет пользователю удовольствие. Использование разумно выбранных установок по умолчанию или проактивных ответов на популярные вопросы может вызывать ощущение понимания и сопричастности. Google Suggest, описанный в главе 5, является хорошим примером такого подхода.

Продукты могут выражать индивидуальность и тем самым вызывать у пользователей положительные эмоции. Обычно это достигается при помощи тональности используемого языка. Юмор – еще один хороший способ вызвать у пользователя восторг. Он реализуется с помощью соответствующих текстовых сообщений и/или вызывающих улыбку изображений.

Удовольствие от использования часто достигается за счет ответной реакции продукта на действия пользователя. Отличным примером является эффект «резиновой ленты», которым интерфейс iOS откликается на попытки пользователя прокрутить сверх допустимого предела отображаемый на экране документ или веб-страницу. Это настолько забавный эффект, что многие люди – сознательно или нет – вызывают его на экране своих устройств снова и снова. Анимация и звуковые эффекты тоже могут вызывать восторг. Я знаю, что многим пользователям Quicken нравится слышать звук кассового аппарата «ка-цзинь» после совершения каждой финансовой транзакции. Сигнал запуска Apple Mac – это еще один звук, который вызывает положительные эмоции у многих пользователей.

Удивление – важная составляющая удовольствия. Ваш продукт может вызывать положительные эмоции у пользователей, делая неожиданные для них вещи. В первые дни существования Twitter его платформа испытывала частые перегрузки. Вместо того чтобы показывать пользователям в таких случаях скучную страницу с сообщением об ошибке, разработчики демонстрировали им ставшую широко известной картинку с терпящим бедствие китом – «fail whale»[15].

В этой связи на память приходит еще один приятный сюрприз из области UX, с которым я столкнулся при использовании приложения поставщика услуг электронного маркетинга MailChimp. Перед отправкой подготовленного вами электронного письма MailChimp позволяет просмотреть, как оно будет выглядеть при разной ширине экрана получателя. При изменении ширины экрана предварительного просмотра в пользовательском интерфейсе отображается талисман MailChimp – шимпанзе, указывающий вытянутой рукой выбранное значение пикселей на линейке. При этом появляется предупреждение, что ширина вашего электронного письма не должна превышать определенного количества пикселей. Когда вы растягиваете письмо сверх определенного размера, выражение лица шимпанзе меняется с радостного на страдальческое, и появляются текстовые предупреждения: «Это уже перебор!» и «Остановите это!». Если вы продолжаете расширять письмо сверх рекомендуемого максимума, указывающая рука шимпанзе отваливается с сопроводительным изображением: «ХЛОП!» Этот восхитительный эффект пользовательского интерфейса показался мне настолько остроумным и удивительным, что спустя годы я до сих пор вспоминаю о нем.

Айсберг UX-дизайна

Как же создать пользовательский опыт, который клиенты сочтут удобным и доставляющим удовольствие при использовании? Разработка дружественного пользовательского опыта требует наличия навыков в нескольких различных областях, в совокупности известных как UX-дизайн. В моем представлении UX-дизайн – это айсберг, показанный на Рисунке 8.1. Как и в реальном мире, у этого айсберга на поверхности находится лишь небольшая видимая пользователю часть UX-дизайна, в то время как скрытым от глаз остается нечто гораздо большее. Он состоит из четырех слоев: концептуального дизайна, информационной архитектуры, интерактивного дизайна и визуального дизайна. Далее я подробно опишу каждый уровень, а сейчас представлю лишь краткий обзор Концептуальный дизайн – нижний слой айсберга – представлен основополагающей концепцией, которая формирует суть пользовательского опыта. Следующий уровень – это информационная архитектура, которая определяет, как вы структурируете информационную составляющую и функциональность вашего продукта. Следующий уровень – это интерактивный дизайн, который отвечает за то, как пользователь и ваш продукт взаимодействуют друг с другом. Верхний слой – видимая часть айсберга – это визуальный дизайн: то, как ваш продукт выглядит в глазах пользователей. Для всех нас визуальная обработка – это основной способ, которым наш мозг усваивает информацию. Но просто приятного на первый взгляд внешнего вида недостаточно для того, чтобы пользовательский опыт продукта соответствовал всем стандартам качества. Превосходный UX-дизайн требует внимания и навыков, применительно ко всем четырем слоям айсберга, а также правильно организованного рабочего процесса проектирования, который последовательно продвигается от нижнего уровня к верхнему.

Рисунок 8.1. Айсберг UX-дизайна

Концептуальный дизайн

Нижний слой айсберга представлен концептуальным дизайном, связанным с основной концепцией, которую вы используете при разработке своего продукта. В идеале концептуальная модель должна соответствовать образу мышления целевых потребителей. Продукт, основанный на хорошо продуманном, ориентированном на клиента концептуальном дизайне, интуитивно понятен и прост в использовании.

Этот слой айсберга UX-дизайна часто вносит значительный вклад в создание инноваций. Если вы представите себе айсберг UX-дизайна как верхнюю часть пирамиды соответствия продукта рынку (то есть стоящим там, где находится слой пирамиды, обозначенный как «опыт пользователя»), то заметите, что уровень концептуального дизайна расположен непосредственно над слоем, обозначающим набор функций продукта. Концептуальный дизайн – это то, что вдыхает жизнь в объекты и придает им форму. Под этим я подразумеваю не визуальное представление или технические детали работы функций, а скорее их сущность – то, как они создают ценность для пользователя.

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

Концептуальный дизайн на примере Uber

Теперь давайте обсудим пример с приложением Uber – популярным сервисом для организации поездок на такси. Какой концептуальный дизайн команда разработчиков использовала для своего мобильного приложения? Приложение Uber использует дизайн, построенный на карте местности. И хотя такой поход является довольно распространенным, инновация концептуального дизайна Uber заключалась в том, чтобы показывать пользователям местоположение ближайших доступных для заказа автомобилей такси в режиме реального времени. Стоит отметить, что применение такого дизайна потребовало внедрения технических инноваций, чтобы отслеживать местоположение водителей Uber в режиме онлайн. Разработчики исходили из понимания того, что клиенты служб такси расстраиваются, когда сталкиваются с опозданиями или неявкой такси к назначенному времени. При формировании своего ценностного предложения разработчики Uber решили, что будет крайне важно обеспечить пользователям продукта прозрачность в отношении того, когда прибудет заказанный ими автомобиль. Инновационный дизайн Uber показывает предполагаемое время ожидания, а также текущее местоположение заказанного вами такси. Концептуальный дизайн, который Uber выбрал для пользовательского опыта своего продукта, сразу делает его ценностное предложение очевидным и позволяет клиенту с первого взгляда заметить принципиальные отличия этого сервиса от конкурентов.

Исследование пользователей

Разработать хороший концептуальный дизайн проще, когда у вас есть глубокое понимание целевых клиентов и их потребностей. Важной, но часто упускаемой из виду составляющей UX является «U»: пользователь[16]. Вы наверняка помните, что пирамида соответствия продукта рынку начинается с целевого потребителя; человека, для которого вы разрабатываете свой продукт.

Вы получаете представление о своем целевом клиенте путем проведения исследований пользователей, которые являются специфическим разделом UX-дизайна. В ходе таких исследований применяется целый ряд методов получения информации о клиентах, такие как установочное интервью, юзабилити-тесты и опросы. В главе 4 я поделился своими рекомендациями по поводу проведения интервью для выявления целевых потребителей. В главе 9 описываются методики проведения собеседований с клиентами для получения от них ценных отзывов о ваших проектах. В главе 13 представлен фреймворк для проведения исследования пользовательского опыта и описаны другие методы получения обратной связи (помимо интервью). Исследование пользователей охватывает все уровни UX-айсберга. Когда клиенты оставляют отзывы, относящиеся к пользовательскому опыту вашего продукта, бывает весьма полезно проанализировать полученную информацию и сопоставить ее с соответствующим слоем айсберга UX-дизайна.

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

Метод персонажей

Без знания своих целевых потребителей невозможно создать для них превосходный пользовательский опыт. В UX-дизайне для осуществления такого близкого знакомства используется метод персонажей, который был описан ранее в главе 3 в контексте идентификации целевых потребителей (см. Рисунок 3.1). Напомню вкратце, что персонаж – это архетип реальных пользователей вашего продукта. Грамотно составленный профиль персонажа содержит описание потребностей целевого пользователя, а также соответствующие ему психографические, поведенческие и демографические характеристики. Персонажи помогают принимать более обоснованные решения при разработке продукта, который обеспечивает потребительские преимущества в рамках сформированного вами ценностного предложения.

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

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

Команды разработчиков используют персонажей в процессе проектирования пользовательского опыта, чтобы постоянно напоминать себе о том, для кого они разрабатывают продукт. Вот почему так важно дать персонажу имя. В ходе обсуждения различных вариантов дизайна любой член команды может спросить себя: «Что из этого больше всего соответствует потребностям Нэнси?» Некоторые команды даже вырезают из картона фигуры персонажей и помещают их внутри своего рабочего пространства, чтобы во время работы над UX-дизайном никогда не забывать о пользователе.

Как только у вас появится концептуальный дизайн, который, как вы считаете, будет интуитивно понятен и ценен для вашего персонажа, следующим шагом должно будет стать высокоуровневое определение компонентов продукта и того, как они должны быть организованы.

Информационная инфраструктура

Следующим (вторым снизу) слоем айсберга UX-дизайна является информационная архитектура. Этот термин часто используется в сокращении – IA. Это составляющая проектирования, ответственная за определение того, как должны быть структурированы информационная и функциональная части программного продукта. Обычно в состав продукта входят несколько страниц или экранов, поэтому существует множество способов их организации. Клиент получает доступ к различным экранам, используя встроенную в приложение навигационную систему. При поиске определенной страницы пользователь полагается на навигационные метки, чтобы понять, как организован продукт и где находится нужная ему страница. С целью выяснить мнение пользователей о взаимной связанности различных компонентов продукта и определить предпочитаемую ими схему организации часто используется метод, который называется «Сортировка карточек». Хорошо продуманная информационная архитектура организует внутренние компоненты продукта интуитивно понятным пользователям образом, снабжает их легко понятными указателями, что в совокупности обеспечивает высокий уровень юзабилити и результативности поиска.

Под результативностью поиска следует понимать, насколько легко пользователям продукта удается найти предмет своих поисков. Чтобы измерить этот показатель, вы могли бы попросить группу участников тестирования найти внутри вашего продукта определенную страницу или экран, после чего высчитать процент успешных попыток. Вы также можете оценить результативность поиска, просмотрев шаблоны навигации с использованием аналитических инструментов. Это позволит получить ответы на такие вопросы, как «Всегда ли пользователи выбирали кратчайший путь, чтобы попасть на нужную страницу? Или они добирались до цели обходными путями и часто нажимали кнопку “Назад” в своем браузере?»

Обратите внимание, что IA имеет дело с набором функций продукта на верхнем уровне: то есть определяет, что это за функции, как они должны быть организованы и промаркированы. На этом уровне вы еще не занимаетесь такими деталями, как потоки пользователей, макеты страниц или внешнее представление. Информационная архитектура – это основополагающий слой, который способствует созданию превосходного пользовательского опыта, делая внутреннюю структуру продукта интуитивно понятной для пользователей. Основным результатом работы проектировщиков IA, который передается на следующий уровень разработки, является карта сайта.

Карты сайтов

Карта сайта используется для описания структуры продукта. Несмотря на то что термин «карта сайта» происходит от слова «сайт» (как в «веб-сайте»), под ним следует понимать результат проектирования структуры любого программного продукта, включая мобильные приложения. Карта сайта показывает все страницы или экраны, входящие в состав продукта, то, как они распределены по разделам, а также высокоуровневые шаблоны навигации. Кроме этого, карта сайта содержит заголовки страниц и метки, используемые для обозначения разделов продукта. Сформированную карту сайта необходимо протестировать на пользователях, чтобы убедиться, что метки действительно передают смысловое содержание страниц и что пользователи легко ориентируются в предложенной структуре продукта. На Рисунке 8.2 приведен пример карты сайта для веб-приложения, позволяющего проводить рекламные кампании с использованием видеороликов.

Каждый прямоугольник на этой карте обозначает определенную страницу. Соединительные линии показывают пути навигации между страницами. В некоторых случаях навигация предполагается односторонней, что обозначено стрелкой (см. условные обозначения на левой стороне). Элементы глобальной навигации – страницы, на которые пользователь может перейти из любого места, – четко определены. Уровень элементов глобальной навигации, расположенный в верхней части карты, включает в себя основные разделы продукта. Ниже показаны страницы, на которые попадают пользователи, когда переходят по ссылкам с верхнего уровня. Для каждого раздела сайта, входящие в него страницы показаны в иерархическом порядке. Кроме этого, на карте обозначено, какие страницы ведут себя нестандартным образом – открываются во всплывающем окне либо в новой вкладке браузера.

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

Рисунок 8.2. Пример карты сайта

Интерактивный дизайн

Следующий слой айсберга представляет интерактивный дизайн, который определяет, как ваш пользователь и продукт взаимодействуют друг с другом. Интерактивный дизайн определяет пользовательские потоки: какие действия доступны пользователю на каждом шаге и как на эти действия должен реагировать продукт. Он также определяет порядок ввода информации пользователем, например, в определенную форму. Любой элемент управления в составе пользовательского интерфейса или ссылка, с которыми пользователь может совершать какие-либо действия (будь то щелчок, наведение курсора, перетаскивание, ввод текста, касание, свайп и так далее), относятся к сфере интерактивного дизайна.

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

Если продукт предлагает пользователю помимо обычных какие-либо особые «операционные режимы» – например, режим редактирования или предварительного просмотра, – это также относится к дизайну взаимодействия пользователя с продуктом. Аналогично, если приложение предусматривает отслеживание различных состояний (признаков) объекта, которые влияют на то, какие действия с этим объектом может или не может совершать пользователь, это также являются частью интерактивного дизайна. Например, на сайте интернет-магазина имеется выставленный на продажу товар. Он может находиться в различных состояниях: быть в наличии, или отсутствовать, лежать в корзине покупок или в составе уже сделанного заказа. Все переходы между этими состояниями определяются решениями, принимаемыми в области интерактивного дизайна: для того чтобы пользователь имел возможность положить товар в корзину и перейти к его оплате, он должен быть в наличии, чтобы оформить заказ. Хорошо продуманный интерактивный дизайн обеспечивает видимость текущего состояния объекта на каждом шаге пользовательского потока. Часто эти состояния могут быть тесно связаны с концептуальным дизайном продукта (нижний слой айсберга). В приведенном выше примере концептуальный дизайн подразумевает наличие виртуальной корзины для покупок, похожей на реальную корзину, которой пользуются покупатели в супермаркете. В приложении Uber также имеется фундаментальная связь между концептуальным дизайном и текущим состоянием поездки пользователя. Прежде чем вы закажете такси, приложение показывает на экране все ближайшие доступные для заказа автомобили; но как только вы сделаете свой заказ, вы будете видеть текущее положение только заказанного такси.

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

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

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

Интерактивный дизайн приложения TurboTax

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

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

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

«Легкий шаг» является основным режимом работы продукта, установленным по умолчанию. Еще один режим работы приложения, который называется «Формы», предоставляет доступ к реальным налоговым формам и рабочим листам, поля которых предзаполнены в соответствии с ответами, которые были даны пользователем в режиме «Легкий шаг». При этом каждое из внесенных числовых значений может быть отредактировано. Таким образом, пользователи TurboTax могут по своему желанию составить декларацию, пройдя через процедуру вопросов-ответов, без перехода в режим ручного заполнения налоговых форм либо заполняя необходимые поля самостоятельно. При этом приложение позволяет пользователю легко переключаться между режимами. Многие в итоге даже не видят заполняемые формы; режимом непосредственного заполнения пользуются, как правило, только те, кто имеет необходимый для этого опыт. Благодаря использованию двух различных режимов работы интерактивный дизайн TurboTax позволяет с помощью одного и того же продукта эффективно удовлетворять потребности как начинающих, так и опытных пользователей.

Блок-схемы

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

На Рисунке 8.3 показан пример блок-схемы, разработанной талантливым UX-дизайнером Кристин Лью (источник: http://christineliu.info) для мобильного приложения CarMax. Это приложение помогает пользователю выбрать понравившийся автомобиль, а затем связаться с дилерским центром CarMax. Приложение использует данные, содержащиеся в профиле пользователя на Facebook, чтобы предложить автомобили, которые могут ему понравиться. Пользователи могут просматривать предлагаемые варианты автомобилей, включая их подробные характеристики, пока не найдут тот, что им понравится. На этом этапе они могут связаться с дилером CarMax по электронной почте, через онлайн-чат или по телефону, чтобы запланировать свой визит в дилерский центр. Блок-схема начинается с этапов загрузки и запуска приложения, а затем показывает пути, по которым пользователь может перемещаться между различными экранами вплоть до получения конечного результата. Обратите внимание, что блок-схема описывает верхний уровень пользовательского опыта, не вдаваясь в детали дизайна отдельных экранов (такие как расположение элементов или визуальный дизайн).

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

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

Рисунок 8.3. Пример блок-схемы

Вайрфреймы

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

На данном этапе процесса проектирования вы не должны беспокоиться о точности передачи изображения вплоть до пикселя или таких аспектах визуального дизайна, как цветовая гамма. Вы создаете макет для каждой страницы или экрана, определяя, какие элементы должны там находиться и как они будут расположены относительно друг друга. Вы задаете себе примерно следующие вопросы: «Должна ли на этой странице быть одна или две колонки?» или «На этой странице изображение должно быть слева, а форма справа или наоборот?». Ранее вайрфреймы могли быть созданы только статичными, но в последнее время все большее распространение получает их кликабельные разновидности, которые позволяют оживить пользовательские потоки. Современные приложения для проектирования позволяют легко и относительно быстро создавать такие вайрфреймы.

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

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

После того как создали начальный набор вайрфреймов, вы можете и должны протестировать их на пользователях. В главах 9 и 10 описаны методы получения обратной связи от пользователей, которая необходима для итеративного улучшения ваших проектных решений. Конечно, вы можете начать со статичных вайрфреймов, но использование при тестировании кликабельных версий приносит намного больше пользы. Это позволяет тестировать не только макеты, но и пользовательские потоки, а также обеспечивает пользователям гораздо более реалистичное представление о продукте. Как только результаты тестирования подтвердят, что ваши вайрфреймы просты в использовании и соответствуют ценностному предложению, наступит момент для перехода к следующему «слою айсберга»: визуальному дизайну.

Визуальный дизайн

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

Цвет

Цвет – важный аспект визуального дизайна продукта. Для всех остальных слоев айсберга вы можете создавать артефакты проектирования в черно-белом цвете, и при этом они будут отлично работать. Но когда вы создаете макеты высокой точности в рамках визуального дизайна, вам просто необходимо четко определиться с используемой цветовой гаммой.

Применение цвета улучшает эстетическое представление продукта и позволяет при необходимости делать акценты на отдельных элементах, расположенных на его страницах. Вы также можете использовать цвет для передачи определенных атрибутов или эмоций. Теплые цвета, такие как красный, оранжевый и желтый, обычно воспринимаются как более энергичные и страстные, в то время как более приглушенные холодные цвета, такие как зеленый, синий и фиолетовый, выглядят более спокойно и сдержано. Многие приложения и веб-сайты используют синюю цветовую гамму, потому что она вызывает ощущение надежности и спокойствия. Зеленый цвет ассоциируется с природой, ростом и деньгами. Фиолетовый связан с роскошью и креативностью. Красный ассоциируется с агрессией, страстью, властью и опасностью. Оранжевый цвет – энергичный и яркий. Желтый символизирует счастье и солнечный свет. Коричневый ассоциируется с теплом и землей. Черный намекает на утонченность, элегантность и загадочность. Белый цвет ассоциируется с чистотой, непорочностью и простотой. Я перечислил распространенные обобщения, при этом восприятие цветов может существенно различаться в разных странах мира. Поэтому, если ваши целевые пользователи принадлежат к определенной культуре, при разработке дизайна следует обратить внимание на возможные особенности восприятия того или иного цвета.

Качественный визуальный дизайн подразумевает, что вы используете для своего продукта хорошо продуманную цветовую палитру, вместо того чтобы раскрашивать элементы страницы как придется. Необходимо подобрать такую комбинацию цветов, чтобы они гармонично смотрелись вместе, и затем уже не отклоняться от сделанного выбора при оформлении каждой страницы или экрана продукта. Сквозное использование одной цветовой палитры помогает создать целостное визуальное представление. Цветовая палитра обычно состоит из одного или двух основных и одного или двух фоновых цветов. Может также использоваться один или два акцентных цвета, которые выступают в качестве дополнения к основным цветам. Полная палитра включает в себя еще и оттенки основного цвета – обычно они отличаются меньшей насыщенностью.

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

Типографика

Типографика определяет расположение и внешний вид текста и является еще одним важным элементом визуального дизайна продукта. На заре существования интернета браузеры поддерживали лишь небольшое количество шрифтов, таких как Arial, Georgia и Verdana. Но широкое внедрение веб-шрифтов CSS3 обеспечило дизайнерам огромное богатство выбора.

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

Размер шрифта – еще одна важная часть используемой типографики. Основной текст, который обычно имеет наименьший размер шрифта, тем не менее, должен быть достаточно крупным, чтобы его можно было прочитать. Заголовки всегда имеют больший размер. Как и в случае с цветами и видами шрифтов, необходимо избегать нагромождений слишком большого количества различных текстовых размеров и поддерживать единство стиля применительно ко всему продукту. Шрифты также могут иметь разные варианты начертания, такие как полужирный, курсив или подчеркивание.

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

Графика

Изображения, как фотографии, так и иллюстрации, часто используются в визуальном дизайне. Для определенных категорий продуктов, таких как сайты интернет-магазинов, правильное использование изображений является очень важным аспектом. Возьмем к примеру приложение Airbnb: чтобы клиенты чувствовали себя комфортно, выбирая жилье для аренды, им необходимо видеть его фотографии. В главе 7 рассказывалось о том, как Airbnb удалось более чем удвоить коэффициент конверсии за счет использования фотографий более высокого качества. Изображения часто присутствуют на целевых и других маркетинговых страницах. Обычной практикой является размещение на целевой странице большой, выделяющейся фотографии типичного пользователя вашего продукта либо какого-то другого художественного или вдохновляющего образа / сюжетной сцены. Например, Netflix часто использует крупные изображения своих пользователей, наслаждающихся просмотром фильма.

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

Иконки – это небольшие символы, используемые для представления объектов или смысловых понятий. Чаще всего они используются для кнопок или других элементов управления пользовательского интерфейса, особенно при нехватке свободного места. Во многих приложениях иконки являются основным способом обозначения кнопок управления. В браузерах иконки используют для таких часто используемых кнопок, как «Назад», «Вперед» и «Обновить». Adobe Photoshop использует панель инструментов, состоящую из иконок, в качестве основного способа обеспечения доступа клиентов к функционалу этого программного продукта. Аналогичным образом продукты Microsoft Office используют «ленту», наполненную иконками. Помимо элементов управления, иконки используются также на маркетинговых страницах как дополняющие и усиливающие приведенный там текст. Иконографика – это особый раздел визуального дизайна; создателям иконок приходится вручную прорисовывать отдельные пиксели, чтобы явить миру свои крошечные шедевры. Важность иконок возросла с расширением использования мобильных устройств. Небольшой размер экрана в еще большей степени заставляет разработчиков мобильных приложений экономить место; поэтому многие элементы управления в таких приложениях представляют собой иконки.

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

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

Стандарты стиля

Стандарт стиля – это результат визуального дизайна, который используется для достижения единообразия во внешнем представлении продукта. Наличие такого стандарта особенно важно для продуктов с большим количеством страниц или экранов. Стилевой стандарт определяет детали визуального оформления – такие как цветовая палитра, размеры, шрифты и графика – для часто используемых элементов дизайна. Следование разработанному стандарту позволяет обеспечить согласованность в работе команды дизайнеров и сократить нагрузку на разработчика пользовательского интерфейса.

Компоновочные сетки

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

Вы можете подобрать размер сетки, наиболее подходящий для вашего макета. На Рисунке 8.4 представлен пример компоновочной сетки, состоящей из 12 столбцов шириной по 94 пикселя каждый, разделенных желобами шириной в 18 пикселей. Общая ширина сетки составляет в этом случае 1326 пикселей и оптимизирована для экранов шириной в 1366 пикселей, чтобы пользователям не приходилось при просмотре сдвигать страницу по горизонтали. Такая ширина макета позволяет разместить дополнительно вертикальную полосу прокрутки и любые другие визуальные элементы интерфейса браузера или операционной системы, имеющие размер до 40 пикселей.

Рисунок 8.4. Пример компоновочной сетки

Основное преимущество компоновочной сетки состоит в том, что она позволяет выравнивать размещение всех элементов страницы или экрана по мере их добавления. Примерами элементов страницы или экрана могут служить текстовые блоки, изображения или кнопки. Элементы могут занимать более одного столбца. Главное, чтобы левая и правая границы элементов начинались и заканчивались на линиях сетки. Взятая нами для примера сетка, состоящая из 12 столбцов, может быть равномерно поделена по 2, 3, 4 и 6 столбцов, что допускает широкий диапазон возможных размеров элементов. На Рисунке 8.5 представлен пример вайрфрейма, который создан с использованием компоновочной сетки для размещения элементов страницы.

Рисунок 8.5. Вайрфрейм, созданный с использованием компоновочной сетки

Сетка, показанная на этих двух рисунках, разбивает рабочее пространство только по горизонтали (на столбцы). Сетки, которые используются в печатном дизайне, часто включают и разбиение по вертикали (на строки). Линии сетки для вертикального позиционирования оказались менее полезными для создания веб-страниц из-за больших различий в высоте экрана различных устройств. Кроме того, контролировать точное вертикальное положение элементов бывает невозможно из-за того, что браузеры динамически масштабируют содержимое в зависимости от ширины используемого экрана. В результате цифровые компоновочные сетки, как правило, ограничиваются разбиением рабочего пространства только по горизонтали. С появлением адаптивного дизайна, о котором пойдет речь ниже, дизайнеры получили больше возможностей контролировать вертикальное положение элементов в своих веб-проектах.

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

Макеты

Макеты, которые мы уже рассматривали в главе 7, – это высокоточные результаты проектирования, представляющие визуальный дизайн. Они основаны на предварительно разработанных вайрфреймах и используют цветовую палитру, элементы типографики и графики для создания внешнего вида продукта. Макеты обычно создаются визуальным дизайнером с помощью таких инструментов, как Adobe Illustrator или Sketch, а затем экспортируются в графические файлы (PNG, GIF или JPG). Вы можете использовать такие статичные макеты для получения обратной связи от пользователей, однако тестирование с использованием кликабельных макетов принесет гораздо большую пользу. Они дают пользователям лучшее представление о продукте и о том, как он работает. Такие инструменты, как InVision, позволяют преобразовать набор статичных макетов в пользовательский поток. С помощью этого и ему подобных инструментов вы можете определить область макета, доступную для клика или нажатия (например, разместив там кнопку или ссылку), и указать, к какому следующему макету должен быть осуществлен переход по этой ссылке. В главах 9 и 10 рассказывается, как организовать получение отзывов пользователей о макетах и использовать результаты тестирования для итеративного улучшения ваших проектов. Как только у вас появится набор кликабельных макетов, которые, по оценке целевых потребителей, достаточно просты в использовании и соответствуют ценностному предложению, этап разработки UX-дизайна будет завершен. Следующим шагом станет реализация пользовательского опыта путем создания продукта. В главе 12 обсуждается, как это сделать с использованием принципов Agile-разработки.

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

Принципы дизайна

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

Гештальт-принципы

Гештальт-принципы – это совокупность полезных теорий о визуальном восприятии объектов. Само слово «гештальт» означает «целостную структуру, образ, который, хотя и состоит из множества частей, воспринимается как нечто единое целое». Это то, к чему наша мыслительная система визуальной обработки пытается свести все то, что мы видим. Существует несколько принципов гештальта, но я сосредоточусь лишь на двух из них: принципах близости и подобия.

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

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

Визуальная иерархия

Визуальная иерархия – это важный принцип дизайна, который связан с тем, как пользователь определяет, какие элементы более важные, чем другие. Это, в свою очередь, влияет на порядок, в котором пользователь переключает свое внимание с одного объекта на другой.

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

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

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

Дизайнеры должны использовать все эти закономерности человеческого визуального восприятия для выстраивания элементов в желаемом иерархическом порядке. Чтобы создать визуальную иерархию, вы должны сначала оценить относительную важность всех компонентов, которые должны присутствовать на странице. Затем следует определить расположение, размер и цвет компонентов, которые позволят произвести расстановку приоритетов. Дизайн страницы с хорошей визуальной иерархией обязательно направит внимание пользователя на самый важный элемент. Затем, опять же, благодаря продуманному дизайну взгляд пользователя будет переходить с одного элемента на другой в соответствии с расставленными вами приоритетами, двигаясь при этом по привычной траектории: сверху вниз и слева направо. Такой подход помогает пользователю быстрее найти то, что он ищет, и успешно выполнить свою задачу. Более того, он приводит к повышению коэффициента конверсии при выполнении пользователем ключевых действий. Хорошая визуальная иерархия – важнейший компонент превосходного пользовательского опыта.

Принципы композиции

В дополнение к принципам гештальта и визуальной иерархии при создании и оценке дизайна необходимо учитывать следующие композиционные принципы:

1. Единство: Воспринимается страница или экран как единое целое или как набор разрозненных элементов?

2. Контраст: Имеется ли достаточно различий в цвете, размере, расположении и так далее, чтобы это вызывало визуальный интерес?

3. Баланс: Равномерно ли распределен визуальный вес (положение, размер, цвет и так далее) элементов в дизайне?

4. Использование пространства: Насколько загроможденным или разреженным выглядит дизайн? Убедитесь, что на странице/экране оставлено достаточное количество свободного места – неиспользуемого пространства, – чтобы дизайн не выглядел перегруженным.

Адаптивный дизайн

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

Очевидно, что экраны смартфонов гораздо меньше, чем у ноутбуков и настольных мониторов. Например, размер экрана оригинального iPhone составлял всего лишь 360 на 480 пикселей. Сейчас размер экрана смартфонов варьируется в очень широком диапазоне. Планшеты, по размеру своего экрана, заполнили нишу между смартфонами и компьютерными мониторами. Фаблеты по этому же параметру находятся где-то между смартфонами и планшетами. В верхней части этого рейтинга находятся настольные мониторы с очень высоким разрешением. Диапазон различных разрешений экрана цифровых устройств расширился еще больше с появлением AppleWatch и других подобных гаджетов с их миниатюрными экранами.

Каким же образом команда разработчиков должна справляться с настолько огромным и разрозненным представительством экранных разрешений? На выручку приходит адаптивный дизайн для веб-продуктов. Он позволяет демонстрировать на экранах разного размера соответствующие версии пользовательского интерфейса. Дизайн подстраивается под размер экрана пользователя, обычно под его ширину. Все начинается с установления так называемых «точек останова», которые определяют разные вариации ширины экрана, после чего для каждого из образовавшихся вариантов применяются стилизованные под них различия дизайна. Обычно используются две полярные версии: большой ширины – для экранов компьютеров и малой ширины – для экранов смартфонов. Многие продукты также используют промежуточную точку останова для создания планшетной версии.

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

Проектирование для экранов разных размеров

Необходимость учитывать факт использования потребителями экранов разных размеров является реальностью современного дизайна программных продуктов. Для веб-продуктов адаптивный дизайн является отличным инструментом, предлагающим элегантное и простое решение этой проблемы. Комплекты для разработки мобильного программного обеспечения (SDK) также включают в себя инструменты, которые позволяют создавать для одного и того же приложения различные макеты, оптимизированные под разные размеры экрана.

У вас может возникнуть вопрос: на какой размер экрана (большой или маленький) следует ориентироваться, начиная процесс разработки UX-интерфейса? Если вы изначально разрабатывали свой продукт под экран большего размера, адаптация его к меньшему экрану может оказаться непростой задачей. Созданный объем контента может просто не поместиться на маленьком экране, и вам придется делать трудный выбор – определить элементы, которые придется удалить. Вероятно, вы будете вынуждены изменить и систему навигации. Необходимо будет пересмотреть и переделать контент, размер которого слишком широк для маленького экрана. Поэтому в подобных случаях разработчики часто создают отдельный продукт, переписывая программный код. Однако такое решение не является идеальным. Во-первых, необходимость в дальнейшем каждый раз вносить изменения и дополнения в два отдельных фрагмента кода приводит к снижению эффективности и увеличению вероятности ошибок. Во-вторых, разработанные по отдельности мобильная и немобильная версии продукта часто оказываются настолько непохожими друг на друга, что это приводит к неорганичности пользовательского опыта, вызывая у клиентов непонимание и раздражение.

Поскольку разработка дизайна для экранов маленького размера является более сложной из-за нехватки свободного места, многие команды разработчиков придерживаются правила: «сначала – мобильные устройства» и начинают с создания версии дизайна, заточенной под самый маленький экран. Это заставляет их сразу расставлять приоритеты. После того как мобильный дизайн оказывается в достаточной степени проработан, они переходят к созданию версии дизайна для экранов больших размеров, на которых могут с легкостью поместиться дополнительные элементы контента и функциональности. Обратите внимание: речь идет не о том, что эти две версии должны разрабатываться последовательно или по отдельности. Работа должна вестись параллельно; просто мобильный дизайн «рулит» этим процессом. Довольно часто вместо того, чтобы быть просто уменьшенной копией полноразмерного продукта, мобильная версия обладает уникальной функциональностью, которой нет у веб-продукта (например, позволяет использовать возможности геолокации или других датчиков, присутствующих в мобильных устройствах). Или же она может предлагать более специализированное подмножество полного функционала веб-продукта. В любом случае, параллельная разработка помогает гарантировать, что версии продукта, предназначенные для использования на устройствах с различными размерами экрана, работают согласованно и создают пользовательский опыт, обеспечивающий соответствие продукта рынку.

Копирайтинг также является частью UX-дизайна

Прежде чем завершить эту главу, необходимо упомянуть о еще одной, часто упускаемой из виду компоненте пользовательского опыта: копирайтинге. Сюда относится создание любого текста, который видят клиенты, причем как на маркетинговых страницах, так и внутри самого продукта. Использование недостаточно качественных текстов на маркетинговых страницах может привести к значительному снижению конверсии. В свою очередь, тексты, которые вы используете внутри продукта – этикетки, инструкции, описания и сообщения об ошибках, – оказывают существенное влияние на удобство использования. Обычно в распоряжении пользователя имеется не так много подсказок, поэтому надписи на кнопках и ссылках должны быть абсолютно ясными и понятными. У вашего продукта будут серьезные проблемы с юзабилити, если пользователь, желая выполнить какое-то важное действие, сомневается, какую именно кнопку ему следует для этого нажать. Описания функций и инструкции пользователя должны быть написаны простым языком с использованием понятных слов, а не внутреннего или отраслевого жаргона. Сообщения об ошибках должны быть полезными и разъясняющими, а не вызывающими лишь новые вопросы. Хорошей новостью является то, что ошибки, допущенные при копирайтинге, можно относительно легко выявить и исправить; достаточно провести юзабилити-тесты продукта. Если в процессе тестирования пользователи испытывают трудности с пониманием определенного слова или фразы, разумно будет попросить их предложить свой вариант формулировки. Довольно часто таким образом можно получить отличные предложения.

«Команда “А”»

Как вы могли заметить по количеству тем, рассмотренных в данной главе, UX-дизайн подразумевает применение множества различных навыков. У многих компаний наблюдается «пробелы в дизайне» из-за нехватки специалистов, участие которых является необходимым для создания превосходного UX-дизайна. Во многих командах разработчиков дизайнеры просто отсутствуют. И даже если у вас есть дизайнер, он, вполне возможно, не владеет всеми аспектами UX-дизайна. Чаще всего такой специалист бывает силен либо в визуальном дизайне (в том, как выглядит продукт), либо в интерактивном дизайне (в том, как продукт работает). Для создания превосходного пользовательского опыта ваша команда должна быть талантливой в каждой из этих областей. Кроме этого, вам потребуется фронтенд разработчик, который сможет грамотно реализовать созданный дизайн, а также сильный менеджер по продуктам. Помимо того, что каждый член команды в отдельности обладает необходимыми навыками, крайне важно чтобы они могли эффективно работать вместе. Я называю команды, обладающие всем этим набором из четырех основных навыков – продакт-менеджмент, интерактивный дизайн, визуальный дизайн и фронтенд-разработка – «Командой “А”» (как в популярном сериале 1980-х годов)[17]. Очевидно, что для создания успешного продукта важны также и другие роли или навыки: бэкенд-разработчики, специалисты по обеспечению качества (QA), DevOps-инженеры и так далее. Но в деле создания превосходного пользовательского опыта наличие «команды “А”» имеет решающее значение.

UX – это то, что видит пользователь

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

Глава 9

Тестирование минимально жизнеспособного продукта (MVP) на пользователях (Шаг 6)

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

Количественные тесты, такие как A/B или лендинг-тесты, относительно просты в проведении и анализе, поскольку они не предусматривают общение с пользователями. В этом случае речь идет только о «сухих цифрах». Вы отслеживаете коэффициент конверсии (или другой интересующий вас показатель) для тестируемого MVP и смотрите, как он соотносится с целевым значением, представляющим успешный результат, или с соответствующими показателями продуктов-аналогов. При этом важно помнить об объеме статистической выборки, так как это напрямую влияет на степень достоверности получаемых результатов.

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

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

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

Сколько пользователей нужно привлечь к тестированию?

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

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

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

Команды, работающие над созданием продукта, часто спрашивают: «Сколько пользователей необходимо привлечь для проведения тестирования?» Вопрос закономерный. Если вы опросите слишком мало людей, то рискуете не уловить все проблемные вопросы, на которые вам необходимо найти ответы. Кроме того, вы можете принять во внимание мнения, которые на самом деле не являются репрезентативными, но не осознавать, что это так. С другой стороны, общение со слишком большим количеством пользователей требует дополнительного времени и ресурсов. Вы можете перейти количественную грань, за которой последует уменьшение отдачи – когда вы будете продолжать выслушивать одни и те же отзывы, не получая никакой новой информации. Я обнаружил, что тестирование раундами с участием пяти-восьми пользователей обеспечивает хороший баланс. Такого количества участников тестов достаточно, чтобы выявить основные проблемы и закономерности мнений разных пользователей. После проведения каждого раунда тестирования вы должны пересматривать свой продукт или дизайнерский проект на основе полученных результатов. Затем измененный продукт следует вновь вынести на суд пользователей в рамках нового раунда тестирования, и так до тех пор, пока вы не убедитесь, что продукт соответствует рынку.

Повторюсь, вы должны быть готовы к тому, что некоторые пользователи не явятся для участия в тестировании. Средний показатель неявки обычно составляет около 10 %. Эту проблему можно решить, просто приглашая на одного участника больше запланированного количества. Например, если мне требуется опросить семь человек, то с целью подстраховаться на случай неявки я назначаю встречи с восемью участниками.

Очное, дистанционное и немодерируемое тестирование с участием пользователей

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

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

Конечно, иногда бывает трудно найти целевых пользователей для проведения очного тестирования. В этом случае на выручку приходит дистанционный модерируемый формат, позволяющий связаться с участниками там, где они находятся. Хотя этот способ и не так хорош, как очное тестирование, вы все равно можете получить с его помощью ценную информацию. Чтобы видеть экран пользователя вам потребуется специальное приложение, такое как GoToMeeting, WebEx, Skype, Screenleap или join.me. Соответственно, вы должны быть готовы столкнуться с техническими трудностями. Для вас не должно стать сюрпризом, что, в тот момент, когда вы будете готовы начать удаленный сеанс, выяснится, что клиенты не установили программное обеспечение, необходимое для предоставления доступа к своему экрану, или им нужна помощь в его настройке. Кроме того, приложение, обеспечивающее совместное использования экрана, может мешать тестированию, например внося путаницу в действия пользователей или искажая размеры элементов дизайна продукта. Помехами могут стать также плохое качество связи, приводящее к задержкам отображения на вашем экране действий пользователя, и использование брандмауэров. Однако, если не принимать во внимание возможные технические трудности, дистанционное тестирование с модерацией может снабдить вас большим объемом ценной информации от пользователей.

Третий способ – немодерируемое дистанционное тестирование – проводится с помощью таких сервисов, как UserTesting или Validately. Они позволяют обеспечить доступ клиентов к артефактам проектирования и фиксируют их действия. Многие из таких сервисов, помимо технического решения, готовы предложить услуги по формированию группы пользователей для участия в тестировании вашего продукта. Одним из преимуществ такого подхода является более быстрое получение результатов: вам не приходится тратить время на поиски и сборы пользователей; несколько участников могут проходить тестирование одновременно, не будучи зависимы от доступности модератора. Однако в этом случае вы не находитесь рядом, а значит, не можете наблюдать за пользователем по ходу выполнения теста. Поскольку в этом случае пользователь следует письменным инструкциям, вам приходится тратить больше времени на разработку процесса тестирования и подробных указаний по прохождению его этапов. В таких случаях рекомендуется провести пилотный тест с одним или двумя участниками, прежде чем запускать тестирование на большой группе пользователей. Кроме того, отсутствие модератора означает, что он не сможет задавать попутные вопросы типа «А почему вы нажали эту кнопку?». Вы должны заранее подготовить полный список вопросов, на которые хотели бы получить ответы, из-за чего придется уделить большее внимание их формулировкам по сравнению с модерируемым вариантом тестирования.

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

Одним из преимуществ немодерируемого тестирования является отсутствие риска влияния модератора на результаты. Действительно, в этом случае клиенты оценивают продукт на основании полностью самостоятельного его использования – то есть в условиях, максимально приближенных к реальной ситуации. Замечено, что большинство участников тестирования в присутствии модератора проявляют большее усердие при выполнении тестов.

Итак, какой же метод тестирования вы должны выбрать? Когда вы только начинаете проверку своего MVP, модерируемое тестирование будет лучшим выбором, поскольку оно позволяет задавать вопросы и получать исчерпывающие отзывы от пользователей. Как я уже подчеркивал, очное тестирование подходит идеально, если удается собрать целевых пользователей. В противном случае на этом этапе следует использовать дистанционное модерируемое тестирование. Когда вы продвинетесь дальше и почувствуете большую уверенность в своем MVP, немодерируемое тестирование может стать полезным инструментом в дополнение к модерируемому, поскольку оно занимает меньше времени и обходится дешевле. По этим же причинам немодерируемое тестирование является хорошим вариантом, если у вас нет ресурсов для проведения тестов с участием модератора.

Как отобрать для тестирования целевых потребителей

Конечно, вы хотите быть уверены в том, что пользователи, на которых вы тестируете свой продукт, являются представителями целевой аудитории. В противном случае полученная обратная связь может вас дезориентировать. Для отбора участников тестирования используют скрининг – некое подобие анкеты, набор вопросов, которые вы задаете кандидатам. Например, если для вашего исследования требуются мнения молодых мужчин, при отборе вы будете задавать вопросы о возрасте и поле. При этом для каждого вопроса вы подготавливаете несколько вариантов ответов и решаете, какие из них указывают на соответствие респондента вашим требованиям, а какие исключают его из числа представителей целевой аудитории. В Главе 3 обсуждались различные типы атрибутов, которые могут использоваться для идентификации целевого потребителя.

Как правило, в дополнение к демографическим поведенческие атрибуты имеют не менее важное значение. Например, если вам для тестирования требуются заядлые любители видеоигр, логично было бы спрашивать респондентов: «Играете ли вы в видеоигры?» – отфильтровывая тех, кто выбрал ответ «нет». Затем вы могли бы спросить ответивших «да»: «Сколько часов в неделю вы обычно играете в видеоигры?» При этом респондентам предлагалось бы сделать выбор из списка возможных вариантов ответов. Например таких: «менее пяти часов в неделю», «от 5 до 10 часов в неделю», «от 10 до 20 часов в неделю», «от 20 до 30 часов в неделю» и, наконец, «более 30 часов в неделю». Вы можете решить для себя, что геймерами вы признаете тех, кто играет не менее 20 часов в неделю. Соответственно, в список участников вашего тестирования попадут только те, кто выбрал какой-то из двух последних вариантов ответа.

Психографические атрибуты – мнения и чувства пользователей – также могут быть полезны для скрининга. При отборе все той же целевой аудитории одним из возможных психографических вопросов мог бы быть такой: «Считаете ли вы себя заядлым геймером?» Или вы могли бы спросить: «Насколько вам нравится играть в видеоигры?» – и предложить цифровую шкалу для ответа.

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

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

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

Один из способов заключается в привлечении местных пользователей вашего продукта путем размещения онлайн-объявлений на Craigslist, TaskRabbit и им подобных веб-сайтах. Рекомендуется включать в объявление ссылку на онлайн-опрос, размещенный на SurveyMonkey, Google Forms или других опросных сайтах, содержащий подготовленные вами вопросы для фильтрации участников. Количество откликов может сильно варьироваться в зависимости от места публикации объявления и размера предлагаемого вознаграждения.

Если количество откликов вас не устраивает, можно прибегнуть к практике дистанционного тестирования, которое позволяет выйти за пределы местного рынка и привлечь любого онлайн-пользователя. Некоторые компании используют Mechanical Turk от Amazon (MTurk) в качестве инструмента для набора участников дистанционного тестирования. Там есть несколько сервисов, которые упрощают эту задачу. Многие приложения для дистанционного тестирования, такие как UserTesting, показывают профили пользователей, доступных для участия в тестировании. При этом объем доступной информации о потенциальных участниках может различаться. Некоторые сервисы предоставляют лишь общие данные, такие как пол, возраст, статус занятости и так далее; в то время как другие позволяют вам задавать пользователям свои собственные вопросы. При выборе приложения для удаленного тестирования убедитесь, что данный сервис предоставляет вам достаточную свободу в выборе задаваемых вопросов. Получение отзывов от клиентов, которые не относятся к целевому рынку – это пустая трата времени и денег, которая к тому же может увести вас в неверном направлении.

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

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

Существуют также компании, постоянно занимающиеся исследованием потребителей. Многие из них имеют постоянную аудиторию, из которой они могут набирать кандидатов для участия в очном тестировании. Такие компании часто предлагают комплексные услуги, которые включают в себя предоставление средств тестирования и модератора, но обычно вы можете просто заплатить им за подбор участников тестирования по указанным критериям. Цена за каждого респондента может варьироваться, но обычно составляет от 75 до 150$. Если ваши целевые клиенты относительно малочисленны и высоко ценят свое время – скажем, кардиохирурги или руководители компаний, – их привлечение может обойтись намного дороже или просто оказаться невозможным. По моему опыту, обращение в исследовательские компании – отличный способ привлечь местных пользователей для участия в очном тестировании. Главным недостатком является стоимость. Но получение ценной обратной связи часто с лихвой компенсирует затраты, особенно если вы хорошо поработали при подготовке скрининга и провели удачное тестирование.

Как избежать ловушки планирования

Довольно часто я сталкиваюсь с тем, что многие компании, которые хотят проводить тестирование на пользователях, испытывают трудности с логистикой планирования. Команды, работающие над продуктом, большую часть своего времени трудятся, не поднимая головы, над определением ценностного предложения, написанием пользовательских историй и разработкой вайрфреймов. Когда они оказываются готовы протестировать результат своего труда на пользователях, они, наконец, отрываются от созидательной работы и пытаются на скорую руку собрать пользователей. Однако набрать подходящих пользователей по щелчку пальцев обычно не получается. К этому моменту команда разработчиков, скорее всего, еще даже не задумывалась о скрининге или сценарии для тестирования. Если у команды нет специального сотрудника, занимающегося отбором и привлечением участников тестирования, эти обязанности часто ложатся на плечи продакт-менеджера или дизайнера. При этом у обоих и без того полно работы. Может пройти неделя или две (или больше), прежде чем все будет готово для проведения первого раунда тестирования. За это время команда, которая, скорее всего, находится под жестким прессингом со стороны требующего результатов руководства, поддается давлению и приступает к разработке высокоточного дизайна или даже написанию программного кода. Таким образом, к моменту получения результатов тестирования на пользователях, возможность безболезненного внесения в продукт каких-либо изменений будет упущена. После завершения одного или двух этапов разработки история с запаздывающим тестированием повторяется. Это в итоге ведет к полному разочарованию – сокращению итераций или даже полному отказу от проведения тестов на пользователях.

Как должна поступать команда разработчиков, придерживающаяся принципов бережливого производства?

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

Тестирование на посетителях Starbucks

Если вы сторонник партизанской тактики, вам подойдет вариант, который я называю «тестированием на посетителях Starbucks». Суть данного метода заключается в том, что вы проводите тестирование, набирая для него участников прямо в кафе. Его основными преимуществами являются низкая стоимость и оперативность. Главный же недостаток такого тестирования заключается в том, что в этом случае вы не можете контролировать принадлежность его участников к целевой аудитории. Конечно, если ваш продукт так же популярен, как, скажем, Google или Facebook, вполне вероятно, что, даже не выходя из кафе, вы сможете найти достаточное число представителей целевого рынка. Однако такой подход, скорее всего, не сработает, если речь идет о тестировании более специфического продукта. Вы можете лишь попытаться провести визуальный отбор потенциальных потребителей на основании их внешнего вида (например, по полу, примерному возрасту, стилю одежды, и т. п.).

Будьте готовы к изрядному количеству отказов; многим людям не нравится, когда к ним обращаются незнакомцы, или же они могут быть слишком заняты. Лично я считаю хорошей альтернативой кафе торговые центры, поскольку там люди кажутся менее занятыми и более открытыми. При этом решающее значение для получения согласия на участие в тестировании от незнакомого вам человека имеет ваша вступительная фраза. Возьмите за правило быстро информировать людей о том, что вам от них требуется, и какую компенсацию вы можете предложить за потраченное ими время. Например, вы можете использовать следующую фразу: «Здравствуйте, не найдется ли у вас 10 минут, чтобы поделиться своим отзывом о новом веб-сайте в обмен на карточку Starbucks стоимостью 25$?»

Оплата участия в тестировании

Кстати, об оплате. Сколько вы должны заплатить участникам тестирования за потраченное ими время? Обычно диапазон размера вознаграждения составляет от 75 до 125$ за час, но многое зависит от того, кто является вашими целевыми клиентами, и сколько стоит их время. Интервью с кардиохирургом, вероятно, обойдется вам гораздо дороже названных выше сумм, в то время как беседа со старшеклассником стоила бы гораздо дешевле. Многие изобретательные стартапы умудряются нанимать тестировщиков без выплаты какой-либо денежной компенсации, просто находя людей, проявляющих повышенный интерес к их продукту. Я, как и многие другие разработчики, использовал в качестве «заманушного пряника» эксклюзивный доступ к бета-версии продукта. Если у вашей компании есть возможность использовать в качестве вознаграждения свои «мерчи» (например, футболки, толстовки с капюшоном или спортивные куртки с вашей символикой), это тоже может сработать.

Для непосредственной оплаты труда тестировщиков существует несколько подходящих вариантов. Например, довольно удобным для обеих сторон средством платежа являются подарочные карты, поскольку их легко купить и использовать. При этом универсальная подарочная карта, такая как Visa или MasterCard, более привлекательна, чем сертификат конкретного магазина. Но, если вы проводите тестирование пользователей в Starbucks, то подарочная карта этого кафе вполне подойдет. Безусловно, прекрасно работает оплата наличными, однако получить их со счета компании может быть непросто из-за ограничений, относящихся к правилам ведения бухгалтерского учета. Если вы проводите тестирование на пользователях, уже являющихся вашими клиентами, то хорошей альтернативой денежной выплате может быть предоставление им скидки на оплату ваших услуг или будущих покупок.

Тестирование на пользователях в компании Intuit

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

Впрочем, далеко не всегда является возможным или экономически оправданным идти туда, где находятся ваши пользователи; иногда имеет смысл, чтобы они сами приходили к вам. Компания Intuit создала ультрасовременную лабораторию юзабилити с несколькими помещениями для проведения тестов. Мы приглашали пользователей в эту лабораторию для проведения тестирования программного обеспечения по ходу его разработки. Модератор оставался в специальной комнате один на один с участником тестирования, но мы имели возможность наблюдать за происходящим благодаря встроенному в стену одностороннему зеркалу. Установленные в лаборатории камеры были направлены на экран компьютера, а также на лицо пользователя и передавали видеоизображение на мониторы в задней комнате.

Тестирование на пользователях по методу «Рамэн»

Лаборатория юзабилити Intuit производила неизгладимое впечатление, и мне как менеджеру по продуктам компании было интересно пользоваться предоставляемыми ей возможностями. Но на самом деле для проведения тестирования на пользователях иметь такое мощное оснащение вовсе не обязательно. С тех пор как я покинул Intuit, я работал во многих стартапах, которым обычно приходится быть гораздо более разборчивыми в своих расходах из-за ограниченности финансовых ресурсов. Я помогал им в проведении того, что я называю тестирование на пользователях по методу «Рамэн»[18]. Этот метод исключает все, кроме самых необходимых составляющих пользовательского тестирования. Вместо выделенного и специально подготовленного помещения вы используете конференц-зал в своем офисе. Вместо того чтобы нанимать профессионального модератора, кто-то из вашей команды (обычно это менеджер по продукту или дизайнер) берет на себя его функции. Если вы никогда не проводили тестирование, я рекомендую обязательно попробовать. Мой опыт подсказывает, что многие люди, которых изначально пугает идея примерить на себя роль модератора пользовательского тестирования, на самом деле просто нуждаются в небольшом поощрении. Это не ракетостроение – как и в большинстве других сфер, нужна лишь некоторая практика, чтобы в достаточной степени освоить этот навык. Однако необходимо учесть тот факт, что пытаться модерировать и одновременно делать заметки может оказаться непростой задачей, поэтому я рекомендую разделить эти обязанности между двумя сотрудниками.

Если это возможно, попросите участников захватить на тестирование ноутбук или другое устройство, которое они используют для работы с продуктом. Как правило, это дает намного лучший результат, чем в том случае, когда клиенты вынуждены использовать во время тестирования устройство, с которым они не знакомы. Я не раз наблюдал, как различия в операционной системе (Windows или Mac), клавиатуре, мыши или браузере заставляют пользователей нервничать и тем самым мешают тестированию. Напротив, весьма приятно наблюдать за тем, как клиенты используют ваш продукт на тех устройствах, которыми они пользуются дома или на работе. При этом вы даже можете выяснить для себя что-то новое, с чем не сталкивались в ходе внутренних обсуждений и тестов.

Я рекомендую модератору и записывающему во время сеанса сидеть за столом рядом с пользователем (по бокам от него). Это позволяет вам смотреть в одну сторону и видеть все происходящее на экране. Кроме того, в этом случае вы сможете наблюдать за его мимикой и улавливать другие малозаметные сигналы.

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

Некоторые члены команды могут выражать желание посмотреть процесс тестирования не в режиме реального времени, а в записи. За свою карьеру я участвовал в огромном количестве тестирований, но никогда не видел, чтобы кто-то действительно просматривал такие записи. Если кто-то из членов вашей команды недостаточно мотивирован, чтобы присутствовать на тестировании лично, у него не появится достаточной мотивации и для того, чтобы потратить время на просмотр записи. Кроме того, многим участникам тестирования не нравится сама идея стать героем хранящейся где-то видеозаписи. Так что, если ваша команда видит в этом реальную необходимость и действительно собирается просматривать записи тестирования, тогда дерзайте – при условии, что пользователь даст на это свое согласие. В противном случае отбросьте эту идею и сосредоточьте все свое внимание на тестировании, происходящем в реальном режиме времени.

Как структурировать процедуру тестирования

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

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

Пользовательские тесты обычно длятся около часа, плюс-минус 15 минут. Это время может быть увеличено, если пользователь в восторге от продукта и дает вам много полезных отзывов. Я рекомендую потратить первые 10–15 минут сеанса на разогрев пользователя и выяснение его потребностей, а также того, какими решениями он пользуется в настоящее время. Затем я трачу от 40 до 45 минут на получение его отзывов о тестируемом продукте или артефактах дизайна. Заключительные 5-10 минут я отвожу на подведение итогов, во время которого отвечаю на вопросы пользователя и сам задаю вопросы, которые у меня остались.

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

Важно, чтобы во время проведения теста пользователь озвучивал свои мысли так, чтобы вы могли это услышать. У некоторых людей есть естественная склонность к проговариванию, в то время как другие, являясь по своей природе более замкнутыми, предпочитают оставлять свои мысли при себе. Чтобы убедиться в том, что вы получаете достаточно полную обратную связь, рекомендуется побуждать пользователя делиться своими мыслями вслух по мере их возникновения (то есть озвучивать поток сознания) на протяжении всего сеанса. Если пользователь продолжает молчать после вашей просьбы, нужно повторить ее еще раз.

Все перечисленные советы позволяют повысить шансы на получение ценной обратной связи, однако результат не гарантирован. Несмотря ни на что, некоторые люди так и не скажут ни слова критики о продукте, а другие дадут вам слишком мало. Вы можете обнаружить, что около 10 % участников тестирования окажутся «бесполезными». Если вы не получаете качественной обратной связи от значительного числа приглашенных на тестирование пользователей, вам стоит пересмотреть свои критерии отбора участников, тестовый скрипт или кандидатуру модератора – поскольку отсутствие нужного результата является признаком того, что что-то из перечисленного (если не все) явно нуждаются в улучшении.

Как задавать правильные вопросы

Ознакомительные вопросы отлично подходят для изучения проблемного пространства и формирования ценностного предложения с помощью пользователей. Вы можете начать интервью с вопроса о текущих потребностях участника, а также выяснить его мнение о ключевом преимуществе, которое вы планируете предоставить своим продуктом. Например, если бы вы были сотрудником Uber, то могли бы начать с того, что спросили бы, как часто участник тестирования пользуется услугами такси, какие виды поездок совершает и как находит такси, когда оно ему нужно. Вы также могли бы попросить подробно рассказать о недавнем опыте пользования данной услугой. Затем вы могли бы поинтересоваться, что ему нравится и что не нравится в существующих рыночных предложениях, а также выяснить общий уровень удовлетворенности услугами такси. Обратите внимание: до этого момента вы еще ни разу не упомянули про Uber. Вы просто пытаетесь понять потребности клиентов, то, каким образом они решают свои проблемы в настоящее время, что им в этом нравится, а что нет, и насколько они удовлетворены получаемым результатом. Таким образом, вы пытаетесь собрать качественную информацию, которую сможете использовать для подтверждения своих гипотез о целевом потребителе и ценностном предложении. Кроме этого, ознакомительные вопросы помогают плавно погрузить пользователя в контекст продукта еще до того, как предъявите его для тестирования.

Далее вы переходите к той части пользовательского тестирования, целью которой является получение обратной связи о продукте. На этом этапе задача модератора состоит в том, чтобы эффективно запрашивать отзывы пользователей, при этом никак не влияя на их содержание. Лучший способ исказить результаты состоит в том, чтобы задавать наводящие вопросы, такие как «Эту форму было легко заполнить, не так ли?» или «Вам ведь захотелось нажать здесь кнопку “Купить”?». Модераторы, которые задают подобные риторические и/или наводящие вопросы, больше заботятся о получении положительной оценки продукта вместо реальной и объективной обратной связи. Смысл тестирования продукта на пользователях не в том, чтобы заставить их похвалить вашу работу, а в том, чтобы получить достоверные отзывы от реальных клиентов. Степень объективности результатов, полученных в ходе тестирования, в огромной степени зависит от модератора. Понятно, что иногда бывает слишком трудно оставаться беспристрастным, тестируя продукт, над которым вы так долго и усердно работали, но это именно то, к чему следует стремиться. Лучшие модераторы знакомят пользователя с продуктом, не допуская личного вмешательства, насколько это только возможно. Они воздерживаются от каких-либо комментариев и оценок, ограничиваясь наблюдением и вопросами.

Если пользователь выполняет какие-либо действия с прототипом, не комментируя при этом, что и почему он делает, модератору следует побудить его дать объяснения, например, таким вопросом: «Я вижу, вы только что нажали на эту кнопку. Не могли бы Вы объяснить, почему?» Обратите внимание, что, вместо того чтобы просто спросить пользователя «почему?», модератор начал с описания того, что он заметил. Такое «обратное эхо» – мощный метод, позволяющий убедиться, что вы понимаете пользователя, и выяснить всю подоплеку его действий. Например, если пользователь отвечает: «Я нажал эту кнопку, потому что искал [_____]», модератор может задать следующий вопрос: «Почему вы искали [_____]?» Это напоминает метод «Пяти почему». Однако, если пользователь будет слышать вопрос «почему?» слишком часто, это может заставить его почувствовать себя защищающимся. Поэтому неплохо бы разбавлять это слово другими фразами, такими как «Не могли бы Вы рассказать мне об этом подробнее?», «Не могли бы Вы помочь мне понять [_____]?» или «О чем Вы подумали, когда делали [_____]?».

Обычно участники тестирования и сами задают вопросы модератору. Например, пользователь может спросить: «Должен ли я нажать эту кнопку, чтобы войти в систему?» Вместо ответа «да» или «нет» хороший модератор мог бы задать встречный вопрос: «А как Вы думаете, что произойдет, если нажать эту кнопку? – или просто сказать – Делайте все так, как будто рядом никого нет». Хорошие модераторы часто пользуются методом ответа вопросом на вопрос.

Открытые и закрытые вопросы

Существует значительная разница между открытыми и закрытыми вопросами. Открытые вопросы предоставляют пользователю большую свободу в ответе. Обычно они начинаются со слов: «почему», «как» и «что». В отличие от них, закрытые вопросы ограничивают возможные ответы (например, вариантами: «да» или «нет»). Задавать во время тестирования закрытый вопрос: «Выбираете ли вы рейс для бронирования билетов, исходя из цены?» – не будет настолько полезно, как если вы спросите: «От чего зависит ваш выбор рейса?» Закрытые вопросы часто начинаются с «Делаете ли вы…», «Есть ли у вас…» или «Хотели бы вы…». Выбор между открытым и закрытым вопросом зависит не столько от предвзятости модератора, сколько от уровня его квалификации. В обычной беседе, когда вы не выступаете в роли модератора, закрытые вопросы вполне уместны. Но при проведении тестирования их следует избегать. В этом может помочь включение списка предполагаемых вопросов в тестовый скрипт. Но хороший модератор должен уметь оперативно формулировать открытые вопросы (например, в ответ на что-то, что пользователь сделал или сказал). Полезный прием – выработать привычку проговаривать свой следующий вопрос в уме, прежде чем его озвучить. Тогда, если пришедший в голову вопрос окажется закрытым, у вас будет возможность переформулировать его прежде, чем он прозвучит.

Еще одна ошибка, которой следует избегать, заключается во включении в вопрос предпочтительного или возможного варианта ответа. Обычно такой вопрос начинается как открытый, но затем превращается в закрытый. Например: «Как бы Вы хотели, чтобы приложение сортировало Ваши транзакции? По дате?» Иногда неопытные модераторы не могут удержаться и добавляют к основному вопросу то, что, по их мнению, является наиболее вероятным ответом. Теперь, даже если пользователь собирался дать другой ответ, он может сказать «да» просто потому, что вы только что предложили свой вариант. Иногда это происходит из-за того, что модератор пытается «облегчить» пользователю задачу. Вы должны быть готовы к тому, что пользователю требуется время на осмысление увиденного и обдумывание своего ответа. Хотя такие длительные паузы выглядят неловкими в обычном разговоре, при проведении пользовательского тестирования они вполне уместны. Не стоит пытаться заполнить их, предлагая подсказки или свой вариант ответа. Задав свой вопрос, просто подождите, оставляя его открытым и обеспечивая пользователю свободу в выборе ответа. Часто это окупается тем, что вы узнаете вещи, которые ранее не приходили вам в голову. Это прекрасно (и может быть забавным) – пытаться предугадать ответ пользователя; и все же, во время тестирования необходимо держать свои предположения при себе, не высказывая их вслух.

Повторюсь, ваше вмешательство в процесс тестирования должно быть минимальным. Вы начинаете с показа пользователю конкретной части продукта или артефакта, в отношении которой хотели бы получить его отзыв; но сразу после того, как вы это сделаете, необходимо предоставить ему полную свободу действий. Пользователь может, взглянув на первую страницу, задать вопрос: «Так, и что мне теперь делать?» Я обычно отвечаю на это: «Представьте, что меня здесь нет. Просто поступайте так, как будто друг посоветовал Вам ознакомиться с этим продуктом, и Вы делаете это дома за своим компьютером». Если пользователь не выражает свои мысли словами, следует попросить его об обратной связи. Например, спросив: «Каковы ваши впечатления от этой страницы?»

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

Когда пользователь в процессе тестирования продукта делает свои комментарии, вы, при наличии такой необходимости, можете и должны задавать ему уточняющие вопросы. Например, если пользователь после заполнения формы говорит: «Это было довольно сложно», – вам следует развить эту тему, например, спросив: «Не могли бы Вы пояснить, что именно вызвало сложности с заполнением?» или предложив: «Пожалуйста, расскажите об этом подробнее».

Принимайте реальность такой, как она есть

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

Нечасто, но я все же становился свидетелем ситуаций, когда модераторы в ответ на критику со стороны пользователей, занимали оборонительную позицию и пытались оспаривать их мнение, или даже обвиняли пользователя в неправильных действиях. Такое поведение непродуктивно и непрофессионально. Если пользователь не смог разобраться в продукте, очевидно, что в этом вина разработчиков, а не пользователя.

Завершение тестирования

Подведение итогов тестирования начинается после завершения работы пользователя с продуктом. Это самый подходящий момент для того, чтобы попросить участников поделиться своим мнением обо всем, что они увидели, а также озвучить свои общие впечатления. Возможно, вы захотите, чтобы пользователи оценили продукт в баллах. Например, вы могли бы спросить: «По шкале от 0 до 10, где 10 – это лучшая оценка, насколько полезным вы считаете это приложение?» или «Исходя из того, что вы сегодня увидели, насколько вероятно, что вы воспользуетесь этим приложением?». Вы также могли бы спросить: «Насколько просто было пользоваться приложением?» Вы можете задать свой вопрос устно или предоставить пользователю краткую форму для заполнения, что, кстати, способствует получению менее предвзятых результатов. По мере прохождения итераций, улучшающих прототип MVP, вы сможете наблюдать, как меняются оценки пользователей при ответах на те же вопросы.

Заключительный этап тестирования наилучшим образом подходит и для ответов на любые вопросы, как возникавшие во время тестирования, так и появившиеся у пользователя по его завершении. Если в процессе тестирования у пользователя возникли проблемы из-за известных разработчикам ошибок или неполадок, вы можете разъяснить ему эти моменты. По окончании сеанса вы также должны будете предоставить участникам подготовленное вознаграждение за потраченное ими время и поблагодарить их. Обычно я прошу пользователей подписать специальную форму, подтверждающую получение платежа. В этой же форме я предлагаю каждому участнику, по желанию, указать свой адрес электронной почты и номер телефона. Я также включаю туда два быстрых вопроса с вариантами ответа «да/нет»: «Хотели бы вы принять участие в будущих исследованиях?» и «Хотели бы вы получить уведомление, когда приложение появится в продаже?». Оба вопроса, на самом деле, являются скрытной проверкой степени заинтересованности. Если пользователь в ходе тестирования давал продукту исключительно положительные отзывы и оценки, но не дает ответ «да» на эти последние два вопроса, значит, в своей обратной связи он просто был излишне вежлив.

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

Как собирать и обобщать отзывы пользователей

В процессе тестирования вы пытаетесь получить сведения, которые подтверждают или опровергают гипотезы, выдвинутые вами на этапе подготовки кандидата в MVP: о целевых потребителях, их недостаточно удовлетворенных потребностях, отличительных особенностях вашего ценностного предложения и так далее. Получаемая от пользователей обратная связь будет касаться трех компонентов продукта: функциональности, пользовательского интерфейса и целевого месседжа. Отзывы о функциональности показывают, обеспечивает ли MVP нужные клиентам преимущества или нет. Пользователи могут пожаловаться на отсутствие какой-либо ключевой функции или сообщить, что какая-то из имеющихся функций, для них не важна. В таких случаях следует сопоставить полученную информацию с преимуществами и ценностным предложением продукта. Возможно, в нем на самом деле имеется нужный функционал, обеспечивающий требуемые преимущества, но плохо прописанный пользовательский интерфейс не позволяет пользователям оценить его в полной мере. Наконец, у продукта могут быть и все необходимые пользователю функции и дружественный интерфейс, но то, как вы подаете свой продукт и рассказываете о его возможностях и преимуществах – ваш целевой месседж – может не найти отклик у потребителя. Когда вы получаете от пользователей критические или положительные отзывы, бывает весьма полезно сопоставить их с тремя перечисленными высокоуровневыми категориями: функциональностью, UX-дизайном и целевым месседжем. Такая группировка обратной связи по результатам тестирования позволяет составить более четкое представление о том, что работает хорошо, а что нет.

Давайте обсудим наглядный пример фиксации пользовательских отзывов. В таблице 9.1 приведены сводные результаты тестирования с участием пяти пользователей. Вы можете видеть, что отзывы каждого из участников представлены в отдельном столбце. При этом все отзывы распределены по представленным выше направлениям: функционал, UX-дизайн и целевой месседж. Кроме этого, я включил в сводную таблицу оценки ценности продукта и простоты использования, которые запрашивал от каждого участника по окончании тестирования. Каждому виду как положительных, так и отрицательных отзывов отведена специальная строка. Я помечаю, кто из пользователей оставил соответствующий отзыв, символом «Y» вместо «Да». Это позволяет легко распознать имеющиеся закономерности. В правой колонке приведены сводные результаты с учетом мнений всех пяти пользователей (проценты и медианные оценки). Для простоты я не включил в таблицу те отзывы, повторяемость которых составила менее 40 %.

Таблица 9.1 Отслеживание ключевых результатов пользовательских тестов

Из таблицы вы можете видеть, что на данном этапе тестирования мы получили от пользователей положительные отзывы о функции X, профессиональном дизайне и изображении на домашней странице. Кроме этого, были выявлены четыре проблемы:

• 80 % пользователей пожаловались на отсутствие функции Y;

• 60 % пользователей не нашли ссылку «Зарегистрироваться»;

• У 60 % пользователей возникли трудности с регистрацией;

• 40 % пользователей не поняли наш слоган.

После того как полученная обратная связь будет учтена при улучшении продукта, мы проведем второй раунд пользовательского тестирования, по результатам которого ожидаем и надеемся увидеть прогресс в повышении степени соответствия продукта рынку по всем трем отслеживаемым направлениям. Во-первых, это должно выражаться в увеличении числа положительных отзывов, полученных от большего процента пользователей, особенно в отношении тех аспектов, которые связаны с нашим ценностным предложением. Во-вторых, те негативные отзывы, которые мы получили в ходе первого раунда тестирования, не должны будут появиться вновь. Вы должны понимать, что те пользователи, которые примут участие во втором раунде, не видели более раннюю версию продукта. Поэтому никто из них не скажет вам: «Вы отлично поработали над устранением проблемы [_____]». Таким образом, прогресс, достигнутый в этом направлении, должен отразиться в отсутствии тех же жалоб, которые вы получили в ходе предыдущего раунда тестирования. Третий показатель прогресса – медианные значения пользовательских оценок, относящихся к дополнительным показателям. Мы хотим увидеть, что после улучшения продукта, оценки его ценности и простоты использования (как и любые другие ключевые показатели) стали более высокими.

Юзабилити и соответствие продукта рынку

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

На ранних этапах разработки MVP вы можете получать от пользователей множество критических замечаний, касающихся UX-дизайна. Недостаточно качественное юзабилити часто не позволяет пользователям в полной мере оценить ценность вашего продукта. Вы можете также обнаружить наличие ошибок, мешающих полноценному использованию продукта. Камнем преткновения могут стать и непонятные или не доходящие до пользователя месседжи.

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

Я испытал это на собственном опыте, работая над продуктом, который в режиме реального времени предлагал пользователям новости, подобранные в соответствии с их интересами. В ходе первого раунда тестирования MVP продукта пользователи предоставили нам обратную связь, содержащую ответы на множество вопросов, связанных с удобством использования. Мы также выявили несколько программных ошибок и неоднозначных текстовых сообщений. После того как эти недочеты были исправлены, мы провели второй раунд тестирования, в ходе которого выявили уже меньшее количество проблем, которые также были исправлены. На третьем круге пользовательские тесты стали гораздо более успешными. Большинство пользователей проходили их без проблем, что привело меня в восторг от достигнутого прогресса.

По завершении каждого теста я стал спрашивать пользователей, насколько вероятно, что они воспользуются нашим продуктом. Несмотря на то, что тесты прошли успешно, около 20 % опрошенных заявили, что не будут им пользоваться. Этот результат меня удивил, ведь негативных отзывов в ходе тестирования практически не было. Кроме того, большинство участников тестирования проявляли определенный интерес к продукту, позволявшему получать персонализированную подборку новостей, из чего я сделал вывод, что они достаточно точно соответствуют профилю нашей целевой аудитории. Когда я стал прямо спрашивать «отказников» о причинах, по которым они не стали бы использовать наш продукт, выяснилось, что определенный сегмент пользователей предпочитает получать новости вполне определенным способом. Это было замечательное, неожиданное озарение, которое побудило меня начать спрашивать людей, как именно они предпочитают получать новости. Теперь я задавал этот вопрос в ходе предварительного опроса. В итоге мне удалось обнаружить, что существует три совершенно разных способа, которыми люди предпочитают получать новости, и наш подход к разработке продукта в наибольшей степени соответствовал лишь одному из них. Данное открытие помогло нам лучше разобраться в рыночной ситуации. Онлайн-новости – это базовый потребительский продукт с большой аудиторией пользователей, поэтому неудивительно наличие на этом рынке сегментов с различающимися предпочтениями. Посовещавшись, мы пришли к выводу, что попытка создать проект, который охватывал бы все три различных способа получения новостей, граничит с сумасшествием и не сделает счастливой ни одну из категорий пользователей. Поэтому мы просто использовали полученные знания для уточнения описания нашего целевого потребителя.

Как видите, не только проблемы с юзабилити могут помешать вам оценить соответствие продукта рынку. Даже наличие отменных удобств использования продукта не означает, что он полностью соответствует рынку. Кроме этого, приведенный пример показывает, как тестирование с участием пользователей может помочь подтвердить и уточнить ключевые гипотезы (в данном случае, о том, кто является вашим целевым клиентом).

Тестирование на пользователях – это один из мощнейших инструментов, используемых в бережливом производстве. При правильном его использовании вы можете получить очень ценную обратную связь о своих гипотезах, относящихся к нескольким уровням пирамиды соответствия продукта рынку: недостаточно удовлетворенные потребности, ценностное предложение, набор функций MVP и UX. Однако важно отметить, что тестирование с участием пользователей по своей сути основано на предположении, что вы общаетесь с подходящим типом клиентов. Очень важно убедиться, что опрашиваемые пользователи действительно являются представителями вашего целевого рынка. Вы можете отлично поработать над определением своего ценностного предложения и набора функций MVP, создать потрясающий набор интерактивных вайрфреймов и качественно провести процедуры тестирования. Однако, если вы при этом разговариваете не с теми людьми, вы не получите нужные вам сведения. Хуже того, вы можете получить неверные данные, которые будут сильно отличаться от того, что сообщили бы вам настоящие целевые клиенты. Дальнейшее совершенствование MVP на основе данных, полученных от неподходящего типа пользователей, может направить вас в неверном направлении – вы полетите с обрыва вместо попадания в Землю обетованную соответствия продукта рынку.

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

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

Глава 10

Итерации и развороты на пути к соответствию рынку

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

Цикл: «Создание – Измерение – Обучение»

Эрик Рис в своей книге «Бережливый стартап»[19] (Lean Startup – является зарегистрированной торговой маркой Эрика Риса) обсуждает концепцию итеративного обучения. Описанный им цикл «Создание – Измерение – Обучение» помог многим людям понять важность применения итерационных методов совершенствования и обучения. Но, основываясь на своих наблюдениях за тем, как некоторые люди понимают и пытаются применять данную концепцию на практике, я вижу необходимость в обсуждении некоторых нюансов этой темы.

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

«Измерение», как правило, подразумевает применение числовых данных, но имейте в виду, что в данном случае «мера» не обязательно должна иметь количественное выражение. Многие люди склонны использовать в качестве аргументов числовые показатели. Я согласен, что наличие таких данных весьма полезно, но A/B-тестирование – не единственный способ проверки гипотез или получения ценной информации. Все, что вы узнаете, наблюдая за пользователями, подпадает под понятие «Измерение». Сюда же – несмотря на отсутствие статистической измеримости – относятся и результаты, полученные в ходе качественного тестирования. Ключевым моментом является то, что на этом шаге цикла вы проверяете свои гипотезы на потребителях. Следовательно, термин «Тестирование» был бы более точным для его обозначения.

Шаг «Обучение» вызывает особый интерес. На самом деле, на этом этапе происходят две вещи. Во-первых, вы узнаете что-то новое из результатов каждого теста. Во-вторых, вы используете полученные знания для модификации гипотез, на которых и был построен проведенный вами тест. Чтобы стало понятнее, разделите процесс «Обучение» на два отдельных этапа: «Изучение [результатов тестирования]» и «Выдвижение гипотезы». Если вдуматься, весь этот цикл начинается не с «Создания», а с выдвижения первоначальных гипотез. Иначе как вы смогли бы принять решение о том, что именно вы хотите создать?

Цикл: Гипотеза – Проектирование – Тестирование – Обучение

По вышеуказанным причинам я использую модифицированную версию цикла Создание – Измерение – Обучение, который в моей интерпретации выглядит так: Гипотеза – Проектирование – Тестирование – Обучение (см. Рисунок 10.1).

Рисунок 10.1. Цикл: Гипотеза – Проектирование – Тестирование – Обучение

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

Чем быстрее вы пройдете обучение, тем раньше сможете обеспечить дополнительную потребительскую ценность и достичь соответствия продукта рынку. Но обучение – это всего лишь один из этапов процесса. Чтобы получить дополнительные знания, вам придется снова пройти весь цикл. Если представить его в виде поля для игры «Монополия», то шаг цикла под названием «Обучение» будет соответствовать полю «Старт», которое вы проходите на каждом круге. В игре вы зарабатываете за прохождение этого поля 200$; в процессе разработки бережливого продукта вы получаете новые знания, подтвержденные результатами тестирования. Прохождение этапов «Обучение» и выдвижения «Гипотезы», как правило, не занимает много времени, поэтому скорость прохождения полного цикла обычно зависит от того, насколько быстро вы сможете выполнять «Проектирование» и «Тестирование».

По мере того как вы будете подтверждать или опровергать свои гипотезы и формировать новые, необходимо обращаться к пирамиде соответствия продукта рынку, вновь приведенной на Рисунке 10.2. Для каждой гипотезы вы должны определить, какому слою пирамиды она соответствует. Любой слой пирамиды основывается на гипотезах, сформированных на уровне, расположенном непосредственно под ним. Вносить изменения на уровнях, находящихся вблизи вершины пирамиды, не так уж сложно, в то время как пересмотр гипотез, лежащих вблизи ее основания, может иметь критические последствия для всех верхних слоев. Например, изменение UX-дизайна страницы с целью сделать ее более удобной для использования можно считать незначительным. Но давайте предположим, что ваше ценностное предложение основывалось на гипотезе о неважности некого потребительского преимущества, однако тестирование на пользователях показало, что на самом деле это не так. Теперь вам придется вносить изменения в свое ценностное предложение, что, в свою очередь, повлияет на набор функций MVP и UX-дизайн продукта. Вот почему необходимо в первую очередь сосредоточиться на решении проблем, возникающих на самом низком уровне, обрабатывая ту информацию, которую вы получаете в ходе пользовательского тестирования. Как только вы убедитесь в том, что все проблемы устранены, можно будет перенаправить усилия на решение задач, относящихся к следующему, более высокому уровню.

Рисунок 10.2. Пирамида соответствия продукта рынку

Итеративное пользовательское тестирование

Как я уже указывал в главе 9, каждый пользовательский тест предоставляет ценную информацию о вашем MVP. По завершении каждого раунда тестирования полезно обсудить его результаты с командой разработчиков, чтобы поделиться наблюдениями и обобщить полученные знания. Я рекомендую использовать таблицы (подобные Таблице 9.1) для фиксации ключевых результатов, полученных в каждом раунде пользовательского тестирования.

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

Раунд первый

Давайте вернемся к примеру, который был представлен в главе 9. Для начала мы обобщим результаты первого раунда тестирования с участием пяти пользователей в одном столбце Таблицы 10.1. Вы можете заметить, что я удалил из результатов положительные отзывы. Это сделано для упрощения. Итак, по результатам первого раунда тестирования мы выявили четыре проблемы:

1. 80 % пользователей пожаловались на отсутствие функции Y;

2. 60 % пользователей не нашли ссылку «Зарегистрироваться»;

3. У 60 % пользователей возникли трудности с регистрацией;.

4. 40 % пользователей не поняли наш слоган.

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

Таблица 10.1 Отслеживание результатов нескольких раундов пользовательского тестирования

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

Трудности с регистрацией относятся к проблемам дизайна интерактивности. Для устранения данной проблемы решено изменить процесс регистрации с учетом мнений пользователей.

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

Раунд второй

Теперь, когда четыре проблемы, выявленные в первом раунде, устранены, мы можем вновь провести тестирование нашего продукта на пользователях. Полученные результаты фиксируем в столбце «Раунд 2» Таблицы 10.1. Мы видим, что после добавления функции Y никто из новых пользователей не пожаловался на ее отсутствие, что, конечно же, свидетельствует о значительном прогрессе в этом направлении. Еще одним серьезным достижением является тот факт, что все пять участников второго раунда тестирования на этот раз обнаружили ссылку «Зарегистрироваться».

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

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

Случается, что после устранения одних ошибок, в обновленной версии MVP обнаруживаются новые. Показательный пример: участники второго раунда тестирования были довольны тем, что у нашего MVP появилась функция Y, но 80 % из них указали, что эту функцию сложно использовать. После подробного обсуждения проблемы юзабилити, с которой, по нашим наблюдениям, столкнулись пользователи, мы разработали ряд улучшений для этой функции и соответствующим образом обновили проектные артефакты.

Для нас стал сюрпризом тот факт, что 80 % участников тестирования выразили желание, чтобы функция Y работала совместно с функцией X, тогда как мы считали, что она должна быть автономной. Тщательный анализ показал, что представление пользователей о том, как должны работать эти две функции, имеет глубокий смысл и делает их более полезными. В итоге мы переработали обе функции и обновили проектные артефакты.

При правильном подходе каждое повторение цикла должно приводить к уменьшению масштаба и количества проблем. В данном случае между первым и вторым раундами тестирования мы успешно решили три проблемы: отсутствия функции Y, плохо видимой ссылки «Зарегистрироваться» и неудачного слогана. Мы попытались, но пока безуспешно, решить проблему с процедурой регистрации. И наконец, мы обнаружили две новые проблемы: функция Y сложна в использовании, и она должна работать совместно с функцией X.

Помимо этого, повторение цикла должно приводить к улучшению общих рейтинговых оценок. В данном случае мы видим, что рейтинг ценности продукта увеличился с 7 до 8 – скорее всего, благодаря добавлению функции Y. А оценка простоты использования повысилась с 5 до 6 баллов, вероятно, в результате переноса ссылки «Зарегистрироваться» и частичного улучшения процесса регистрации.

Раунд третий

После обновления проектных артефактов на основе информации, полученной по результатам второго раунда тестирования, мы готовы к проведению третьего раунда. По его окончании мы получили данные, приведенные в столбце «Раунд 3» в Таблице 10.1. Как видите, в этот раз пользователи уже не жаловались на то, что функции X и Y не работают совместно, поэтому нашу цель на этом направлении можно считать достигнутой. Все участники тестирования справились с процедурой регистрации. Таким образом, пусть и со второй попытки, но нам удалось решить и эту проблему. Несмотря на переработку функции Y, 40 % пользователей по-прежнему считают ее сложной в использовании. Конечно, это меньше, чем предыдущие 80 %, но нам все еще предстоит поработать над этой важной функцией.

В результате всех проделанных усовершенствований продукта рейтинг его полезности повысился до 9, а рейтинг простоты использования – до 7 баллов. Из этого следует, что мы добились значительного прогресса с момента создания своего первого MVP. Мы больше не получаем серьезной критики в отношении недостающего функционала. Наши месседжи стали гораздо более доходчивыми. В основном отзывы пользователей теперь говорят о необходимости улучшения UX-дизайна, как это обычно и происходит на ранних этапах разработки продукта.

Я упростил данный пример, включив в него лишь небольшое количество основных элементов обратной связи. На самом деле при проведении тестирования на пользователях мы получаем большое количество незначительных замечаний. Конечно, мы можем и должны внедрять улучшения, направленные на решение и таких проблем. С каждым прохождением цикла «Гипотеза – Проектирование – Тестирование – Обучение» степень соответствия нашего продукта рынку должна повышаться.

Раунд четвертый

На данном этапе мы продолжаем улучшать функцию Y, чтобы упростить ее использование, после чего проводим четвертый раунд тестирования. В столбце «Раунд 4» Таблицы 10.1 можно увидеть, что на этот раз никто из участников не пожаловался на то, что функцию Y трудно использовать. Кроме того, не было обнаружено никаких новых серьезных проблем. Рейтинг ценности продукта остался на том же высоком уровне, а рейтинг простоты использования повысился до 9 баллов.

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

Не существует какого-либо жесткого правила, указывающего, в какой именно момент ваш проект можно будет считать «достаточно протестированным». Безусловно, существует риск продолжения тестирования уже после того, как оно потеряет свою ценность. И наоборот, вы можете запустить кодирование продукта, не доведя его предварительную проверку до нужной степени готовности, что в дальнейшем может привести к необходимости болезненных переделок на уровне проектирования и кодирования. Таким образом, речь идет о необходимости нахождения правильного баланса. Так или иначе, в определенный момент ваш «птенец» должен будет покинуть гнездо; то есть нужно будет прекратить тестирование артефактов проектирования и создать непосредственно MVP. Это захватывающий переход. Он в значительной степени приближает вас к созданию реальной потребительской ценности в виде живого продукта, а также позволяет выйти на следующий уровень тестирования.

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

После создания реального продукта весьма полезно провести еще один раунд тестирования, чтобы понять, где вы находитесь на этот момент. Результатом должно стать подтверждение или повышение степени соответствия продукта рынку по сравнению с оценками, полученными на последнем этапе тестирования с использованием проектных артефактов. Если этого не происходит, необходимо будет повторять цикл «Гипотеза – Проектирование – Тестирование – Обучение» уже с живым продуктом до достижения требуемых результатов. Многие компании используют на этом этапе закрытое бета-тестирование, когда с продуктом может ознакомиться лишь ограниченное число клиентов. Это происходит до тех пор, пока ваше детище не будет полностью готово к выходу в свет.

Идти напролом или свернуть?

Необходимо отметить, что выше я «нарисовал» довольно радужную картину. Да, там было сказано, что придется проделать большой объем кропотливой работы, пройти через несколько этапов итераций. Но в конце этого пути вас неизбежно будет ожидать главный приз – соответствие продукта рынку. К сожалению, многие команды разработчиков имеют совсем иной опыт. При проведении тестирования своего продукта на пользователях они не получают восторженных отзывов. Они проводят итерации, но не добиваются прогресса. В результате возникает тупиковая ситуация: разработчики чувствуют, что уперлись в глухую стену.

На пути, который я описал, что-то может пойти совсем не так, как ожидалось. Одна или несколько ваших гипотез могут оказаться неверными. Или, даже если гипотезы верны, результаты проектирования, создания или маркетинга продукта могут оказаться недостаточно хорошими. Если вы обнаруживаете, что проводимые итерации не приводят к видимому прогрессу, я рекомендую сделать паузу и отступить на шаг назад. Проведите со своей командой мозговой штурм, чтобы понять, что лежит в основе возникших проблем. Сопоставьте каждую проблему с конкретным слоем пирамиды соответствия продукта рынку, представленной на Рисунке 10.2. В результате вы можете обнаружить, что выполняете итерации на более высоком уровне, чем тот, где находится истинная причина проблем. Например, если ваша гипотеза о целевом клиенте неверна, итеративное совершенствование UX-дизайна продукта не будет иметь большого значения. Необходимо начать с самого основания пирамиды и продвигаться вверх до тех пор, пока не определите, какие из выдвинутых гипотез оказались неверны.

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

Существует множество примеров успешных разворотов в создании продукта. Сайт для обмена фотографиями Flickr начинался как многопользовательская ролевая онлайн-игра «Game Neverending», ориентированная на социальное взаимодействие. После того как компания-разработчик добавила инструмент, позволяющий легко обмениваться фотографиями на веб-страницах, стало ясно, что пользователям он очень понравился. Компания развернулась навстречу пожеланиям клиентов и в феврале 2004 года запустила фото-приложение Flickr, которое быстро обрело популярность и было выкуплено компанией Yahoo! в марте 2005 года.

Популярное приложение для обмена фотографиями Instagram изначально именовалось Burbn и представляло собой социальный проект, написанный на HTML 5, в котором сочетались элементы игр Foursquare и Mafia Wars. После выхода Burbn в качестве нативного приложения для iPhone разработчики посчитали, что его функционал слишком перегружен. В итоге они решили создать новое приложение с нуля, убрав из него все, кроме таких функций, как «фото», «комментарий» и «лайк». Так, в октябре 2010 года появился Instagram, который, пережив взрывной рост, в апреле 2012 года был приобретен Facebook примерно за 1 млрд $.

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

Я знаю несколько стартапов, которые, похоже, постоянно меняют направление своего движения. На самом деле вы не должны сворачивать с намеченного пути каждый раз, когда попадаете в трудную ситуацию, бросаться в погоню за каждой пришедшей вам в голову новой крутой идеей. Такое поведение известно как синдром блестящего предмета. Я часто повторяю шутку о том, что, если вы свернули трижды, значит, вы теперь движетесь в направлении, противоположном изначальному. Однако есть и другая крайность, в которую впадают те, кто упрямо продолжают биться головой о стену, вместо того чтобы, отступив на шаг назад, переосмыслить ситуацию.

Итак, если «дедлайн» еще не наступил, и у вас все еще есть деньги на разработку, как решить, стоит ли продолжать упорствовать или нужно сменить направление движения? Если после нескольких итераций усовершенствования продукта вы все еще не можете добиться прогресса в улучшении его соответствия рынку, следует рассмотреть возможность разворота. Если, несмотря на все затраченные усилия, целевые потребители все также критичны в отношении вашего MVP, опять же, следует подумать о развороте. Другими словами, если вы так и не смогли определить архетип клиента, который был бы в восторге от вашего MVP, следует подумать о развороте.

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

На Рисунке 10.3 концепция разворота при продвижении к рыночному соответствию продукта объясняется через аналогию с восхождением в гору. Вы начинаете свой путь с подножия первой горы, которая олицетворяет собой рыночную возможность, выбранную вами на основе имевшихся представлений о целевом рынке и гипотез о ценностном предложении. Чем выше вы поднимаетесь, тем в большей степени ваш продукт соответствует рынку. Первый раунд тестирования обеспечил вас знаниями, которые способствовали улучшению продукта. Результаты второго раунда тестирования показывают, что вы приблизились к вершине горы (соответствию продукта рынку); однако по итогам следующего раунда стало понятно, что продвижение вверх существенно замедлилось. Ваш продукт стал лучше по сравнению с его начальным состоянием, но достичь достаточно высокого уровня его соответствия рынку не удалось. На последующих двух итерациях вы пробуете разные способы улучшения продукта, но, похоже, не можете добиться прогресса.

Рисунок 10.3. Смена направления движения для достижения более высокого соответствия продукта рынку.

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

Эта аналогия служит напоминанием о том, что при совершении итераций необходимо отслеживать, насколько высоко вам удается подняться в гору (повысить степень соответствия продукта рынку). Старайтесь измерять скорость своего продвижения (улучшения рыночного соответствия продукта) после каждого раунда пользовательского тестирования. Если вам не удается добиться значительного прогресса, попробуйте найти другие пути, ведущие к вершине (пересмотрите свои гипотезы). Если после этого вы все еще не можете достичь заметного прогресса, остановитесь, чтобы по-новому взглянуть на ту «гору», на которой вы находитесь в данный момент (подвергните ревизии свои гипотезы о целевом клиенте и ценностном предложении), и оглянитесь вокруг в поисках других «вершин» (рыночных возможностей), до которых, возможно, вам будет легче добраться. Выберите себе новую цель (смените направление разработки) и попытайтесь ее покорить (совершайте итерации до достижения соответствия продукта рынку).

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

Глава 11

Практический пример создания бережливого продукта

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

MarketingReport.com

Все началось с того, что один из клиентов пригласил меня поработать с новым продуктом под названием MarketingReport.com. Компания этого клиента уже имела успешный опыт создания веб-сервиса в сфере потребительских услуг и теперь планировала разработку нового приложения, чтобы воспользоваться потенциальными рыночными возможностями. Работая над этим проектом, я тесно сотрудничал с двумя руководителями компании и UX-дизайнером.

Идея нового сервиса была основана на широко распространенной клиентской проблеме, связанной с прямой почтовой рассылкой. Дело в том, что многие респонденты, получающие прямую почтовую рассылку, находят ее не столько ценной, сколько неприятной. Руководители компании имели некоторое представление об индустрии прямых почтовых рассылок. В частности, они знали, что такие рассылки являются таргетированными, то есть проводятся на основе маркетинговых баз данных, в которых представлены описания клиентских профилей. Например, вы можете неожиданно получить на свой e-mail купон на покупку наполнителя для кошачьих туалетов от некой сети зоомагазинов просто потому, что где-то в маркетинговой базе данных было когда-то указано, что в вашем доме есть (или, скорее всего, есть) кошка.

Пригласившая меня компания хотела предложить целевым потребителям такой продукт, который обеспечивал бы прозрачность клиентского профиля, созданного маркетологами, и предоставлял возможность отредактировать этот профиль, сделав его более точным. Другими словами, если у меня нет кошки, но есть собака, я мог бы скорректировать маркетинговые базы данных таким образом, чтобы получать купоны на корм для собак вместо скидки на покупку наполнителя для кошачьего туалета. Руководители компании-разработчика видели в этом определенные параллели с индустрией кредитования. Каждый день тысячи решений, связанных с предоставлением займов, принимаются на основе кредитных рейтингов заемщиков. До появления возможности ознакомления со своей кредитной историей потребители не имели четкого представления о том, насколько высок или низок их кредитный рейтинг; кредитоспособность заемщиков основывалась на неких «закулисных» данных, которыми оперировали банки при принятии своих решений. В итоге потенциальные заемщики могли получать отказы в предоставлении кредита, не понимая причин принятия таких решений. При этом негативное влияние могли оказывать неточные данные, содержащиеся в кредитной истории, – например, просрочка по выплате, которой на самом деле не было. Наличие прозрачности кредитной истории позволяет клиентам видеть данные, лежащие в основе их кредитного рейтинга, и исправлять любые имеющиеся в них неточности. Продукт MarketingReport.com должен был сделать с персональными маркетинговыми профилями ровно то, что бюро кредитных историй сделали с кредитными профилями потенциальных заемщиков.

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

Шаг 1: Идентификация целевых потребителей

Надеюсь, вы помните, что первый шаг процесса создания бережливого продукта заключается в идентификации его целевых потребителей. На этом раннем этапе мы договорились, что наш продукт будет нацелен на массового потребителя. Шаг 1 (клиенты) и шаг 2 (потребности клиентов) тесно взаимосвязаны, поэтому изначально мы решили не сужать нашу гипотезу о целевом рынке. Мы знали, что сможем уточнить ее позднее, когда получим ясность в отношении клиентских преимуществ, которые мы могли бы предложить потребителям.

Шаг 2: Определение недостаточно удовлетворенных потребностей

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

1. Получение интересных предложений, позволяющих мне сэкономить на покупках.

2. Уменьшение количества получаемого мной «спама».

3. Получение представления о моем потребительском поведении.

4. Возможность знакомства и взаимодействия с другими людьми, имеющими схожие с моими предпочтения в покупках.

5. Возможность заработать на разрешении продавать мои маркетинговые данные.

Чтобы определить, на каких клиентских преимуществах сосредоточить свое внимание, мы разработали набор оценочных критериев, некоторые из которых были положительными, а другие отрицательными. Каждое из преимуществ было оценено по следующим критериям:

• Высокий спрос со стороны потребителей (+).

• Ценность полученных маркетинговых данных (+).

• Уровень конкуренции (—).

• Величина затрат на создание продукта в версии v1 (—).

• Затраты на масштабирование концепции (—).

• Соответствие бренду компании (+).

• Степень зависимости от партнеров (—).

Такой подход позволил на основании сделанных нами оценок отсеять наименее привлекательные идеи. В итоге первые четыре преимущества из приведенного выше списка были сочтены заслуживающими дальнейшего рассмотрения.

Шаг 3: Формирование ценностного предложения

Чтобы сформировать наше ценностное предложение, на этом этапе я хотел определить, какие из сформулированных преимуществ могли быть охвачены нашим предполагаемым продуктом, а какие находились вне сферы его применения. Вместе с руководителями компании мы проделали упражнение, позволяющее определить пространство проблем для нашего продукта. Результаты вы можете видеть на Рисунке 11.1. Все преимущества я разбил на группы на основании имеющихся между ними взаимосвязей. Наше основное преимущество состояло в том, что продукт давал понять, что «они» [маркетологи] знают о пользователе (в середине). Вторая группа преимуществ (вверху) включала сокращение объема получаемого «спама» и сохранение деревьев (бережное отношение к окружающей среде). Третья группа преимуществ (внизу) включала экономию денег при покупках, получение информации о расходах и взаимодействие с покупателями, имеющими схожее потребительское поведение.

Рисунок 11.1. Первоначальное ценностное предложение продукта MarketingReport.com

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

В главе 5 я рекомендовал использовать при формировании ценностного предложения продукта модель Кано, чтобы классифицировать каждое преимущество как базовое, улучшающее производительность или восхищающее. При этом должны быть приняты во внимание аналогичные характеристики продуктов конкурентов. Мы отнесли основное преимущество нашего продукта – «раскрытие известной маркетологам информации» – к категории восхищающих, поскольку на тот момент подобных сервисов на рынке не существовало. Вместе с тем конкуренты предлагали достаточно много решений, позволяющих клиентам экономить на покупках; поэтому мы рассматривали это как преимущество производительности. К этой же категории мы отнесли и социальное взаимодействие, хотя соответствующие продукты конкурентов далеко не всегда были ориентированы на шопинг. При этом нам не были известны другие продукты, которые позволяли бы сравнивать себя с другими пользователями по критерию совершаемых покупок, поэтому мы сочли это преимущество восхищающим. Что касается концепции «Маркетингового щита», то мы отнесли сокращение количества «спама» к восхищающим «фишкам» продукта. И наконец, с учетом присутствия на рынке множества приложений экологической направленности мы посчитали «сохранение деревьев» преимуществом производительности.

Шаг 4: Определение функционала для MVP

Теперь, когда у нас было ценностное предложение для каждой из двух наших концепций продукта, мы перешли в пространство решений и провели мозговой штурм, пытаясь определить функции, которые могли бы обеспечить предлагаемые преимущества. На Рисунке 11.2 представлены функции, которые мы в итоге подобрали для каждой концепции продукта.

Рисунок 11.2. Функции MarketingShield и MarketingSaver

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

Двумя ключевыми компонентами, которые мы предусмотрели для маркетингового отчета, были маркетинговый профиль и маркетинговый рейтинг. Профиль был основан на наборе кластеров сегментации потребителей, используемых службами прямого маркетинга. При этом каждый кластер имеет запоминающееся описательное название – например, «молодые диджерати[20]», «футбол и внедорожники» или «сельские пенсионеры» – и основан на ключевых демографических показателях, таких как возраст, семейное положение, наличие детей, недвижимости, а также район проживания. Маркетологи используют такие профили для составления таргетированных рекламных предложений.

Идея маркетингового рейтинга родилась у нас с нуля. Предполагалось, что этот показатель будет подобен кредитному рейтингу заемщика – оценке его кредитоспособности, выраженной в баллах. Аналогичным образом маркетинговый рейтинг должен был представлять собой оценку, отражающую общую маркетинговую привлекательность клиента в баллах. Как более высокий кредитный рейтинг обеспечивает более выгодные условия кредитования, так и более высокий маркетинговый рейтинг позволял бы клиенту получать больше купонов на скидки и промо-кодов. Мы определили несколько факторов, которые будут влиять на маркетинговый рейтинг.

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

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

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

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

Шаг 5: Создание прототипа MVP

После определения функционала для нашего MVP пришло время перейти к шагу 5, чтобы с помощью проектных артефактов приступить к реализации запланированных функций. Мы хотели протестировать проектные артефакты, прежде чем приступить к созданию программного кода, поэтому решили использовать макеты средней точности. Эти макеты имели достаточно подробный визуальный дизайн – цвета, шрифты, графику и стиль оформления, – для того чтобы продукт можно было эффективно представить пользователям, но при этом мы не стремились сделать их точными до пикселя.

Мы начали с продумывания и определения структуры продукта (информационной архитектуры) и потока взаимодействия с пользователями (дизайна взаимодействия). Согласно нашему плану, пользователь получал электронное письмо с описанием предлагаемого сервиса. Призыв к действию, содержащийся в этой письме, звучал следующим образом: «Ознакомьтесь с вашим маркетинговым отчетом», – и содержал ссылку, ведущую на целевую страницу, где продолжалось описание сервиса и имелась ключевая кнопка конверсии: «Просмотреть отчет». Каждому пользователю присваивался уникальный код, который был включен в электронное письмо. После нажатия кнопки «Просмотреть отчет» пользователи попадали на веб-страницу «Проверка информации». Эта страница представляла заполненную форму с указанием имени, адреса, семейного положения, диапазона доходов домохозяйства и других основных демографических атрибутов пользователя. Информация была взята из маркетинговых баз данных, при этом пользователю предоставлялась возможность исправить в ней любые имеющиеся неточности. После нажатия кнопки «Далее» на этой странице происходило перенаправление на страницу маркетингового отчета.

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

Страница маркетингового отчета являлась для пользователя центром управления. Они могли щелкнуть по любому модульному блоку и перейти на соответствующую тематическую страницу. Например, страница, посвященная скидочным предложениям, позволяла клиенту выбрать интересующие его виды товаров и услуг, такие как отдых, электроника и т. п. На странице, посвященной «блокировке “спама”», отображался список различных категорий прямой рассылки и пользователям разрешалось выбрать, какие из них они больше не хотят получать. На этой же странице было размещено предложение о подписке на дополнительную платную услугу «Маркетинговый щит. Премиум», которая обеспечивала еще более жесткую фильтрацию нежелательных почтовых сообщений и большую конфиденциальность данных маркетингового профиля. За исключением этой услуги, все остальные функции продукта как в версии «Маркетинговый щит», так и в версии «Маркетинговая экономия» предлагались пользователям на бесплатной основе.

Шаг 6: Тестирование MVP на пользователях

После подготовки макетов пришло время перейти к шагу 6: тестированию на пользователях. На этом этапе нам требовалось уточнить идентификацию нашего целевого клиента, прежде чем приступать к подбору участников тестирования. Поскольку у нас было два разных MVP, каждый со своим собственным ценностным предложением, нам, соответственно, пришлось идентифицировать целевых клиентов для каждого из имеющихся вариантов продукта. Целевыми клиентами и в том, и в другом случае мы по-прежнему считали широкий круг потребителей, но с некоторыми уточнениями. Для «Маркетингового щита» это должны были быть люди, которые высоко ценят свою конфиденциальность. Целевые потребители версии «Маркетинговая экономия», по нашему мнению, должны были придавать большое значение экономии денег при покупках и получению выгодных скидочных предложений.

Привлечение представителей целевого рынка для участия в тестировании

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

Во-первых, я хотел, чтобы участники тестирования были работающими людьми с полной занятостью (не менее 30 часов в неделю). Многие безработные и пенсионеры с удовольствием принимают участие в маркетинговых исследованиях, поскольку располагают достаточным для этого количеством свободного времени, но они не слишком подходят под описание наших целевых клиентов. Вторым критерием был уровень образования – не ниже среднего и, кроме того, я старался соблюсти образовательный баланс, чтобы обеспечить соответствие участников тестирования нашей целевой аудитории. Участники тестирования должны были представлять домохозяйства с доходом не менее 40000$. Они также должны были иметь домашний компьютер и пользоваться интернетом, по крайней мере несколько часов в неделю (поскольку наша услуга должна была предоставляться через интернет). Мы также хотели убедиться, что они недавно совершали какую-либо онлайн-покупку (чтобы у них не было трудностей и предубеждений по поводу оплаты услуг онлайн). На мой взгляд, всем этим критериям мог соответствовать обычный работающий человек, являющийся потребителем веб-сервисов.

Наконец, мне необходимо было решить, к какой именно целевой группе («Щит» или «Экономия») следовало отнести того или иного участника тестирования. В этом случае в качестве критерия я решил использовать прошлое поведение участников. Поскольку несомненным преимуществом версии «Маркетинговая экономия» была экономия денег при покупках, для отбора участников этой группы я предусмотрел вопросы, связанные с различными способами экономии:

• Использовали ли вы три или более скидочных купона за последние три месяца?

• Являетесь ли вы членом клуба Costco[21]?

• Совершали ли вы покупки на eBay за последние шесть месяцев?

• Совершая покупки, вы тратите время на то, чтобы убедиться в том, что нашли самую низкую цену?

За каждый ответ «да» респондент получал один балл. Мы исходили из того, что каждый, кто наберет, как минимум, два балла, относится к целевому рынку версии «Экономия».

Аналогичным образом, основываясь на том, что «Маркетинговый щит» в первую очередь был направлен на обеспечение конфиденциальности и безопасности, кандидаты для включения в эту группу отвечали на следующие тематические вопросы:

• Вы когда-нибудь отправляли запрос на отказ от маркетинговых звонков?

• Используете ли вы блокировку нежелательных звонков в своем телефоне?

• Есть ли у вас дома уничтожитель документов?

• Пользовались ли вы за последние шесть месяцев платными антивирусными приложениями?

Респонденты также получали по одному баллу за каждый ответ «да», и целевым клиентом для версии «Маркетинговый щит» считались те, кто наберет два или более балла.

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

Как только все респонденты прошли отбор для участия в тестировании, от каждого из них запросили такие сведения, как адрес, возраст, семейное положение, количество детей, наличие недвижимости, уровень дохода домохозяйства, образование, род занятий и этническая принадлежность. Вся эта информация была нужна нам для создания персональных макетов страницы «Проверка информации». Кроме того, мы использовали эти данные для адаптации маркетингового профиля каждого участника к соответствующему кластеру сегментации. Персонализация макетов позволила нам создать для проведения тестов гораздо более реалистичный пользовательский опыт по сравнению с использованием безликой типовой страницы и упованием на то, что участники тестирования задействуют в этом месте свое воображение. На самом деле, большинство пользователей, впервые увидев свою персональную маркетинговую страницу, удивленно спрашивали: «Откуда у вас вся эта информация?» Таким образом, мы успешно спровоцировали у пользователей осознание того, что маркетинговые базы данных действительно хранят о вас большой объем информации, что согласовывалось с ключевым ценностным предложением MarketingReport.com.

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

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

Скрипт пользовательского тестирования

Пока шел набор участников, я разработал скрипт, который планировал использовать для модерирования пользовательского тестирования. Продолжительность каждого сеанса должна была составлять 90 минут. Мой многоуровневый скрипт учитывал распределение этого времени между этапами и выглядел следующим образом:

1. Знакомство и разминка (5 минут).

2. Общие вопросы для ознакомления (15 минут).

a. Прямая маркетинговая рассылка.

b. Данные о вас, которыми располагают маркетинговые компании.

c. Сравнение своего потребительского поведения с другими людьми.

3. Вопросы, относящиеся к конкретной концепции (версии) (общее время – 45 минут).

d. Ознакомительные вопросы, связанные с основной темой концепции (10 минут).

e. Обратная связь по представленным макетам версии (35 минут).

4. Обзор: Что вам больше всего понравилось/не понравилось в том, что вы увидели? (5 минут).

5. Мозговой штурм: что сделало бы данный продукт более полезным/ценным? (10 минут).

6. Обратная связь по возможным названиям продуктов (10 минут).

7. Благодарности и прощание.

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

В течение трех вечеров я модерировал по две сессии, в каждой из которых должны были принимать участие три пользователя. Первая половина сессий была посвящена версии «Маркетинговый щит», а вторая – версии «Маркетинговая экономия». Таким образом, с каждой из концепций должны были ознакомиться по девять участников тестирования. В итоге из-за двух неявок нам удалось протестировать каждую версию продукта на восьми пользователях. Как я уже упоминал, все данные в используемых макетах были персонализированными под каждого из участников. Поскольку этот этап тестирования проводился до разработки интерактивных макетов, я распечатал каждый макет на бумаге. Страницы макетов были уложены стопками перед каждым из участников в нужном порядке. Я следовал своему скрипту и, по мере того как пользователи просматривали макеты, переворачивал страницы.

Что мы узнали от пользователей

Сеансы тестирования прошли хорошо. Участники демонстрировали вовлеченность в процесс и четко выражали свои мысли. Мы получили множество замечательных отзывов – на самом деле, их было так много, что я напечатал восемь страниц заметок, чтобы зафиксировать все, что мы узнали. При этом главный вывод заключался в том, что ни одна из концепций не оказалась достаточно привлекательной для пользователей. Однако нескольким солнечным лучам все же удалось пробиться сквозь тучи.

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

Функция сравнения своих расходов на покупки с другими людьми, равно как и возможность социального взаимодействия, входившие в состав концепции «Экономия», также не вызвали большого интереса. Однако участникам тестирования понравилась опция получения скидочных предложений (один из наших солнечных лучей). Эта функция оказалась самой привлекательной в концепции «Экономия». Идея сокращения количества присылаемого «спама» стала фаворитом в концепции «Щит», как и идея сохранения деревьев в качестве вторичного преимущества. Здесь я должен пояснить, что указанный мной уровень привлекательности функций на самом деле был довольно далек от однозначного признания ценности. У пользователей возникало множество вопросов и опасений по поводу того, что им показывали. Однако я был уверен, что мы сможем использовать полученную в ходе этого раунда тестирования информацию для того, чтобы сделать следующие версии более эффективными. Я посчитал, что скрытый интерес к предлагаемым нами преимуществам был достаточно велик.

После завершения тестирования я взял карту с описанием наших пространств проблем и решений – показанную на Рисунке 11.2 – и раскрасил каждую ячейку зеленым, желтым или красным цветом, чтобы обозначить степень их привлекательности как высокую, незначительную или низкую, соответственно. Когда я посмотрел на полученный результат, то увидел два отдельных островка зелени: целевым пользователям «Экономии» понравились предложения по экономии денег, а целевым пользователям «Щита» – возможность блокировать нежелательную почту. Мы оказались на распутье: перед нами ясно вырисовывались две дороги для дальнейшего продвижения вперед. Нужно было выбрать, на какую из них мы хотим повернуть.

Итерации и развороты для повышения степени соответствия продукта рынку

В то время как обе наши концепции обладали потенциальной привлекательностью, «Маркетинговый щит» выглядел все же более предпочтительно. Это объяснялось тем, что многие веб-сайты уже занимались предоставлением скидочных предложений (такие как coupons.com). Участники тестирования не могли понять, чем наше предложение отличается от уже существующих на рынке. Кроме того, пользователи не были готовы к тому, чтобы платить за подобную услугу, заявляя, что могли бы рассмотреть только такую цену, которая была бы меньше фактической суммы экономии, полученной с использованием данного сервиса. Кроме того, эта услуга не очень сочеталась с брендом компании разработчика, а ее реализация требовала слишком много дополнительных усилий по заключению сделок со сторонними компаниями, которые могли бы предоставлять скидочные предложения.

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

Разворот

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

Мы решили остановиться на первом варианте. Проект JunkmailFreeze довольно сильно отклонялся от нашей базовой концепции, поскольку мы узнали много нового о том, как можно улучшить сервис блокировки «спама». Кроме того, создание нового набора макетов и привлечение еще одной группы пользователей для тестирования не заняло бы много времени. На этот раз в целях экономии времени и денег мы решили привлечь к тестированию меньшее число участников.

Итерации, основанные на обучении

Мы выбросили наши старые макеты и приступили к разработке нового продукта, ориентированного на сокращение количества нежелательной почты, с дополнительным преимуществом – сохранением деревьев. Для нового прототипа MVP мы разработали довольно простой пользовательский опыт. Он начинался с электронного письма от друга, рекомендовавшего JunkmailFreeze. В письме была ссылка на домашнюю страницу, на которой объяснялись преимущества продукта и имелась большая кнопка для перехода «Начать». Кроме этого, на странице присутствовала еще одна ссылка: «Узнать больше». Нажатие кнопки «Начать» переносило пользователя на простенькую страницу регистрации, где он вводил свое имя, домашний адрес, адрес электронной почты и пароль. После нажатия кнопки «Зарегистрироваться» пользователь переходил на страницу «Моя учетная запись», где мог указать, какие типы «спама» он больше не желает получать. Мы создали и другие страницы, на которых объяснялись преимущества использования JunkmailFreeze; но данная страница была ключевой, поскольку именно на ней происходило взаимодействие пользователя с продуктом для получения предлагаемых преимуществ. До того как мы провели первый раунд пользовательского тестирования, мы считали, что это преимущество заключается просто в сокращении количества получаемой нежелательной почты.

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

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

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

Еще мы выяснили, что потребители считают каталоги товаров слишком громоздкими и потому неудобными. Люди выбрасывают ненужные им каталоги, считая это хлопотным делом и пустой тратой бумаги. Но при этом они все же хотели бы продолжать получать некоторые из видов каталогов; высказывались различные предпочтения в отношении того, какие из них хотели бы сохранить.

Наконец, мы также узнали, что многие клиенты считают назойливой местную рекламу. Одной из форм «спама» были пачки скидочных купонов от локальных магазинов, которые многие получатели выбрасывали, даже не открывая. Сюда же относились рекламные листовки из местных супермаркетов. Участники тестирования также жаловались на то, что им присылают бесплатные местные газеты, на которые они не подписывались. Это отличный пример того, как общение с целевыми пользователями помогает получить более четкое представление о проблемном пространстве. Мы узнали так много, что наша обновленная страница «Моя учетная запись» предоставляла пользователю возможность выбора для блокировки из списка, содержавшего более 30 различных видов «спама», разделенных на семь категорий. После того как пользователь отмечал, какие виды нежелательной почты он хотел бы заблокировать, оставалось нажать кнопку «Продолжить», чтобы завершить регистрацию.

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

На этой же странице объяснялось, что пользователи могут вернуться в JunkmailFreeze в любое время, чтобы изменить свой выбор типов блокируемого «спама». Это также стало реакцией на пожелания, высказанные участниками первого раунда тестирования. Несколько человек выразили обеспокоенность тем, что, заблокировав нежелательную почту, они могут непреднамеренно отказаться от рассылок, которые на самом деле хотели бы получать. Увидев сообщение о возможности изменения настроек блокировки, большинство пользователей удовлетворенно кивали или говорили: «Звучит неплохо».

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

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

Раунд второй

После подготовки макетов JunkmailFreeze мы, используя хорошо себя зарекомендовавший скринер для отбора целевых потребителей «Щита», набрали еще одну группу участников тестирования. Для второго раунда мы планировали использовать три группы по два пользователя в каждой. Я обновил сценарий тестирования таким образом, чтобы сосредоточиться на проблеме нежелательной почты. Тестовые сеансы имели продолжительность в 90 минут и начинались в 18:00 и в 20:00 (как и в прошлый раз).

Учитывая, что первый раунд принес нам немало открытий, а также тот факт, что на этот раз мы хотели сфокусироваться на представлении деталей продукта, я отвел больше времени на обсуждение макетов (45 минут вместо 35). Новые участники, к нашей радости. проявили высокую заинтересованность и четко выражали свои мысли.

Восхождение на вершину соответствия продукта рынку

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

Тем не менее, эти макеты все еще нельзя было считать «финальными». У нас возникло еще более глубокое понимание того, что хотели бы получить пользователи от сервиса блокировки нежелательной почты. Например, мы узнали, что блокировка на уровне категорий рассылки не подходит для случаев, связанных с кредитными картами и каталогами. В отношении этих предложений пользователи хотели бы иметь возможность указывать свои предпочтения на уровне конкретных компаний (например, получать предложения от Chase или Wells Fargo по кредитным картам, каталоги от Nordstrom и L.L. Bean). Мы также получили обратную связь по поводу наших сообщений и пользовательского интерфейса, которая могла помочь в дальнейшем совершенствовании продукта.

На этот раз в ответ на вопрос о том, сколько они были бы готовы заплатить за предлагаемую услугу, участники тестирования продемонстрировали большую готовность воспользоваться платной подпиской по более высокой стоимости. Это заметно отличалось от реакции, полученной в ходе первого раунда. Здесь стоит вспомнить о необходимости скептически воспринимать ответы участников тестирования на вопросы, связанные с готовностью платить за использования продукта. Слова и реальные действия могут сильно различаться. На самом деле, вы не сможете узнать, сколько клиенты будут готовы заплатить до тех пор, пока у вас не появится реальный продукт, за который потребителям придется платить реальными деньгами. Но в этот раз было очевидно, что интерес к нашему продукту оказался гораздо выше. Я был уверен, что с имеющимися у нас к тому моменту макетами мы достигли достаточного уровня соответствия продукта рынку, чтобы двигаться дальше.

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

Выводы

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

Мне нравится делиться этим примером еще и потому, что он является очень показательным. Ведь на самом деле мы не делали ничего особенного или уникального. Мы просто строго следовали процессу бережливого производства. Нет никаких причин, по которым кто-то другой не смог бы повторить наш путь. Следуя процессу, который я описываю в этой книге, любая команда сможет достичь аналогичных высот со своим продуктом. Конечно, детали будут отличаться. В вашем случае процесс может занять больше времени. Возможно, вам придется совершить несколько итераций или не совершить ни одной. И нет никаких гарантий того, что вы сумеете добиться соответствия рынку абсолютно для каждой идеи, за реализацию которой вы беретесь. Но важно то, что у вас есть способ проверить свои гипотезы и достоверно оценить степень соответствия вашего продукта рынку.

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

Часть III

Создание и оптимизация продукта

Глава 12

Создание продукта с помощью методов Agile-разработки

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

Непосредственное создание продукта является критическим важным шагом, поэтому на этом этапе действительно важно обеспечить качественное исполнение. Существует множество рисков, которые могут помешать вам в этой работе. Вы можете столкнуться с техническими проблемами, когда то, что вы спроектировали, будет невозможно или слишком сложно воплотить в жизнь. Например, ваш проект может быть реализован с технической точки зрения, но его масштабы настолько велики по сравнению с имеющимися ресурсами, что создание займет слишком много времени. Перспективные рыночные возможности существуют лишь до тех пор, пока в ходе конкурентной борьбы они не переместятся в правый верхний квадрант шкалы соотношения важности и удовлетворенности. Важной частью соответствия продукта рынку является его своевременность (вспомните обсуждение продуктовой стратегии в главе 5). Даже когда для продукта существует рынок сбыта, плохое исполнение может привести к тому, что предложенное потребителям итоговое решение будет сильно отличаться от ожиданий, заявленных прототипом. Естественно, что вы хотели бы свести к минимуму все перечисленные риски. И тут критическую важность обретает процесс разработки продукта. В этой главе рассказывается о лучших практиках разработки, которые помогут вам быстрее создавать успешные продукты с наименьшими рисками.

Agile-разработка

До этого момента мы успешно применяли итеративный подход, поэтому вполне логично будет использовать его и при непосредственном создании продукта. «Agile-разработка» – это термин, используемый для описания различных итеративных и поэтапных методов создания продукта. До внедрения Agile-разработки большинство программных продуктов создавались с использованием «водопадного» подхода, суть которого состоит в последовательном выполнении ряда шагов. При нем команда разработчиков сначала определяет все требования технического задания, и лишь затем приступает к разработке продукта. Далее проводится внедрение и тестирование, чтобы убедиться, что все работает так, как было задумано. Ключевой особенностью «водопадного» подхода является то, что разработчики не переходят к следующему шагу до тех пор, пока предыдущий этап не будет завершен на 100 %. Другими словами, никакого проектирования не происходит до тех пор, пока не будут определены все требования, и никакой программный код не пишется до тех пор, пока не будет спроектирован весь продукт. Такой подход также называют BDUF (Big Design Up Front)[22].

В свою очередь, разработчики, практикующие Agile-подход (сам термин Agile означает «гибкий», – прим. пер.), разбивают проект на более мелкие составляющие, для реализации которых требуются короткие циклы определения требований, проектирования и кодирования. У Agile-разработки имеется несколько преимуществ. Во-первых, тактика продвижения мелкими шагами позволяет быстрее реагировать на рыночные и прочие внешние изменения. Во-вторых, в процессе разработки продукт быстрее выносится на суд пользователей, что означает более раннее получение обратной связи, которая помогает концентрировать последующие усилия в правильном направлении. В-третьих, разработчикам проще выявлять и ликвидировать ошибки за счет одновременного выполнения меньшего объема работ.

Я упоминал выгоды концепции бережливого производства небольших партий в главе 6, но давайте рассмотрим, почему она так полезна при разработке программного обеспечения (или при любой другой разработке, осуществляемой в условиях с высокой степенью неопределенности). Когда разработчики оценивают количество времени, которое им потребуется для создания новой функции, в их оценке присутствует некоторая неопределенность. Наличие такой неопределенности приводит к тому, что произведенная оценка затрат оказывается ошибочной и фактическая продолжительность разработки отличается от расчетной. Хороший способ сравнения фактической и расчетной продолжительности разработки заключается в количественном измерении их соотношения. Если реализация проекта заняла в два раза больше времени, чем ожидалось, величина такого соотношения будет равна 2x; если же на реализацию ушло вдвое меньше расчетного времени, соотношение будет равно 0.5x.

Стив Макконнелл[23] создал диаграмму под названием «Конус неопределенности», которая характеризует диапазон величины ожидаемой ошибки при оценке затрат на протяжении всего срока реализации проекта. На его диаграмме верхняя и нижняя границы ошибки оценки представляют собой симметричные кривые, которые начинаются с уровней 4x и 0.25x, соответственно, в начале проекта, и плавно опускаются по мере продвижения разработки, сходясь в конце на нулевой отметке. Это иллюстрирует интуитивно понятный и подтвержденный практическим опытом факт, что в начале разработки величина ошибки при оценке затрат потенциально выше, чем ближе к завершению проекта.

Однако на практике я не сталкивался с тем, чтобы подобные ошибки оказывались симметричными. Другими словами, я не замечал, чтобы разработчики с одинаковой вероятностью опаздывали и завершали задачи раньше намеченного срока. В большинстве случаев задачи по разработке программного обеспечения занимают больше времени, чем предполагалось изначально. И хотя некоторые действительно выполняются досрочно, количество сэкономленного времени, как правило, оказывается намного меньшим, чем масштабы отрицательных сюрпризов. Почему так происходит? Чтобы объяснить асимметричную природу ошибок в оценке затрат на создание программного обеспечения, я процитирую эпистемолога и бывшего министра обороны США Дональда Рамсфелда:

«Существуют известные нам известные. Это вещи, о которых мы знаем, что мы о них знаем. Мы также знаем о существовании известных нам неизвестных. То есть мы знаем, что есть некоторые вещи, о которых мы не знаем. Но есть и неизвестные нам неизвестные. Это то, о чем мы не знаем, что мы о них не знаем».

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

Допустим, я подсчитал, что выполнение задачи A займет у меня пять минут, а выполнение задачи B – пять месяцев. С обеими задачами могут быть связаны неизвестные мне неизвестные. Однако неопределенность не является линейной при увеличении масштаба задачи, о чем свидетельствует верхняя кривая конуса неопределенности. Вероятность того, что пятиминутное задание выйдет из-под контроля, довольно мала. В отличие от нее, пятимесячная задача, которая более чем в 30 000 раз масштабнее, имеет гораздо больше шансов на то, что с ней могут быть связаны неизвестные нам неизвестные факторы.

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

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

Стоит отметить, что для некоторых проектов «водопадный» подход является наилучшим. Например, вряд ли кому-нибудь пришла бы в голову идея отправить человека в космос на минимально жизнеспособной версии космического корабля. Я начинал свою карьеру с проектирования атомных подводных лодок. Могу вас уверить, что мы многократно проверяли все технические задания и по нескольку раз пересматривали проекты, прежде чем приступить к строительству. В таких ситуациях риск неудачи слишком высок и связан с жизнями людей. Кроме того, в отличие от написания программного кода для веб-сайта, в который при желании или необходимости можно быстро внести изменения, поменять что-то в структуре космического корабля или подводной лодки, после того как они уже построены, гораздо сложнее, если вообще возможно. Когда риск неудачи или стоимость внесения изменений слишком высоки, лучше потратить больше времени на подготовительные этапы, чтобы максимально повысить степень уверенности в будущем успехе.

Основные принципы гибкой разработки были изложены в «Манифесте Agile», который был написан в 2001 году (вы можете ознакомиться с Манифестом и принципами Agile по ссылке: http://agilemanifesto.org). Agile поощряет раннюю и непрерывную поставку работающего программного обеспечения с ориентацией на создание ценности для потребителей. Ключевой частью Agile является определение продукта с точки зрения потребителя и использование с этой целью пользовательских историй. Как уже было сказано в главе 6, история пользователя – это краткое описание преимуществ, которые должен предоставлять конкретный функционал. Это описание включает как самого персонажа – для которого предназначены эти преимущества, так и его цели. Хорошо написанные пользовательские истории обычно соответствуют шаблону:

Я как [тип пользователя]

хочу [что-то сделать],

чтобы [получить желаемую пользу].

Agile также способствует тесной межфункциональной коммуникации и сотрудничеству, когда бизнесмены и разработчики постоянно работают вместе, в идеале – лицом к лицу. Вместо побуждения к соблюдению жесткого плана, Agile обеспечивает гибкость, позволяющую быстро реагировать на изменения. Команды разработчиков достигают этого, выполняя работу мелкими частями в коротких итеративных циклах с обратной связью и обучением в противовес стремлению заранее и подробно определить весь набор требований к заданию. Наконец, Agile – это постоянное совершенствование процесса разработки продукта с помощью обратной связи и экспериментов.

Существует несколько различных разновидностей Agile-разработки, включая экстремальное программирование (сокращенно XP) и бережливую разработку программного обеспечения. Далее я приведу краткий обзор двух наиболее часто используемых методологий Agile: Scrum и Канбан.

Scrum

Scrum является наиболее популярной методологией Agile. Ее относительно легко внедрить, благодаря существованию множества предписывающих руководств о том, как практиковать Scrum. Ключевым аспектом Scrum является то, что команда работает в условиях строгого соблюдения фиксированных временных интервалов. Каждый рабочий интервал, называемый спринтом или итерацией, представляет собой заранее спланированный промежуток времени. Особенно распространены двухнедельные спринты, но есть команды, использующие недельные, трехнедельные и четырехнедельные спринты.

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

Вторая роль Scrum-команды имеет обобщенное название: «член команды разработчиков». В руководстве по Scrum говорится, что команда разработчиков должна быть многопрофильной и обладать всеми навыками, необходимыми для выполнения работы. В состав Scrum-команды обычно входят несколько разработчиков, чья работа заключается в оценке масштаба пользовательских историй и в создании продукта. Носителями этой важной роли также являются UX-дизайнеры, визуальные дизайнеры и специалисты по обеспечению качества (QA). В соответствии с традиционными принципами Scrum, внутри команды не должно существовать иерархических различий; признается лишь деление на роли. Дизайнеры занимаются реализацией пользовательских историй, разрабатывая пользовательский опыт, который они передают через созданные ими дизайн-проекты. Хорошо написанные пользовательские истории включают в себя критерии приемлемости, которые используются для подтверждения того, что история завершена и работает именно так, как было задумано. Специалисты по контролю качества проверяют, соблюдены ли критерии приемки, и обеспечивают качество продукта.

Идеальная численность Scrum-команды составляет от пяти до девяти человек. Возможно, вы слышали о «правиле двух пицц»: если двух пицц недостаточно, чтобы накормить всех членов команды, значит, вас слишком много. Численный состав команды должен быть достаточным для выполнения значительного объема работы за один спринт. Но при этом команда должна быть достаточно мала, чтобы оставаться сплоченным коллективом и не иметь проблем с коммуникацией, часто присущих многочисленным группам.

Третья роль – Scrum-мастер, чья работа заключается в том, чтобы помогать команде в процессе разработки и повышать ее производительность. В крупных компаниях один и тот же Scrum-мастер может работать как с одной, так и с несколькими Scrum-командами. Зачастую эту роль берет на себя ведущий разработчик или менеджер по разработке. Хотя это не согласуется с руководящими принципами Scrum, иногда эта роль не принадлежит какому-то конкретному члену команды – она либо игнорируется вовсе, либо обязанности, связанные с этой ролью, распределяются между несколькими членами команды.

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

Рисунок 12.1 дает наглядное представление о рабочем потоке, совещаниях и подведении итогов, согласно принципам Scrum.

Рисунок 12.1. Структура Scrum

Каждый спринт команда начинает с проведения совещания по планированию спринта, на котором принимается решение, какие пользовательские истории будут реализованы в ходе очередной итерации. Отобранные истории перемещают из бэклога продукта в бэклог спринта. Частью этого процесса является оценка масштаба каждой истории, которая осуществляется с использованием оценочных баллов, отражающих относительную трудоемкость реализации конкретной истории. Сам процесс оценки часто является скорее искусством, чем наукой. В разных источниках вы можете найти множество используемых систем начисления баллов. Некоторые из них позволяют присваивать истории любое количество баллов: 1, 2, 3, 4, 5, 6 и так далее. Распространенным подходом является использование ряда Фибоначчи, где допустимыми значениями являются числа: 1, 2, 3, 5, 8, 13 и так далее. Преимущество такого подхода заключается в том, что он лучше отражает различия между разными парами рядом стоящих оценок. Другой популярной системой, которая в еще большей степени отражает различия в оценочных значениях, является шкала, построенная на «степенях двойки»: 1, 2, 4, 8, 16 и так далее. Еще один популярный метод основан на «размерах футболки» и использует для оценки масштабов пользовательских историй обозначения, обычно применяемы к размерам одежды: S, M, L, XL. Истории, набравшие наибольшее количество баллов в любом из применяемых диапазонов оценок, имеют значительную степень неопределенности и должны быть разбиты на более мелкие истории (см. главу 6). Истории, которые слишком велики для того, чтобы их можно было завершить за одну итерацию, называют эпопеями. Прежде чем добавить их в спринт, они в обязательном порядке должны быть разбиты на части. Многие применяемые в Agile инструменты отслеживания позволяют использовать эпопеи для создания связанных историй и управления ими на протяжении нескольких итераций.

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

На Рисунке 12.2 представлен пример того, как команда отслеживает свою скорость на протяжении нескольких итераций. По горизонтальной оси показана пронумерованная последовательность итераций. Вертикальная ось показывает количество отработанных баллов. На протяжении приведенных на рисунке 12 итераций скорость работы команды была переменной (от 22 до 40 баллов), что является нормой. Несмотря на подобную изменчивость, линия тренда показывает, что с течением времени команда неуклонно увеличивала скорость своей работы.

Рисунок 12.2. Скорость работы команды

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

Покер планирования – популярная техника получения быстрой, но при этом надежной оценки пользовательской истории. Все члены команды получают набор карт, каждая из которых соответствует одному из возможных значений оценки (например, 1, 2, 3, 5 и 8 баллов). После обсуждения истории каждый участник независимо от других выбирает карту, соответствующую его оценке истории в баллах. Затем все участники одновременно вскрывают свои карты. Если в предъявленных оценках наблюдается относительный консенсус, это говорит в пользу их большей точности. Если в оценках имеются существенные расхождения, обсуждение истории продолжается с целью приближения к согласию. При этом каждую историю часто разбивают на набор задач по кодированию. Это позволяет гарантировать, что при оценке трудозатрат были объективно учтены все известные факторы. Кроме того, оценить масштаб каждой из небольших задач обычно легче, чем всю историю целиком. Объем таких задач некоторые команды измеряют все также в баллах, другие предпочитают оценивать их в часах работы. Иногда разработчики не утруждают себя оценкой масштаба отдельных задач, ограничиваясь оценкой на уровне истории.

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

В ходе выполнения спринта команда проводит ежедневные оперативные совещания, которые называют стендапами, из-за того что их обычно проводят «на ногах», чтобы сделать более короткими. Такие совещания проходят, как правило, по утрам и включают в себя обсуждение планов на предстоящий рабочий день. Обычно они занимают не более 15 минут. Каждый член команды кратко описывает, что он сделал накануне, что планирует сделать сегодня, а также указывает на имеющиеся для этого помехи.

Реализация пользовательских историй происходит, начиная с верхней части бэклога спринта. При этом члены команды взаимодействуют между собой по мере необходимости. Существует множество Scrum-инструментов, помогающих командам управлять своей работой и отслеживать результаты. Среди наиболее популярных из них: JIRA Agile, Rally, VersionOne и Pivotal Tracker. Все они облегчают планирование спринтов и бэклогов, а также общее управление процессом. Члены команды используют их, в том числе, для отслеживания хода реализации каждой пользовательской истории, например, путем присвоения ей различных статусов готовности: «для разработки», «в разработке», «кодирование выполнено», «готово».

В целях отслеживания прогресса команды часто используют график выполнения спринта, который показывает, какой объем работы осталось выполнить для завершения итерации. На таком графике оставшийся объем работы отражается либо в баллах, либо в часах, в зависимости от выбранной единицы измерения. На Рисунке 12.3 показан пример дневного графика выполнения скрипта, где по горизонтальной оси указаны дни спринта, а по вертикальной – количество оставшихся до завершения баллов истории. График берет свое начало в «нулевой день» спринта с количеством не отработанных баллов, равным, в данном случае, 45. На горизонтальной оси отложены 10 дней, что соответствует двухнедельному спринту (учитываются только рабочие дни). В идеале, в конце спринта количество не отработанных баллов должно равняться нулю.

Тестирование качества проводится во время спринта. Чтобы добиться более высокой скорости разработки, члены команды должны тестировать истории сразу после их реализации. Если отработанная история соответствует критериям приемлемости, она считается завершенной; в противном случае она отклоняется и возвращается в разработку. Необходимо также предусмотреть в конце спринта время на тестирование результатов разработки и исправление возможных ошибок. Далее в этой главе мы рассмотрим тему тестирования более подробно.

Рисунок 12.3. График выполнения спринта

Цель, которая должна достигаться в конце каждого спринта, состоит в «приращении» функциональности продукта. Руководство по Scrum предписывает командам определять, что именно в их случае будет подразумеваться под статусом «Готово». Многие команды понимают под готовностью так называемый «выпущенный продукт» или «потенциально выпущенный продукт». Во многих случаях количество выпусков продукта соответствует количеству итераций, когда результаты спринта представляются клиентам вскоре после завершения спринта. Другие разработчики организуют более длительные циклы, когда выпуск продукта происходит по результатам нескольких спринтов. В любом случае цель состоит в том, чтобы к окончанию спринта обеспечить готовность продукта к выпуску. По завершении каждого спринта члены команда проводят обзорное совещание по спринту (также называемое демонстрационным совещанием), на котором они показывают результаты своей работы. Это позволяет гарантировать, что продукт работает должным образом, и делает прогресс команды более заметным. В идеале для участия в таких совещаниях приглашаются клиенты или иные заинтересованные лица, чтобы они могли оставить свои отзывы, которые будут учтены при проведении последующих спринтов.

Как и другие Agile-методологии, Scrum фокусируется на последовательном улучшении рабочих процессов. Для достижения этой цели команды проводят ретроспективы, в ходе которых обсуждают, как прошел их последний спринт, что сработало хорошо, что пошло не так, и какие улучшения стоит внедрить при проведении следующего спринта. Некоторые команды проводят такие обсуждения после каждого спринта; другие делают это по итогам двух или трех спринтов.

Это был лишь краткий обзор методологии Scrum – если вы хотите узнать о ней больше, ознакомьтесь с последней версией руководства по Scrum по ссылке: http://scrumguides.org.

Канбан

Другой популярной разновидностью Agile-разработки является Канбан – процесс, созданный на основе системы, разработанной автоконцерном Toyota для улучшения сборки автомобилей. Система Toyota ориентирована на производство по принципу «точно в срок» и ликвидацию отходов (издержек). Я изучал оригинальную систему Канбан и принципы бережливого производства во время обучения в аспирантуре Технологического института Вирджинии.

На производстве работники используют бумажные карточки – «канбан» – в качестве сигналов, передаваемых на предыдущий этап процесса, о необходимости пополнения запасов (заготовок). Канбан был адаптирован для целей разработки программного обеспечения с применением виртуальных карточек, каждая из которых представляет находящееся в работе задание, но при этом уже не выполняет сигнальной функции. Основным принципом Канбана является визуализация рабочего процесса. Каждая карточка представляет собой историю пользователя или относящееся к ней задание для разработки. Карточки помещают на специальную канбан-доску, состоящую из набора столбцов, каждый из которых соответствует определенной стадии рабочего процесса. Столбцы расположены слева направо в том порядке, в котором выполняется работа. Пример канбан-доски приведен на Рисунке 12.4. Здесь вы можете видеть следующий набор столбцов (стадий рабочего процесса) слева направо: «Бэклог», «Подготовлено», «В процессе разработки», «Разработка завершена», «В процессе тестирования», «Тестирование завершено» и «Выпуск», которые определяются следующим образом:

• Бэклог: рабочие задания, которые членам команды предстоит взять в работу, отсортированные по приоритетности.

• Подготовлено: задания, которые были взяты из бэклога, и готовы к передаче в разработку.

• В процессе разработки: задания, разработка которых происходит в данный момент.

• Разработка завершена: задания, прошедшие этап разработки, но еще не переданные на тестирование.

• В процессе тестирования: задания, находящиеся в процессе тестирования.

• Тестирование завершено: задания, которые успешно прошли тестирование, но еще не были выпущены.

• Выпуск: задания, которые были выпущены после их разработки и тестирования.

Некоторые столбцы канбан-доски представляют выполняемую работу (например, «В процессе разработки», «В процессе тестирования»), в то время как другие обозначают стадии ожидания обработки (например, «Подготовлено», «Завершено»). Столбцы последнего типа дают представление о состоянии очереди на выполнение работ. Когда член команды завершает работу над одним заданием, он берет верхнюю карточку следующего задания из тех, что находятся в соответствующей очереди, и начинает работать над ним.

Рисунок 12.4. Пример канбан-доски

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

Возможно, вы заметили, что каждый из столбцов «Разработка» и «Тестирование» на Рисунке 12.4 разделен на два подраздела: один из которых обозначает нахождение задания в процессе работы, а другой соответствует завершенному состоянию. Это позволяет составить более четкое представление о текущем рабочем процессе и его узких местах.

В Канбане количество заданий, находящихся в активном состоянии, регулируется путем ограничения объема «незавершенных процессов» или сокращенно – НЗП. Команда определяет максимальное количество карточек, которое может накапливаться в каждом столбце, что представляет собой лимит НЗП. Члены команды последовательно перемещают карточки заданий между этапами работы. Однако они могут перенести карточку в следующий столбец только в том случае, если там имеется свободное место (то есть лимит карточек, находящихся в следующем столбце, еще не исчерпан). Это правило помогает выровнять процессы обработки и добиться стабильного рабочего потока. Командам предписано периодически корректировать установленные лимиты НЗП в целях оптимизации рабочего процесса. На канбан-доске размер лимита НЗП указывается над каждым столбцом. Как показано на Рисунке 12.4, команды часто используют единый лимит НЗП для связанных стадий одного этапа – «В процессе» и «Завершено». Например, общее количество карточек в столбце «Разработка» (включая обе его стадии: «В процессе» и «Завершено») не может быть больше трех. Это помогает стимулировать более быстрое продвижение карточек, находящихся в ожидания обработки.

Возьмем для примера ситуацию, представленную на Рисунке 12.4. Когда разработчик завершит работу над заданием D, он переместит его карточку из столбца «В процессе» в столбец, соответствующий стадии «Завершено». Однако при этом он не сможет перенести задание F из состояния «Подготовлено» в столбец «Разработка», поскольку лимит НЗП для этой стадии, равный трем карточкам, уже исчерпан. Аналогично, когда тестировщик завершит работу с заданием B, он переместит его карточку в столбец «Тестирование завершено», но не сможет взять в работу задание C, поскольку для стадии «Тестирование» исчерпан лимит НЗП, равной двум карточкам. Для продолжения работы необходимо «вытолкнуть» одну из карточек из столбца «Тестирование завершено». Как только это произойдет, задание C может быть переведено в состояние «В процессе тестирования», что, в свою очередь, освободит место в столбце «Разработка» для задания F.

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

Основное внимание в Канбане уделяется рабочему потоку. Здесь нет ограниченных по времени итераций, как это принято в Scrum. Карточки рабочих заданий непрерывно перемещаются слева направо по канбан-доске по мере выполнения работы. В Канбане не применяется обязательная оценка масштаба пользовательских историй, поэтому Scrum-концепция скорости выполнения работы (количество баллов пользовательских историй, отрабатываемых за одну итерацию) в этом случае не работает. Тем не менее, вы можете измерить так называемую пропускную способность команды, просто оценив количество рабочих заданий, выполненных за определенный промежуток времени, например, 10 заданий в неделю. Если вы отслеживаете изменение производительности работы вашей команды во времени, то она должна увеличиваться за счет постепенного совершенствования рабочих процессов и накопления опыта.

Двумя наиболее часто используемыми показателями в Канбане являются продолжительность цикла – среднее количество времени, проходящего с момента начала разработки до момента выпуска; и время выполнения заказа – среднее количество времени, проходящего с момента создания заказа (например, по запросу клиента) до момента сдачи готового результата работы. Важно отметить, что продолжительность цикла и время выполнения заказа не обязательно коррелируют с затраченными усилиями. Так, непосредственно разработка и тестирование может занять всего час, но при этом время выполнения окажется гораздо большим, если задание долго лежало в очереди на отработку.

Вы можете визуализировать ход работы в системе Канбан с помощью диаграммы кумулятивного потока (Рисунок 12.5), которая показывает, сколько карточек заданий находилось в каждом из рабочих состояний в конце каждого дня. Для простоты на Рисунке 12.5 отслеживаются только три вида рабочего состояния: «Бэклог», «В процессе» и «Завершено». Вы можете видеть, что продолжительность цикла измеряется горизонтальной толщиной слоя, относящегося к заданиям, находящимся «В процессе», а показатель времени выполнения равен суммарной горизонтальной толщине слоев, отражающих количество заданий в «Бэклоге» и «В процессе». Количество НЗП равно вертикальной толщине слоя, характеризующего количество заданий, находящихся «В процессе».

Рисунок 12.5. Диаграмма кумулятивного потока

Мышление Канбан ориентировано на постоянное совершенствование, поэтому команда должна на регулярной основе выявлять и обсуждать способы работать лучше и быстрее. Идея заключается в том, что показатели времени выполнения заказа и продолжительности цикла должны снижаться по мере того, как команда совершенствует процессы и становится более опытной.

Многие команды работают с бэклогами, находящимися в подвижном состоянии; задания, которые изначально считались важными, теряют свой приоритетный статус по мере добавления новых заданий. В отличие от подхода Scrum, который предусматривает, что бэклог спринта остается неизменным в течение всего времени прохождения итерации, члены команды, работающей по Канбану, могут изменять порядок расстановки заданий бэклога в любой момент. При этом необходимо также отслеживать, сколько времени занимает подготовка заданий бэклога к разработке, чтобы убедиться, что на этой стадии не происходит снижения пропускной способности команды.

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

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

Инструменты Канбана

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

Однако существует множество цифровых инструментов для управления канбан-процессами. Одним из наиболее популярных приложений для визуализации канбан-доски в ходе разработки программного обеспечения является Trello. На самом деле, многие используют Trello для управления и другими рабочими процессами. Это приложение особенно популярно среди менеджеров по продуктам и дизайнеров. Они используют собственные рабочие панели, которые могут подключаться к канбан-доскам разработчиков. Многие канбан-команды используют такие приложения, как JIRA Agile, SwiftKanban и LeanKit.

Еще одним достойным внимания приложением является Pivotal Tracker, хотя оно и не относится к инструментам, специализированным для Канбана. Я использовал Tracker при создании нового продукта, когда получал полезный опыт работы с Pivotal Labs. Это приложение использует виртуальную доску со столбцами, отведенными для каждого из заранее определенных рабочих состояний. Данный инструмент поддерживает интересное сочетание Канбана и Scrum (существует даже Agile-методология под названием «Scrumban», которую будет полезно изучить, если эта идея выглядит для вас привлекательной).

Приложение Pivotal Tracker позволяет оценивать пользовательские истории в баллах и вычислять скорость выполнения работы. Такой подход в большей степени соответствует методологии Scrum, за тем исключением, что бэклог текущего спринта не фиксирован, а определяется динамически. По умолчанию истории пользователей сортируются на основе количества присвоенных им баллов и автоматически включаются в текущую итерацию и выходят из нее. При этом ведется учет расчетной скорости отработки и времени, оставшегося до завершения спринта. Если вас не устраивает такая настройка, вы можете воспользоваться режимом «ручного планирования» (называемым также режимом «фиксации»), который позволяет зафиксировать порядок расположения историй в бэклоге спринта. В том случае, если вы не воспользуетесь перечисленными опциями, работа приложения будет в большей степени соответствовать методологии Канбана.

Выбор правильного метода Agile-разработки

Теперь, когда у вас есть общее представление о Scrum и Канбане, осталось решить, какой из методов больше подходит для использования в вашем конкретном случае. Несмотря на то что приверженцы каждой из этих методологий видят в них серьезные различия, на самом деле оба подхода построены на общих принципах Agile. Я обнаружил, что Agile-фреймворки подобны обуви: чтобы понять, насколько хорошо вам подходят те или иные туфли, их нужно просто примерить. Разумный выбор подходящей методологии состоит в том, чтобы поочередно опробовать их в течение нескольких месяцев. Многие команды начинают с того, что пробуют применять либо Scrum, либо Канбан. Если методология работает хорошо, они продолжают ее придерживаться. Если нет, переходят к следующей. Примерив обе «пары обуви», команда получит все необходимое, чтобы решить, какая из них подходит ей лучше.

Тем не менее, вот несколько советов, которые увеличат шансы начать «выбор обуви» с наиболее подходящего варианта: Канбан, как правило, подходит для небольших команд разработчиков. Меньшие накладные расходы и отсутствие заранее определенной продолжительности итерации могут обеспечить более быстрый выпуск продукта. Но, по мере того как компания разрастается до нескольких команд разработчиков, применение Канбана может становиться все более сложным. Отсутствие строго определенного графика выполнения работы может усугубить ситуацию, поскольку многочисленным группам разработчиков требуется больше времени на коммуникации, чтобы оставаться на одной волне. Команды, которые имеют хороший опыт совместной работы, способны масштабировать Канбан до больших размеров без негативных последствий. Но, если в вашей компании есть несколько команд, которым необходимо координировать свою работу, то Scrum с его предсказуемым темпом разработки может оказаться более полезным.

Идея жестких плановых сроков запуска новых продуктов плохо соотносится с любыми методами гибкой разработки. Большинство компаний, применяющих «водопадный» подход, привыкли к тому, что у них есть нисходящая дорожная карта, которая диктует, какие функции они должны запускать каждый месяц или квартал, хотя эти сроки часто оказываются фикцией из-за регулярных задержек. При переходе на Agile многие из них по-прежнему придерживаются «водопадного» подхода в отношении бэклогов своих продуктов. Мне нравится использовать термин «Agilefall»[24] для описания компаний, переживающих трудности перехода с «водопадного» подхода на Agile и пытающихся поначалу усидеть сразу на двух стульях. Если вашей команде будет трудно отказаться от «подушки безопасности» в виде жестких сроков запуска, то вам, скорее, подойдет Scrum, нежели Канбан. По крайней мере, используя Scrum, вы знаете, что определенный объем работ будет выполнен к концу каждой итерации, и можете примерно оценить, сколько спринтов потребуется для запуска той или иной функции. Большинство команд, работающих по Канбану, не тратят время на оценку трудоемкости или планирование сроков завершения работ. Тщательно отслеживая продолжительность цикла и используя простые статистические методы, даже в случае с применением Канбана можно делать относительно достоверные прогнозы в отношении срока запуска продукта, однако лишь немногие команды разработчиков могут похвастаться настолько высоким уровнем точности отслеживания своих рабочих процессов.

Независимо от того, какую методологию Agile вы выберете, я настоятельно рекомендую использовать при этом хороший инструмент, предназначенный для управления ходом работ. Одна из ошибок, которую допускают некоторые команды, заключается в использовании инструмента общего назначения вместо того, который оптимизирован именно под вашу методологию разработки. Опять же, я рекомендую проводить апробацию того инструмента, который, как вы считаете, лучше всего подходит для вашего случая. Если через месяц или два он вас разочарует, попробуйте другой.

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

Возможно, совместное посещение членами команды тренинга по Agile стнет в такой ситуации весьма удачным решением. Я знаю множество примеров, когда команды внедряли новую методологию разработки в условиях отсутствия достаточного уровня понимания у всех участников. Неудивительно, что многие из этих команд испытывали трудности. Прежде чем внедрять новую методологию, неплохо было бы оценить степень готовности каждого члена команды. Даже если некоторые из них имели дело со Scrum или Канбаном на предыдущих местах работы, есть вероятность, что практическое применение любой из этих методологий имело там свои особенности. Если вы не будете устанавливать для членов команды новых ожиданий, они, скорее всего, решат, что вы следуете тем методам, с которыми они уже знакомы. Очень важно, чтобы все участники одновременно услышали одно и то же объяснение того, как должен протекать процесс разработки продукта. Это позволит гарантировать наличие одинакового понимания, отсутствие недоразумений и повышение производительности.

Достижение успеха с помощью Agile

Независимо от того, какую методологию Agile вы выберете, приведенные ниже дополнительные советы должны помочь добиться успеха в создании продукта.

Взаимодействие внутри команды

Одной из основ Agile является тесное межфункциональное взаимодействие, под которым подразумевается свободное постоянное общение между менеджерами по продуктам, дизайнерами, разработчиками, тестировщиками и любыми другими членами команды. Важно избегать создания изолированных подсистем, в которых каждая функциональная группа живет собственной жизнью и перебрасывает свою часть продукта «через стену» для перехода на следующий этап рабочего процесса. Живые коммуникации в режиме реального времени имеет решающее значение для достижения максимального взаимопонимания и высокой скорости работы команды. Эффективность совместной работы поддерживается также за счет использования таких средств коммуникации, как чаты, инструменты для отслеживания разработки (например, JIRA Agile), а также приложения для совместной работы с базами знаний (например, wiki или Google Docs).

Каждая функция должна быть задействована на протяжении всего процесса разработки, хотя вполне естественно, что на определенном этапе какая-то из них будет задействована в большей степени, если ей определена ведущая роль. Короче говоря: менеджеры по продуктам пишут пользовательские истории, затем проектировщики создают соответствующие артефакты, для которых разработчики пишут программный код, после чего тестировщики проводят проверку полученного результата. Каждый занят своим делом, но при этом разработка продукта – это командный вид спорта. Разработчики и тестировщики должны в определенной степени участвовать в ранних стадиях рабочего процесса, чтобы понимать, на чем основаны пользовательские истории, UX-дизайн и другие базовые решения в отношении продукта. Они должны быть заинтересованы в том, чтобы задавать вопросы и вносить свой вклад на всех этапах рабочего процесса. Аналогичным образом менеджеры по продуктам и дизайнеры должны быть в курсе событий, происходящих в зоне ответственности разработчиков и тестировщиков, тем более что там часто возникают непредвиденные вопросы или неполадки. В Intuit у нас была любимая поговорка: хорошие идеи приходят отовсюду. О достигнутом внутри команды уровне сотрудничества можно судить по тому, насколько чаще члены команды, говоря о своих коллегах, употребляют местоимение «мы» вместо «они».

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

Жесткая расстановка приоритетов

Вы должны поддерживать актуальность бэклога с учетом приоритетности входящих в него заданий. Важно иметь четкое представление о наборе пользовательских историй, которые планируется отработать в следующем цикле, как только для этого появятся ресурсы. Применение такого подхода позволяет действовать быстро. Команды разработчиков высокотехнологичных продуктов обычно работают в динамичной среде, для которой характерна быстрая смена требований и приоритетов. При этом явно недостаточно присваивать заданиям такие нечеткие приоритеты, как высокий, средний и низкий. Если в бэклоге будет 15 заданий с высоким приоритетом, то как понять, к какому из них разработчик должен приступить в первую очередь? Поэтому необходимо дополнительное ранжирование заданий, входящих в состав бэклога. Я являюсь сторонником жесткой расстановки приоритетов (в противовес расплывчатому ранжированию заданий). Четкая расстановка заданий внутри бэклога дает ясное понимание того, какое из них стоит первым в очереди на отработку. Это также значительно облегчает определение места в бэклоге для вновь поступающих заданий.

Тонкость заключается в том, что жесткая расстановка приоритетов не означает отсутствие гибкости этого процесса. Вы должны четко представлять себе приоритеты ранжирования в любой момент времени; но при этом также должны уметь быстро реагировать на изменение существующих или появление новых требований. Я вижу здесь аналогию с водой и льдом. Большую часть времени бэклог подобен льду: порядок ранжирования находящихся в нем заданий фиксирован – находится в замороженном состоянии. Но с появлением новых требований или изменением приоритетов вы на короткое время растапливаете лед, переводя его в жидкое состояние, чтобы произвести перенастройку. После определения новой очередности выполнения заданий вы снова замораживаете свой бэклог. Следование такому подходу гарантирует, что всякий раз, когда кто-то из членов команды обращается к бэклогу за получением нового задания, он имеет дело с его максимально актуальной версией. Таким образом, разработчик может просто брать задание, стоящее первым в очереди, ни с кем при этом не советуясь и не тратя время на получение дополнительных подтверждений.

Создавайте для разработчиков адекватное описание продукта

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

Опережайте разработчиков

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

Другими словами, к сроку окончания спринта N они должны уже подготовить артефакты проектирования для спринта N+1 или даже N+2. Конечно, для этого проектировщикам потребуются качественно написанные пользовательские истории, поэтому менеджеры по продукту должны в свою очередь опережать дизайнеров также на один или два спринта.

Цель состоит в том, чтобы убедиться, что вы никогда не заставите разработчиков сидеть без дела, и у вас наготове всегда будет бэклог для очередного спринта. Это также требует соблюдения баланса, поскольку делать заранее слишком много заготовок для спринтов может быть неразумно из-за того, что все может измениться. Несмотря на то что я описал ситуацию в терминах Scrum, это также справедливо и для Канбана. Исходя из продолжительности цикла работы дизайнеров, продакт-менеджер должен обеспечить достаточное количество заданий, готовых для проектирования. Аналогично, исходя из продолжительности цикла разработки, дизайнеры должны обеспечить достаточное количество карточек заданий в столбце «Готово для разработки».

Ни менеджеры по продуктам, ни проектировщики не должны работать в вакууме. Необходимо выделить определенное количество времени в текущем спринте на то, чтобы члены команды могли просмотреть и обсудить пользовательские истории и проекты для будущих спринтов.

Разбивайте истории на фрагменты

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

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

До этого момента речь шла об использовании методов Agile в проектировании и разработке. Еще одной важной частью процесса создания продукта является тестирование, когда вы проверяете качество результата, полученного в ходе разработки, прежде чем представить его заказчикам. Тестирование – это составляющая часть обеспечения качества, более широкой дисциплины, связанной с созданием высококачественных рыночных продуктов.

Гарантия качества

Программные продукты являются сложными по своей природе. Лишь в очень редких случаях они работают на 100 % идеально, поэтому вам необходимо иметь некий план обеспечения качества продукта, прежде чем вы начнете предлагать его покупателям. Отсутствие должного контроля за качеством продукта может привести к головным болям, которые могут обеспечить раздраженные клиенты, потеря дохода и невосполнимые потери ресурсов команды.

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

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

Обзор кода другим разработчиком помогает обнаружить ошибки, пропущенные его коллегой. Кроме того, он часто может предложить хорошие идеи по улучшению написанного кода. Такие проверки позволяют находить и исправлять ошибки до начала этапа тестирования и являются отличным способом учиться друг у друга.

Еще одним шагом в том же направлении является парное программирование – это метод, предусматривающий, что созданием программного кода одновременно и совместно занимаются сразу два разработчика. Они сидят рядом друг с другом за одним компьютером и клавиатурой, глядя в один и тот же экран. Разработчик, которому досталась роль «драйвера», занимается непосредственным написанием кода. Второй разработчик играет роль «наблюдателя» и просматривает код по мере его создания партнером. Затем они меняются ролями. Работа в паре способствует обучению и обычно приводит к улучшению дизайна и качества продукта. Парное программирование – это центральный принцип экстремального программирования, еще одной популярной методологии Agile.

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

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

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

Второй из требующих проверки аспектов состоит в том, чтобы ни одна из имеющихся функциональных возможностей продукта не была непреднамеренно нарушена в процессе создания новой или улучшения существующей функции. Другими словами, после добавления в состав продукта функции D вы хотите убедиться, что функции A, B и C работают так, как они работали до внедрения функции D. Это называется регрессионным тестированием. В этом контексте слово «регресс» означает «ухудшение текущего состояния», то есть внесение в существующий функционал ошибки, которой там раньше не было.

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

Разработка через тестирование

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

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

Непрерывная интеграция

Многие команды для ускорения разработки продуктов применяют метод непрерывной интеграции. Чтобы объяснить, что это значит, нужно начать с описания того, как разработчики программного обеспечения осуществляют управление создаваемым кодом. Обычно для этого используют систему контроля версий, позволяющую отслеживать и управлять всеми вносимыми в программный код исправлениями. Контроль версий также упрощает процесс восстановления кодовой базы до любого предшествующего состояния, благодаря чему нежелательные изменения могут быть отменены. На момент написания этой книги, пожалуй, самой популярной системой контроля версий для Agile-разработки является Git.

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

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

Непрерывное развертывание

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

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

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

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

Сразу после запуска продукта вы сможете на практике ощутить всю ценность аналитики. Надежная аналитическая платформа поможет понять, как развивается ваш бизнес и как клиенты используют ваш продукт. Анализ динамики отслеживаемых показателей во времени и по мере внедрения различных изменений снабдит вас ценной информацией, которая поможет добиться существенных улучшений. В следующих двух главах рассказывается о том, как использовать аналитику для оптимизации вашего продукта и бизнеса.

Глава 13

Измерение ключевых показателей

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

Аналитика в сравнении с другими методами исследования

Прежде чем погрузиться в описание аналитических методов, я хочу поделиться с вами полезным фреймворком, созданным моим коллегой Кристианом Рорером, успешным специалистом в области UX-дизайна и исследования потребителей. Он позволяет классифицировать различные способы обучения путем проведения пользовательских исследований. На Рисунке 13.1 показана упрощенная версия фреймворка Рорера. Вертикальная ось – тип информации, которую вы собираете. Она может быть отношенческой или поведенческой. Отношенческая (аттитюдная) информация – это то, что клиенты говорят о своих установках и мнениях. Допустим, вы показываете клиенту макет целевой страницы. Он говорит, что ему нравится зеленая цветовая гамма и что он, скорее всего, нажмет на расположенную на этой странице большую кнопку «Купить». Оба эти утверждения передают отношенческую информацию.

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

Рисунок 13.1. Структура методов исследования

По горизонтальной оси на Рисунке 13.1 показан подход к сбору информации, который может быть либо качественным, либо количественным. Допустим, вы проводите индивидуальные интервью с 10 потенциальными клиентами, пытаясь понять их потребности и предпочтения. Или же вы наблюдаете, как клиент пользуется вашим сайтом. И в том, и в другом случае вы проводите качественное тестирование, то есть исследование, основанное на непосредственном взаимодействии с пользователями.

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

Опра против Спока

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

Я использую для сравнения качественного и количественного подходов к исследованию потребителей выражение: «Опра против Спока». Популярная телеведущая Опра [Уинфри, – прим. пер.] является олицетворением качественного подхода; она общается со своими гостями один на один и проводит долгие, углубленные интервью, в ходе которых узнает о своих собеседниках много нового и получает их мнения по разным вопросам. С другой стороны, Спок – очень логично мыслящий персонаж сериала «Звездный путь» – ориентирован исключительно на количественные метрики; он основывает все свои решения строго на объективных данных и цифрах. Когда вы пытаетесь понять, насколько первая версия вашего продукта соответствует требованиям рынка, вам должен быть более близок подход Опры. Затем, после выхода продукта на рынок, вы все еще можете продолжать использовать качественный подход, но в интересах дальнейшей оптимизации будет полезно применить и метода Спока.

Интервью с пользователями

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

Тестирование юзабилити

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

Даже если основное внимание уделяется удобству использования продукта, в большинстве случаев результаты пользовательского тестирования состоят из смеси поведенческой и отношенческой информации. Коротко повторю то, что подробно обсуждалось в главе 9: важно четко представлять себе, какого рода информацию вы хотите получить от пользователя в ходе тестирования и какого рода сведения он вам предоставляет на самом деле.

Опросы

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

Ранее я уделил опросам гораздо меньше внимания, чем другим типам пользовательских исследований. Это объясняется в первую очередь тем, что я слишком часто сталкивался с примерами злоупотребления данным методом. Хорошо спланированный опрос может принести полезные сведения. Но при этом необходимо четко осознавать, для чего именно вы можете их использовать, и не выходить за очерченные границы. Если вы попросите 1000 человек оценить по шкале от 1 до 10, насколько вероятно, что они воспользуются новым, простым в использовании приложением для обмена фотографиями, которое вы планируете создать, это будет злоупотреблением. Почему? Во-первых, они почти ничего не знают о вашем продукте. Предложенное вами описание: «новое, простое в использовании приложение для обмена фотографиями» содержит всего восемь слов информации. Это не живой продукт, не набор кликабельных вайрфреймов и даже не макет, поэтому у опрашиваемых людей не так много данных, на которые они могли бы опереться, чтобы сформировать объективное суждение. Как в таком случае они могут с точностью предсказать, будут ли они пользоваться вашим приложением или нет? Раз за разом я наблюдаю, как создатели опросов просят респондентов высказать свое мнение о том, о чем у них нет достаточно полного представления.

Во-вторых, поскольку опросы направлены на получение отношенческой информации, вы должны воспринимать полученные результаты соответствующим образом. Люди могут давать положительные или отрицательные ответы на вопрос о том, насколько вероятно, что они будут использовать новый продукт; но эти ответы часто не совпадают с реальным поведением. Я бы предпочел этому проведение «Дымового теста» с использованием целевой страницы, на которой разместил бы кнопку «Купить», или попросил людей указать свой адрес электронной почты для включения в список ожидания бета-тестирования. Затем я бы отследил значение показателя конверсии. Собранные таким образом поведенческие данные дали бы более точный ответ по сравнению с результатами, полученными в ходе опроса.

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

Итак, если опросы не годятся для получения ответов на определенные виды вопросов, то для чего же они тогда подходят? Они хорошо работают в тех случаях, когда вы хотите узнать мнение респондентов в отношении хорошо известной им темы. Например, в главе 4 обсуждалась возможность использования опросов при измерении показателей важности и удовлетворенности. Опросы могут помочь понять, как люди относятся к вашему продукту и бренду. Вы также можете использовать этот инструмент, чтобы увидеть, как клиенты воспринимают ваш продукт в сравнении с его рыночными аналогами. Отслеживающие опросы, когда респондентам задаются одни и те же вопросы через определенные промежутки времени, могут быть полезны для выявления трендов.

Чистая оценка промоутера

Одним из наиболее широко используемых опросных показателей является чистая оценка промоутера («индекс лояльности», – прим. пер.), или сокращенно – NPS. Этот показатель основан на ответах респондентов всего на один вопрос: «Какова вероятность того, что вы порекомендуете [продукт X] другу или коллеге?» Шкала оценки «вероятности рекомендации» имеет диапазон от 0 до 10, где 10 означает «весьма вероятно», а 0 – «очень маловероятно». Респондентов, дающих оценку в 9 или 10 баллов, называют промоутерами; тех, кто ставит 7 или 8 баллов, – пассивными; а тех, кто оценивает такую вероятность от 0 до 6 баллов, – недоброжелателями. Чтобы рассчитать значение NPS, нужно из процента промоутеров вычесть процент недоброжелателей.

Значение показателя NPS может варьироваться в диапазоне от -100 до 100. По своему смыслу NPS является показателем отношения потребителей к продукту и косвенным показателем его соответствия рынку. Пользователи будут рекомендовать только тот продукт, которым они очень довольны. Среднее значение NPS, полученное по результатам одного раунда опроса имеет определенный смысл, но основную ценность представляет отслеживание динамики NPS продукта с течением времени по результатам периодически повторяемых опросов. По мере того как вы вносите в свой продукт улучшения, повышая тем самым степень его соответствия рынку, показатель NPS должен увеличиваться. Конечно, при возникновении проблем данный показатель может снижаться. Как измеритель общего настроения клиентов, он может свидетельствовать о наличии проблем в широком спектре областей, выходящих за рамки непосредственно продукта, включая качество обслуживания или технической поддержки. По этой причине важно включить в состав опроса открытый вопрос о том, почему респондент выставляет ту или иную оценку. Кроме этого, бывает полезным сравнение показателя NPS своего продукта с аналогичной метрикой конкурентов и ее эталонным значением для соответствующей продуктовой категории.

Вопрос Шона Эллиса о соответствии продукта рынку

Шон Эллис – талантливый маркетолог и практик бережливого стартапа – человек, который придумал термин «хакер роста» и управляет сайтом сообщества http://growthhackers.com. Эллис также является генеральным директором компании Qualaroo, занимающейся анализом потребностей клиентов http://qualaroo.com. Многие компании обязаны ему активным ростом числа своих клиентов.

Эллис, как и я, считает, что не следует вкладывать средства в развитие бизнеса до тех пор, пока выпускаемый продукт не добьется соответствия рынку. Для оценки степени соответствия он предлагает использовать опросы, в ходе которых вы должны спросить пользователей продукта: «Как бы вы себя чувствовали, если бы больше не могли пользоваться [продуктом X]?» Респондентам предлагается четыре возможных варианта ответа:

• Весьма разочарован.

• Немного разочарован.

• Не разочарован (без него вполне можно обойтись).

• Нет ответа – Я больше не пользуюсь [продуктом X].

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

Аналитика и A/B-тестирование

Верхний правый квадрант на Рисунке 13.1 соответствует исследованию, имеющему количественный и поведенческий характер. Именно здесь применяются аналитика и A/B-тестирование. Аналитика позволяет получить измеримую оценку реального поведения клиентов, поэтому в этом случае вам не приходится беспокоиться о каком-либо несоответствии между словами и реальными действиями клиентов. Кроме того, в отличие от качественных исследований поведения пользователей, аналитика агрегирует поведение большого числа клиентов, тем самым позволяя делать статистически значимые выводы.

Для примера, допустим, что у вас есть целевая страница. Анализ показывает, что коэффициент конверсии составляет всего 5 %, что намного ниже ожидаемых вами значений. По этой причине вы разрабатываете новую, улучшенную версию целевой страницы. Вы проводите юзабилити-тесты и просите пользователей дать обратную связь в отношении новой страницы. Отзывы оказываются в целом положительными; 9 из 10 пользователей указали, что они бы нажали кнопку «Зарегистрироваться». Вы решаете запустить страницу. До того как вы это сделаете, вы на самом деле не можете реально оценить влияние ее нового дизайна. Реальный коэффициент конверсии вряд ли составит 90 %. Это значение искусственно завышено из-за особенностей модерируемого юзабилити-тестирования. Да, можно ожидать, что коэффициент конверсии повысится, но, насколько серьезным будет это повышение, невозможно определить, основываясь только на результатах юзабилити-теста.

A/B-тестирование позволяет отправить одну часть пользовательского трафика на новую версию целевой страницы, а другую – на старую версию, отслеживая при этом результаты каждого из вариантов. Таким образом, вы сможете узнать, насколько велика разница в значениях коэффициента конверсии. Если объем пользовательского трафика достаточно велик, степень достоверности такого количественного сравнения будет приемлемо высокой.

Аналитика имеет огромное практическое значение для любой команды разработчиков, поскольку позволяет понять, как клиенты используют разработанный ей продукт. При этом аналитика не может дать вам полной картины. Для того чтобы лучше узнать своих клиентов, необходимо также проводить качественные исследования. Но без аналитики вы будете действовать вслепую. Перефразируя Питера Друкера[25], вы не можете управлять тем, что не измеряете. A/B-тестирование основывается на аналитике и дает возможность с достаточной степенью точности оценить влияние вносимых изменений. Это способствует созданию платформы для экспериментов и обеспечивает бережливые команды мощным инструментом для быстрого внедрения инноваций.

Стоит отметить, что полная версия фреймворка Рорера включает в себя еще и третье измерение для определения «контекста использования». Дополнительная шкала предусматривает наличие разных контекстов использования продукта в зависимости от метода исследования: «естественное использование» (например, для аналитики), «использование по сценарию» (например, для юзабилити-тестов) и «без использования продукта» (например, для поисковых интервью). Я рекомендую вам ознакомиться с полной версией этого фреймворка, которая классифицирует 20 различных методов UX-исследования. Вы можете найти ее на веб-сайте Nielsen Norman Group по ссылке: http://nngroup.com/articles/which-uxresearch-methods. Вы можете также ознакомиться с другими публикациями в блоге Рорера по ссылке: http://xdstrategy.com.

Теперь, когда мы выяснили, как сочетаются аналитика и A/B-тестирование, давайте обсудим некоторые схемы применения этих мощных инструментов.

Аналитические фреймворки

Для любого бизнеса существует множество метрик, отслеживая которые можно понять, как он работает. С учетом наличия такого большого количества различных показателей, которые вы могли бы попытаться улучшить, очень полезно иметь целостную аналитическую систему, охватывающую все аспекты вашего бизнеса. Наличие такой системы позволяет обеспечить четкое представление о том, как различные показатели влияют друг на друга, и может помочь в определении того, на чем вам следует сосредоточиться.

Аналитика в Intuit

Во время своей работы в компании Intuit после запуска очередного веб-продукта я задался целью отслеживать его метрики с целью дальнейшего улучшения как самого продукта, так и связанных с ним бизнес-аспектов. Для этого я создал аналитическую систему, которая охватывала четыре основных элемента нашего бизнеса:

1. Привлечение: Сколько потенциальных клиентов (новых посетителей) привлекают на наш веб-сайт реализуемые маркетинговые программы?

2. Конверсия: Какой процент посетителей нашего сайта регистрируются в качестве клиентов?

3. Удержание: Какой процент наших клиентов остаются активными в течение продолжительного времени?

4. Доход: Сколько денег приносят наши клиенты?

После выхода продукта на рынок у него появились подписчики, которые приносили нам доход. Это вселяло в нас уверенность в том, что продукт соответствует рынку. Но одновременно с этим мы поняли, что имеется проблема с конверсией: доля посетителей веб-сайта, подписавшихся в итоге на наш продукт, оказалась заметно ниже ожиданий. Специфика продукта требовала применения многоступенчатого процесса регистрации, который занимал несколько веб-страниц. Используя аналитику, мы измерили, сколько потенциальных клиентов отсеивалось на каждом этапе этого процесса. Затем провели юзабилити-тестирование с участием пользователей, сосредоточив внимание на самых проблемных областях. В итоге мы обнаружили несколько проблем с UX-дизайном. Полученные знания были использованы для быстрой разработки целенаправленных улучшений. После их внедрения мы увидели 40 %-ное повышение коэффициента конверсии. Самое забавное, что благодаря тому, что мы построили очень подробную модель с различными вариантами использования продукта и решений проблем юзабилити, а также располагали точными данными о показателях, мы смогли предсказать повышение с точностью до двухпроцентных пунктов.

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

Аналитика во Friendster

Два года спустя, присоединившись к разработчикам новаторской социальной сети Friendster, я решил вновь использовать аналитику для отслеживания и улучшения продукта и бизнеса. С этой целью я разработал новый фреймворк. Руководители компании согласились с тем, что ключевым показателем для их продукта является количество пользователей. Социальные продукты выигрывают за счет сетевого эффекта, означающего, что их ценность растет по экспоненте с увеличением числа пользователей. Кроме того, описанные события происходили на заре развития социальных сетей, когда лидерство на этом рынке еще не было однозначным. Лучший способ увеличить клиентскую базу состоял в том, чтобы побудить наших существующих пользователей пригласить как можно больше своих друзей и знакомых присоединиться к Friendster. Если в среднем каждый пользователь сети приводит такое количество новых посетителей, которое впоследствии превращаются в более чем одного реального клиента, это выливается в вирусный рост клиентской базы. Социальные продукты обладают высоким потенциалом вирусного роста (а также высокими темпами невирусного роста). Подробный алгоритм, пошагово описывающий, как существующий пользователь генерирует появление нового клиента, называются вирусной петлей.

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

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

1. Компания хочет, чтобы потенциальные клиенты были осведомлены о ее продукте.

2. Компания хочет превратить потенциальных клиентов в реальных.

3. Компания хочет сохранить как можно больше своих клиентов в течение долгого времени.

4. Компания хочет получать доход от своих клиентов.

5. Компания хочет, чтобы ее клиенты распространяли информацию о продукте, поскольку это способствует привлечению новых клиентов.

Стартап-метрики для «пиратов»

В 2007 году мне посчастливилось познакомиться с Дэйвом Макклюром. Скорее всего, вы слышали о Дэйве, но на всякий случай отмечу, что сам он считает себя «гиком, маркетологом, инвестором, блогером и смутьяном». Помимо прочего, этот человек является партнером-основателем стартап-фонда и стартап-акселератора 500 Startups (http://500.co). Мы встретились на конференции, где Дэйв выступал с докладом, в котором презентовал свой фреймворк под названием «Стартап-метрики для пиратов». Я был рад заметить, что этот фреймворк был очень похож на те, которые я разработал для продуктов Intuit и Friendster. Дэйв представил свои идеи настолько простым и эффективным способом, что высокая практическая ценность его фреймворка была очевидна.

Наши аналитические системы имели лишь два незначительных расхождения в терминологии. Во-первых, Дэйв использовал термин «активация» вместо «конверсия». Он вложил в свой термин более широкий смысл, включавший в себя и конверсию – в том виде, как ее определил я, – и иные способы, которыми потенциальный клиент может взаимодействовать с продуктом, не становясь при этом реальным клиентом. Например, потенциальный клиент может не подписываться на предлагаемую ему услугу, но при этом предоставить свой адрес электронной почты для получения уведомлений о новостях, касающихся продукта. Это действие не будет квалифицироваться как конверсия в полноценного клиента, но может быть включено в показатель активации. Во-вторых, Дэйв использовал слово «реферал» – отличный, универсальный термин – для описания концепции, согласно которой существующие клиенты предпринимают действия, приводящие к тому, что о вашем продукте узнают новые потенциальные клиенты. Дэйв назвал свой фреймворк «Стартап-метрики для пиратов». Такое название появилось благодаря акрониму, который образуется из наименований пяти используемых им показателей: Acquisition [привлечение], Activation [активация], Retention [удержание], Referral [рекомендации] и Revenue [доход] – получается «ААRRR!» (с восклицательным знаком, добавленным для пущего сходства)[26].

В своем выступлении Дэйв рекомендовал отслеживать два или три ключевых показателя для каждого из пяти элементов своего фреймворка. Это хорошая идея, потому что, например, воронка конверсий на самом деле не является одной общей метрикой; вы можете (и должны) отслеживать более подробные показатели. Исходя из этого, можно провести различие между макро-метриками и относящимися к ним микро-метриками. Определение микро-метрик, наиболее подходящих для отслеживания заданной макро-метрики, – это часть того, что я называю «чисткой аналитической луковицы», о чем я расскажу позже.

Компания KISSmetrics создала отличную диаграмму для описания фреймворка AARRR, и это неудивительно, если учесть, что генеральный директор и основатель KISSmetrics Хитен Шах является одним из ведущих специалистов в области бережливого стартапа и аналитики. Я немного модифицировал эту диаграмму – полученный результат представлен на Рисунке 13.2.

Рисунок 13.2. Фреймворк показателей AARRR!

Определение наиболее значимой метрики

В любой момент существования бизнеса какая-то из пяти макро-метрик, входящих в состав модели AARRR, будет более важна, чем остальные. Я называю ее «наиболее значимой метрикой» – или сокращенно НЗМ. Улучшение других показателей тоже имело бы позитивный эффект, но НЗМ – это тот показатель, который говорит, как в текущий момент можно получить наибольшую отдачу от вложений. Уточнение «в текущий момент» является очень важным. В какой-то момент, после того как вы добьетесь значительного улучшения своей НЗМ, она перестанет быть наиболее значимой, поскольку ее место займет другой показатель, обеспечивающий лучшие возможности с точки зрения рентабельности инвестиций. Предположим, что после запуска продукта вы обнаруживаете, что только 10 % посетителей сайта, которые начинают процесс регистрации, доходят до ее завершения. Вы решаете, что коэффициент конверсии, рассчитываемый на основе количества завершенных регистраций, является на текущий момент вашей НЗМ, и поэтому проводите пользовательское тестирование процесса регистрации и в результате обнаруживаете несколько проблем, связанных с юзабилити. Также выясняется, что форма регистрации не работает в одном из браузеров. Вы проверяете журналы своего сервера и понимаете, что в некоторые моменты возникает ошибка, из-за которой форма регистрации работает не так, как было задумано. Усердно потрудившись над устранением всех этих проблем, вы видите, что коэффициент конверсии повысился до 90 %. Таким образом, на текущий момент коэффициент конверсии перестал быть вашей НЗМ. Теперь уже другие метрики указывают на наличие возможности получить большую отдачу на затраченные ресурсы.

Смена НЗМ происходит из-за феномена убывающей отдачи. Когда вы впервые займетесь поиском метрики, оптимизация которой способна привести к существенным улучшениям бизнеса, вы вскоре обнаружите множество «низко висящих плодов»: идей, которые без приложения особых усилий могут привести к значительным улучшениям. Но затем вы замечаете, что с каждым улучшением рентабельность инвестиций при реализации следующей идеи становится все ниже, и это убывание отдачи продолжается по мере того, как вы добиваетесь все большего прогресса.

Существует естественный порядок очередности, в которой имеет смысл проводить оптимизацию макро-метрик, когда вы начинаете работу с новым продуктом. Согласно этому порядку, первой НЗМ становится удержание клиентов, затем следуют конверсия и привлечение. Давайте выясним, почему это так.

Начните с удержания клиентов

Работая над новым продуктом, вы стремитесь прежде всего добиться его соответствия рынку. Пока вы не будете уверены в том, что пользователи считают ваш продукт ценным, не имеет никакого смысла тратить значительные ресурсы на попытки привлечения клиентов. Аналогично не имеет смысла вкладываться в оптимизацию показателей конверсии. Трата ресурсов в этих направлениях не только окажет меньшее влияние на бизнес, но и отвлечет их от того, что в текущий момент наиболее важно. Если клиенты посчитают ваш продукт достаточно полезным, они продолжат им пользоваться; в противном случае они этого не сделают. Таким образом, удержание – это макрометрика, наиболее тесно связанная с соответствием продукта рынку. По этой причине именно она, как правило, становится первой НЗМ для нового продукта.

Оптимизируйте конверсию до привлечения клиентов

Как только вы убедитесь в том, что продукт соответствует рынку и что достаточно высокий процент клиентов продолжает его использовать в течение долгого времени, имеет смысл сосредоточиться на том, чтобы обеспечить максимально возможную долю превращения потенциальных клиентов в реальных. Конверсия – макро-метрика, характеризующая этот аспект работы – теперь становится вашей НЗМ. Почему именно она, а не показатели привлечения клиентов? Если на этом этапе вы сосредоточите свои усилия на привлечении клиентов, то, образно говоря, вам удастся собрать толпу людей у своей входной двери. Однако большая часть собравшихся так и не станет вашими клиентами, если коэффициент конверсии предлагаемого им продукта ниже, чем должен бы быть. Начав с конверсии, вы затем получите гораздо более высокую отдачу от своих инвестиций в привлечение, поскольку значительно большая часть потенциальных клиентов будет превращаться в реальных.

Оптимизация привлечения клиентов

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

На верхнем уровне вы можете разделить привлечение на платное и бесплатное. Платное привлечение требует финансовых затрат – например, на оплату рекламы продукта в Google или Facebook. Вирусный маркетинг бесплатен. Действия существующих клиентов побуждают других людей попробовать ваш продукт, но вы им за это не платите. Еще одним бесплатным каналом для привлечения клиентов является органический поиск.

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

Существует бесчисленное множество показателей, которые можно отслеживать и оптимизировать. Поскольку создание успешного продукта начинается с достижения его соответствия рынку, было бы полезно определить наилучший способ для измерения именно этого показателя. Во время своих выступлений и при проведении семинаров я часто спрашиваю аудиторию: «Если бы вы могли отслеживать только один показатель для оценки соответствия продукта рынку, то что бы вы выбрали в качестве такой метрики?» Ответы обычно бывают самыми разными. Некоторые утверждают, что доход является наиболее универсальной мерой. Другие – что наибольшую важность имеет показатель темпов роста клиентской базы. Действительно, при определенных обстоятельствах оба этих показателя могут быть наиболее значимыми для бизнеса. Однако я намеренно включил в формулировку своего вопроса уточнение: «для оценки соответствия продукта рынку». Наилучшим единственным показателем для такой оценки является коэффициент удержания. Поэтому давайте рассмотрим его более подробно и выясним, как его можно измерить.

Коэффициент удержания

Коэффициент удержания показывает, какой процент клиентов активно пользуется продуктом. Чтобы рассчитать его значение нужно разделить количество активных клиентов на их общее число. Еще более полезным является отслеживание динамики коэффициента удержания, что позволяет понять, как доля активных пользователей продукта изменяется во времени. С этим показателем связана одна сложность, не присущая другим метрикам. Она заключается в том, что разные клиенты начинают использовать продукт в разное время, поэтому вы не можете подходить к оценке срока использования, отталкиваясь от конкретных календарных дат (в отличие от большинства других показателей). Наиболее подходящим решением данной проблемы является агрегирование данных с использованием количества дней, прошедших с момента регистрации каждого пользователя.

Кривые удержания клиентов

Кривые удержания – это интуитивно понятный способ визуализации удержания клиентов. Пример такой диаграммы представлен на Рисунке 13.3. По вертикальной оси здесь измеряется процент возвращающихся пользователей. Горизонтальная ось представляет количество дней (или недель, или месяцев), прошедших с момента первого использования. Значение для каждой точки кривой рассчитано на основе данных о регистрации и о фактах использования продукта для совокупности пользователей. По чисто математической причине кривые удержания всегда начинаются со 100 %-ной отметки в нулевой день (которым является день регистрации каждого пользователя), а затем имеют тенденцию снижаться с течением времени, поскольку доля пользователей, которые не возвращаются, чтобы снова воспользоваться вашим продуктом, постепенно накапливается. Уже на 1-й день (то есть следующий день после регистрации) может наблюдаться значительное снижение показателя удержания. Поэтому нулевой день обычно не отображают на графике, а начинают отсчет с первого дня, чтобы график выглядел более читабельным.

Рисунок 13.3. Кривая удержания

Обратите внимание, что на представленной на рисунке кривой удержания значение, соответствующее первому дню, составляет около 20 %. Это означает, что около 80 % клиентов не вернулись на следующий день после регистрации. Этот «начальный коэффициент отсева» является одним из ключевых отличительных параметров кривой удержания. Разные категории продуктов имеют различающиеся показатели начального отсева. Показанная кривая относится к мобильному приложению – категории, для которой характерны очень высокие значения показателя начального отсева. Посудите сами: люди постоянно устанавливают новые мобильные приложения. Но часто после первого использования уже не возвращаются к тем приложениям, которые не представляют для них интереса. При этом иконка установленного приложения обычно теряется в море других значков на экране смартфона. При отсутствии какой-либо «напоминалки» об установленном приложении, которым они ранее пользовались, люди через некоторое время просто забывают о нем. Вот почему для мобильных приложений так важны встроенные периодические уведомления, с помощью которых разработчики пытаются не попасть под действие принципа: «с глаз долой – из сердца вон».

Вторым отличительным параметром кривой удержания является скорость, с которой происходит снижение показателя. Некоторые кривые удержания демонстрируют очень крутое пике, в то время как другие являются более пологими. При этом снижение может либо продолжаться вплоть до нулевого значения, либо в конечном итоге сглаживаться в горизонтальную линию. Если кривая стремится к нулю, это означает, что вы с течением времени потеряете всех клиентов из отслеживаемой группы. Если же кривая, достигнув определенного значения, становится плоской, то уровень, на котором произойдет такое выравнивание, будет соответствовать проценту клиентов, которых вам удается удерживать. Такое терминальное значение является третьим характерным параметром кривых удержания. Кривая удержания одного продукта может прекратить снижение на уровне пяти процентов, тогда как в другом случае это произойдет на отметке 20 %.

Три перечисленных выше отличительных параметра кривой удержания – начальный отсев, скорость снижения и терминальное значение – являются непосредственными показателями соответствия продукта рынку. Чем выше степень соответствия, тем ниже процент начального отсева, меньше скорость снижения и выше терминальное значение. Чем ниже степень соответствия продукта рынку, тем выше начальный отсев и скорость снижения, и тем ниже терминальное значение. Последний из этих параметров является наиболее важным, поскольку отвечает на вопрос: «Какой процент клиентов, попробовавших продукт, продолжают им пользоваться в течение долгого времени?» Если бы вы сказали мне, что терминальное значение кривой удержания для продукта А составляет 1 %, а для продукта В – 50 %, я бы мог ответить, какой из этих продуктов в большей степени соответствует рынку (продукт В), не владея никакой дополнительной информацией об этих продуктах.

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

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

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

Когортный анализ

Группа пользователей, которые имеют общую характеристику – например, месяц, в котором они зарегистрировались, – называется когортой. Мощным инструментом анализа меняющихся во времени показателей для различных когорт является когортный анализ. На Рисунке 13.4 показан график с тремя кривыми удержания для различных когорт. По горизонтальной оси здесь измеряется количество недель, прошедших с момента регистрации (вместо дней, как это было на Рисунке 13.3). Вы можете видеть, что когорта А имеет самый низкий начальный отсев, самую высокую скорость снижения и самое низкое терминальное значение. Когорта С имеет самый высокий начальный отсев, самую низкую скорость снижения и самое высокое терминальное значение. Параметры кривой для когорты B находятся между соответствующими значениями для когорт A и B. Итак, какую из трех кривых удержания вы предпочли бы для своего продукта? Я бы выбрал кривую когорты C, из-за того, что она имеет самое высокое терминальное значение. Начиная с 3-й недели, в когорте C процент активных пользователей выше, чем в двух других когортах. Это приводит к увеличению дохода. В качестве отступления: если у вас на одном графике отображается более пяти кривых, он становится трудночитаемым.

Рисунок 13.4. Кривые удержания для когорт

В Таблице 13.1 показан стандартный формат хранения данных, используемых при построении кривых удержания для нескольких когорт. Содержание первого столбца указывает, что каждая строка отведена для определенной когорты. В представленном примере показаны когорты, сформированные по месяцам за период с января по май; данные представлены по состоянию на июнь. Во втором столбце для каждой когорты указано начальное количество пользователей. В каждом последующем столбце зафиксировано количество активных пользователей с учетом количества месяцев, прошедших с момента их регистрации. Чем раньше сформирована когорта, тем больше точек для построения соответствующей кривой.

Таблица 13.1 Исходные данные для когорт

Данные, приведенные в Таблице 13.1, используются для расчета значений, приведенных в Таблице 13.2. Процент в каждой ячейке Таблицы 13.2 – это коэффициент удержания для соответствующей когорты (указанной в строке) за определенный временной интервал (указанный в столбце). Каждый коэффициент удержания рассчитывается путем деления количества активных пользователей (для данной когорты и периода времени) на начальное количество пользователей в когорте. Каждая строка Таблицы 13.2 отображается затем на графике в виде отдельной кривой удержания.

Таблица 13.2 Коэффициенты удержания для когорт

Отслеживание улучшений степени соответствия продукта рынку

Если вы со временем повышаете степень соответствия своего продукта рынку, кривые удержания для ваших когорт будут двигаться вверх, достигая более высоких терминальных значений для новых когорт. На Рисунке 13.5, где представлены кривые удержания для трех когорт, показан пример того, как это могло бы выглядеть при реализации идеального сценария. Пользователи, сгруппированные в когорту А, зарегистрировались 24 месяца назад – сразу после выпуска продукта. Пользователи, вошедшие в когорту B, зарегистрировались 18 месяцев назад, а пользователи из когорты C – 12 месяцев назад. Как вы можете видеть, со временем мы улучшили соответствие нашего продукта рынку, и кривая удержания клиентов пошла вверх. Каждая последующая когорта имеет более низкий начальный отсев, более низкую скорость снижения и более высокое терминальное значение, чем предыдущая.

Рисунок 13.5. Повышение показателя удержания с течением времени

Уравнения для улучшения вашего бизнеса

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

Когда я хочу что-то оптимизировать, инженерное и математическое образование побуждает меня первым делом использовать для этого уравнение. В средней школе мы бесчисленное количество раз выражали переменную Y как функцию другой переменной – X. При этом цель состояла в том, чтобы найти такое значение X, которое приводило бы к максимально возможному значению Y. Более продвинутые версии этого упражнения включали применение нескольких переменных. Отправной точкой всегда было уравнение, которое показывало, как Y выражается через X (или через несколько переменных). Таков теоретический мир математики, но аналогичная техника применима и в реальном мире бизнеса.

Любой бизнес можно представить в виде уравнения. Цель состоит в том, чтобы получить количественное представление о бизнесе, построенное на основе набора показателей, которые могут быть использованы для оптимизации бизнес-результатов. Если вам пока не совсем ясно, как это можно сделать, позвольте привести пример.

Вот стартовое уравнение, которое применимо к любому бизнесу:

Прибыль = Доходы – Затраты

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

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

Такой продукт, как Facebook, является хорошим примером для иллюстрации этого явления. Приложение имеет более миллиарда пользователей. Соответствующее такому масштабу клиентской базы обслуживание веб-сайта и мобильного приложения Facebook требует наличия большого количества серверов, хранилищ данных, сетевого оборудования и пропускной способности каналов связи для стабильной работы. Приходится ли команде Facebook разрабатывать какое-либо дополнительное программное обеспечение при появлении каждого нового пользователя? Нужно ли им включать в работу дополнительный сервер, когда к их сети присоединяется новый пользователь? Нет. Единственное, что действительно потребуется в этом случае из дополнительных ресурсов – это крошечная часть емкости хранилища для сохранения пользовательских данных и столь же незначительная дополнительная пропускная способность. По сути, величина предельных издержек в расчете на одного нового пользователя Facebook равна нулю.

Источником дохода для Facebook в основном является реклама, которую разработчик демонстрирует внутри своих продуктов. Новый пользователь будет генерировать небольшой дополнительный доход от рекламы. Таким образом, предельные издержки, практически равные нулю, и небольшой предельный доход приносят в совокупности небольшую предельную прибыль.

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

Доход = Пользователи * Средний доход на одного пользователя

Это уравнение говорит нам о том, что в принципе есть два основных способа повышения дохода: увеличить количество пользователей и/или увеличить средний доход, генерируемый одним пользователем. Возможно, вам уже приходилось слышать сокращенное название данного показателя (Average Revenue Per User, или ARPU), поскольку он относится к числу ключевых и отслеживается многими компаниями.

Уравнения для бизнес-модели, связанной с получением дохода от рекламы

Наилучший способ дробления параметров из уравнения для расчета дохода на более подробные показатели зависит от бизнес-модели, применяемой для получения этого дохода. Для примера давайте предположим, что у нас есть бизнес, который приносит доход за счет медийной рекламы. Во многих продуктах, основанных на рекламе, люди, которые видят эту рекламу, не обязательно должны быть зарегистрированными пользователями. Достаточно вспомнить такие популярные сайты, как YouTube или веб-сайт New York Times: для этих и других подобных продуктов, построенных на контенте, вместо термина «пользователи» используется термин «посетители». Учитывая нюансы отслеживания показателей веб-аналитики, термин «уникальные посетители» дает понять, что мы учитываем каждого посетителя сайта только один раз за определенный интервал времени. Итак, доход при применении рекламной бизнес-модели образуется следующим образом:

Доход = Посетители * Средний доход на одного посетителя

Медийная реклама продается рекламодателям исходя из количества показов – термин, который подразумевает, что рекламное сообщение было показано на веб-странице, которую посетил пользователь. Это не обязательно означает, что посетитель увидел рекламное объявление. Допустим, рекламодатель покупает 100 000 показов. Медиасайт, продавший ему эти показы, будет отслеживать их количество и завершит рекламную кампанию, как только рекламное сообщение будет показано 100 000 раз. Стоимость рекламы указывается в единицах «CPM», то есть за тысячу показов (здесь «M» – это римская цифра, обозначающая 1000). При цене в 10$ CPM общая стоимость рекламной кампании из нашего примера составит 1000$ (за 100 000 показов). Выражение цены через CPM представляет собой хороший способ для сравнения стоимости различных видов рекламы. В результате вы можете заметить, как термин «эффективный CPM» часто используется в более широком контексте. Теперь мы можем составить уравнение, раскрывающее, как формируется средний доход на одного посетителя:

Средний доход на одного посетителя = Показы на одного посетителя * Эффективный CPM ÷ 1000

Дальнейшее разбиение эффективного CPM не имеет смысла. Из уравнения видно, что это достаточно подробный для целей анализа показатель, значение которого прямо пропорционально влияет на величину дохода. При удвоении эффективного CPM вы получите удвоение дохода.

Каким образом можно разбить на составляющие такую метрику, как показы в расчете на одного посетителя? Помните, что каждое из представленных уравнений применимо к определенному интервалу времени. Итак, какие же факторы определяют количество показов рекламы одному посетителю за определенный период времени? Поскольку один и тот же человек может посещать наш сайт несколько раз за учитываемый интервал времени, мы должны отразить этот факт в своем уравнении. Реклама отображается на веб-страницах, поэтому чем больше веб-страниц посещает средний посетитель (количество просмотров страниц), тем больше количество показов, приходящихся на одного посетителя. Наконец, мы контролируем количество показов рекламы на каждой странице, поэтому и этот показатель мы можем учесть в своем уравнении. Таким образом, количество показов на одного посетителя определяется следующим образом:

Каждый из трех показателей, участвующих в этом уравнении в роли множителей, является переменной величиной, которую мы контролируем и на значение которой можем повлиять. Изменение значения любого из этих показателей приведет к пропорциональному изменению дохода. Например, мы можем увеличить частоту посещений нашего сайта, чаще обновляя контент или отправляя пригласительные электронные письма. Мы также можем попытаться заставить посетителей просматривать при каждом посещении больше страниц, размещая контент более чем на одной странице или включая ссылки на связанные страницы. Наконец, мы можем разместить больше рекламных объявлений на каждой странице, хотя применение данной меры должно иметь разумные пределы, поскольку в какой-то момент это может вызвать недовольство пользователей и негативно отразиться на показателе удержания.

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

Посетители = Новые посетители + Возвращающиеся посетители

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

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

Возвращающиеся посетители(T) = Количество посетителей(T-1) * Коэффициент возвращений

Я добавил индекс (T) для обозначения текущего и (T–1) для предыдущего интервала времени. Посетители и возвращающиеся посетители – это просто параметры, которые вы измеряете, не пытаясь повлиять на них напрямую. Переменной, которую мы действительно хотели бы улучшить, является коэффициент возвращений. Например, мы могли бы ввести в практику еженедельные или ежемесячные рассылки электронных писем, содержащих ссылки на популярный или рекомендуемый контент, чтобы побудить пользователей снова посетить нашу веб-страницу. Коэффициент возращений может быть рассчитан на основе двух других параметров:

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

Уравнения для бизнес-модели, связанной с получением дохода от подписок

Не вдаваясь в настолько же подробные объяснения, вот как бы я «почистил аналитическую луковицу» для бизнес-модели, основанной на подписках.

Прибыль = Доходы – Затраты

Снова сосредоточимся на увеличении дохода, а не на снижении затрат.

Доход = Платные пользователи * Средний доход на одного платного пользователя

Я использовал термин «платные пользователи» вместо просто «пользователи», чтобы учесть тот факт, что не все пользователи платят за подписку на продукт. Например, есть те, кто использует 30-дневную бесплатную пробную версию. Кроме этого, некоторые продукты предполагают наличие как платной, так и бесплатной версии подписки. Для данного примера будем исходить из того, что все наши сервисы требуют платной подписки, но мы предлагаем, в том числе, бесплатную пробную версию.

Платные пользователи = Новые платные пользователи + Повторные платные пользователи

Как и в предыдущем примере, мы делим платящих пользователей на новых, которых приобрели за отслеживаемый интервал времени, и уже имеющихся, которые совершили повторную оплату.

Повторные платные пользователи(T) = Платные пользователи(T-1) * (1 – Коэффициент отмены)

Как и в предыдущем примере, количество повторных платных пользователей за текущий период (обозначен индексом T) выражается через количество платных пользователей за предыдущий период (обозначен индексом T–1). Коэффициент отмены – это доля платных пользователей, которые отменяют свою подписку при переходе от одного периода к следующему. Это очень важный показатель для бизнеса, зарабатывающего на подписках, поэтому его необходимо отслеживать и пытаться улучшить. Мы достаточно подробно разобрали показатели, относящиеся к этому источнику дохода, поэтому давайте обратимся к новым платным пользователям, чтобы проанализировать эту метрику.

Новые платные пользователи = Бесплатные пробные пользователи * Коэффициент конверсии пробной версии + Прямая платная регистрация

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

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

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

Достижение прибыльности

Ранее я привел уравнения для улучшения вашего бизнеса в том виде, в каком они применимы к определенному интервалу времени. Другой способ состоит в том, чтобы не обращать внимания на временные интервалы и рассматривать бизнес-показатели в расчете на одного клиента.

Прибыль = Количество клиентов * Прибыль на одного клиента

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

Прибыль на одного клиента = Доход на одного клиента – Затраты на одного клиента

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

Прибыль на одного клиента = Пожизненная ценность клиента – Затраты на привлечение клиента

Пожизненная ценность клиента

Это уравнение является очень полезной альтернативной функцией прибыли, приходящейся на одного клиента. Пожизненная ценность клиента (lifetime value, или LTV) – это выручка, которую генерирует клиент, без учета затрат на его привлечение. Затраты на привлечения клиента – это средняя сумма, в которую обходится привлечение нового клиента. Выделение этих затрат в отдельный показатель позволяет проводить его отслеживание и улучшение. Когда значение LTV превышает величину затрат на привлечение клиента, каждый новый клиент приносит бизнесу прибыль. Чтобы получить контролируемые показатели, которые могут быть улучшены за счет практических действий, следует снять с «аналитической луковицы» еще одним слой.

LTV = ARPU * Средний жизненный цикл клиента * Валовая маржа

В этом уравнении снова появляется показатель ARPU, который упоминался ранее. Напомню, что он представляет собой средний доход на одного пользователя (за интервал времени). Например, если все ваши подписчики платят по 10$ в месяц, значение ARPU составляет 10$ в месяц. Средний жизненный цикл клиента показывает, в течение скольких временных интервалов среднестатистический клиент остается с вами. Если вы умножите ARPU на величину среднего жизненного цикла клиента, то узнаете, какой доход в среднем приносит вам каждый клиент (на протяжении всего времени, пока он является платным клиентом). Допустим, проанализировав данные о своих клиентах, вы обнаружили, что величина среднего жизненного цикла клиента составляет 10 месяцев. Тогда для расчета среднего пожизненного дохода нужно 10$ ежемесячной платы умножить на 10 месяцев. Получится 100$.

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

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

Из уравнения мы видим, что увеличение LTV возможно за счет увеличения ARPU. Такого эффекта можно достичь, например, повысив стоимость своих услуг, продав больший объем услуг существующим клиентам или добавив новые услуги с более высокой стоимостью.

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

Например, если показатель оттока составляет 5 % в месяц, то жизненный цикл вашего клиента равен 20 месяцам. Вы можете снизить коэффициент оттока, улучшив уровень обслуживания и технической поддержки клиентов, повысив качество и надежность продукта, а также создав все необходимые условия для того, чтобы он продолжал удовлетворять потребности клиентов. Поскольку коэффициент оттока – это тот показатель, который вы собираетесь отслеживать и улучшать, стоит включить его в преобразованный вариант формулы для расчета LTV. Если пренебречь коэффициентом валовой маржи, то представленное уравнение предельно ясно показывает, что повысить пожизненную ценность клиента можно двумя способами – увеличив ARPU и снизив уровень оттока:

Стоимость привлечения клиента

Давайте вернемся к показателю затрат на привлечение одного клиента (Customer Acquisition Cost, сокращенно – CAC), который вы можете рассчитать, если знаете количество новых клиентов, которых вы привлекли за отслеживаемый период, и объем затрат на продажи и маркетинг за тот же интервал времени:

Это уравнение является удобным способом для расчета CAC, но оно не обеспечивает нас показателями, которые мы могли бы реально контролировать. С применением более действенных показателей уравнение будет выглядеть следующим образом:

Стоимость привлечения (часто сокращаемая до CPA, сost per action) – это то, во сколько в среднем обходится привлечение каждого потенциального клиента. Допустим, вы размещаете рекламу через Google AdWords и платите за каждый клик (CPC, cost per click) 1$. Тогда ваш CPA составляет доллар, поскольку каждый человек, который кликнет по ссылке, попадает на ваш сайт (становится потенциальным клиентом). Чтобы увеличить прибыль с одного клиента, вы можете уменьшить CAC путем сокращения стоимости привлечения. Это возможно в том случае, если вам удастся найти более дешевые маркетинговые инструменты и каналы. Как вариант, вы можете подобрать ключевые слова с более низкими ценами за клик. При использовании рекламы, стоимость которой зависит от количества показов, вы можете снизить значение CPA, повысив эффективность рекламных сообщений (то есть добившись увеличения количества переходов по рекламной ссылке).

Когда люди кликают по вашему рекламному сообщению в Google, они попадают на целевую страницу вашего продукта и становятся потенциальными клиентами. В этом месте они могут узнать больше о вашем предложении и стать клиентами. Процент потенциальных клиентов, которые превращаются в реальных – это коэффициент конверсии потенциальных клиентов. Вы можете улучшить этот показатель, оптимизировав свои целевые страницы, что подразумевает повышение качества маркетинговых сообщений и UX-дизайна. Как вы уже знаете, A/B тестирование является отличным инструментом для достижения этих целей.

Чтобы получать прибыль, показатель LTV должен превышать показатель CAC, и чем больше величина такого превышения, тем выше прибыль. Некоторые компании предпочитают оперировать не разницей значений этих показателей, а их соотношением. Например, общее правило для успешного SaaS-бизнеса гласит, что коэффициент отношения LTV к CAC должен быть больше трех.

В этой главе я показал, как можно использовать аналитику для улучшения вашего бизнеса и создания основы для оптимизации. До запуска продукта вы в большей степени полагаетесь на результаты качественных исследований; но как только продукт попадает на рынок, в вашем распоряжении оказывается огромный объем аналитических данных. Вы можете оценить степень соответствия продукта рынку, используя когортный анализ для отслеживания показателей удержания клиентов. Кроме того, вы можете использовать систему AARRR и уравнения для анализа вашего бизнеса, чтобы определить ключевые показатели, на улучшении которых вам следует сосредоточить свои усилия. Наконец, вы можете использовать показатели LTV и CAC для достижения и повышения рентабельности своего продукта.

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

Глава 14

Использование аналитических инструментов для оптимизации продукта и бизнеса

В главе 13 рассказывалось о том, как определять и измерять ключевые метрики, которые должны лечь в основу последующего анализа для улучшения вашего продукта и бизнеса. Самое замечательное в «живом» продукте то, что аналитика позволяет четко видеть результаты вносимых в него изменений. Имея хорошую платформу для A/B-тестирования, вы можете с легкостью проводить эксперименты и немедленно проводить необходимые улучшения. Те компании, которые умеют это делать, получают конкурентное преимущество. При этом более значимым в конкурентной борьбе становится уже не размер вашего бизнеса, а то, насколько быстро вы умеете извлекать уроки из обратной связи от клиентов и вносить соответствующие изменения в свой продукт. Скорость – это оружие. В современном быстро меняющемся мире Давид в одночасье может повергнуть Голиафа. В этой главе рассказывается о том, как следует использовать существующие аналитические возможности для оптимизации вашего продукта и бизнеса.

Процесс анализа бережливого продукта

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

Первым шагом в процессе анализа бережливого продукта является определение ключевых метрик для вашего бизнеса, о которых я рассказал в предыдущей главе. Далее вам нужно провести измерение этих показателей, чтобы зафиксировать для каждой метрики ее базовое значение, которое показывает, где вы находитесь сегодня. Этот шаг может показаться относительно простым, но многие компании на нем спотыкаются. Настройка отслеживания – или измерения – показателей продукта требует выполнения определенной работы. После первоначальной настройки обычно требуются дополнительные усилия для обеспечения точности и сопоставления значений отслеживаемых показателей. Аналитические приложения, такие как Google Analytics, KISSmetrics, Mixpanel и Flurry, позволяют упростить эту задачу. Данные, необходимые для расчета ключевых метрик, часто хранятся в базе данных продукта, поэтому многие компании используют комбинацию из приложений сторонних разработчиков и собственного аналитического ПО. Цель всех этих действий состоит в том, чтобы создать набор аналитических панелей, позволяющих видеть, как с течением времени изменяются значения каждой из отслеживаемых метрик.

Рисунок 14.1. Процесс анализа бережливого продукта

Как только у вас появятся точные базовые значения для каждой из ключевых метрик, можно будет перейти к следующему шагу: оценке потенциала роста каждого отслеживаемого показателя. На этом этапе вы оцениваете каждый показатель через призму рентабельности инвестиций (ROI). Я считаю полезным представлять диапазон значений каждого показателя в виде шкалы со стрелкой, подобной той, что вы можете наблюдать на приборной панели автомобиля или на манометре. Цифры, на которые в данный момент указывает стрелка, являются базовым значением для наблюдаемой метрики. Теперь вам нужно оценить, насколько легко или сложно будет сдвинуть стрелку вправо, то есть улучшить каждый показатель. Для этой цели используется кривая рентабельности инвестиций, и на этом шаге мы хотим получить хотя бы примерное представление о том, в каком месте на этой кривой находится исследуемый показатель в настоящий момент времени.

На Рисунке 14.2 показаны кривые рентабельности инвестиций для трех различных метрик. По вертикальной оси каждого графика отложены значения самой метрики (где чем выше, тем лучше). Зная особенности своего бизнеса и существующие взаимосвязи между его ключевыми показателями, вы имеете представление о том, в какой степени увеличение значения каждой метрики приводит к улучшению показателя более высокого уровня, который вы, в конечном счете, пытаетесь повысить за счет вложения соответствующих ресурсов (например, это может быть показатель объема выручки). Горизонтальная ось показывает объем инвестиций (ресурсов), направляемых на улучшение отслеживаемого показателя. Кружком обозначено текущее базовое значение метрики, то есть в каком месте на кривой рентабельности инвестиций каждый показатель находится в данный момент.

Рисунок 14.2. Кривые рентабельности инвестиций для трех различных метрик

Текущее значение метрики A находится в нижней части кривой рентабельности инвестиций, где подъем линии является достаточно крутым. Это означает, что вы можете значительно улучшить значение данного показателя, совершив относительно небольшие вложения. Такая ситуация обычно возникает в том случае, когда вы еще не работали над улучшением метрики. В свою очередь, показатель B находится вблизи вершины своей кривой рентабельности инвестиций, там, где наклон линии в значительной степени выровнен. Таким образом, даже при значительных инвестициях, вы сможете улучшить данный показатель лишь в небольшой степени. Такая ситуация характерна для случаев, когда на улучшение метрики уже потрачено много ресурсов.

Кривая рентабельности в том виде, как она показана для метрик A и B, является типичной для большинства показателей. Однако в некоторых обстоятельствах даже небольшие затраты ресурсов на улучшение показателя могут привести к его значительному росту. Я называю такие ситуации эффектом «волшебной пилюли». В таких случаях кривая рентабельности инвестиций будет выглядеть иначе – примерно так, как показано на Рисунке 14.2 для метрики C. Это особые случаи, при которых небольшое, но влиятельное изменение может привести к тому, что какой-то аспект продукта или бизнеса станет работать гораздо лучше, чем это было до вашего вмешательства. Обычно такие возможности обнаруживаются в результате тщательного анализа.

Как только вы оценили потенциал роста каждого показателя, можно переходить к следующему этапу процесса: выбору показателя, который предлагает наиболее многообещающие возможности для улучшения. Это и будет та самая «Наиболее значимая метрика» (НЗМ), которая обсуждалась в предыдущей главе. Если вспомнить Рисунок 14.1, то можно сказать, что вы сейчас осуществляете переход от глобального рассмотрения полного набора метрик к сосредоточению всех усилий только на главной из них.

Далее, в ходе проведения «мозгового штурма» вам необходимо сгенерировать как можно больше идей по улучшению своей наиболее значимой метрики. Затем предстоит оценить, насколько реализация каждой из сгенерированных идей способна улучшить эту НЗМ. В процессе вы формируете гипотезы, такие как «Оптимизация мобильной версии страницы регистрации повысит коэффициент конверсии с 20 до 30 %». Кроме этого, вам необходимо оценить стоимость реализации каждой идеи, чтобы рассчитать значение рентабельности инвестиций – ROI (как обсуждалось в главе 6). Проделав эту работу, вы сможете выбрать для реализации идею с наилучшей оценкой рентабельности инвестиций.

Далее вы разрабатываете и внедряете выбранную идею улучшения главной метрики. Наилучшим вариантом было бы использовать при этом платформу A/B-тестирования, чтобы опробовать улучшение на небольшой части пользователей. Это позволяет получить сравнимые значения метрики для оценки относительной эффективности сделанного улучшения в сравнении с базовым показателем. Если у вас нет платформы для проведения A/B-тестирования, и при этом метрика, которую вы пытаетесь улучшить, имеет относительно стабильное значение, вы можете после реализации идеи улучшения провести простое сравнение показателей «до» и «после». Однако я настаиваю, что применение A/B-тестирования является более предпочтительным вариантом, поскольку оно снижает риск влияния неизвестных факторов, приводящих к возникновению разницы в полученных результатах.

Конечно, на протяжении всего процесса вы надеетесь улучшить целевой показатель. Однако, даже если этого в итоге не происходит, вы все равно добьетесь прогресса, поскольку получите ценный опыт, который сможете применить для создания более совершенных гипотез на последующих итерациях. Теперь вы пересматриваете свой список идей по улучшению метрики и выбираете следующую лучшую идею (занявшую изначально второе место при оценке рентабельности инвестиций). Затем вы повторяете весь цикл, показанный в правой части Рисунка 14.1.

В конце концов, после опробования нескольких идей вы должны, наконец, увидеть действительное улучшение целевого показателя. В ходе таких повторений цикла рентабельность проверяемых идей будет постепенно снижаться. Это может привести к тому, что в какой-то момент обнаружится, что лучшие возможности для улучшения представляет уже другая метрика.

В этом случае, как показано на Рисунке 14.1, вы должны вернуться с уровня Метрики на Глобальный уровень, проанализировать показатели и определить новую НЗМ для ее улучшения. После этого вы снова применяете описанный выше цикл итеративного улучшения, но уже к этой метрике.

Повторные выполнения данного процесса позволяют осуществлять систематическое улучшение бизнеса. Наличие продвинутой аналитической платформы и набора информационных панелей обеспечивает отслеживание прогресса в этом направлении. Использование платформы для A/B-тестирования помогает проводить регулярные эксперименты, чтобы увидеть, смогут ли новые идеи обеспечить более высокий результат по сравнению с тем, что уже находится в реализации. Как только в вашем распоряжении окажутся все критически важные элементы – аналитическая платформа, информационные панели, платформа A/B-тестирования – и будет запущен процесс непрерывного совершенствования, ограничивающим фактором останется лишь то, насколько быстро вы сможете выявлять и внедрять лучшие креативные идеи для своего продукта и бизнеса.

Решение проблемы локального максимума

На этом этапе возникает опасность застрять на локальном максимуме. В какой-то момент в процессе улучшения метрики у вас может возникнуть ощущение, что дальнейшее продвижение невозможно. Иногда это действительно так; вы настолько хорошо потрудились над совершенствованием своего продукта, что в отношении целевого показателя достигли максимума возможного. Однако в некоторых случаях вы просто застреваете на локальном максимуме, хотя на самом деле могли достичь большего, если бы рассмотрели возможность применения совершенно иного подхода.

Например, если у вас есть целевая страница, вы могли бы провести A/B-тестирование разных вариантов цветов для главной кнопки, чтобы определить, какой из них дает наибольший коэффициент конверсии. Разработчик Google протестировал 41 оттенок синего цвета для своей панели инструментов, чтобы понять, какой из них обеспечивает наилучший коэффициент кликабельности. Однако, если вы прекратите итерации после того, как подберете наилучший цвет для своей главной кнопки, вы, вероятно, застрянете на локальном максимуме. Таким же образом необходимо поэкспериментировать с различными вариантами сообщений, изображений, макетов страниц и так далее, чтобы посмотреть, сможете ли вы добиться еще более высокого коэффициента конверсии. Скорость улучшения напрямую зависит от того, насколько быстро вы сможете выявить и реализовать хорошие идеи. A/B-тестирование упрощает проведение экспериментов, но определить гипотезы для проверки должны вы сами. Чтобы не застрять на локальном максимуме, вы должны быть уверены, что используете все имеющиеся возможности для поиска потенциальных идей, направленных на улучшение вашего продукта.

Анализ бережливого продукта на примере Friendster

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

Присоединившись к стартапу разработчиков социальной сети Friendster в качестве главного продакт-менеджера, я выяснил, что одним из наиболее важных моментов является вирусное привлечение клиентов. У нас имелась солидная база пользователей, и мы получали некоторый доход от рекламы, но показатель среднего дохода в расчете на одного пользователя был слишком низким, чтобы мы могли позволить себе тратить деньги на привлечение клиентов (как это делают крупные потребительские компании). К счастью, у нас был для этого альтернативный способ – вирусный маркетинг позволял нам привлекать пользователей бесплатно. Благодаря сетевому эффекту ценность таких продуктов, как социальная сеть, к которым относился и Friendster, возрастает по экспоненте с увеличением числа активных пользователей. Мы знали, что быстрый рост нашей пользовательской базы имеет решающее значение для достижения успеха, и лучший способ добиться этого предлагал вирусный маркетинг. Поэтому я определил улучшение показателя вирусного роста в качестве одной из своих главных целей. Другие члены команды разделяли эту точку зрения, но никто на самом деле не имел представления о том, как можно провести измерение нашего вирусного роста. Я начал с первого шага процесса анализа бережливого производства: определения ключевых метрик.

Определение ключевых метрик

Мы отслеживали новых пользователей и могли определить, кто из них присоединился к нам по приглашениям. Показатель «новые приглашенные пользователи» относился к верхнему уровню. Мы заботились о его росте, но не могли влиять на него напрямую. Поэтому я применил свой метод «уравнений для улучшения бизнеса» (описан в главе 13, – прим. пер.), чтобы разбить его на более действенные показатели, которые мы могли бы попытаться улучшить.

Я начал с определения нашей вирусной петли, то есть описания процесса, благодаря которому мы с помощью существующего клиента приобретаем нового. Результат моих изысканий показан на Рисунке 14.3. Процесс начинается с наших существующих пользователей (прямоугольник в левом нижнем углу). Не все пользователи сети участвуют в привлечении новых клиентов с помощью вирусного маркетинга. Поэтому активные пользователи, которые приглашают своих друзей присоединиться к Friendster, выделены в отдельный блок. Используя наш продукт, активные пользователи отправляют по электронной почте приглашения своим родственникам, друзьям и знакомым, которые еще не используют Friendster (потенциальные пользователи). Когда потенциальный пользователь получает приглашение, он либо нажимает на ссылку в пригласительном письме, чтобы зарегистрироваться на Friendster, либо не нажимает. Процедуру регистрации также доводят до завершения не все потенциальные пользователи. Те приглашенные, кто успешно завершил процедуру регистрации, становятся пользователями, которые, в свою очередь, могут стать активными и запустить этот вирусный цикл на новый виток.

Рисунок 14.3. Вирусная петля Friendster

Составив описание вирусной петли, я занялся определением метрик, характеризующих данный процесс. Я не собирался отслеживать абсолютные показатели, такие как количество активных пользователей, потому что их значения меняются в зависимости от размера клиентской базы. Вместо этого я хотел выявить относительные показатели, которые позволяли бы сравнивать «яблоки с яблоками» при их изменении с течением времени. В итоге я разработал систему, состоящую из пяти показателей, которые в своей совокупности полностью охватывали все аспекты нашей вирусной петли. На Рисунке 14.4 показана все та же схема вирусной петли, к которой добавлены следующие метрики:

1. Процент активных пользователей: Этот показатель рассчитывается путем деления количества активных пользователей на общее количество зарегистрированных пользователей.

2. Процент пользователей, посылающих приглашения: Не все активные пользователи отправляли приглашения, поэтому данный показатель введен, чтобы учесть данное обстоятельство. Он рассчитывается путем деления количества пользователей, посылающих приглашения, на общее количество активных пользователей.

3. Среднее количество приглашений, посылаемых одним пользователем: Пользователи могут отправить приглашения как одному, так и нескольким своим друзьям. Соответственно, данный показатель рассчитывается путем деления общего количества отправленных приглашений на общее количество пользователей, пославших приглашения.

4. Коэффициент «кликабельности» приглашений: Процент потенциальных пользователей, которые перешли по ссылке, содержащейся в пригласительном письме; рассчитывается путем деления количества потенциальных пользователей, которые перешли по ссылке, на общее количество потенциальных пользователей, которым было отправлено приглашение.

5. Коэффициент конверсии: Процент потенциальных пользователей, пришедших на целевую страницу, которые фактически завершили процедуру регистрации. Этот показатель рассчитывается путем деления количества потенциальных пользователей, прошедших регистрацию, на общее количество потенциальных пользователей, посетивших страницу регистрации.

Рисунок 14.4. Показатели вирусной петли Friendster

Все эти метрики являются действенными и могут быть рассчитаны для любого заданного интервала времени (например, за последние 30 дней). При перемножении всех пяти показателей получается коэффициент вирусной петли. Если значение этого коэффициента больше единицы, то продукт официально является «вирусным». Это означает, что каждый существующий пользователь генерирует более одного нового пользователя, что в итоге приводит к экспоненциальному росту – подобно ядерному реактору, переходящему на сверхкритическую мощность. Продукты не сохраняют свой вирусный статус в течение долгого времени (иначе пользователем нашей социальной сети, в конце концов, стал бы каждый, у кого есть доступ в Интернет). Когда вирусный продукт достигает высокого уровня проникновения на рынок, там уже не остается достаточно большого количества потенциальных пользователей, которых еще можно было привлечь в качестве клиентов. В таком завидном положении находится, например, сеть Facebook. Однако если значение вирусного коэффициента оказывается меньше 1, но все равно является довольно высоким – скажем, 0.4, – у вас нет серьезного повода для беспокойства. Это по-прежнему означает, что в каждом отслеживаемом временном интервале вы с помощью вирусного маркетинга совершенно бесплатно увеличиваете свою клиентскую базу на 40 %.

Фиксация базовых значений для метрик

После определения пяти ключевых метрик на следующем шаге процесса требуется установить для каждой из них базовое значение. Современное аналитическое программное обеспечение обладает гораздо большими функциональными возможностями, чем это было во времена, когда я работал с Friendster. Тогда нам пришлось написать свой собственный программный код для отслеживания и осуществления необходимых расчетов. Мы начали со сбора данных по каждому из исходных показателей, таким как количество зарегистрированных пользователей, количество активных пользователей, количество переходов по ссылке из пригласительного письма и так далее. Затем на основе собранных атомарных показателей мы вычислили базовые значения для всех пяти ключевых метрик.

Для простоты в дальнейшем я буду использовать только три из пяти метрик, включая рассчитанные для них базовые значения:

• Процент пользователей, посылающих приглашения = 15 %.

• Среднее количество приглашений, посылаемых одним пользователем = 2.3.

• Коэффициент конверсии = 85 %.

Оценка потенциального ROI для каждой метрики

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

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

Рисунок 14.5. Потенциал роста для метрик

Давайте начнем с анализа коэффициента конверсии. Это процентный показатель, поэтому он может варьироваться от минимального значения – 0 %, до максимального – 100 %. Базовое значение составляет 85 %. Таким образом, независимо от того, какие улучшения мы внесем, увеличить значение этой метрики можно не более чем на 15 процентных пунктов (до 100 %). Поскольку потенциал роста нужно оценить в процентах к базовому значению, мы берем 15 пунктов возможного прироста и делим их на 85 (базовое значение), что дает нам 18 %. Таким образом, максимальный потенциал повышения коэффициента конверсии составляет 18 %.

Вторая метрика – процент пользователей, посылающих приглашения, – также может варьироваться в диапазоне от 0 до 100 %. Базовое значение составляет 15 %, так что теоретически мы могли бы улучшить этот показатель на целых 85 процентных пунктов. Опять же, чтобы выразить этот потенциал роста в процентах, мы берем 85 пунктов возможного прироста и делим их на базовое значение – 15 %, получая в итоге 570 %. Таким образом, процент пользователей, посылающих приглашения, имеет значительно больший потенциал роста, чем коэффициент конверсии.

Теперь давайте перейдем к третьей метрике: среднему количеству приглашений, посылаемых одним пользователем. Этот показатель не является процентным. Его минимальное значение равно 0. Базовое значение равно 2.3. Каково же максимально возможное значение для этой метрики? На первый взгляд кажется, что его невозможно определить достаточно точно. Но нам нужна хотя бы приблизительная оценка максимального значения, чтобы рассчитать потенциал роста. Может ли оно быть бесконечным? Нет, поскольку численность населения нашей планеты измеряется конечным числом. Каждый пользователь может пригласить всех своих родственников, друзей и знакомых присоединиться к Friendster. Таким образом, максимальным значением будет среднее количество друзей, которое есть у пользователя Friendster. Что это за число? Я не знал точно, но мне казалось, что разумная оценка составляет от 100 до 200 человек. В 1990-х годах психолог Робин Данбар провел исследование, пытаясь определить максимальное число людей, с которыми человек может поддерживать стабильные социальные отношения. Он пришел к выводу, что этот предел – называемый числом Данбара – равен 150, что соответствует середине моего предполагаемого диапазона. Если мы используем это значение, то увидим, что потенциал роста среднего количества посылаемых приглашений в расчете на одного пользователя составляет 150 ÷ 2.3 = 6 520 %. Даже если отталкиваться от более консервативной оценки максимального значения в 100 приглашений, потенциал роста этой метрики все равно будет значительно превышать аналогичный показатель для двух других метрик.

Когда вы впервые увидели Рисунок 14.5, не возникло ли у вас ощущение дежавю? Взгляните еще раз на кривые рентабельности инвестиций для трех метрик на Рисунке 14.2. Замечаете сходство? Процент пользователей, посылающих приглашения, подобен метрике A с хорошим показателем ROI. Коэффициент конверсии подобен метрике B, для которой характерна низкая рентабельность. Среднее количество приглашений, посылаемых одним пользователем, в наибольшей степени соответствует метрике C. Однако мы не будем знать этого наверняка до тех пор, пока не увидим, насколько значительно можно улучшить значение метрики и каких усилий это потребует.

Выбор НЗМ для улучшения

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

Цикл оптимизации метрики

Теперь, когда я выбрал наиболее значимую метрику для улучшения, можно было перейти к следующему шагу в процессе анализа бережливого продукта. На этом этапе происходит запуск цикла оптимизации метрики, показанный в правой части Рисунка 14.1. Вместе с командой мы провели мозговой штурм с целью генерации потенциальных идей по улучшению выбранного целевого показателя. Затем каждую из выдвинутых идей оценили с точки зрения того, насколько она может повлиять на улучшение метрики, и каких ресурсных затрат потребует ее реализация. После этого мы пришли к выводу, что наилучшей по показателю своей рентабельности является идея с импортом адресной книги. Сейчас наличие в приложениях функции импорта адресной книги является привычной, но в то время это было редкостью. Многие из наших пользователей хранили адреса электронной почты своих друзей в адресной книге, которая была привязана к их учетной записи у почтовых провайдеров, таких как Gmail и Yahoo!Mail. Наша новая функция должна была позволить пользователям, введя учетные данные для доступа к своему электронному почтовому ящику, импортировать во Friendster хранящуюся в почтовом сервисе контактную информацию своих друзей. Разработанный нами импортер адресной книги отображал список перенесенных контактов и позволял пользователям выбирать из него тех, кому они хотели бы направить приглашение. Мы предполагали, что реализация данной функции приведет к значительному увеличению среднего количество приглашений, посылаемых одним пользователем.

Что касается технической реализации, несмотря на то что часть функционала была общей для всех почтовых провайдеров, все же требовалось проделать определенный объем работы, чтобы интегрироваться с каждым конкретным почтовым сервисом. На этом этапе я понял, что было бы полезно разбить разрабатываемую функцию на более мелкие части (как это описано в главе 6), выделив в отдельные блоки задачи по интеграции с каждым из провайдеров. Чтобы протестировать нашу гипотезу, затратив на это минимальное количество усилий, я решил использовать MVP, функционал которого позволял импортировать адресную книгу, но работал пока только с одним из почтовых сервисов. Проанализировав профили наших пользователей, я обнаружил, что наибольшей популярностью у них пользуется «почтовик» Yahoo!Mail. Соответственно, разработка именно этого функционального блока должна была обеспечить наиболее высокую рентабельность инвестиций. Следующим шагом в этом направлении стала разработка и внедрение программного решения. На выполнение этой работы менеджеру по продукту и разработчику потребовалось около недели.

«Волшебная пилюля» или нет?

Мы запустили разработанную функцию и перешли к следующему, самому захватывающему шагу в процессе анализа бережливого продукта: отслеживанию изменений ключевой метрики. На Рисунке 14.6 показана динамика изменений метрики до и после запуска функции, позволяющей импортировать адресную книгу. Вертикальная ось показывает среднее количество посылаемых приглашений в расчете на одного отправителя, а горизонтальная – даты фиксации наблюдений. Характерной особенностью социальных приложений, и в этом смысле социальная сеть Friendster не была исключением, является довольно сильная зависимость активности пользователей от дня недели. Поэтому для большинства показателей мы учитывали их средние значения за семь дней, чтобы можно было более точно выявлять тренды. Каждая точка данных на графике, представленном на Рисунке 14.6, фактически отображает среднее значение показателя за последние семь дней.

На графике отчетливо видно, что изначально значение метрики колебалось незначительно, оставалось в узком диапазоне между 2.2 и 2.4. То место, где плавная горизонтальная линия разворачивается и устремляется вверх, соответствует дате запуска функции импорта адресной книги. Поскольку мы использовали 7-дневную среднюю, потребовалось несколько дней на то, чтобы линия графика пришла в полное соответствие с текущими дневными значениями метрики. Новое усредненное значение количества приглашений, посылаемых одним пользователем, продолжало расти с каждым днем и добралось до отметки 5.3. Я был в полном восторге!

Идея сработала как «волшебная пилюля»: всего за неделю работы ключевой показатель удалось улучшить более чем в два раза (5.3 ÷ 2.3 = 2.3x)! Если вспомнить соответствующее уравнение для улучшения бизнеса, то увеличение данной метрики в 2.3 раза означало, что число наших новых клиентов выросло также в 2.3 раза за счет вирусного привлечения. И это притом, что созданная нами функция импорта умела работать пока только с одним из почтовых сервисов. Получив количественные статданные, столь однозначно подтвердившие нашу гипотезу, мы немедленно приступили к разработке усовершенствований, необходимых для интеграции нашего приложения с другими почтовыми провайдерами. В конечном итоге это привело к дополнительному улучшению ключевой метрики.

Рисунок 14.6. Среднее количество приглашений, посылаемых одним пользователем: до и после запуска

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

Приведенный пример показывает, насколько простым и эффективным может быть использование аналитики в деле улучшения вашего бизнеса. Вы можете достичь аналогичных результатов, применяя процесс анализа бережливого продукта. Как и в случае с MarketingReport.com, описанным в главе 11, я не делал ничего экстраординарного; просто следовал процессу и принципам, описанным в этой книге.

Оптимизация с применением A/B-тестирования

Как уже обсуждалось в главе 7, A/B-тестирование, также известное как сплит-тестирование, представляет собой количественный метод исследования, в ходе которого вы проводите испытание двух (или более) альтернативных варианта одновременно, чтобы затем сравнить их эффективность. В то время, когда я работал с Friendster, специализированное программное обеспечение, которое сейчас используется для проведения A/B-тестирования, было недоступно, а создание собственного инструментария потребовало бы привлечения большого количества ценных инженерных ресурсов. Поэтому я просто провел сравнение значений улучшаемой метрики по состоянию на «до и после», и получил прекрасный результат. Современные технологии позволяют с легкостью проводить A/B-тестирование для каждой из реализуемых идей по улучшению продукта. Запуск обновленной версии одновременно со старой помогает исключить влияние на результат каких-либо посторонних факторов.

Важным понятием в A/B-тестировании является степень статистической достоверности, которая зависит от различий в характеристиках сравниваемых вариантов и от размера выборки. Существуют онлайн-инструменты, которые помогают рассчитать значение показателя статистической достоверности для любого теста. Соответственно, вам не требуется владеть методикой его расчета, но важно понимать, что статистическая достоверность выше при существенных различиях в характеристиках и при больших размерах выборки. Если размер выборки слишком мал, вы не получите статистически значимых результатов. Если объектами тестирования являются два очень схожих по характеристикам варианта, может потребоваться очень большой размер выборки, чтобы выявить хоть какие-то статистически значимые различия показателей.

Арсенал инструментов для проведения A/B-тестирования отличается большим разнообразием и включает в себя такие приложения, как Optimizely, Unbounce, KISSmetrics, Visual Website Optimizer и Google Content Experiments (в составе Google Analytics). Многие компании предпочитают создавать собственные платформы для A/B-тестирования. Все эти инструменты позволяют взять один или несколько подлежащих проверке вариантов (например, целевой страницы) и затем случайным образом распределить между ними пользовательский трафик. Далее происходит отслеживание результатов по интересующему вас показателю, что в итоге обеспечивает понимание того, как работает каждый из протестированных вариантов с указанием степени статистической достоверности, рассчитанной на основании размера выборки.

Многие компании включают A/B-тестирование в качестве обязательного этапа процесса разработки своих продуктов, особенно при внесении в них серьезных изменений. Вместо того чтобы сразу заменять прежнюю версию продукта новой, они оставляют ее в работе для большей части своих клиентов и дают доступ к обновленной версии лишь небольшому проценту пользователей. Затем они сравнивают полученные в ходе этого эксперимента значения ключевых показателей для существующей и обновленной версий. Прежде чем увеличить процент пользователей, которые получают доступ к новой версии, команда разработчиков хочет убедиться в том, что предполагаемые улучшения, которые и являлись целью создания обновления, действительно имеют место, при том что другие ключевые показатели продукта существенно не ухудшились. Такой процесс, иногда называемый дросселированием, является отличным способом применения принципов бережливого производства для снижения рисков, возникающих после запуска продукта. На заключительном этапе, если отслеживаемые показатели выглядят хорошо, 100 % пользователей переводят на новую версию продукта, а старая просто уходит в небытие.

Компания Netflix славится своей приверженностью A/B-тестированию, причем как на маркетинговом, так и на продуктовом направлениях. В ответ на вопрос «Для каких функций, помимо процедуры регистрации, Netflix проводит A/B-тестирование?», заданный на веб-сайте Quora, директор по продуктам Netflix Нил Хант ответил: «Если коротко, то почти для всех». Далее он рассказал, что Netflix проводит сравнительное тестирование различных вариантов пользовательского интерфейса, алгоритмов рекомендаций, расположения и размеров кнопок, времени загрузки страниц и уровней качества кодирования потокового видео. Свой ответ Хант завершил словами:

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

A/B-тестирование – это все, что нам нужно?

Метод A/B-тестирования – это основной инструмент для формирования решений в отношении продукта, основанных на фактических данных. Эти данные отражают поведение большого числа пользователей, поэтому в данном случае не возникает риска расхождения между тем, что говорят участники тестирования, и тем, что они реально делают. В этот момент вы не сидите с ними рядом, поэтому не должно быть никаких опасений по поводу того, что присутствие модератора может повлиять на результаты теста. Конечно, разработчики не должны полагаться исключительно на количественные исследования – не стоит забывать и об Опре. Во многих случаях количественное тестирование должно быть дополнено качественным исследованием, способным объяснить причины, стоящие за поведением пользователей.

Команды, которые в процессе разработки достигли такого уровня, когда они могут насладиться процессом быстрого итеративного A/B-тестирования, прошли до этого момента долгий путь, принимая решения в условиях недостатка точных данных. Некоторые разработчики могут поддаться соблазну пропустить этап качественных исследований и сразу перейти к A/B-тестированию своего кандидата в MVP на соответствие рынку. Но такой подход почти наверняка приведет к напрасному расходованию ресурсов и провалу. В этом случае проведенное A/B-тестирование, скорее всего, закончится достижением низкого локального максимума, на котором они и застрянут в значительном отдалении от соответствия рынку.

Давайте вернемся к пирамиде соответствия продукта рынку, снова показанной на Рисунке 14.7. Гипотезы, которые вы выдвигаете на одном слое, влияют на все слои, находящиеся выше. Гипотезы, относящиеся к уровню пользовательского опыта, являются наименее затратными для внесения изменений. Изменение набора функций продукта также возможно, но потребует уже больших усилий. Что же касается основополагающих элементов соответствия продукта рынку – представление о целевых клиентах, их недостаточно удовлетворенных потребностях, а также ценностное предложение, – то их будет очень сложно изменить после того, как вы создадите свой продукт. Как только вы сформулируете свои гипотезы, соответствующие этим слоям пирамиды, они становятся похожи на взаимосвязанные тектонические плиты. Если вы сдвинете хотя бы одну из них после завершения разработки, созданный вами продукт в значительной мере утратит свою актуальность и устойчивость – эффект будет подобен тому, как землетрясение превращает здание в руины. Когда это происходит, человеческая природа заставляет нас стремиться к сохранению и повторному использованию как можно большей части результатов уже проделанной работы. Но это может добавить обременительные ограничения в пространство решений, что еще больше осложняет ситуацию в условиях, когда изменение гипотез происходит в пространстве проблем. В таких случаях бывает проще начать строительство с нуля, уже на новом фундаменте.

Рисунок 14.7. Пирамида соответствия продукта рынку

Последовательность шагов в процессе разработки бережливого продукта выстроена таким образом, чтобы ключевые гипотезы подвергались проверке в том порядке, который в наибольшей степени снижает риски и увеличивает шансы на достижение соответствия продукта рынку. Проблемное пространство не настолько пригодно для использования метода A/B-тестирования, как пространство решений. На трех нижних уровнях пирамиды соответствия продукта рынку требуется проведение качественных исследований, чтобы вы могли создавать, тестировать и совершенствовать свои гипотезы. После запуска продукта происходит плавный переход от преимущественного использования качественных методов сбора информации и обучения к количественным. Короче говоря: качественное исследование помогает вам определить, что должен представлять собой продукт, а количественное – как довести его до совершенства. Таким образом, чтобы создать успешный продукт, вам потребуется помощь и Опры, и Спока.

Глава 15

Заключение

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

Процесс создания бережливого продукта позволяет сформулировать и протестировать выдвинутые вами гипотезы путем выполнения следующих шести шагов:

1. Идентификация целевых потребителей.

2. Определение недостаточно удовлетворенных потребностей.

3. Формирование ценностного предложения.

4. Определение функционала минимально жизнеспособного продукта (MVP).

5. Создание прототипа MVP.

6. Тестирование MVP на пользователях.

Процесс начинается в пространстве задач и постепенно переходит в пространство решений. Сначала вы идентифицируете своих целевых клиентов, которых описываете, используя метод персонажей. Чтобы создать максимально ценный для клиентов продукт, вы используете соотношение важности и удовлетворенности, что позволяет выделить важные, но недостаточно удовлетворенные потребности. Используя модель Кано, вы формируете дифференцированное ценностное предложение, которое наилучшим образом отвечает потребностям целевых клиентов. Затем вы определяете минимальный набор функциональных возможностей, необходимых для реализации ключевых составляющих ценностного предложения. На следующем этапе вы разрабатываете прототип MVP с удобным и продуманным пользовательским интерфейсом, применив принципы создания превосходного UX-дизайна.

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

Убедившись в достижении достаточно высокой степени соответствия продукта рынку, вы приступаете к непосредственному созданию MVP. Для снижения рисков и ускорения процесса разработки вы должны действовать поэтапно, итеративно, используя принципы Agile-разработки. При этом постоянный контроль и применение методов тестирования помогают достичь более высокого качества продукта, а непрерывная интеграция и непрерывное развертывание позволяют ускорить процесс разработки.

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

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

1. Имейте собственную точку зрения, но оставайтесь непредубежденными. Как вы наверняка понимаете, создание новых продуктов – занятие не для слабонервных. Вам постоянно приходится принимать решения в условиях неопределенности. Поэтому так важно иметь собственную точку зрения и быть решительными в ее отстаивании. Вместе с тем в процессе создания продукта вам необходимо исследовать те области, которые характеризуются наибольшей степенью неопределенности и риска. Во время проведения тестирования следует избегать ситуаций, когда вы становитесь заложником своей первоначальной точки зрения. Вместо этого вы должны быть объективны и основывать свои выводы на фактических данных. Будучи непредвзятым слушателем, вы получите максимум знаний, которые в дальнейшем сможете использовать для пересмотра и улучшения своего мышления.

2. Сформулируйте свои гипотезы. Создание продукта требует выдвижения множества предположений. Интересный способ осмысления продукта – рассматривать его как совокупность всех гипотез, которые привели к конечному результату. Вы должны постараться быть как можно более откровенными в отношении выдвигаемых вами гипотез. Невероятно полезно фиксировать свои гипотезы. Как сказал адмирал Хайман Риковер: «Ничто так не обостряет мыслительный процесс, как изложение своих аргументов». Ваши коллеги должны поступать таким же образом, чтобы обеспечить прозрачность выдвигаемых гипотез для всех участников команды. Делая гипотезы доступными и открытыми для обсуждения, вы тем самым способствуете их улучшению.

3. Жестко расставляйте приоритеты. В процессе создания продукта существует множество идей, которые ведут конкурентную борьбу за ресурсы, поэтому компромиссы неизбежны. Расплывчатое представление о приоритетах обычно приводит к неэффективности и нерешительности. Вот почему я рекомендую жестко ранжировать как бэклоги, так и все прочие списки невыполненных дел и заданий. Четкое определение того, что в данный момент является наиболее важным, помогает разумно расходовать ценные ресурсы и время. Как сказал Питер Друкер: «Время – самый дефицитный ресурс, и без управления им невозможно управлять чем-либо другим».

4. Ешьте слона по частям. С расстановкой приоритетов связана идея намеренного ограничения объема работ, выполняемых единовременно. Как обсуждалось в главе 6, работа с меньшими размерами партий способствует концентрации внимания и выполняется быстрее, что позволяет ускорить получение обратной связи от пользователей. Будьте осторожны и не пытайтесь откусывать больше, чем вы сможете проглотить. Это не означает, что вам следует вообще избегать масштабных задач – просто, взявшись за их решение, необходимо попытаться разбить их на более мелкие элементы, чтобы снизить риски возникновения ошибок и ускорить выполнение итераций.

5. Чаще общайтесь с пользователями. Именно пользователи являются главными оценщиками продукта; они помогают получить знания, которые необходимы вам для достижения соответствия рынку. Чем раньше и чаще вы начнете общаться с клиентами, тем лучше. Стоит потратить усилия на создание платформ, упрощающих планирование и проведение пользовательского тестирования, чтобы в итоге получить возможность контактировать с максимально большим числом пользователей. Не допускайте, чтобы с момента последнего пользовательского тестирования проходило слишком много времени; поверьте, клиенты всегда найдут, чем вас удивить.

6. Тестируйте перед созданием. Многие команды спешат запустить свой продукт, не проверив предварительно ни одну из своих гипотез. Но переход к созданию без наличия подтверждений, что создаваемый продукт соответствует требованиям рынка, почти наверняка приведет к тому, что ваши ресурсы окажутся потраченными впустую. Итерации, проводимые на основе результатов тестирования проектных артефактов, происходят быстрее и обходятся дешевле, чем в том случае, когда вы выносите на суд потребителей сразу готовый продукт. Кроме того, в процессе создания члены команды разработчиков естественным образом привязываются к продукту, что может привести к наличию пре- дубеждений и отсутствию желания и готовности к внесению в результат своего труда серьезных изменений.

7. Остерегайтесь застрять на локальных максимумах. Как вы помните из главы 14, локальный максимум означает, что вы достигли наилучших результатов из возможных в пределах диапазона рассмотренных вами вариантов, но при этом за границами зоны вашего внимания существуют и более привлекательные альтернативные возможности. Вы можете понять, что достигли локального максимума, когда продолжение итераций уже не приводит к дополнительным улучшениям продукта или ключевых показателей. На этом этапе необходимо сделать паузу и взглянуть на ситуацию под другим углом зрения. Чтобы добиться дальнейшего прогресса, попробуйте перейти на более высокий уровень, используйте дивергентное мышление для генерации новых заслуживающих внимания идей.

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

9. Убедитесь, что ваша команда обладает необходимыми навыками. Как можно заметить, исходя из многообразия тем, рассмотренных в этой книге, создание успешного продукта требует наличия широкого спектра навыков. Для программных продуктов этот перечень включает: управление продуктом, исследование пользователей, интерактивный дизайн, визуальный дизайн, копирайтинг, Agile-разработку, фронтенд и бэкенд программирование, контроль качества, DevOps и аналитику. У разных продуктовых команд уровни владения каждым из ключевых навыков будут различаться. Вы должны знать сильные и слабые стороны своей команды. Выясните, улучшение каких навыков принесет наибольший эффект в вашей ситуации, и попытайтесь соответствующим образом усилить свою команду (например, путем обучения или за счет приглашения дополнительных сотрудников, подрядчиков, консультантов).

10. Развивайте сотрудничество внутри команды. Я часто повторяю, что создание продуктов – это командный вид спорта. Представьте себе баскетбольную команду, состоящую из пяти игроков. Защитники, нападающие, центровые – у каждого из них своя роль. Чтобы достичь общей цели – забросить мяч в корзину, все пять игроков должны скоординировать свои действия, выступать как единая команда, передавая мяч и открываясь для получения паса. Команда разработчиков, создающая новую функцию, подобна баскетбольной команде, пытающейся забросить мяч в корзину. Менеджер по продукту ведет мяч по площадке, записывая истории пользователей и расставляя приоритеты в бэклоге. Он передает мяч специалисту по интерактивному дизайну, который разрабатывает пользовательские потоки и вайрфреймы, а затем делает пас визуальному дизайнеру. Тот создает внешний вид с помощью высокоточных макетов и передает инициативу разработчику. Разработчик, создавая продукт на основе предоставленных ему пользовательских историй и макетов, делает бросок и забрасывает мяч в корзину. Но одного только наличия даже хорошо развитых профессиональных навыков недостаточно для создания отличной продуктовой команды. Каждый ее участник должен понимать свою роль, роли других членов команды, а также то, как все эти роли сочетаются и взаимодействуют для достижения поставленных целей. Очень полезно время от времени делать перерывы в работе, чтобы обсудить вопросы командного взаимодействия и идеи по его улучшению. Всегда приятно работать в команде, представляющей собой слаженный коллектив профессионалов. Тесное сотрудничество позволяет значительно увеличить шансы на создание успешного продукта.

Я рекомендую также посетить посвященный этой книге веб-сайт http://leanproductplaybook.com. Там вы найдете новую и обновленную информацию, относящуюся к темам, которые я затронул в данном руководстве. Этот же веб-сайт призван служить тем местом, где мы с вами можем делиться своими идеями и обсуждать их с другими людьми, увлеченными созданием успешных продуктов. Вы также можете связаться со мной, используя следующие контакты:

@danolsen в Twitter: http://twitter.com/danolsen

Lean Product Meetup: http://meetup.com/lean-product

Olsen Solutions consulting: http://olsensolutions.com.

Я был бы рад узнать о вашем опыте применения идей, изложенных в этой книге, а также получить от вас вопросы или отзывы. Вы можете связаться со мной по адресу dan@leanproductplaybook.com. Надеюсь, что вы сочтете полезными советы, содержащиеся в этом руководстве, и что они помогут вам добиться успеха с вашими продуктами.

Благодарности

Прежде всего я хотел бы выразить глубочайшую благодарность моей замечательной жене Ванессе. Эта книга была бы невозможна без ее невероятной поддержки. Наша жизнь уже и без того была довольно насыщенной, когда я приступил к работе над этим проектом; спасибо тебе за то, что самоотверженно взвалила на свои плечи тяжелое бремя домашних забот, чтобы у меня появилось время для достижения поставленной цели – написания этой книги.

Спасибо вам, мама и папа, за всю любовь, поддержку, ободрение и счастье, которые вы мне подарили.

Спасибо вам, София и Ксавье. Каждый день вы заставляете меня улыбаться и вдохновляете на то, чтобы быть самым лучшим.

Спасибо тебе, Диана, за то, что всегда была рядом с нами, и за все, что ты делаешь в нашей жизни.

Я благодарю редакционную команду John Wiley&Sons за их напряженную работу по воплощению идеи этой книги в реальность: Ричарда Наррамора, Кристину Мур, Тиффани Колон и Абирами Шрикандана. Ричард, спасибо за то, что поделился своим видением того, какой могла бы быть эта книга. Кристина, я искренне ценю ваш ценный вклад в написание моей книги, а также незаменимые советы и поддержку.

Я очень благодарен Дэйву Макклюру. Спасибо вам за то, что помогли мне стать спикером, за всю вашу поддержку и за то, что вы являетесь такой уникальной личностью.

Спасибо моим рецензентам Леону Барнарду, Эли Бейт-Зури, Луке Канделе, Ананду Чандрасекарану, Грегу Коэну, Стивену Кону, Сэму Криско, Майку Гусу, Каарен Хансон, Лоре Кляйн, Томасу Кунджаппу, Алексису Лонгинотти, СК Моатти, Майклу Нолану, Кристиану Пиркнеру, Дону Питту, Хитен Шаху, Сунилу Шарме и Кристине Вакера. Ваши отзывы оказались невероятно полезными, и я действительно ценю то, что вы справились с этим в кратчайшие сроки.

Спасибо Шону Эллису, Кристин Лью, Дэйву Макклюру, Джеффри Муру, Бену Норрису, Юсси Пасанену, Кристиану Рореру, Хитен Шаху, Хуанме Тейшиду, Бекке Тецлафф и Тони Ульвику за любезное разрешение сослаться на их замечательные работы.

Я благодарен Марти Кейгану, Жан-Кристофу Кьюрелопу, Диане Кандер, Эшу Маурье, Брайану О’Лири, Дэвиду Вандагриффу, Александре Уоткинс и Брюсу Уильямсу за их полезные советы, связанные с этой книгой.

Кену Файну, Майку Гусу, Стиву Грею, Крису Хаазе, Кристиану Пиркнеру, Джону Гейтвуду, Ивану Гейтвуду, Ричу Шенку, Гаю Борде, Мэтту Макпартлину, Таю Ахмад-Тейлору, Марти Кэгану, Чун Менг Чонгу, Грегу Коэну, Стивену Кону, Сэму Криско, Шону Эллису, Джошу Элману, Каарен Хэнсон, Лоре Кляйн, Ранджиту Кумарану, Тому Ли, Аарону Леви, Алексису Лонгинотти, Алексу Лопес, Джеку Линчу, Джеффу Маджионкалде, Дэну Мартеллу, Дэйву Макклюру, Скотту Митичу, СК Моатти, Майклу Нолану, Кену Нортону, Альберто Савойя, Джиму Шейнману, Джеффу Шульте, Хитен Шаху, Джеффу Тангни, Джо Вулфу и Каю Сюй: я благодарен вам за дружбу и поддержку.

Мне повезло, что я многому научился, работая с талантливыми людьми в невероятно интересных местах. В Naval Reactors, единственной в своем роде организации, которая устанавливает для своих сотрудников высочайшие интеллектуальные требования, я научился проектировать и создавать очень сложные продукты силами кросс-функциональных команд. Я благодарю Джима Кирни, Стива Роджерса, Карла Остермана и Билла Ширли за их наставничество.

Я благодарен Стэндфордской высшей школе бизнеса за все, чему я научился за два незабываемых года, проведенных там, а также за то, что они свели меня со столькими замечательными однокашниками.

Спасибо всем замечательным людям, с которыми я работал в Intuit, компании, где я многому научился. Я особенно благодарен Стиву Грею за его наставничество, за создание столь мощной команды и за огромное количество приятных воспоминаний.

Я выражаю свою искреннюю признательность своей команде YourVersion за вашу самоотверженность и трудолюбие. Как начинающий генеральный директор я многому научился у вас и многое почерпнул из нашего совместного опыта. Я горжусь нашими достижениями и тем, как быстро мы расширили свои возможности для создания, тестирования и запуска новых функций продукта.

Всем, кто посетил или просмотрел видеозаписи моих выступлений, семинаров и слайд-шоу, а также тем, кто прочитал мои посты – спасибо за то, что выслушали все, что я хотел сказать, и помогали распространять идеи, изложенные в этой книге.

Всем участникам, докладчикам и спонсорам семинара по бережливому производству и бережливому UX, состоявшемуся в Кремниевой долине: спасибо вам за вашу заинтересованность в совместном обмене лучшими практиками.

Наконец, я выражаю искреннюю благодарность всем моим клиентам за возможность работать с вами. Это помогло мне усовершенствовать идеи, изложенные в этой книге. У меня была возможность встретиться и поработать со столькими замечательными руководителями, основателями, лидерами и членами прекрасных команд. Их слишком много, чтобы перечислить всех, но вы знаете, о ком я говорю, и я благодарен каждому из вас.

Я также хочу выразить особую благодарность командам Medallia и Financial Engines за всю ту поддержку, которую получал от вас, пока работал над этой книгой.

Ссылки

Cooper, Alan. 1999. The Inmates Are Running the Asylum. Indianapolis: Sams.

Moore, Geoffrey. 2014. Crossing the Chasm, 3rd ed. New York: Harper Business.

Ries, Eric. 2011. The Lean Startup. New York: Crown Business.

Ulwick, Anthony. 2005. What Customers Want. NewYork: McGraw-Hill.

Алан Купер. «Психбольница в руках пациентов. Алан Купер об интерфейсах». СПб.: «Питер», 2018.

Джеффри Мур. «Преодоление пропасти». М.: МИФ, 2012.

Эрик Рис «Бизнес с нуля: Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели». М.: «Альпина Паблишер», 2012.

Энтони Ульвик. «Чего хотят потребители». Киев: CompanionGroup, 2007.

Полезные ресурсы

Представляю вам список полезных инструментов, некоторые из которых я упоминаю в этой книге. Помимо этого, я перечисляю здесь ценные книги, а также людей и ссылки на их блоги, которые рекомендую вам просмотреть. Все они являются отличными источниками информации, относящейся к темам, которые я затронул в своем руководстве. С обновленным списком ресурсов вы всегда можете ознакомиться на сайте http://leanproductplaybook.com.

ИНСТРУМЕНТЫ ДЛЯ:

UX-дизайна:

Balsamiq: http://balsamiq.com

Axure: http://axure.com

UXPin: www.uxpin.com

Sketch: http://bohemiancoding.com/sketch

InVision: http://invisionapp.com

Flinto: https://www.flinto.com

Marvel: https://marvelapp.com

POP: https://popapp.in

Dapp: http://dapp.kerofrog.com.au

OmniGraffle: https://www.omnigroup.com/omnigraffle

Bootstrap: http://getbootstrap.com.

Исследования пользователей:

UserTesting: http://usertesting.com

Validately: https://validately.com

Ask Your Target Market: http://aytm.com

Qualaroo: https://qualaroo.com

SurveyMonkey: https://surveymonkey.com

Join.me: https://www.join.me

Screenleap: http://screenleap.com.

Agile-разработки:

Trello: https://trello.com

JIRA Agile: https://atlassian.com/software/jira/agile

Pivotal Tracker: http://pivotaltracker.com

Rally: https://rallydev.com

VersionOne: http://versionone.com

SwiftKanban: http://swiftkanban.com

LeanKit: http://leankit.com.

Аналитики и A/B-тестирования

Google Analytics: http://google.com/analytics

KISSmetrics: https://www.kissmetrics.com

Mixpanel: https://mixpanel.com

Flurry: http://flurry.com

Optimizely: https://www.optimizely.com

Unbounce: http://unbounce.com

Visual Website Optimizer: http://vwo.com.

КНИГИ

• Anthony Ulwick, «What Customers Want»

• Laura Klein, «UX for Lean Startups»

• Eric Ries, «The Lean Startup»

• Ash Maurya, «Running Lean»

• Geoffrey Moore, «Crossing the Chasm and Inside the Tornado»

• Marty Cagan, «Inspired»

• Alan Cooper, «The Inmates Are Running the Asylum»

• Steve Krug «Don’t Make Me Think and Rocket Surgery Made Easy»

• Robin Williams, «The Non-Designer’s Design Book»

• Jesse James Garrett, «The Elements of User Experience»

• Tom Tullis, Bill Albert, «Measuring the User Experience»

• Aaron Walter, «Designing for Emotion»

• John Hammond, Ralph Keeney, Howard Raiffa, «Smart Choices»

• Alberto Savoia, «PretotypeIt»

• Colin Ware, «Information Visualization».

ЛЮДИ И БЛОГИ

Примечания

1

Упоминаемые здесь и далее социальные сети Facebook и Instagram запрещены на территории Российской Федерации на основании осуществления экстремистской деятельности.

2

Стив Бланк – известный американский предприниматель, создатель восьми успешных стартапов, «Крестный отец Кремниевой долины», автор методики развития клиентов (англ. Customer Development methodology), которая легла в основу концепции бережливого стартапа, автор популярных книг, посвященных стартапам, преподаватель ведущих американских университетов. – Прим. ред.

3

В оригинале данная концепция называется «get out of the building» (сокр. GOOB) – буквально: «покинуть здание». – Прим. пер.

4

Джеффри Мур. «Преодоление пропасти». М.: МИФ, 2012. – Прим. пер.

5

Алан Купер – американский дизайнер, программист и технический писатель. Широко известен как «отец Visual Basic» (предложил принцип связи языка и графического интерфейса). – Прим. ред.

6

Алан Купер «Психбольница в руках пациентов. Алан Купер об интерфейсах». СПб.: «Питер», 2018. – Прим. пер.

7

От англ. «ladder» – лестница. – Прим. пер.

8

Абрахам Маслоу – американский психолог, основатель гуманистической психологии. Диаграмма человеческих потребностей Маслоу нашла широкое применение в экономической теории и занимает важное место в построении теорий мотивации и поведения потребителей. – Прим. ред.

9

Gap в переводе с англ. как раз и означает «разрыв, пробел, окно». – Прим. пер.

10

Энтони Ульвик, «Чего хотят потребители», Киев: Companion Group, 2007. – Прим. пер.

11

Клейтон Кристенсен – американский ученый, теоретик менеджмента, разработавший теорию «подрывных инноваций», которую называют самой влиятельной бизнес-идеей начала XXI века, один из основателей методологии разработки Jobs to Be Done. – Прим. ред.

12

Нориаки Кано – профессор университета Токио. Известен работами по вопросам оценки качества. Основной работой, которая дала начало модели Кано, можно считать «Attractive Quality and Must-Be Quality», опубликованную в журнале Японского сообщества контроля качества в 1984 году. – Прим. ред.

13

Игра слов: произношение названия этой поисковой системы похоже на английское слово «cool», которое в т. ч. употребляется в значении «круто», «крутой». – Прим. пер.

14

Используемый дизайнерами классический вариант заполнения тестового поля в макете страницы, не имеющий смысловой нагрузки. – Прим. пер.

15

Картинка с изображением кита-белухи, которого вытаскивает из воды стайка оранжевых птиц. – Прим. пер.

16

От англ. «user» – пользователь. – Прим. пер.

17

Главными героями сериала являются бывшие спецназовцы, приходящие на помощь людям в сложных ситуациях. – Прим. пер.

18

По названию недорогой лапши быстрого приготовления. – Прим. пер.

19

Эрик Рис. «Бизнес с нуля: Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели». М: Альпина Паблишер, 2012. – Прим. пер.

20

Диджерати (англ. digerati) – элита компьютерной индустрии и онлайн-сообществ, объединяющая известных ученых в области вычислительной техники, авторов техноизданий и блогеров. Слово образовано от слов «digital» и «literati» и напоминает ранее образованный неологизм «glitterati». – Прим. ред.

21

Крупнейшая в мире сеть магазинов самообслуживания складского типа, для посещения которых требуется клубная карта. – Прим. пер.

22

Масштабное проектирование прежде всего. – Прим. пер.

23

Стивен Макконнелл — американский программист, автор книг по разработке программного обеспечения. Журнал Software Development дважды удостоил его книги премии Jolt Excellence как лучшие книги года о разработке программного обеспечения. – Прим. ред.

24

Автор использует здесь игру слов: «Agile» + «Waterfall» [водопад] = «Agilefall». – Прим. пер.

25

Питер Друкер (1909–2005) – один из бизнес-гениев XX века, известный теоретик менеджмента. Более 50 лет преподавал искусство менеджмента сначала в университете Нью-Йорка, а потом – в Университете Клермонта. – Прим. ред.

26

Имеется ввиду сходство с воинственным кличем, с которым пираты атаковали суда своих жертв. – Прим. пер.

Content

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

Введение Почему инновационные продукты терпят крах и как бережливое производство меняет правила непростой игры – создания успешных продуктов

Почему продукты терпят крах

Почему нужна именно эта книга?

Для кого предназначена эта книга?

Как организована эта книга

Часть I Основные концепции

Глава 1 Достижение соответствия продукта рынку с помощью процесса создания бережливого продукта

Что понимается под соответствием продукта рынку?

Пирамида соответствия продукта рынку

Рынок

Продукт

Соответствие продукта рынку

Взлет: с 47-го места на первое

Процесс создания бережливого продукта

Глава 2 Пространство проблем и пространство решений

Космическая ручка

Проблемы, формирующие рынки

Что и как

Разработка продукта «снаружи – внутрь»

Нужно ли прислушиваться к потребителям?

История о двух «фишках» Apple

Использование пространства решений для обнаружения пространства проблем

Часть II Процесс создания бережливого продукта

Глава 3 Идентификация целевого потребителя (Шаг 1)

Ловля потребителя

Как сегментировать целевой рынок

Демографическая сегментация

Психографическая сегментация

Поведенческая сегментация

Сегментация на основе потребностей

Пользователи и покупатели

Жизненный цикл внедрения новых технологий

Метод персонажей

Что вы должны знать о своем персонаже?

Как создавать персонажей

Потенциальные проблемы с персонажами

Глава 4 Выявление недостаточно удовлетворенных потребностей клиентов (Шаг 2)

Завуалированные потребности

Клиентские потребности на примере приложения TurboTax

Интервью с целью идентификации потребителей

Лестница потребительских преимуществ

Иерархии потребностей

Иерархия человеческих потребностей по Маслоу

Моя иерархия потребностей онлайн-пользователей

Соотношение важности и удовлетворенности

Успех Uber: удовлетворение неудовлетворенных потребностей

Прорывные и постепенные инновации

Прорывные инновации: музыка на прогулке

Измерение степени важности и удовлетворенности

Применение соотношения показателей важности и удовлетворенности на реальных данных

Нулевой размер выборки – это нормально

Другие фреймворки

Gap-анализ

Jobs-to-Be-Done («Работа для выполнения»)

Визуализация потребительской ценности

Потребительская ценность, обеспечиваемая продуктом или функцией

Возможность повышения потребительской ценности

Потребительская ценность, создаваемая улучшениями продукта

Модель Кано

Практическое использование фреймворков

Глава 5 Формирование ценностного предложения (Шаг 3)

Стратегия отказа

Ценностные предложения на примере поисковых систем

Не так уж и «круто»

Формирование ценностного предложения продукта

Катись туда, где будет находиться шайба

Флип-камера

Учет прогнозов при формировании ценностных предложений

Глава 6 Определение функционала минимально жизнеспособного продукта (MVP) (Шаг 4)

Истории пользователей

Фрагментация функций

Преимущества работы с мелкими партиями

Определение трудозатрат на основе балльной оценки историй пользователя

Использование показателя рентабельности инвестиций для расстановки приоритетов

Визуализация рентабельности инвестиций

Приблизительная оценка показателя ROI

Выбор кандидата в MVP

Глава 7 Создание прототипа MVP (шаг 5)

Чем является (и чем не является) MVP?

MVP-тесты

Продуктовые и маркетинговые MVP-тесты

Количественные и качественные MVP-тесты

Матрица MVP-тестов

Качественные маркетинговые MVP-тесты

Количественные маркетинговые MVP-тесты

Целевая (лендинговая) страница / «Дымовой тест»

MVP-тест целевой страницы на примере приложения Buffer

Демо-ролик

Рекламная кампания

Маркетинговое A/B тестирование

Краудфандинг

Качественные продуктовые MVP-тесты

Эскизы

Вайрфреймы

Макеты

Интерактивный прототип

MVP-тесты: «Волшебник страны Оз» и «Консьерж»

MVP-тест «Консьерж» на примере Airbnb

«Живой» продукт

Количественные продуктовые MVP-тесты

Аналитика продукта и A/B-тесты

Глава 8 Применение принципов превосходного UX-дизайна

Что отличает превосходный UX-дизайн?

Удобство использования

Удовольствие от использования продукта

Айсберг UX-дизайна

Концептуальный дизайн

Концептуальный дизайн на примере Uber

Исследование пользователей

Метод персонажей

Информационная инфраструктура

Карты сайтов

Интерактивный дизайн

Интерактивный дизайн приложения TurboTax

Блок-схемы

Вайрфреймы

Визуальный дизайн

Цвет

Типографика

Графика

Стандарты стиля

Компоновочные сетки

Макеты

Принципы дизайна

Гештальт-принципы

Визуальная иерархия

Принципы композиции

Адаптивный дизайн

Проектирование для экранов разных размеров

Копирайтинг также является частью UX-дизайна

«Команда “А”»

UX – это то, что видит пользователь

Глава 9 Тестирование минимально жизнеспособного продукта (MVP) на пользователях (Шаг 6)

Сколько пользователей нужно привлечь к тестированию?

Очное, дистанционное и немодерируемое тестирование с участием пользователей

Как отобрать для тестирования целевых потребителей

Как избежать ловушки планирования

Тестирование на посетителях Starbucks

Оплата участия в тестировании

Тестирование на пользователях в компании Intuit

Тестирование на пользователях по методу «Рамэн»

Как структурировать процедуру тестирования

Как задавать правильные вопросы

Открытые и закрытые вопросы

Принимайте реальность такой, как она есть

Завершение тестирования

Как собирать и обобщать отзывы пользователей

Юзабилити и соответствие продукта рынку

Глава 10 Итерации и развороты на пути к соответствию рынку

Цикл: «Создание – Измерение – Обучение»

Цикл: Гипотеза – Проектирование – Тестирование – Обучение

Итеративное пользовательское тестирование

Раунд первый

Раунд второй

Раунд третий

Раунд четвертый

Идти напролом или свернуть?

Глава 11 Практический пример создания бережливого продукта

MarketingReport.com

Шаг 1: Идентификация целевых потребителей

Шаг 2: Определение недостаточно удовлетворенных потребностей

Шаг 3: Формирование ценностного предложения

Шаг 4: Определение функционала для MVP

Шаг 5: Создание прототипа MVP

Шаг 6: Тестирование MVP на пользователях

Привлечение представителей целевого рынка для участия в тестировании

Скрипт пользовательского тестирования

Что мы узнали от пользователей

Итерации и развороты для повышения степени соответствия продукта рынку

Разворот

Итерации, основанные на обучении

Раунд второй

Восхождение на вершину соответствия продукта рынку

Выводы

Часть III Создание и оптимизация продукта

Глава 12 Создание продукта с помощью методов Agile-разработки

Agile-разработка

Scrum

Канбан

Инструменты Канбана

Выбор правильного метода Agile-разработки

Достижение успеха с помощью Agile

Взаимодействие внутри команды

Жесткая расстановка приоритетов

Создавайте для разработчиков адекватное описание продукта

Опережайте разработчиков

Разбивайте истории на фрагменты

Гарантия качества

Разработка через тестирование

Непрерывная интеграция

Непрерывное развертывание

Глава 13 Измерение ключевых показателей

Аналитика в сравнении с другими методами исследования

Опра против Спока

Интервью с пользователями

Тестирование юзабилити

Опросы

Чистая оценка промоутера

Вопрос Шона Эллиса о соответствии продукта рынку

Аналитика и A/B-тестирование

Аналитические фреймворки

Аналитика в Intuit

Аналитика во Friendster

Стартап-метрики для «пиратов»

Определение наиболее значимой метрики

Начните с удержания клиентов

Оптимизируйте конверсию до привлечения клиентов

Оптимизация привлечения клиентов

Коэффициент удержания

Кривые удержания клиентов

Когортный анализ

Отслеживание улучшений степени соответствия продукта рынку

Уравнения для улучшения вашего бизнеса

Уравнения для бизнес-модели, связанной с получением дохода от рекламы

Уравнения для бизнес-модели, связанной с получением дохода от подписок

Достижение прибыльности

Пожизненная ценность клиента

Стоимость привлечения клиента

Глава 14 Использование аналитических инструментов для оптимизации продукта и бизнеса

Процесс анализа бережливого продукта

Решение проблемы локального максимума

Анализ бережливого продукта на примере Friendster

Определение ключевых метрик

Фиксация базовых значений для метрик

Оценка потенциального ROI для каждой метрики

Выбор НЗМ для улучшения

Цикл оптимизации метрики

«Волшебная пилюля» или нет?

Оптимизация с применением A/B-тестирования

A/B-тестирование – это все, что нам нужно?

Глава 15 Заключение

Благодарности

Ссылки

Полезные ресурсы

Примечания