А пользователь кто? Моделирование пользовательских ролей и описание персон

В гибкой разработке как никогда популярно использование пользовательских историй (user story). И если вы слышали или работали с ними, то в курсе, что они пишутся от имени разных пользователей (user types). Определение пользователей важно не только для этого инструмента, но и если используются сценарии (use cases) или иное представление требований. Эта статья расскажет о моделировании персон, о том, как можно определить пользовательские роли для своего продукта.

Сначала еще раз про user story

Пользовательская история (user story, US) содержит описание функциональности, которая будет представлять ценность для пользователя или покупателя программного обеспечения (ПО).

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

Пример пользовательской истории:

Пользователь может создать список покупок.

Кроме такого лаконичного описания могут быть примечания, которые нужны для обсуждения («Он должен быть доступен всем в доме? Сохранять автоматически или по кнопке?») и список тестов, которые раскрывают суть реализации («Проверить: создание списка, добавление пунктов, удаление пунктов, возможность задать заголовок для списка, возможность указать количество товара, возможность не указывать количество товара» и т.д.). Само описание тестов может быть разным, но главное, чтобы по тестам было понятно, когда история действительно реализована.  Также, если требуется, после обсуждения появляются дочерние истории, более мелкие.

Вообще формат истории может быть разным, самое важное в этом инструменте — обсуждение!

Для тех, кто привык к стандартному описанию требований, такой подход может быть непривычен («Как так без конкретного описания, что сделать?», «Неужели тесты – это часть user story»?). Приемочные тесты как раз должны описывать, что должно быть сделано, чтобы история считалась решенной. По крайней мере, задумка такова. В реальности зачастую к историям прибавляются задачи на разработку (tasks), в которых дается больше конкретики по принятым решениям.

В отличие от классических спецификаций (Software requirements specification, SRS) пользовательские истории краткие, не содержат в себе описания конкретной реализации, не являются контрактными обязательствами (!). Тем не менее, их использование хорошо зарекомендовало себя, так как отлично ложится на итеративную разработку (как extreme programming, agile или конкретно scrum), позволяет максимально привлекать заказчика в проект, стимулирует общение в команде и откладывает проработку деталей до момента непосредственной реализации (а не на старте проекта). В целом, использовать пользовательские истории можно даже в государственных контрактах, так как в первоначальном ТЗ может не быть конкретных деталей (а как раз, по сути, список US), однако по результатам разработки необходимо будет написать весь пакет требуемой документации.

На мой взгляд, в случае заказной разработки отдельно необходимо работать с разрешением споров, так как пользовательские истории (еще раз) – не контрактные обязательства. Нельзя обратиться к ним и сказать: «Вот тут так написано, мы так и сделали». Конечно, за счет привлечения заказчика к обсуждению и постоянного контакта с ним не должно возникать ситуации «сделали не то, что хотелось», но часто может возникать ситуация «сделали не всё, что хотелось», ведь у контрактов есть цена, рассчитанная на определенные трудозатраты. Этот момент необходимо прорабатывать отдельно, но он не является блокирующим для использования user story в проекте. Часто в подобных ситуациях команды приходят к некоторому гибридному варианту, что тоже имеет право на жизнь.

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

Пользовательские роли, персоны

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

Для разделения историй по разным типам пользователей придуманы пользовательские роли.

Пользовательская роль (user role) – описание некоторой совокупности пользователей и предполагаемого взаимодействия с системой.

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

Существует несколько способов выявить, смоделировать роли пользователей.

Способ 1. Реальные пользователи

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

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

Способ 2. Мозговой штурм

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

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

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

В ходе мозгового штурма были сгенерированы следующие роли, которые расположили по близости и пересечению:

После обсуждения каждой роли было принято решение оставить следующие (розовые стикеры):

Команда пришла к мнению, что задачи уборщицы схожи с теми, что решают соседи или члены семьи. В случае если появятся истории, которые этому противоречат, то будет добавлена новая роль. Ребёнок не был объединен с кем-то, так как детям может потребоваться больше мотивации для выполнения домашних дел (возможно, некоторая геймификация процесса).

После этого для каждой роли необходимо дать описание. Атрибут роли (role attribute) — факт или полезная информация о пользователях, которые действуют в данной роли. Главное указать, что пользователь ожидает от вашего программного обеспечения.

Пример — описание роли «Мама»:

Естественно, не обязательно, чтобы в самом приложении фигурировало название этой роли.

Способ 3. Сегментирование

Лично мне нравится другой способ моделирования ролей – от целевой аудитории. В данном случае также можно (даже рекомендуется) использовать мозговой штурм, но не сразу для названия ролей, а для определения критериев по разделению ЦА.

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

Изначально необходимо определить целевую аудиторию (в нашем примере – люди, которые делят обязанности по ведению хозяйства), само описание может немного меняться в ходе исследования, так как можно находить новые, неучтенные изначально, сегменты ЦА.

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

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

После этого с помощью критериев необходимо определить категории целевой аудитории, и для каждой категории задать название или сразу описать персону. То есть необходимо придумать роль, человека, который сочетает в себе разные значения критериев для разделения ЦА. Например, член семьи, который распределяет и контролирует обязанности по дому – мать Анжела. Сосед в съемной квартире или общежитии, который заинтересован в понимании, кто когда что делает по дому – Санёк. Человек, который не заинтересован в наведении порядка, но вынужден что-то делать по дому – подросток Володька.

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

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

Можно заметить, что в ходе такого способа моделирования был найден неучтенный ранее пользователь – хозяин фермы с наемными работниками (во время мозгового штурма по придумыванию ролей он не пришел никому в голову, а вот критерий размера дома помог сформулировать и такую роль).

Способ 4. Экстремальные персонажи

Что еще? Еще есть дополнительная методика – использование экстремальных персонажей (extreme characters). Вместо проектирования продукта для типичного пользователя предлагается подумать о пользователях с неординарными личностными качествами. Так, при проектировании персонального цифрового помощника предлагается подумать не о бизнес-консультанте в костюме, а о наркоторговце и о папе римском. Это может помочь нащупать новые полезные фичи, но не факт, что их целесообразно будет включать в продукт. Во всяком случае, это интересный инструмент развития креативности.

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

Что дальше

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

Резюме

• При разработке важно понимать, для кого та или иная функциональность имеет ценность.

• Определение пользовательских ролей (user types) полезно для разных методов документирования разработки.

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

• Для полноты картины следует использовать все способы моделирования пользовательских ролей.

• Персона (persona) – воображаемое представление пользовательской роли (её очеловечивание), помогает членам команды лучше представлять пользовательскую роль.

• Само моделирование пользовательских ролей уже позволяет выявить новые пользовательские истории (или требования).