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