User story пример описания




User stories

В теме 16 ответов, и 9 участников, последнее обновление сделано пользователем Snowball 8 г, 1 мес. назад.

Each line is an individual object with all corresponding operation applicable, like copy, cut, paste, drag around the editor.

Mockup
И картинка как это выглядит.
——————
ИМХО это вполне понятное описание и уже несколько итераций по таким вот описаниям уже завершились.

Как правило, User Storу имеет следущий формат:
Я, как [название бизнес-роли] хочу иметь возможность [описание возможности], потому что [мотивация необходимости]

На торрентах скачал User Stories Applied. Вроде как хорошая книжка. Читаю. Если кому надо — обращайтесь.

Брось мне мылом, я выложу в соответствующий раздел. Или залей сам в соответствующую ветку (:

То, что Вы написали в своем первом посте, мне напоминает не User Stories, а упрорщенный вариант описания Use Case.

Как правило, User Storу имеет следущий формат:
[i]Я, как [название бизнес-роли] хочу иметь возможность [описание возможности], потому что [мотивация необходимости][/i]

Согласен, этот шаблон всюду приводят. Но что делать если нужно уточнить детали?

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

[quote=»Sergey.Shimansky»]То, что Вы написали в своем первом посте, мне напоминает не User Stories, а упрорщенный вариант описания Use Case.

Как правило, User Storу имеет следущий формат:
[i]Я, как [название бизнес-роли] хочу иметь возможность [описание возможности], потому что [мотивация необходимости][/i]

Согласен, этот шаблон всюду приводят. Но что делать если нужно уточнить детали?[/quote]

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

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

Именно это и предлагают разработчики scrum. Всю историю исправлений, изменений и уточнений хранить нужно в ежедневно обновляемом документе-таблице. Формат его может быть выбран по вашему усмотрению, обычно его вести должен PM, ну а уточнения происходят при общении на ежедневных митингах — PM просто фиксирует в таблице то, о чем договорились члены команды. Это гораздо проще, чем перегружать User stories кучей информации. Идея самой этой штуки в том, чтобы за один взгляд на «карточку» c user story любой мог представить себе, что нужно реализовать, а не как нужно реализовать.

Как и зачем писать Use Cases

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

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

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

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

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:

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

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

Кому и в каких случаях нужны сценарии

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

— Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.

— Тестировщику. Почти готовый тест-кейс 🙂

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

А также другим участникам процесса.

В каких случаях они нужны:

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

— Для поддержки системы. Чтоб выявить ошибку, разобраться, на каком шаге что пошло не так.

— Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие — отклик системы», или даже совместить такую табличку со сценарием.

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Успешный сценарий:

  1. Администратор выбирает пользователя и активирует «Разблокировать».
  2. Система переключает учетную запись пользователя в статус «активный», и посылает сообщение (тут можно сослаться на текст сообщения из списка сообщений, см. примечание ниже) пользователю на email (если «User Account → email» не пусто).

Пример 2. Авторизация пользователя:

Успешный сценарий:

  1. Пользователь запускает систему. Система открывает сессию пользователя, предлагает ввести логин и пароль.
  2. Пользователь вводит логин и пароль.
  3. Система проверяет логин и пароль.
  4. Система создает запись в истории авторизаций (IP адрес пользователя, логин, дата, рабочая станция).
  5. Система выдает пользователю сообщение по поводу успешной авторизации (ссылка на сообщение).

Важные моменты

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

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

— Если в двух и более сценариях повторяется одинаковый набор шагов, есть смысл вынести эти шаги в отдельный сценарий, и ссылаться на них. Документ будет легче. А если что-то в этих шагах поменяется, то достаточно будет изменить в одном месте.

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

— Перечитайте документ со сценариями, перед тем, как отдавать его разработчикам или заказчикам. Лучше даже несколько раз. Всегда находятся моменты, которые можно описать лаконичнее, или выявляются какие-то несоответствия. Или случайные «копипасты». Уважайте время и головы других людей.

— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.

Правильных и полезных вам сценариев! Вопросы, примеры, предложения, комментарии приветствуются. Спасибо за внимание.

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

Как создать User Story, сценарии и кейсы

Не забывайте о пользователях

Вы знаете как рассказывать User Story. Почему именно так, а не иначе? И уверены ли вы что вы делаете это правильно, а не просто потому что так сложилось.

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

Любой проект это синтез знаний — с помощью обмена знаний, появляется что-то новое и это целиком и полностью результат совместной работы.

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

Довольно проще и “дешевле” взаимодействовать заказчику с командой разработки. Но как в эту картину вписать клиента?

Для этого нужны, как минимум, две вещи:

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

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

В частности любое решение должно быть обосновано: необходимость>опыт>результат.

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

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

User Story

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

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

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

Чаще всего подобные магазины имеют совершенно разных клиентов, со своими потребностями. Пользовательские истории помогают документировать практические различия этих пользователей. Если у вас персон 3–4, то пользовательских историй может быть 20, или даже больше. Но не пугайтесь. Они короткие, каждая из 1–2 предложений.

Пользовательские сценарии

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

Вот пример пользовательской истории для того же самого интернет-магазина

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

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

Варианты использования

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

Пример вариантов использования на примере сценария Джерри:

Рубильная машина Джерри ломается

  1. Находит руководство пользователя, выясняет название и номер модели
  2. Вбивает название модели и номер модели в поисковике
  3. Нажимает энтер
  4. Просматривает выдачу результатов, сканирует страницу в поисках совпадения названия и модели
  5. Находит результаты, которые кажутся ему правильными
  6. Вводит имя модели в поле поиска на сайте
  7. Нажимает ентер
  8. Просматривает страницу
  9. Находит список рубильных машин
  10. Нажимает на ссылку
  11. Смотрит описание для машины от производителя
  12. Сканирует страницу в поисках модели
  13. Находит ссылку на руководство пользователя
  14. Нажимает скачать PDF
  15. Смотрит PDF-руководство, сканирует на поиск своей модели
  16. Ищет ту часть, которая, как ему кажется, нуждается в обслужвании
  17. Находит, по номеру, указанному в схеме гидравлического насоса
  18. Пытается скопировать номер, но не получается, так как являяется частью изображения
  19. Записывает номер на бумаге
  20. Возвращается на веб сайт
  21. Ищет по номеру детали в поисковой строке
  22. Нажимает на кнопку Поиск
  23. На странице поиска не находит результатов
  24. Сканирует страницу на поиск контактной информации
  25. Нажимает : “Контакты”
  26. Страница загружается, он заполняет форму
  27. Нажимает : отправить

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

User Flow

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

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

Как это использовать?

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

User story пример описания

Войти

Формирование PBL с использованием Use case для проектов реализуемых по Scrum

Коллеги, добрый день. По ряду причин я должен использовать Use case для описания реализации проекта по разработке большой системы. К сожалению, до настоящего момента у меня не было опыта использования Use case для проектов, реализуемых по Scrum. Основная проблема с которой я столкнулся – что считать Product backlog Item (PBI) и как трассировать по отношению к Use case (UC)? Ниже представлены мои рассуждение. Буду признателен за критику, совет и помощь.

User story vs Use case

Первый вопрос, который надо было решить — использовать User story или Use case. После некоторых размышлений на тему, а также после прочтения книги Алистера Коберна «Современные методы описания функциональных требований к системам», книгу Майка Кона «Пользовательские истории» и статьи на эту тему я пришел к некоторым выводам:

1. User story нам не подходят т.к. сложно понять поведение большой системы через формат записи User story.
2. User story не обладают механизмами таксономии и их сложно группировать по каким то признакам. В результате возникает груда записей, которым логически мало связаны друг с другом. В этом плане возможности Use case значительно выше и позволяют построить логически связанное описание. Очевидно, что без иерархии нам не обойтись.
3. При этом оказалось, что без User story не сделать Use case т.к. нужен первоначальный драйвер, который позволит быстро их подготовить. После подготовки Use case их можно было выкинуть.
4. Отличие хорошо написанных user story от хорошо написанных use case не велико. Формально Use case имеет более глубокую детализацию, что неплохо, когда в проекте работает больше 6 разработчиков и сложные заказчики. Об этом говориться в книгах обоих авторов, приведенных выше.

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

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

Пример (заведомо максимально упрощенный):
==================================
UC_1 Пользователь получает деньги в банкомате
Уровень: небо
Сценарий:
1. Пользователь проходит процедуру авторизации введя пин код и сумму к выдаче.
2. Пользователь завершает операцию, получив деньги и карту.

Что бы достигнуть этой цели нужно для начала пройти авторизацию. Мы описываем это в следующем Use case:

==================================
UC_2 Процедура авторизации
Уровень: море
Необходимое условие: Пользователь вставил карту
Сценарий:
1. Система авторизует пользователя.
2. Система запрашивает процессинговый центр разрешение на операцию и разрешение выдачи запрошенной суммы.
3. Система сообщает банкомату результат процедуры авторизации.
==================================

Следующий кейс завершает задачу:

==================================
UC_3 Завершение операции
Уровень: море
Необходимое условие: успешное завершение UC_2 (пользователь авторизован, запрошенная сумма разрешена к выдаче).
Сценарий:
1. Система возвращает карту пользователю.
2. Система осуществляет подсчет купюр и их выдачу.
2. Система обменивается данными с процессинговым центром для фиксации результата выдачи денег.
==================================

Формирование PBL на основании use case

Последний вопрос, на который нам надо было ответить, как сформировать Product backlog (PBL) с использованием представленных выше кейсов. Мы рассмотрели несколько вариантов.
Вариант, который сразу отпал — взять в качестве PBI 1й уровень (UC_1 Пользователь получает деньги в банкомате) нельзя т.к. это однозначно может не уложиться в спринт т.е. слишком эпично и нереализуемо в рамках одного спринта. Далее мы рассмотрели другие варианты:

Вариант 1
В качестве PBI взять UС_2 и UС_3. Получится PBL, содержащий:
1. Процедура авторизации
2. Завершение операции
Плюсы: Простота трассировки. В качестве задач для реализации PBI элемента мы можем использовать шаги кейса. Описание, содержащееся в Use case, достаточно полное для понимания требований и критериев приемки.
Минусы: Задача может быть слишком большая для спринта. При этом этот минус легко нивелировать разбив этот Use case на несколько меньшего размера.

Вариант 2
В качестве PBI взять шаги 2го и 3го use case. Получится PBL, содержащий:
1. Система авторизует пользователя.
2. Система запрашивает разрешение на операцию и размер максимальной суммы выдачи.
3. Система сообщает банкомату результат процедуры авторизации.
4. Система возвращает карту пользователю.
5. Система осуществляет подсчет купюр и их выдачу.
6. Система обменивается данными с процессинговым центром для фиксации результата выдачи денег.
Плюсы: Хорошая атомарность, поддающаяся оценке.
Минусы: Сложно трассировать с конкретным Use case. Сложно отслеживать последовательность реализации (критический путь). С точки зрения невилирования проблем можно использовать таксономию, что может также создать дополнительные сложности.

Вариант 3
Отталкиваяс от имеющихся Use case подготовить свой набор PBI элементов, не связанный наприямую с UC. Получится PBL, содержащий:
1. Процудура авторизации.
2. Взаимодействие с процессинговым центром.
3. Завершение операции.
Плюсы: есть возможность удобного атомарного разделения задач.
Минусы: трассировка элементов PBL с конкретными UC очень сложная.

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

История пользователя (user story)

Что такое история пользователя? Для чего она нужна? И как “рассказать” правильную историю?

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

Первое знакомство с маркетингом началось с того, что любой продукт, который мы создаем начинается с потребности. У каждого из нас есть разные потребности: кушать, ходить в туалет, красиво одеваться, получать социальное признание и не только. Под каждую из этих потребностей создаются продукты (товары, услуги), которые решают так называемую “внутреннюю боль”.

Чтобы понять, как лучше решить ту или иную “боль” вы должны представлять себе сценарий или ситуацию, в которой находится человек с определенной потребностью. Вот тут и появляется история пользователя.

Что такое история пользователя (user story)

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

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

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

Какие задачи решает история пользователя

  • описывает потребности пользователя/ей или типа пользователя/ей
  • помогает разбить потребности на конкретные задачи для разработки
  • оценивает ресурсы, которые потребуются на разработку
  • позволяет лучше приоритезировать задачи в общем плане развития продукта (или roadmap)
  • дает возможность другим участникам команды лучше понять контекст задачи
  • является основой для проведения тестирования с реальными пользователями
  • и многое другое

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

Как писать историю пользователя

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

Я как , хочу , потому что

По существу, чтобы заполнить форму, вам необходимо:

  • определить тот тип пользователей, который вас интересует (как правило, это ваша целевая аудитория)
  • понять те действия, которые нужны пользователям
  • выяснить почему именно эти действия нужны

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

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

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

Давайте перейдем к конкретным примерам и поймем как же это работает.

Почта, это прошлый век, подписывайтесь на наш telegram канал!

Пример истории пользователя: эмоджи

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

Понимаю, как тяжело это представить…

И вот все бы ничего, да видите вы, что время, которое проводят пользователя а вашей платформе, начинает сокращаться. Если раньше в среднем за день человек проводил у вас час, то сейчас это уже 52 минуты. “В чем дело?”, – подумаете вы. Проведете опрос, поговорите с пользователями, в конце концов спросите совет у друзей и тут станет понятно, что пользователям стало скучно, хочется чего-то новенького.

Вас посещает идея, что неплохо бы удивить их чем-нибудь. Вы формируете историю пользователя:

Я как пользователь социальных сетей, хочу чего-то новенького, так как мне скучно.

Поштурмили немного с командой и придумали эмоджи (смайлы или эмоциональные реакции). Докрутили немного user story:

Я как пользователь социальных сетей, хочу эмоджи, так как мне скучно.

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

Если историй много

Если история пользователя у вас не одна (а это скорее всего так), то вы расставляете приоритеты между ними и берете в работу “самую наболевшую” у пользователей, а после переходите к следующей. Таким образом на первом плане у вас стоит всегда интерес пользователя и каждая следующая функциональность выпущенная в релизе, будет востребована.

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

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

Не забудьте про измерения

Вы приступили к написанию истории пользователя, которая должна решить чью-то “боль”. Но как понять, что “боль” решилась? Наверняка необходимо как-то оценить эффект от того, что вы сделаете? Вопрос: “Как?”. Для этого используйте критерии приемки.

Критерии приемки – показатели, которые будут подтверждать результат ваших трудов.

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

Два основных вопроса для критериев приемки:

  • Какие показатели будем измерять, чтобы померить эффект от новой фишки?
  • Какие показатели считать успешными, а какие нет?

Маленький секрет

Будь то разработка на гибких методологиях или же маркетинговое исследование, в результате которого появились истории пользователя, вам обязательно потребуется тесный контакт с реальными пользователями. Команда, которая делает что-то для определенных людей, должна периодически общаться с этими людьми. Узнавайте у своих пользователей, правильно ли вы поняли их боль, делайте customer development и оттачивайте свой функционал до блеска. В противном случае, вы просто один раз снимите данные с пользователей, “запилите” что-то, а в итоге это будет никому не нужно.

Закругляемся

История пользователя, это один из мощнейших инструментов для создания нужного продукта. Используйте его в своих проектах, общайтесь с пользователями и будьте открыты для изменений. А главное запомните, много историй не бывает, хороших историй пользователя тем более 😉

Интересный ролик от компании Under Armor, атмосферное и заряженное видео.