Что такое "тип пользователя" в истории пользователя?
Я работаю в качестве UX-дизайнера и имею некоторый опыт работы с пользовательскими историями из гибких проектов разработки, где они использовались для документирования функциональных требований в форме:
Как [тип пользователя] я хочу [цель], чтобы [причина]
После обсуждения с некоторыми коллегами мы определили три разные интерпретации того, каким должен быть [тип пользователя].
- Для меня, как UX-дизайнера, [тип пользователя] будет представлять собой персону, конечного пользователя-архетипа или клиента, созданного на основе исследования пользователей реальных людей.
- Один из разработчиков сказал, что [тип пользователя] играет определенную роль в программном обеспечении, например, медик или снайпер в военной игре.
- Руководитель проекта сказал, что [тип пользователя] представляет командные роли в проекте разработки, например, тестер или разработчик.
Кто прав? Если все мы правы, разве это не будет распространенным источником путаницы?
6 ответов
Пользовательские истории написаны на языке и с точки зрения конечных пользователей продукта.
Таким образом, пользователи являются именно такими: они являются пользователями системы.
Примеры включают в себя:
- Врач использует медицинское программное обеспечение
- Покупатель с помощью интернет-магазина
- Менеджер по продукту, использующий отчет по продукту
Чтобы ответить как можно короче: человек является "заинтересованным лицом".
Что же это за доля? Это человек, имеющий (наибольшую) выгоду от сюжетных задач, которые должны быть выполнены.
- В основном это пользователь приложения. Он может использовать новую функцию.
- Это может быть разработчик, например, история могла бы сделать приложение более устойчивым
- Это может быть ваш менеджер, может быть, есть риск быть закрытым
И многое, многое другое. Пока это извлекает выгоду из этой истории, чтобы быть законченным.
(примечание: мне никогда не нравился такой способ написания историй. Слишком много шаблонов, но наш проворный тренер призывает нас писать истории в этом формате)
1 и 2 очень распространены в использовании. Я работал со многими командами, которые создали несколько персон для своего продукта, скажем, Джейн, пожилая женщина, Дафна, хипстер, которая все делает со своим смартфоном, и Джон, исполнительный директор, который позволяет все устроить своему личному помощнику.
Эти персоны предъявляют очень разные требования к программному обеспечению, даже если они выполняют одну и ту же функцию в системе или действуют с точки зрения одной и той же роли.
Оператор значения для одного может даже конфликтовать с оператором значения для другого. Там, где Джейн может понадобиться крупный шрифт и только информация, относящаяся к ее текущему действию, Джон (помощник) может захотеть иметь более широкое представление и не возражает против визуализаций и небольших шрифтов, если это означает, что она может собрать больше информации о том же самом экран.
Так что воспринимайте персонажей как способ еще более ограничить конкретные роли и сделать ваши пользовательские истории более "человечными", избегая ограниченных ролей. Помните, что пользовательская история предназначена для того, чтобы действительно рассказать историю пользователя и то, какие функциональные возможности помогут ему / ей достичь и что это принесет этим людям. Роли "администратор", "клиент", "золотой клиент", как правило, лишены эмоций и часто не приводят к правильным дискуссиям.
Я помню некоторые командные дискуссии, где люди отмечали в середине дискуссии: "Хотя Джону это понравится, мы потеряли бы Джейн 3 шага назад". Что приводит к изменению предлагаемого функционала.
Что касается варианта 3, я вижу, что многие команды делают это, и для определенных ролей это может иметь смысл... Как операционный инженер, мне нужна тщательная регистрация, чтобы быстро анализировать производственные инциденты. может быть примером. Но команды, принимающие это как аналитик требований, мне нужны требования для истории 27, заходит слишком далеко. Часто эти элементы попадают в корзину нефункциональных требований и не обеспечивают истинную функциональность конечного пользователя. Для этих типов элементов журнала невыполненных работ вам может понадобиться проверить, является ли пользовательская история лучшим форматом для их описания.
Первое и второе правы, но они не отличаются, скорее дополняют друг друга.
Тип пользователя может быть:
- Джо человек.
- Банкир, какой-то рол.
- Джо банкир, человек, у которого есть роль.
В резюме вы можете использовать любой контекст для типа пользователя, так что вы можете использовать один из них или смесь.
Надеюсь мой английский можно предпринять =).
TL;DR Все полезно, никто не ошибается, и никто не единственный путь. Читайте больше на сообщении в блоге, которое я написал, чтобы продолжить этот ответ.
Каждый из трех описанных вами нюансов является действительным и предоставляет полезную информацию. Попробуйте каждый из них, чтобы увидеть, что работает лучше для вас. Я бы посоветовал избегать ограничения того, что может означать "пользователь", поскольку это может отрезать вас от полезного понимания и более глубокого понимания того, что вы создаете.
Цель пользовательской истории (изначально Кент Бек хотел, чтобы их просто называли "историями") - не писать лучшие пользовательские истории; это выходить за рамки требований и в истинное понимание. Для этого вам необходимо узнать, для кого предназначено программное обеспечение, какую проблему оно решает для них и почему эта проблема является ценной для решения.
Рассмотрите это как эксперимент, чтобы узнать, есть ли у вас правильный тип пользователя. Ответьте на вопрос: "Знаю ли я, как эта вещь, которую я строю, изменит мир тех, кто ее использует?" Если нет, вы можете еще не понять, для кого это.
Пользовательские истории лучше всего использовать для описания требований из блогов продукта, чтобы конечный пользователь или заинтересованная сторона увидели и использовали продукт с его точки зрения. И ПО должно быть лучшим человеком, который может прокомментировать правильность пользовательской истории. Если ПО принимает информацию от команды для разработки пользовательских историй, нужно больше визуализировать использование продукта, а не просто классифицировать тип пользователя. Хотя тип пользователя важен, но особое внимание следует уделять его использованию, например: 1. врач, заходящий на медицинский веб-сайт, чтобы узнать содержание препарата и его производителя, так что какой тип доступа ему должен быть предоставлен на с другой стороны, 2. если аптекарь ищет конкретное лекарство, доступное количество, время доставки, то необходимо предоставить соответствующий доступ и рабочий процесс.
Исходя из вышеизложенного, я нахожу первый подходящим, то есть персону и использование системы с его точки зрения. Для каждого использования системы можно создавать пользовательские истории и, соответственно, разрабатывать рабочий процесс.