[Перевод] Время заменить пользовательские истории рабочими
Слишком большое количество предположений опасно.
Я уже писал о проблеме пользовательских историй раньше. Тогда наилучшим для меня решением было обсуждать с командой предложенные изменения продукта. Это прекрасно работало, когда команда была сработавшейся, а продукт – зрелым; однако, теперь я занят созданием нового продукта с нуля с новой командой. В этом случае, так как мы разрабатываем проект с чистого листа, мы сталкиваемся с проблемой недопонимания, когда речь идет о мотивации клиентов, событиях и ожиданиях. Но сегодня все изменилось. Я нашел великолепный способ использовать философию GTD для лучшего определения особенностей.
Я называю их Рабочими Историями.
Откуда это пошло
Идея эта была придумана очень умными парнями из компании Intercom. Вот что они говорят:
Мы выделяем каждую проблему дизайна в работе, фокусируясь на инициирующем событии или ситуации, и ожидаемый результат выглядит следующим образом:
Когда_____, я хочу_____, тогда я смогу_____.
К примеру: Когда важный новый клиент оформляет подписку, я хочу получить уведомление, тогда я смогу начать с ним разговор.
В том посте это не было названо Рабочей Историей, но я буду использовать именно это название далее. В статье не так много внимания уделено концепту, так что я расскажу, почему мне это нравится, и чем это лучше Пользовательских Историй.
Проблема Пользовательских Историй (в который уже раз)
Если подвести итог, то проблема с пользовательскими историями заключается в том, что имеет место слишком много допущений и нет причинной связи. Когда задача предстает в формате пользовательской истории (Как [тип пользователя], я хочу выполнить [действие], чтобы был [результат]), то не остается места для вопроса «почему?» – по существу вы оказываетесь ограничены определенной последовательностью, оторванной от контекста.
А вот как я вижу этот формат:
Допущения и нестыковка между искусственным образом и действием
Первая проблема – это то, что мы начинаем с искусственного образа, что, в свою очередь, является очень плохой идеей, и затем мы проектируем действия, которые, по нашему мнению, должны быть приведены в порядок для получения ожидаемых результатов. На рисунке отмечено, что действие и искусственный образ не объединены между собой.
Давайте дальше посмотрим на некоторые существующие Пользовательские Истории:
Пример того, как писать Пользовательские Истории
На расположенной выше таблице действительно ли что-то меняется, когда кто-то читает «модератор» или «оценщик»? Если что-то и добавляется, так это неоднозначность для потока. Я и вы будем по-своему интерпретировать значение модератора или то, почему они представлены здесь, в данном контексте.
Попробуйте следующее. Отбросьте целый первый столбец (под названием As a / an – «в качестве кого» – прим. переводчика) и посмотрите, потеряете ли вы что-нибудь. Сравните следующие утверждения:
Как модератор, я хочу создать новую игру, введя имя и опциональное описание
VS
Я хочу создать новую игру, введя имя и опциональное описание
Небо не упало на землю, не так ли?
Рабочая История: бал правят контекст и причинная связь
Формат Рабочей Истории
Обновление от 03.03.2015: Основываясь на большем использовании и фидбеке, теперь я использую немного другое объяснение. Его вы можете почитать в этих твитах. Статью я обновлю позже.
Посмотрите на изображение выше. Вот теперь все на местах!
Вся информация, изложенная выше, довольно критична и очень содержательна, так как мы фокусируемся на причинной связи. Каждая рабочая история должна предоставлять как можно больше контекста и сосредотачиваться на мотивации… а не только на этапе реализации.
Обновление от 04.06.2015: После того, как я уже некоторое время поработал с Рабочими Историями, я изменил «Мотивации» на «Мотивации и Силы». Посмотрите на статью «5 полезных советов для написания Рабочей Истории», которая созвучна с данным материалом. Также вы можете узнать больше о силах в этом подкасте и в этой короткой статье.
Давайте перепишем некоторые примеры из расположенной выше таблицы пользовательских историй в виде Рабочих Историй и добавим мотивацию и контекст в каждую из них:
Пользовательская История:
Как модератор я хочу создать новую игру, введя имя и опциональное описание, тогда я смогу приглашать оценщиков.
Рабочая История:
Когда я буду готов к тому, чтобы оценщики предложили цену за мою игру, я хочу создать игру в понятном для них формате, тогда они смогут найти мою игру и понять, за что они назначают цену.
Пользовательская История:
Как оценщик, я хочу видеть продукт, который мы оцениваем, тогда я буду знать, что мне дали на оценку.
Рабочая История:
Когда я нахожу продукт, который я хочу оценить, то я хочу посмотреть на него, тогда я могу подтвердить, что я оцениваю нужный продукт.
Пользовательская История:
Как модератор, я хочу выбрать продукт для оценки или переоценки, тогда команда увидит продукт и сможет оценить его.
Рабочая История:
Когда продукт не был оценен или я не был доволен полученной оценкой, я хочу иметь возможность перезапустить процесс оценки и сообщить всем об этом, тогда команда будет знать конкретный продукт, который нужно оценить.
Как насчет многократных ролей и событий?
*Добавлено 28.07.2014: Поскольку я получаю огромный фидбек касательно Рабочих Историй и продолжаю работать с ними, то я обнаружил, что иногда полезно включать Роли, или Персонажей как часть пункта «Когда выполняется _ Условие».
Продукты с множественными ролями
Роли/Персонажи наиболее полезны, когда продукт имеет множественные роли, например, IT-продукт (Администратор, Менеджер, Участник…) или продукт рынка (Покупатель, Продавец). Смысл состоит лишь в том, чтобы разъяснить, о ком мы говорим.
Рассмотрим в качестве примера eBay:
Когда Покупатель уже предложил цену за продукт, он переживает, что пропустит встречную ставку, поэтому он хочет немедленно получить оповещение о более высокой ставке, чтобы у него самого было достаточно времени для оценки и изменения собственной ставки.
Роли с Причиной и Эффектом
Иногда встречаются ситуации, когда Рабочие Истории сразу же влияют на множественные роли: устанавливая сценарий причины и следствия.
И опять рассмотрим eBay в качестве примера:
Когда Продавец не доволен ставками, которые он получает, и забирает свой продукт с рынка, Покупатели, которые уже сделали ставки, хотят тут же получить оповещение о том, что продукт выбыл, и тогда Покупатели будут знать, что им уже не нужно следить за продуктом, а вместо этого стоит поискать какой-то другой похожий продукт.
Использование Событий вместо Ролей
Правда, иногда может сложиться ситуация, при которой событие влияет на все роли или группы ролей: например, необходимость получения напоминания пароля. В этом случае нет смысла в конкретной роли. Более важным было бы говорить о ней в контексте данного события, пользуясь такими общими терминами, как клиент или кто-то еще (но не пользователь):
Когда клиент, работая с мобильным устройством, забывает пароль, он хочет получить его таким способом, который облегчает исправление пароля с мобильного устройства, и тогда они могут продолжать регистрацию и получить доступ к своей ленте новостей.
Почему не пользователь? Последний выглядит безжизненным и безрезультативным, а покупатель, наоборот, напоминает нам о том, что у нас есть аудитория, которую нужно обслуживать и уважать.
Определите мотивации, но не определяйте этап реализации
Рабочие истории хороши тем, что они заставляют вас думать о мотивации и контексте и уменьшают роль какой-либо добавленной реализации. Нередко из-за того, что люди слишком сосредоточены на параметрах «кто» и «как», они абсолютно не улавливают значение «почему». Когда вы начнете понимать это «почему», ваш разум откроется для мыслей над новыми творческими и оригинальными способами решения проблемы.
© Megamozg
