Всем привет! 👋

Когда продукт IT-компании постепенно укрепляется в доверии пользователей, а интерес к функциональным возможностям этого ПО повышается, ожидания от работы и результатов взаимодействия с этим продуктом тоже растут 📈

А раз увеличивается количество требований, то появляется жёсткая необходимость их приоритезировать и фильтровать. Важно, чтобы те требования, которые команда реализует в ближайшем спринте не только отвечали цели ПО, но и закрывали как можно больше потребностей реальных пользователей продукта.

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

Догадались, о чём будет речь?
Пишите предположения в комментариях ⬇️

Первому, кто угадает название этой техники, вышлем в подарок электронную книгу на эту тему 🎁

✨ КАРТА ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ ✨

Для продуктов, которые стремительно набирают популярность, очень легко перестать понимать, в чём заключается общее предназначение ПО. В конечном итоге в руках у проектной команды может оказаться множество «кусочков» различных функциональностей, которые никак не складываются в единую картину или того хуже – перестают решать реальные «боли» пользователей.


В современной практике существует решение, которое снизит риск «свернуть не туда» при проектировании ПО – это построить карту планируемых функциональных возможностей от лица пользователей или по-другому – User Story Map.

Карта пользовательских историй (User Story Map) — это техника, которая позволяет расположить пользовательские истории согласно последовательности использования функций продукта.

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


А ещё User Story Map позволяет команде разработки:

1️⃣ увидеть масштаб всего продукта и последовательный путь взаимодействия с ним;
2️⃣ определиться с приоритетами при разработке продукта — решить, какие функции ПО нужно реализовать в первую очередь, а какие перенести на потом;
3️⃣ заранее определить узкие места и возможные конфликты внутри функциональных возможностей внутри ПО.


Если при внедрении новой функциональности у команды перед глазами есть User Story Map, снижается вероятность того, что внедряемая фича поломает существующие процессы внутри продукта.
Ну и конечно визуализация возможностей продукта – это отличный способ донести до всех заинтересованных лиц ценности и содержание ПО, а также подключить творческий взгляд на развитие продукта.


Ставьте 🔥 на этот пост – так мы поймём, интересна ли вам тема визуализации требований.

Далее расскажем, из чего состоит карта пользовательских историй, а также поделимся алгоритмом её построения.

#hardGetAnalyst

👩‍🎨 СТРОИМ КАРТУ ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ 👨‍🎨

Составить карту пользовательских историй можно с помощью разных инструментов: начиная с аналоговых (стикеров на стене или большой маркерной доски) и заканчивая специальным ПО (Miro, Draw.io, FigJam, Jira, Visual Paradigm и прочие).

🥷: User Story Map создают коллективно. Желательно, чтобы в этом участвовала вся команда разработки и представители пользователей. Эта встреча похожа на мозговой штурм, где регулятором встречи как раз может быть аналитик. Но часто в практике можно встретить, что аналитик выстраивает карту самостоятельно.

Карта пользовательских историй состоит из следующих элементов:

1. Описание персон пользователей продукта
2. Информационный блок о целях и глобальной проблеме, которую решает продукт
3. Перечисление пользовательских активностей на протяжении основного пользовательского пути
4. Описание задач пользователей внутри каждой активности
5. Пользовательские истории внутри каждой задачи (они же требования к реализации возможностей)
6. Разделение всех требований на итерации или релизы

😖 Бррррр! Много слов и ничего непонятно!

Без паники, разберёмся с каждым пунктом последовательно, а в конце дадим вам готовый шаблон, который вы сможете использовать в работе 💪

⬇️⬇️⬇️

ШАГ 1: Описываем персоны

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

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

🥷: Например, олицетворением персоны может быть пользователь определённой возрастной категории, уклада жизни, профессии и так далее.

На карте Персоны размещаются сверху, олицетворяя собой пользователей, чьи интересы планируется учесть в текущем проектировании ПО. Для удобства персоны, которые преследуют одни и те же цели, объединяют в группы. Благодаря этому реализация требования для группы позволит покрыть сразу несколько персон. А это круто! 😎



