Разрешите мне вернуться к сходству историй с камнями. Части, на которые вы разобьете камень, все равно можно назвать камнями, просто меньшего размера. Но это все еще такие же камни, как тот, первоначальный, который нам нужно было внимательно рассмотреть, чтобы понять, достоин он разбиения или нет. Давайте условно назовем его «нулевой камень». В терминах метода историй я бы употребил слово «возможность».
Под возможностями я подразумеваю идеи, которые, по нашему мнению, могли бы решить проблему. Нет, я вовсе не тот человек, чей стакан всегда наполовину пуст, но все-таки не очень умно считать любую возникшую идею достойной реализации в нашем продукте, ведь, как вы знаете, времени и людей, чтобы реализовать все, никогда не бывает достаточно. Но даже если бы у вас было сколько угодно ресурсов, ваши заказчики были бы слегка шокированы таким продуктом.
Обсуждайте свои возможности
Когда мы предлагаем для обсуждения какую-нибудь идею, обычно эта идея довольно велика, хоть и не всегда. На жаргоне историй мы можем назвать такую идею эпиком, но я предпочитаю слово «возможность». Независимо от того, как вы их называете, это все еще истории, и главная цель их начальных обсуждений – решить, стоит ли продолжать работу над этими историями или просто отбросить их. Для каждой возможности мы можем обсудить:
• для кого она. На этом уровне чаще всего упоминаются разные группы пользователей, заказчиков или целевой сегмент рынка;
• какие проблемы она может решить. Нужно разобраться, какие проблемы всех типов пользователей мы можем решить. А также как они решают свои проблемы сейчас – вручную, или с помощью продуктов наших конкурентов, или, что еще хуже, с помощью продукта, который неудобен для них сейчас и неэффективен;
• что представляет собой идея. У нас могут быть соображения о том, какими должны быть продукт или функциональность. Об этом следует поговорить;
• почему именно эта возможность. Хороший момент для обсуждения причин, почему вашей организации выгодно создавать программные продукты для этих пользователей. Чаще всего решение проблем пользователей оказывается недостаточно весомым аргументом. Нужно предусмотреть отдачу от инвестиций в программное решение, а также соответствует ли эта инвестиция действующей бизнес-стратегии. Я не говорю, что нужно вычислять рентабельность инвестиций, так как на данной стадии, имея всего лишь истории, это сложно сделать. Просто обсудите в общем, какую пользу получит организация, если решение будет реализовано;
• каков ее размер. На этом уровне, даже если размах идей велик, мы можем сделать осторожные оценки времени на разработку, пусть даже они и не будут особенно точными. Лучше всего рассмотреть данную возможность в сравнении с чем-то, что мы уже делали раньше: «Это звучит похоже на ту, другую функцию, которую мы выпустили в прошлом релизе. На нее потратили несколько недель, значит, и эта займет примерно столько же». Для принятия решения о том, стоит ли продолжать работу над идеей, полезно знать, сколько времени займет ее разработка – дни, недели или месяцы.
Полный набор таких историй называется бэклогом возможностей. Мы пока не знаем точно, стоит ли реализовывать их или, по крайней мере, не нужно ли их выбросить. Помните: идей функций или продуктов, которые можно создать, всегда больше, чем времени. Поэтому ищите возможности, согласующиеся с бизнес-стратегией своей организации, а также решающие проблемы пользователей или заказчиков. Проведите достаточно обсуждений, чтобы принять решение «да» или «нет».
После анализа: выбрасываем или продолжаем думать
«Да» не означает «мы собираемся реализовать это» – это означает, что мы переводим возможность на новый уровень и продолжаем дискуссии, углубляя анализ. Исследование потребует еще больше обсуждений – скорее всего, с другими людьми за пределами зала для совещаний. Если это новая функция или совершенно новый продукт, потребуется глубокий анализ поведения заказчиков и пользователей, способов решения их проблем на сегодняшний день. В идеале – пообщайтесь с ними напрямую. Потребуется также исследование и прототипирование разных решений. Тщательных обсуждений потребует вопрос о том, какие знания необходимы вам и вашей команде для принятия решения, что именно нужно разработать для эффективной помощи заказчикам, пользователям и своей организации. Но, даже выполнив всю эту работу, вы все еще можете отбросить данную идею.
«Нет» – это отличный результат обсуждения возможности. Помните: того, что нужно разработать, всегда больше, чем времени или ресурсов. Если в результате обсуждений выяснится, что возможность не так уж благоприятна, смело отправляйте ее в утиль. В этом случае полезно, чтобы в дискуссии принимали участие те, кто предложил эту идею, чтобы они сами могли прийти к такому же заключению.
У вашей группы может быть недостаточно информации для принятия решения «да» или «нет». Если это так, составьте список того, что нужно выяснить, и соберите нужную информацию.
Если вы все еще не можете решить, «да» или «нет», всегда можно перенести эту возможность обратно в бэклог. Это называется «отложенный выбор», и я прибегаю к нему довольно часто.
Сетка возможностей
Рассматривая возможности продукта, я в качестве отправной точки использую шаблон экспертизы возможностей Марти Когана. В последнее время мне все больше нравятся подходы, основанные на использовании сетки. Такой подход к рассмотрению бизнес-моделей, описанный в книге «Выработка бизнес-модели» [26] , – эффективный способ групповой работы для определения размера запускаемого бизнеса. Но мне самому, а также большинству людей, с которыми я работаю, редко приходится разворачивать новый бизнес или запускать принципиально новый продукт. Чаще всего мы должны добавить очередную важную функциональность к продукту, который уже существует, впрочем, это не должно помешать вам применить подход сетки к определению размера возможностей продукта.
Сетка организует информацию в пространстве. Большой объем информации удобно расположен в одном месте, в результате чего группа может охватить его взглядом и работать с ним. Делать то же самое со слайдами или печатным документом гораздо сложнее. Кроме того, такая организация позволяет вам увидеть зависимости: факты, зависящие друг от друга, расположены рядом.
Вот как может выглядеть сетка.
Совместная работа в попытке собрать информацию в виде сетки выглядит следующим образом.
Использование сетки дает следующие преимущества.
• Вы можете охватить самые важные проблемы одним взглядом.
• Вы можете видеть взаимосвязи между проблемами.
• Выработка одинакового понимания, участие в принятии решений и сплоченность, возникающие в результате совместной работы, позволяют создать сетку, куда свой вклад внес каждый.
Работая над сеткой, команда исследования продукта должна заполнить ячейки, основываясь на том, что вам известно сегодня. Привлекайте представителей бизнеса, экспертов в предметной области и любых других людей, которые, по вашему мнению, могут дополнить эту беседу полезной информацией.
Используйте стикеры, чтобы легче было редактировать сетку по мере развития дискуссии. Последовательно совершенствуйте сетку, узнавая что-то новое.
Вы можете заполнять сетку, начав с первой ячейки и последовательно двигаясь к девятой. Но если у вас пока нет ответов для какой-либо ячейки, запишите только то, что знаете или предполагаете, а затем двигайтесь дальше.
Заполните сетку одним махом, а в следующий раз перечитайте
Сетки в ячейке пронумерованы в логическом порядке, который можно использовать для обсуждения возможности. Но если вы покажете эту сетку кому-то другому, то можете прочитать ее слева направо или сверху вниз. Как можно видеть, порядок слева направо соответствует продвижению от «сейчас» к «будущему», как в модели объема работы и результата, представленной ранее. Кроме того, порядок сверху вниз соответствует продвижению от нужд пользователя к нуждам бизнеса.
Это не просто форма, которую нужно заполнить. Это набор тем, которые необходимо обсудить и в которых хорошо разобраться. Помните: дизайн через сотрудничество – не то что дизайн в комиссии. Привлечение множества разных людей позволяет всем узнавать новое быстрее, но все же решение «да» или «нет» в отношении этой возможности остается за владельцем продукта. Лучшие владельцы продукта привлекают к принятию решения свою команду, и, как правило, оказывается, что между ними и их командами нет противоречий.
Вот как протекает обсуждение в сетке возможностей.
1. Проблемы и решения
В идеале мы должны начать с ясно сформулированной проблемы, которую необходимо решить, но в реальном мире такое встречается редко. Чаще всего у нас есть просто функциональность или идея улучшения, а затем мы должны отступить назад, чтобы понять, в чем проблема. Поэтому начинайте с того, что у вас есть.
• Идеи по поводу решения. Перечислите продукты, функции или мысли по поводу улучшений, которые могут решить проблемы целевой аудитории.
• Проблемы. Какие проблемы есть сейчас у целевых пользователей и заказчиков? Если вы создаете развлекательный продукт, например игру или приложение для размещения в социальной сети каких-то забавных вещей, речь может идти не о реальной проблеме , а просто о желании развлечься.
2. Пользователи и заказчики
Какие типы пользователей и заказчиков испытывают трудности, которые устранит ваше решение? Рассмотрите различия целей или нужд разных людей, влияющие на способ, которым они используют продукт. Разделите пользователей и заказчиков на разные типы, основанные на этих различиях. Адресовать продукт всем и каждому – очень плохая мысль.
3. Существующие решения
Как пользователи решают свои проблемы сегодня?
Перечислите продукты-конкуренты или способы, с помощью которых ваши пользователи решают свои задачи вручную.
4. Выгоды пользователей
Какие положительные изменения ощутит целевая аудитория, получив ваше решение? Какие выгоды это принесет?
5. Пользовательские параметры
Какие параметры поведения пользователя вы можете измерить, чтобы понять, как проходят адаптация, использование вашего решения и получение выгоды от этого?
6. Стратегия адаптации
Каков будет процесс перехода пользователей и заказчиков к использованию вашего решения?
7. Проблемы бизнеса
Какую проблему вашего бизнеса решает создание этих продуктов, функциональности или улучшения?
8. Показатели бизнеса
Какие показатели эффективности бизнеса будут затронуты в случае успеха вашего решения?
9. Бюджет
Во что вам это обойдется?
Возможность не должна быть эвфемизмом
Я знаю, что в вашей компании, скорее всего, не используется понятие «возможности». Если она хоть немного похожа на те, с которыми мне случалось работать в прошлом, у вас есть стратегический план, куда включено то, что вы планируете разработать. Может быть, вы даже воспринимаете его как требования. Скорее всего, решение «нет» принимаете не вы. Правда заключается в том, что на самом деле мы не можем превратить все эти мудрые идеи в программные продукты независимо от должности человека, который их выдвинул.
Используйте первое большое обсуждение истории, чтобы примерно определить, какую работу придется выполнить вам и вашей команде. Несмотря на то что ответом на вопрос «Да или нет?» может быть «нет», перед уходом из комнаты совещаний удостоверьтесь, что у вас выработано одинаковое мнение о проблемах, которые вы решаете, о том, для кого вы их решаете, а также о выгоде для вашей организации от создания этого программного обеспечения.
Если не вы и не кто-то в вашей команде принимает решение, работать ли дальше с этой возможностью, постарайтесь выяснить это в беседе с теми, кто будет решать. Если эти люди недоступны для вас, все равно проведите обсуждение и сделайте предположения «Кто?», «Что?» и «Почему?». Затем передайте эти предположения лицам, ответственным за решения. Обещаю, они непременно поправят вас, если ваши предположения неверны. Рассматривая же корректировки, вы сможете начать правильное обсуждение.
Карты историй и возможности
Как бы я ни любил карты историй, я редко использую их при управлении возможностями. Возможности – довольно крупномасштабные вещи, поэтому обсуждение этих «больших камней» чаще всего сводится к деталям, которые нужны нам, чтобы принять решение о более детальном исследовании.
Но вот где карты историй могут сработать – это действительно эффективная возможность сделать шаг назад и окинуть взглядом цельную картину продукта, как он есть сейчас. Используйте карту существующего продукта, чтобы найти возможности или рассмотреть те, которые вам предложены, в контексте всего, что у вас есть сейчас.
Попробуйте построить простую, высокоуровневую карту существующего продукта. Это карта «сейчас», похожая на представленую в главе 5, где отображается ваше утро (вы же построили ее, правда?). Эти типы карт много раз встречались нам в различных формах. Часто их называют картами маршрутов. Чтобы составить такую карту для текущего состояния вашего продукта и взаимодействия пользователя с ним, просто составьте карту основных действий пользователя в вашей программе, которые ведут к какой-либо цели. Используйте эту карту, чтобы рассмотреть свои возможности в контексте, – для этого нужно добавить на карту каждую возможность. Используйте стикеры или карточки разных цветов, чтобы выделить их. Скорее всего, вы обнаружите горячие точки возможностей – места на маршрутах взаимодействия пользователей с системой, где не помешают улучшения и где, скорее всего, пользователи испытывают затруднения.
Рассмотрите пользователей, вовлеченных в каждое такое действие, и частоту этих действий. Возможности, которые затрагивают часто встречающиеся действия и критически важных пользователей, следует взять в работу в первую очередь, оставив прочие на потом.
Вы можете также использовать эту карту, чтобы добавлять на нее то, на что ваши пользователи сейчас жалуются. Чтобы добиться баланса, рассмотрите части продукта, которые они любят, и добавьте на карту то, что им нравится. Если же вы обнаружили место, где много жалоб пользователей, но пока нет ни одной возможности, очевидно, стоит о нем подумать.
Карта маршрутов и генерация концептов
Бен Кротерс, Atlassian
Поскольку мы предлагаем больше десяти различных продуктов, нам необходимо быть уверенными в том, что мы проектируем, разрабатываем и улучшаем эти продукты так, чтобы наши клиенты могли использовать их вместе, а не только по отдельности. Поэтому в рамках проекта по исследованию и улучшению совместной работы этих проектов мы сформировали мультидисциплинарную команду, которая должна была составить карту полного, от начала до конца, маршрута пользователя в системе: знакомство, оценка, покупка и использование, а кроме того, получение помощи и добавление других продуктов и сервисов.
Объем работы оказался огромным. Чтобы разделить его на части, мы сначала построили очень высокоуровневую карту маршрутов, а затем разбили ее на подгруппы, чтобы впоследствии развивать каждую секцию получившегося каркаса. Сначала мы заполнили стену ключевыми моментами, действиями и вопросами, с которыми работали клиенты, присвоили им цветовые коды, а затем повторно прошлись по этой карте, добавляя точки раздражения, возможности и предположения.
Мы сделали множество открытий, когда появилась возможность проследить всю историю от начала до конца, а не просто рассматривать каждую функциональность в отдельности. Так, мы быстро поняли, что некоторые части пользовательского взаимодействия, например настройка продукта или получение помощи, не были выделены в особую ветку маршрута и нуждаются в большей детализации и проработке.
Много других команд и партнеров были привлечены к этой работе для добавления деталей, относящихся к определенным точкам высокоуровневого маршрута. В результате мы зафиксировали и подтвердили максимально возможное на тот момент количество сведений.
Затем мы с головой ушли в поиск как можно большего количества идей улучшения и реорганизации различных этапов уже детализированных маршрутов. Все эти идеи были как следует выверены и записаны на карточки, которые в свободном порядке приклеили на стену вдоль маршрута.
Каждый член команды объяснил каждый свой концепт, после чего все мы проголосовали за эффективность всех концептов методом точек, учитывая их реализуемость, жизнеспособность и полезность для пользователей.
После этого мы уже были способны сформировать полноценное видение идеального взаимодействия клиента и всех продуктов, основываясь на картах маршрутов и подтвержденных концептах. За время работы над картой родился 20-страничный комикс, который трансформировал маршрут, а также всех персонажей, истории и концепты, которые были как-то с ним связаны, в один набор историй, в результате чего значительно упростилась коммуникация во всей организации. В комиксе описываются возможные улучшения в продукте, и он продолжает развиваться.
Для нас был очень показателен тот факт, что многие из вовлеченных в разработку и корректировку этих улучшений затем включились в разработку концептов, с которых мы начали работу. И хотя это упражнение было проделано восемь месяцев назад, одинаковое понимание и концептуализация значительно повысили эффективность работы.
Сложные обязательства и прогон карты
Эрин Бейерволтес и Аарон Уайт
1. Одна карта, чтобы управлять всем
После долгого общения с клиентами, интервью и исследований владелец продукта получил маршрут, который, как он был уверен, отражал наилучший итог работы для заказчика. Все происходило как обычно. Настало время поделиться информацией с командой и взяться за работу.
2. Все под сомнением…
Но по прошествии нескольких обсуждений мы уже не были так уверены, что ничего не пропустили. Возможно, мы сделали какие-то простые предположения, эффект от которых окажется больше ожидаемого? Нужен был быстрый способ проверить наши предположения, обнаружить пробелы, а также выработать одинаковое понимание у всех, кто примет участие в проекте.
3. Подготовка сцены
Мы собрали команду, назначили, кто каким персонажем будет (их несколько), и описали желаемые результаты, которые должны были естественным образом обусловливать действия персонажей во время использования части нашего продукта. Таким образом мы должны были подтвердить или опровергнуть свои предположения. Мы не писали пошаговые инструкции. Задача была поставлена такая: «Просто, как сделал бы этот персонаж, вы должны достичь такой-то цели». Прогон!
4. Прогон
Пока актеры играли свои роли и пытались достичь поставленных целей, несколько наблюдателей смотрели на них, словно из зрительного зала. Владелец продукта следил, какие способы находили актеры, ответив на пару вопросов, но не указав никому конкретного пути. Дизайнер пользовательского взаимодействия наблюдал за их поведением, комментариями и реакциями.
5. Перестроение карты
Мы не показывали участникам изначальную карту, вместо этого попросили актеров под нашим руководством построить новую, где бы они описали, как достигли своих целей, по ходу дела поделившись друг с другом найденными способами.
6. Удовольствие и раздражение
После перестроения карты мы попросили каждого актера рассказать, из-за чего он или она испытывали раздражение (в частности, что вызывало сложности, злило или ставило в тупик), а из-за чего – удовольствие (что было легко и приятно сделать или было интуитивно понятно). Во время беседы все почувствовали усиление сопереживания и понимания.
7. Выводы
Под конец настала очередь зрителей задавать вопросы об интересных моментах поведения, которые они наблюдали. Мы были поражены тем, как много актеры проделали, сами того не зная, но это навело нас на мысль, что кто-то может попытаться сделать то же самое намеренно, имея какую-то цель.
8. Профит!!!
Всего через 2,5 часа у нас сложилось одинаковое понимание того, как воспринимается новое решение, что могло произойти только в обсуждении. Актеры действовали, реально сочувствуя клиентам, роль которых исполняли, а исследовательская команда сделала массу открытий о том, как что работает и где может потребоваться больше экспериментов.
Не бойтесь риска
Если вы просто согласитесь со всем, что у вас есть, ничего хорошего не выйдет. Активно отбрасывайте возможности, не обещающие достижения тех результатов, на которые вы надеетесь. Сотрудничайте для этого с представителями бизнеса, возможно, они помогут вам принять эти решения.
Если же вы приняли решение «да», настало время засучить рукава и взяться за работу. Именно об этом следующая глава.