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

Разделитель для чтения книг в онлайн библиотеке

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

Cтраница 52

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

2. Пользователи и заказчики

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

3. Существующие решения

Как пользователи решают свои проблемы сегодня?

Перечислите продукты-конкуренты или способы, с помощью которых ваши пользователи решают свои задачи вручную.

4. Выгоды пользователей

Какие положительные изменения ощутит целевая аудитория, получив ваше решение? Какие выгоды это принесет?

5. Пользовательские параметры

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

6. Стратегия адаптации

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

7. Проблемы бизнеса

Какую проблему вашего бизнеса решает создание этих продуктов, функциональности или улучшения?

8. Показатели бизнеса

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

9. Бюджет

Во что вам это обойдется?

Возможность не должна быть эвфемизмом

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

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

Если не вы и не кто-то в вашей команде принимает решение, работать ли дальше с этой возможностью, постарайтесь выяснить это в беседе с теми, кто будет решать. Если эти люди недоступны для вас, все равно проведите обсуждение и сделайте предположения «Кто?», «Что?» и «Почему?». Затем передайте эти предположения лицам, ответственным за решения. Обещаю, они непременно поправят вас, если ваши предположения неверны. Рассматривая же корректировки, вы сможете начать правильное обсуждение.

Карты историй и возможности

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

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

Попробуйте построить простую, высокоуровневую карту существующего продукта. Это карта «сейчас», похожая на представленую в главе 5, где отображается ваше утро (вы же построили ее, правда?). Эти типы карт много раз встречались нам в различных формах. Часто их называют картами маршрутов. Чтобы составить такую карту для текущего состояния вашего продукта и взаимодействия пользователя с ним, просто составьте карту основных действий пользователя в вашей программе, которые ведут к какой-либо цели. Используйте эту карту, чтобы рассмотреть свои возможности в контексте, – для этого нужно добавить на карту каждую возможность. Используйте стикеры или карточки разных цветов, чтобы выделить их. Скорее всего, вы обнаружите горячие точки возможностей – места на маршрутах взаимодействия пользователей с системой, где не помешают улучшения и где, скорее всего, пользователи испытывают затруднения.

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

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


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

Карта маршрутов и генерация концептов

Бен Кротерс, Atlassian

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

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

Пользовательские истории. Искусство гибкой разработки ПО
Вход
Поиск по сайту
Ищем:
Календарь
Навигация