ШАГ 2: Фиксируем цели и глобальные проблемы, которые решает продукт

Для этого шага необходимо ответить на следующие вопросы:
- Над каким ПО вы работаете?
- Какова его основная задача?
- Какую глобальную проблему пользователей оно решает?

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



ШАГ 3: Заполняем пользовательские активности

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

Активности (User Activities) — это последовательные действия, которые пользователю нужно совершить, чтобы достичь своих целей.

Пользовательские активности — это каркас (backbone) карты, который формирует представление об основных функциях внутри ПО.

🥷: Примером последовательных активностей в приложении для заказа такси будет:
Указать маршрут -> Подтвердить заказ -> Совершить поездку и так далее.

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

🔘🔘🔘

Продолжим разбирать карту пользовательских историй завтра, а пока предлагаем найти первые три шага на схематичном представлении карты, приложенной выше ⬆️

ШАГ 4: Описываем задачи пользователей

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

Пользовательская задача (User Task) — это более конкретное описание действий, которые пользователь должен выполнить в рамках активности.

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

🥷: Например, для активности "Указать маршрут" в приложении для заказа такси можно обозначить следующие задачи:
- Указать точку отправления
- Указать точку прибытия

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



ШАГ 5: Оформляем пользовательские истории

Если активности и задачи описывают функции ПО верхнеуровнево, то добавление пользовательских историй позволяет детализировать функции ПО. Это помогает увидеть «пробелы» в карте, добавить неучтённые задачи и увидеть альтернативные варианты решения пользовательских задач. Ну и конечно пользовательские истории – это отправная точка для формулирования функциональных и нефункциональных требований к ПО.

🥷: Короче говоря, благодаря этому шагу мы становимся на шаг ближе к постановке задач на разработку.

Под каждой задачей необходимо расположить пользовательские истории, написанные по шаблону, с которым вы уже знакомы:

1. Как [кто-то] — например пользователь или роль;
2. Я хочу [чего-то] — выполнить какую-то задачу;
3. Чтобы [что-то] — достигнуть конкретную цель.

🥷: Например, для задачи "Указать точку отправления" можно сформулировать следующие истории:
- Как пользователь приложения для заказа такси, я хочу указать точку отправления на карте, чтобы быстро указать адрес, откуда меня нужно забрать.
- Как пользователь приложения для заказа такси, я хочу ввести адрес отправления вручную, чтобы не искать отправную точку сложным для меня способом.
- Как пользователь приложения для заказа такси, я хочу, чтобы точка отправления определилась автоматически, чтобы не указывать отправную точку самостоятельно.
и так далее.

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


🥵 Ребят, ну как вы? Уже утомились? Мы на финишной прямой!


При составлении User Story Map нужно уметь вовремя остановиться.
Задача этого инструмента — составить представление о том, как пользователь может работать с ПО и, как итог, какие функции должно выполнять ПО. Не стоит сильно углубляться в детали функциональности, подробно описывать элементы интерфейса и используемые данные.


🔘🔘🔘

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

Если всё ок, далее расскажем про последний шаг построения карты пользовательских историй и дадим готовый шаблон User story map, который вы сможете применять в работе уже сегодня (а лучше с понедельника! 😀)

ШАГ 6: Разделение User Story Map на релизы или итерации

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


Итерация (англ. iteration) — это согласованный период работы в виде отрезка времени, в течение которого разрабатывается часть ПО.

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

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


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

Релиз (англ. release) — выпуск готового для использования продукта.

Один из вариантов такого разделения — определение MVP (Minimal Viable Product — минимально жизнеспособный продукт). Для этого в первый релиз вносят только основные функциональные возможности, чтобы приложение выполняло основную свою задачу. В последующие релизы будут вынесены дополнительные возможности.


🙂🙂🙂


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

🥷: User Story Map – это отличный способ передавать требования для дизайна прототипа. Так, дизайнер получит необходимую, а главное, понятно оформленную информацию о функциональных возможностях на интерфейсе ПО и не будет «скован» жесткими требованиями к решению. А значит сможет творить! Поэтому использовать карту в работе можно для крупной новой функциональности внутри ПО, а не только для проектировании целого продукта.

