Пользовательские истории. Искусство гибкой разработки ПО - [64]
8. Показатели бизнеса
Какие показатели эффективности бизнеса будут затронуты в случае успеха вашего решения?
9. Бюджет
Во что вам это обойдется?
Возможность не должна быть эвфемизмом
Я знаю, что в вашей компании, скорее всего, не используется понятие «возможности». Если она хоть немного похожа на те, с которыми мне случалось работать в прошлом, у вас есть стратегический план, куда включено то, что вы планируете разработать. Может быть, вы даже воспринимаете его как требования. Скорее всего, решение «нет» принимаете не вы. Правда заключается в том, что на самом деле мы не можем превратить все эти мудрые идеи в программные продукты независимо от должности человека, который их выдвинул.
Используйте первое большое обсуждение истории, чтобы примерно определить, какую работу придется выполнить вам и вашей команде. Несмотря на то что ответом на вопрос «Да или нет?» может быть «нет», перед уходом из комнаты совещаний удостоверьтесь, что у вас выработано одинаковое мнение о проблемах, которые вы решаете, о том, для кого вы их решаете, а также о выгоде для вашей организации от создания этого программного обеспечения.
Если не вы и не кто-то в вашей команде принимает решение, работать ли дальше с этой возможностью, постарайтесь выяснить это в беседе с теми, кто будет решать. Если эти люди недоступны для вас, все равно проведите обсуждение и сделайте предположения «Кто?», «Что?» и «Почему?». Затем передайте эти предположения лицам, ответственным за решения. Обещаю, они непременно поправят вас, если ваши предположения неверны. Рассматривая же корректировки, вы сможете начать правильное обсуждение.
Карты историй и возможности
Как бы я ни любил карты историй, я редко использую их при управлении возможностями. Возможности – довольно крупномасштабные вещи, поэтому обсуждение этих «больших камней» чаще всего сводится к деталям, которые нужны нам, чтобы принять решение о более детальном исследовании.
Но вот где карты историй могут сработать – это действительно эффективная возможность сделать шаг назад и окинуть взглядом цельную картину продукта, как он есть сейчас. Используйте карту существующего продукта, чтобы найти возможности или рассмотреть те, которые вам предложены, в контексте всего, что у вас есть сейчас.
Попробуйте построить простую, высокоуровневую карту существующего продукта. Это карта «сейчас», похожая на представленую в главе 5, где отображается ваше утро (вы же построили ее, правда?). Эти типы карт много раз встречались нам в различных формах. Часто их называют картами маршрутов. Чтобы составить такую карту для текущего состояния вашего продукта и взаимодействия пользователя с ним, просто составьте карту основных действий пользователя в вашей программе, которые ведут к какой-либо цели. Используйте эту карту, чтобы рассмотреть свои возможности в контексте, – для этого нужно добавить на карту каждую возможность. Используйте стикеры или карточки разных цветов, чтобы выделить их. Скорее всего, вы обнаружите горячие точки возможностей – места на маршрутах взаимодействия пользователей с системой, где не помешают улучшения и где, скорее всего, пользователи испытывают затруднения.
Рассмотрите пользователей, вовлеченных в каждое такое действие, и частоту этих действий. Возможности, которые затрагивают часто встречающиеся действия и критически важных пользователей, следует взять в работу в первую очередь, оставив прочие на потом.
Вы можете также использовать эту карту, чтобы добавлять на нее то, на что ваши пользователи сейчас жалуются. Чтобы добиться баланса, рассмотрите части продукта, которые они любят, и добавьте на карту то, что им нравится. Если же вы обнаружили место, где много жалоб пользователей, но пока нет ни одной возможности, очевидно, стоит о нем подумать.
Бен Кротерс, Atlassian
Поскольку мы предлагаем больше десяти различных продуктов, нам необходимо быть уверенными в том, что мы проектируем, разрабатываем и улучшаем эти продукты так, чтобы наши клиенты могли использовать их вместе, а не только по отдельности. Поэтому в рамках проекта по исследованию и улучшению совместной работы этих проектов мы сформировали мультидисциплинарную команду, которая должна была составить карту полного, от начала до конца, маршрута пользователя в системе: знакомство, оценка, покупка и использование, а кроме того, получение помощи и добавление других продуктов и сервисов.
Объем работы оказался огромным. Чтобы разделить его на части, мы сначала построили очень высокоуровневую карту маршрутов, а затем разбили ее на подгруппы, чтобы впоследствии развивать каждую секцию получившегося каркаса. Сначала мы заполнили стену ключевыми моментами, действиями и вопросами, с которыми работали клиенты, присвоили им цветовые коды, а затем повторно прошлись по этой карте, добавляя точки раздражения, возможности и предположения.
Мы сделали множество открытий, когда появилась возможность проследить всю историю от начала до конца, а не просто рассматривать каждую функциональность в отдельности. Так, мы быстро поняли, что некоторые части пользовательского взаимодействия, например настройка продукта или получение помощи, не были выделены в особую ветку маршрута и нуждаются в большей детализации и проработке.
