Слишком большое количество предположений опасно.



Я уже писал о проблеме пользовательских историй раньше. Тогда наилучшим для меня решением было обсуждать с командой предложенные изменения продукта. Это прекрасно работало, когда команда была сработавшейся, а продукт – зрелым; однако, теперь я занят созданием нового продукта с нуля с новой командой. В этом случае, так как мы разрабатываем проект с чистого листа, мы сталкиваемся с проблемой недопонимания, когда речь идет о мотивации клиентов, событиях и ожиданиях. Но сегодня все изменилось. Я нашел великолепный способ использовать философию GTD для лучшего определения особенностей.

Я называю их Рабочими Историями.

Откуда это пошло


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

Когда_____, я хочу_____, тогда я смогу_____.


К примеру: Когда важный новый клиент оформляет подписку, я хочу получить уведомление, тогда я смогу начать с ним разговор.

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

Проблема Пользовательских Историй (в который уже раз)


Если подвести итог, то проблема с пользовательскими историями заключается в том, что имеет место слишком много допущений и нет причинной связи. Когда задача предстает в формате пользовательской истории (Как [тип пользователя], я хочу выполнить [действие], чтобы был [результат]), то не остается места для вопроса «почему?» – по существу вы оказываетесь ограничены определенной последовательностью, оторванной от контекста.

А вот как я вижу этот формат:



Допущения и нестыковка между искусственным образом и действием

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

Давайте дальше посмотрим на некоторые существующие Пользовательские Истории:



Пример того, как писать Пользовательские Истории

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

Попробуйте следующее. Отбросьте целый первый столбец (под названием As a / an – «в качестве кого» – прим. переводчика) и посмотрите, потеряете ли вы что-нибудь. Сравните следующие утверждения:

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

VS

Я хочу создать новую игру, введя имя и опциональное описание


Небо не упало на землю, не так ли?

Рабочая История: бал правят контекст и причинная связь





Формат Рабочей Истории

Обновление от 03.03.2015: Основываясь на большем использовании и фидбеке, теперь я использую немного другое объяснение. Его вы можете почитать в этих твитах. Статью я обновлю позже.

Посмотрите на изображение выше. Вот теперь все на местах!

Вся информация, изложенная выше, довольно критична и очень содержательна, так как мы фокусируемся на причинной связи. Каждая рабочая история должна предоставлять как можно больше контекста и сосредотачиваться на мотивации… а не только на этапе реализации.

Обновление от 04.06.2015: После того, как я уже некоторое время поработал с Рабочими Историями, я изменил «Мотивации» на «Мотивации и Силы». Посмотрите на статью «5 полезных советов для написания Рабочей Истории», которая созвучна с данным материалом. Также вы можете узнать больше о силах в этом подкасте и в этой короткой статье.

Давайте перепишем некоторые примеры из расположенной выше таблицы пользовательских историй в виде Рабочих Историй и добавим мотивацию и контекст в каждую из них:

Пользовательская История:

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

Рабочая История:

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

Пользовательская История:

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

Рабочая История:

Когда я нахожу продукт, который я хочу оценить, то я хочу посмотреть на него, тогда я могу подтвердить, что я оцениваю нужный продукт.

Пользовательская История:

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

Рабочая История:

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

Как насчет многократных ролей и событий?


*Добавлено 28.07.2014: Поскольку я получаю огромный фидбек касательно Рабочих Историй и продолжаю работать с ними, то я обнаружил, что иногда полезно включать Роли, или Персонажей как часть пункта «Когда выполняется _ Условие».

Продукты с множественными ролями

Роли/Персонажи наиболее полезны, когда продукт имеет множественные роли, например, IT-продукт (Администратор, Менеджер, Участник…) или продукт рынка (Покупатель, Продавец). Смысл состоит лишь в том, чтобы разъяснить, о ком мы говорим.

Рассмотрим в качестве примера eBay:

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

Роли с Причиной и Эффектом

Иногда встречаются ситуации, когда Рабочие Истории сразу же влияют на множественные роли: устанавливая сценарий причины и следствия.

И опять рассмотрим eBay в качестве примера:

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

Использование Событий вместо Ролей

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

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

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

Определите мотивации, но не определяйте этап реализации

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

Комментарии (0)