Всем привет! 👋

На прошлой неделе мы спрятали тему User story map за теоретическим описанием и попросили вас догадаться о ней в обмен на книгу.
Кстати говоря, книга* нашла своего победителя! 🎉

Также среди ответов были предложены три других формата описания возможностей продукта: Road map, Use case и Customer journey map (CJM). И мы подумали: а ведь действительно эти способы визуализации продуктовых возможностей можно с лёгкостью перепутать, если не знать разницу между ними.

В 80% случаев на собеседованиях на позицию БА / СА уровня middle и выше справшивают хотя бы один вопрос из этих трёх тем.

А раз спрашивают, то постараемся подготовиться, чтобы с лёгкостью щелкать такие «орешки» на интервью в компанию мечты 💪 Ну что, а ю рэди?


* «Пользовательские истории. Искусство гибкой разработки ПО», автор: Джефф Паттон.
Рекомендуем для глубокого погружения в USM.

Привет! 🙋‍♀️

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

Но прежде чем определить функциональные требования, аналитику придётся как следует поработать с предыдущими типами требований – бизнес- и пользовательскими. Без этого существует риск спроектировать классную фичу, которая может оказаться никому не нужна - ни бизнесу, ни пользователям.

🥷: Подробнее тему типов требований мы разобрали в серии постов, начиная с этого.


С одной из техник описания пользовательских требований вы уже знакомы — это пользовательская история (англ. user story). Да что там знакомы – вы теперь можете целую карту историй построить (USM)!

🥷: Шаблон для построения USM мы давали вот тут.

Но существует ещё одна популярная техника описания функциональных требований к продукту с участием пользователя. Она помогает качественно и на достаточном для разработчиков уровне детализации отразить ожидаемые функциональные возможности продукта. И техника эта называется «вариант использования» (use case).

#hardGetAnalyst

⬇️⬇️⬇️

✨ ПРО ВАРИАНТ ИСПОЛЬЗОВАНИЯ (USE CASE) ✨

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

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

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


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

Актор (англ. actor) — человек, устройство или система, играющие некоторую определённую роль во взаимодействии с решением (BABOK Guide).

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

Выделить акторов, которые участвуют в описании вариантов использования, помогут такие вопросы:
❔ Кто (или что) уведомляется, если что-то происходит внутри системы?
❔ Кто (или что) предоставляет системе информацию и сервисы?
❔ Кто (или что) помогает системе среагировать и выполнить задачу?


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

🤔 USER STORY И USE CASE – В ЧЁМ РАЗНИЦА? 🤔

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

Рассмотрим их в разрезе ключевых атрибутов:
- фокус (на что делается упор в подходе),
- цель подхода,
- его формулировка,
- уровень детализации.


1️⃣ Фокус

*️⃣Пользовательская история сфокусирована на конкретной задаче или потребности пользователя.

*️⃣Вариант использования делает упор на взаимодействии системы с актором, а также на последовательность событий в этом взаимодействии.


2️⃣ Цель подхода

*️⃣Пользовательская история описывает задачу пользователя и причину для её выполнения.

🥷: Вспомните конструкцию user story:
как [кто-то (пользователь / роль)],
я хочу [выполнить задачу],
чтобы [достичь результата].

*️⃣Вариант использования же представляет описание поведения системы в различных ситуациях.


3️⃣ Формулировка подхода

*️⃣Пользовательская история формулируется по чётко заданному шаблону. Его вы уже знаете.

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


4️⃣ Уровень детализации

*️⃣Пользовательская история верхнеуровнево описывает функциональность, которую нужно реализовать.

*️⃣Вариант использования же содержит более структурированное и подробное описание взаимодействия актора и системы.

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


🥷: Хотим КВИЗануть ваше понимание отличий между двумя подходами. Вы как, в ресурсе? 😀
Если да, то ставьте 🔥 на этот пост. Пустим КВИЗ, закрепим полученную теорию и перейдём к шаблону use case.

Хола, амигос! 💃

Вы просили КВИЗ - мы замутили КВИЗ 😎

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

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

Ставим ❤️, если ю а рэди!

#quizGetAnalyst