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

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

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

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

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

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

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

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

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