Пользовательские истории. Искусство гибкой разработки ПО

4. Прогон

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

5. Перестроение карты

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

6. Удовольствие и раздражение

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

7. Выводы

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

8. Профит!!!

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

Не бойтесь риска

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

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

Глава 14. Вырабатывайте единое понимание с помощью исследований

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

Суть исследований не в создании программных продуктов

Исследовательская работа обычно не направлена на создание пригодного к предъявлению программного продукта. Ее основная цель – выработка углубленного понимания того, что мы можем создать. Речь идет о постановке и поиске ответов на следующие вопросы.

• Какие проблемы мы решаем в действительности?

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

• Как должно выглядеть решение, наиболее удобное и эффективное в использовании?