User Stories: Выделение ролей пользователей

Текстовая расшифровка одного из уроков курса Введение в профессию аналитика.

Практика, о которой пойдёт речь в этом уроке, — выявление видов пользователей. Вообще, в книгах они называются обычно ролями пользователей. Но я решил здесь всё-таки использовать в названии урока другое слово, чтобы отделить понятие, используемое при разработке User Stories, от других ролевых моделей. Мы сейчас поймём, что имеется в виду.

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

Таких ситуаций в работе аналитика возникает довольно много. Если вы читаете какой-то свод знаний — например, BABOK (Business Analysis Body of Knowledge) для бизнес-аналитиков или PMBOK (Project Management Body of Knowledge) для менеджеров проектов, — то обнаруживаете, что там довольно часто предлагается использовать метод «мозгового штурма». Для того, чтобы выявить риски, например, используйте мозговой штурм. Предложение использовать мозговой штурм обычно означает, что авторы этих сводов знаний не могут предложить какого-то формального метода для получения нужного результата. То есть нужно использовать коллективный разум: собрать множество заинтересованных участников в одной комнате, дать им возможность свободно высказывать свои идеи в надежде, что то-то из этого получится. Метод на самом деле эффективный, но его нельзя назвать формальным. Он по определению формализации не поддаётся.

Для выделения типов пользователей для User Stories в большинстве книг тоже предлагается использовать мозговой штурм. Это означает, что авторы вместо каких-то формальных методов предлагают полагаться, прежде всего, на опыт и интуицию.

Этот пример я взял пример из книги Майка Кона «Пользовательские истории». Здесь рассматривается вариант того, что может в результате этого мозгового штурма появиться. Я не буду описывать технику мозгового штурма, этому посвящено много источников. И Википедию можете почитать, и книги есть, и курсы на эту тему проводятся. Но, если коротко, смысл в том, что люди собираются вместе, им даётся полная свобода на высказывание любых идей, при этом самое главное условие — нельзя критиковать идеи, когда они высказываются. А потом из этого перечня выбираются те идеи, которые будут дальше прорабатываться.

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

Выпускник — человек, который выпустился из университета и ищет работу.

Новичок — человек, который хочет освоить какую-то специальность, но никакого опыта в ней не имеет.

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

Соискатель — просто человек, который ищет работу.

Наблюдатель — человек, который заходит на сайт, например, чтобы просто изредка мониторить вакансии и понять, насколько его текущая зарплата соответствует его уровню. Бывают разные причины. Если говорить о реальной жизни, некоторые руководства рекомендуют просто периодически ходить на собеседования в разные компании, чтобы не вариться в собственном соку, а, чтобы видеть, что ещё в мире происходит.

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

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

Есть люди, которые отвечают за публикацию вакансий, их так и назвали — Публикаторы вакансий.

Читатель резюме. Есть люди, которые со стороны компании подбирают кадры. Они читают резюме, выложенные соискателями, и смотрят, насколько они соответствуют потребностям компании.

Есть обобщённая роль — рекрутинговый агент или рекрутер, человек, который занимается поиском людей, которые подойдут для работы в компании.

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

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

Отчасти перекрываются функции рекрутингового агента, читателя резюме и публикатора вакансий.

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

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

Решили, что у нас есть обобщённая роль соискателя. Её разновидностями могут быть «новичок» — человек у которого опыта никакого нет, а также человек, которому срочно нужно найти работу, и которого могут быть какие-то особенные потребности. Он здесь называется «жертва увольнения», и мы хотим на нашем сайте эти его особые потребности удовлетворить.

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

И отдельно остался вид пользователя «администратор».

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

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

У разных сотрудников банка, например, есть разные цели и разные функции. Или как на этой картинке: мы говорили, что у нас в команде разработки есть роль разработчика, и есть роль тимлида. Разработчик — это тот, кто занимается программированием и исправляет баги, а тимлид разработки — тот, кто решает конфликтные ситуации, когда что-то нарушается в процессе исправления багов. И с тестировщиками точно так же. Есть люди, которые тестируют, а есть тимлиды, которые тоже разрешают конфликты. В этой модели, мы тоже об этом говорили, все эти роли может исполнять один человек. Или один человек может две роли совмещать. Допустим, тестировщик до обеда тестирует, а после обеда сам собой руководит.

Но важно именно функциональное деление. И очень часто такое деление на роли ещё и определяет права доступа. Если мы дали сотруднику роль только разработчика, то он может фиксить баги, но не может отказать в приёме бага на исправление. Он должен обратиться к кому-то у кого есть роль тимлида разработки. А если мы хотим, чтобы разработчик имел право на это, тогда мы должны ему эту роль тоже присвоить.

Чем эта функциональная модель ролей отличается от того, что мы сейчас рассмотрели в User Stories? Я свёл основные отличия в табличку.

Если для разработки юзкейсов определяют роли по функциональным обязанностям и правам, то в методе User Stories при делении на роли руководствуются различием интересов и ожиданий от продукта. У новичка и у только что уволенного человека с опытом, вероятно, разные ожидания от продукта. Один хочет найти хорошую первую работу, а второй хочет срочно найти работу, потому что у него в семейном бюджете брешь, его из компании сократили. И это может как-то сказаться на его взаимодействии с продуктом.

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

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

И в результате получается так, что с точки зрения Use Cases мы нарезаем роли по функциональности. При этом один человек может совмещать несколько ролей (мы говорили, что тимлид может и должен иметь права и программиста тоже). А в случае с User Stories выходит, что мы однотипных пользователей нарезаем, скорее, на группы с разными параметрами. Очевидно, что у всех этих ролей в случае с User Stories права доступа будут одни и те же, они могут воспользоваться равными возможностями по отношению к сайту, но при этом одна группа будет использовать одни возможности, а другая группа предпочтёт другие. И, собственно, задача состоит в том, чтобы удовлетворить все виды пользователей.

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

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