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

Используйте стикеры, чтобы легче было редактировать сетку по мере развития дискуссии. Последовательно совершенствуйте сетку, узнавая что-то новое.

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

Заполните сетку одним махом, а в следующий раз перечитайте

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

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

Вот как протекает обсуждение в сетке возможностей.

1. Проблемы и решения

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

• Идеи по поводу решения. Перечислите продукты, функции или мысли по поводу улучшений, которые могут решить проблемы целевой аудитории.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. Бюджет

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

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

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