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