Глава 3. План быстрых исследований
Это мой друг Эрик, стоящий перед своим бэклогом и доской задач в кабинете своей команды. Эрик – владелец продукта; он и его команда тяжело работают, чтобы выпустить успешный продукт, но пока не добились этого. Впрочем, это не слишком беспокоит Эрика, ведь у него есть стратегия достижения успеха. И она обязательно сработает.
Эрик работает на компанию под названием Liquidnet – огромную торговую сеть для крупных инвестиционных организаций. Задолго до того, как Эрик сфотографировался перед своей доской, кто-то в этой компании обнаружил группу заказчиков, которых Liquidnet могла бы обслуживать лучше, а также выдвинул пару предложений, как это сделать. Эрик был в команде, которая начала работу с этими идеями. Это работа владельцев продукта. Не думайте, что эти люди всегда работают только со своими собственными идеями, это не так. Одна из самых больших сложностей в работе владельца продукта – принять чье-то предложение и продвигать его до воплощения в жизнь или, напротив, доказать его несостоятельность. Лучшие владельцы продуктов вроде Эрика включают в эту работу всю команду.
Начните с обсуждения перспектив
Эрик начал свою работу вовсе не с составления бэклога пользовательских историй. Оттолкнувшись от отличной идеи, пришедшей кому-то в голову, он рассмотрел ее как благоприятную возможность для всей компании, чем она на самом деле и являлась. Он говорил об идее с руководством компании, обсуждалось следующее.
В чем состоит идея?
Кто эти заказчики? Что за компании, как мы предполагаем, будут покупать продукт?
Кто наши пользователи? Какие типы людей в этих компаниях, мы считаем, будут использовать продукт и для чего?
Почему он им нужен? Какие задачи заказчиков и пользователей решит продукт и почему они не могут решить их сегодня? Какие преимущества получат эти люди, купив продукт и начав его использовать?
Почему мы его создаем? Если мы создадим этот продукт и он будет успешным, что это нам даст?
Эрику необходимо было, чтобы он и другие сотрудники его организации одинаково понимали проблему, прежде чем взять на себя ответственность за реализацию этой возможности. Было очевидно, что в ближайшие месяцы ему придется изложить историю этого продукта множество раз, поэтому стоило заранее изучить все как следует.
Первое обсуждение истории нужно для формирования структуры потенциала.
Подтвердите наличие проблемы
Эрик, конечно, доверял интуиции своего руководства, но твердо знал: любая грандиозная идея – это только гипотеза. А гипотезу об успешности идеи можно проверить только одним способом – своими глазами увидеть ее успешную реализацию.
Поэтому первым делом Эрик поговорил с заказчиками и пользователями, чтобы узнать о них побольше. Так он убедился, что у некоторых заказчиков и в самом деле были проблемы и они очень заинтересованы в их решении. Эрик поговорил и с людьми, которые должны были работать с продуктом. Они ничего о нем не знали, поэтому могли лишь поделиться с существующим рабочим окружением проблемами, которые должен был решить новый продукт.
Убедитесь, что проблема, которую вы собираетесь решить, на самом деле существует.
За время общения с пользователями и заказчиками Эрик наметил группу людей, которых считал хорошими кандидатами для пользовательского тестирования новой программы. Некоторые компании называют таких людей партнерами по разработке на стороне заказчика. Обратите внимание на эту деталь, так как позже она встретится в этой истории.
Фактически на этой стадии действовал не только Эрик. Он работал с небольшой командой других людей, которые много обсуждали эту проблему со своими заказчиками и в конце концов пришли к тому, что проблему решить непросто – имелись и другие проблемы, которые нужно было решить в первую очередь. Очень важно понять следующее: чем больше они узнавали, тем сильнее менялась оригинальная идея – вплоть до неузнаваемости. Счастье, что они не начали с разбегу воплощать в жизнь изначальный замысел! Эта работа оказалась бы не нужной ни заказчикам, ни их организации.
К настоящему моменту команда Эрика, поговорив с заказчиками, сформулировала и была готова реализовать решение, которое было бы востребовано у пользователей, а значит, принесло бы выгоду компании-нанимателю. Вот теперь команда могла бы пойти ва-банк и поставить на кон все. Наконец можно было приступить к созданию бэклога историй, описывающих их решение, и набрать команду специалистов для воплощения его в жизнь. Кроме того, будучи разумными людьми, они разработали карту историй, чтобы проработать детали большой идеи в виде набора конкретных функций для реализации. Но поскольку они и в самом деле разумные люди, последнее, что они собираются делать на этом этапе, – это начать программировать.
Прототипируйте, чтобы исследовать
Эрик начал работать как владелец продукта. Сначала он рассмотрел свое решение как набор простых несложных историй – пользовательских историй. Затем перешел к визуализации идеи, превратив ее в простые наброски интерфейса. А после этого создал высокоточный прототип. Это еще не было работающее программное обеспечение – всего лишь простой электронный прототип, созданный с помощью несложной программы наподобие Axure или даже PowerPoint.
Для Эрика все это было исследовательскими этапами, которые помогли ему детально рассмотреть свое решение. Разумеется, ему хотелось скорее выдать продукт пользователям, чтобы узнать их мнение, но он знал: нужно быть твердо уверенным в том, что продукт решит проблемы пользователей, прежде чем выпускать его.
Создавайте прототипы и эскизы, чтобы детально представлять себе свое решение.
Между прочим, я скрыл от вас важную деталь: Эрик был дизайнером взаимодействия. Для представителей этой профессии вполне естественно проводить много времени в общении с заказчиками и пользователями, а также создавать простые прототипы. Но для нового продукта он выступил также в роли владельца – человека, который несет полную ответственность за успех всей работы. Другие владельцы продукта в компании, где работал Эрик, не имели навыков дизайна, но они работали в тесной связке с дизайнерами, которые помогали им проводить интервью с пользователями и визуализировать решения.
Я не присутствовал, когда Эрик показывал свои прототипы пользователям, и не знаю точно, как прошло тестирование. Но я бывал в таких ситуациях множество раз и всегда поражался тому, как много я могу почерпнуть у людей, которые будут использовать мое решение на практике. Все, что я могу вам сказать: будьте готовы к неприятным сюрпризам и плохим новостям, хотя на самом деле плохим результатам надо радоваться, ведь вы могли получить их через несколько месяцев, потратив время и деньги на разработку программного продукта. Вот тогда это и в самом деле беда, а пока изменения сделать легко и стоит это недорого. Именно так Эрик и поступил.
Разрабатывайте прототипы и проверяйте с реальными пользователями, насколько полезно и пригодно к использованию ваше решение.
Эрик повторял процедуру внесения изменений и тестирования несколько раз, пока не убедился, что наконец получил по-настоящему хорошее решение. Теперь можно было приступить к заполнению бэклога и усадить за работу команду программистов, чтобы они реализовали обновленный прототип в настоящее, работающее программное обеспечение. Но Эрик пока не собирался этого делать. По крайней мере, конкретно этого. Он пока не был готов принять этот вызов.
Критически относитесь к тому, что люди говорят о своих желаниях
Эрик прототипировал то, что считал хорошим, жизнеспособным решением. Но он не был полностью уверен в том, что оно минимально, ведь он продемонстрировал людям множество крутых идей. А когда вы показываете людям такие идеи, неудивительно, что они в восторге. Но Эрик знал, что его работа состоит в уменьшении объема разработки, притом что люди должны остаться довольными. Что же можно отбросить, сохранив при этом жизнеспособность решения?
Была и другая причина для беспокойства. Эрик хорошо знал: когда люди утверждают, что им нравится идея и они охотно работали бы с продуктом, они тоже только предполагают.
Вспомните, как вы сами что-нибудь покупали. Вы, наверное, рассматривали этот продукт. Консультант магазина, возможно, демонстрировал вам какие-то его впечатляющие функции. Вы, может быть, даже опробовали его самостоятельно и представляли, как будете пользоваться этим продуктом и как это будет здорово. Но когда вы купили продукт и начали им пользоваться, оказалось, что все крутые функции не так важны, как вы думали, а важно то, о чем вы не задумывались вовсе. А может быть, оказалось, что вам вообще не так уж нужна была эта покупка. Впрочем, может быть, так происходит только со мной – в моем гараже целая куча хлама, который мне лучше было бы никогда не покупать.
Вернемся к Эрику. Он знал, что его заказчики и пользователи представляли себе продукт, который очень хотели бы использовать, и это давало ему некоторую уверенность. Но по-настоящему убедиться в своей правоте он смог бы лишь после того, как эти люди реально пользовались бы этим продуктом каждый день. Именно к такому результату он стремился, и только он дал бы компании то, чего она хотела достичь. Чтобы проверить это, нужно было нечто большее, чем прототип.
Разрабатывайте, чтобы исследовать
Для Эрика настало время продемонстрировать свою компетентность.
Эрик и его команда приступили к разработке программного обеспечения. Но их первая цель не разработка минимально жизнеспособного продукта. Пока они собираются сделать совсем немного – продукт должен всего лишь позволить потенциальным пользователям выполнять что-то для них полезное. Вряд ли он сильно впечатлит пользователей, а может быть, даже не понравится некоторым. Этот продукт определенно не будет пользоваться популярностью в отделах маркетинга и продаж. Достаточно лишь, чтобы его увидели только те люди, которые могут воспользоваться им хотя бы один раз и на практике понять, решает ли он их проблему.
К счастью, у Эрика была небольшая группа как раз таких людей. Это были заказчики и пользователи, с которыми он работал раньше, когда изучал проблему и подтверждал ее существование, – партнеры по разработке со стороны заказчиков. Именно они давали обратную связь по первым прототипам. Из этой группы Эрик выделил несколько человек, которые могли бы помочь в дальнейшем исследовании. Они должны первыми увидеть продукт – первую версию, меньше минимальной, определенно нежизнеспособную. Эрик надеялся, что они станут первыми испытателями.
И вот что сделал Эрик.
Здесь Эрик очерчивает часть существующего бэклога. Когда делалась эта фотография, программный продукт уже был предъявлен партнерам по разработке и Эрик назначил встречу для обсуждения обратной связи. Кроме того, команда добавила в продукт несколько простых метрик, чтобы можно было видеть, действительно ли люди используют программу и что именно они в ней делают.
Эрик отлично знал, что люди, как правило, вежливы и не хотят вас обидеть. Они могут сказать, что им очень нравится продукт, хотя на самом деле они даже не пробовали его использовать. Но от вежливости в данном случае нет никакого толку, ведь настоящий результат, который Эрик хотел бы получить, – это реальная работа пользователей с продуктом. Кроме того, люди часто бывают придирчивы: они могут перечислить множество проблем, которые есть у продукта, или жаловаться на баги, но метрики показывают, что продукт все-таки используется каждый день. Значит, есть чему порадоваться, несмотря на все жалобы, хотя жалобы – это тоже хорошо, ведь благодаря им Эрик получал идеи дальнейших улучшений.
Бэклог Эрика был организован как карта историй с каркасом из желтых стикеров, расположенным наверху. На этих желтых стикерах в виде глагольных фраз были кратко обозначены действия пользователей с продуктом, которые формировали большую и связную высокоуровневую историю. Ниже располагались подробности – конкретные действия пользователей и то, что им нужно для реальной работы с продуктом. И если детали, над которыми работали Эрик и его команда, менялись от релиза к релизу, то каркас оставался неизменным.
Над тем, что находится в верхнем срезе, выше клейкой ленты, Эрик и команда работают прямо сейчас. Этот релиз займет у Эрика два спринта: они используют методологию Scrum, где спринт, как правило, составляет двухнедельный отрезок времени, так что два спринта равны примерно месяцу. Ниже на доске тоже есть несколько срезов. Следующий слайд, по мысли Эрика, содержит то, что должно выйти в следующем релизе, и т. д. Слева от каждого среза точно так же, как было в Globo.com, наклеен стикер с названием релиза и несколькими словами о том, что ребята хотят изучить в нем, – кроме самого верхнего: там был наклеен постер из мультфильма Dilbert – какая-то шутка, понятная членам команды, но неизвестная мне.
Если вы присмотритесь, то заметите, что верхняя часть текущего среза пуста – это я дорисовал контуры стикеров там, где они должны были быть. По мере того как члены команды совместно работали над планированием, они перемещали эти стикеры на доску с задачами по разработке, находящуюся справа от карты историй. Эта доска показывает истории, которые находятся в работе в текущем спринте, вместе с задачами по предъявлению, в рамках которых программисты и тестировщики обрабатывают различные технические детали, необходимые для успешного воплощения идей истории в работающее ПО.
В работе Эрика с бэклогом в виде карты историй есть еще одна хитрость, доказывающая прозорливость команды: высота верхнего среза. Как только Эрик и его команда заканчивают работу над очередным срезом и отправляют его партнерам по разработке – они называют их бета-заказчиками, – они перемещают вверх стикеры из нижнего среза. После этого следующий релизный срез обсуждается более детально: команда проговаривает все "что, если…", чтобы обнаружить проблемы и внести недостающие детали. Обсуждаются также некоторые идеи для следующего релиза, в результате этой дискуссии большая идея может быть разбита на две-три более мелкие. И в конце концов устанавливается высота этого среза, чтобы расставить приоритеты и определить, что следует брать в работу первым.
Теперь вы поняли, какие это умные ребята?
Повторяйте до жизнеспособности
Эрик мог бы запустить весь этот процесс, сразу оттолкнувшись от идеи минимально жизнеспособного процесса, но он намеренно для начала построил меньше минимума, чтобы затем добавлять понемножку каждый месяц. От партнеров по разработке постоянно поступает обратная связь – как из прямого обсуждения с ними (субъективная), так и из анализа данных (объективная).
Эрик намеревается продолжать в том же духе и дальше, обеспечивая медленный, но постоянный рост проекта и внедрение улучшений, пока его партнеры по разработке не начнут реально использовать продукт в ежедневной работе. Кроме того, Эрик надеется, что эти люди в конце концов порекомендуют продукт другим – настоящим заказчикам. Лишь когда это произойдет, Эрик будет уверен, что создал минимальный и жизнеспособный продукт. И только тогда его можно будет без опаски выпустить на рынок, где он, вне всяких сомнений, станет успешно продаваться. Если Эрик с ребятами попробуют продать продукт до этого момента, то, очевидно, будут иметь дело с толпой разочарованных клиентов, ведь с этими людьми не были установлены личные отношения на протяжении процесса разработки, и поэтому они настроены далеко не так снисходительно.
Как делать не надо
Эрик мог взять свой самый последний, лучший прототип, разбить его на составляющие и начать разрабатывать один фрагмент за другим. Несколько месяцев спустя он был бы готов что-то выпустить и только после этого узнал бы, верны ли его смелые предположения и догадки. И скорее всего, они бы оказались неверны. Можете мне не верить, но чаще всего бывает именно так.
Вот простая иллюстрация, нарисованная моим другом Хенриком Нибергом, – здесь отлично показана ситуация, когда из-за неверной релизной стратегии с каждым выпуском пользователь получает нечто, что не может использовать, пока в последнем релизе не выпустят наконец что-то полезное.
Хенрик предлагает вот такую альтернативную стратегию.
Если я планирую свои релизы по этому принципу, то с каждым выпуском люди получают что-то, что могут реально использовать. Если я, как в этом простом примере, хочу передвигаться на большие расстояния, да еще и таскать с собой какие-то вещи, а вы даете мне скейтборд, я, конечно, буду не слишком доволен. Я скажу вам, как сложно будет уехать далеко на этой штуке, хотя, уверен, есть и любители кататься на скейтборде по автомобильным дорогам. Если вы хотели мне угодить, то, возможно, несколько огорчитесь, но ваша настоящая цель – исследование. Поэтому все нормально: вы узнали, что я хотел бы иметь возможность путешествовать на более дальние расстояния и, кроме того, делать это с комфортом.
По мысли Хенрика, таким образом, дело доходит до выпуска велосипеда, с помощью которого я получаю возможность передвигаться, более соответствующую моим потребностям. А получив мотоцикл, я действительно могу видеть, что ваши идеи работают, – я еду и получаю от этого удовольствие. Таким образом, это и есть минимально жизнеспособный для меня продукт. Если мне очень понравился мотоцикл, возможно, следующим шагом будет его улучшение до более крупной и быстрой модели, скажем, Harley-Davidson, а до спортивного автомобиля дело не дойдет (у меня как раз наступил кризис среднего возраста, поэтому мысль о Harley-Davidson мне очень нравится). Но принять это решение можно только после того, как я опробую мотоцикл и мы оба получим определенный опыт.
Рассматривайте каждый релиз как эксперимент и помните о том, что хотите узнать.
Но что с другими пользователями, которые хотят путешествовать подальше или имеют детей? Этот сегмент рынка не удовлетворит ни один этап из перечисленных выше.
Всегда помните о вашей основной целевой аудитории, заказчиках, пользователях, а также результатах, которые надеетесь получить. Обеспечить потрясающий результат для всех типов пользователей очень нелегко, поэтому фокусируйтесь.