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

В начале 2000-х я руководил небольшой компанией по разработке продуктов под названием Tomax. Мы работали над программой для розничных магазинов – тех самых, куда ходили за покупками, прежде чем с головой погрузились в Интернет. У нас появился новый клиент – крупная сеть магазинов лакокрасочной продукции и предметов интерьера. Мы немного разбирались в розничной торговле, а также в людях, которые обслуживают покупателей в магазине и работают с оборудованием, но совсем ничего не знали о многих вещах – в основном о деталях, характерных для торговли красками и предметами интерьера. Например, нам были неизвестны особенности продажи краски индивидуальных оттенков или жалюзи на заказ. А учиться нужно было быстро.

Чтобы ускорить процесс, мы попросили этих трех дам нам помочь. Они не имели никакого отношения к разработке программного обеспечения – они дизайнеры интерьеров, работающие в компании, которая хотела заказать у нас программу. С их помощью мы от начала до конца изучили процесс продажи жалюзи на заказ. Мы попросили их записать все, что они обычно делают, от появления клиента до установки готовых жалюзи к его удовольствию. Вероятно, вы уже догадались: мы попросили их сделать то же самое, что делали вы, составляя карту своего утра. Все происходило точно так же. Они легко называли все, что делали в процессе продажи жалюзи, так же, как вы перечисляли свои утренние действия при сборах на работу. А когда мы расположили их задачи на карте, оказалось, что существует не единственный способ достижения цели: все трое выполняли задачи немного по-разному или в разном порядке. Вы заметите то же самое, если попробуете составить карту сборов на работу вместе с небольшой группой разных людей.

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

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

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

Я хочу свести главное из предыдущих четырех глав в шесть простых шагов. Вы можете задаться вопросом: «Почему он не сделал этого с самого начала?» Что ж, я мог бы пропустить все эти рассуждения и истории и просто перечислить требования. Но толку от этого не было бы никакого.

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

1. Сформулируйте проблему: для кого вы это делаете, зачем вы это делаете?

2. Обрисуйте общую картину. Концентрируйтесь на широте, а не на глубине, продвигайтесь на милю вперед и на дюйм вглубь (или на километр вперед и на сантиметр вглубь – для моих неамериканских друзей). Если у вас нет готового решения или даже если, как вам кажется, оно есть, попробуйте построить карту по состоянию на сегодня, включая проблемы и преимущества, которые отмечаются у ваших пользователей.

3. Исследуйте. Углубляйтесь и обсудите другие типы пользователей и то, как еще они могут выполнять свои задачи, а также варианты их действий, если (или, скорее, когда) что-то пойдет не так. Для пущей уверенности нарисуйте эскизы, составьте прототипы, протестируйте их, усовершенствуйте идеи решений, по ходу дела меняя и расширяя карту.

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