User story — что это, структура и 7 примеров

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

О том, как продвигать свои приложения в Google Play и AppStore, можно узнать из нашего канала в Телеграм, а еще больше интересных новостей мы публикуем здесь.

Что такое пользовательские истории и их значение для разработки

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

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

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

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

Agile-разработка в целом — это все этапы разработки по порядку. Каждый этап перетекает в другой, и так по кругу. Наглядно это выглядит так:

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

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

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

Инкремент — это уже готовый продукт по итогам каждого спринта, обычно он демонстрируется на митапах внутри команды.

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

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

Зачем нужны юзер стори

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

Структура пользовательской истории

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

Структура юзер стори едина для каждой — она состоит из трех частей:

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

Таким образом, структура приобретает следующий вид:

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

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

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

Принципы и шаги написания пользовательской истории

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

Принципы написания юзер стори называют INVEST — их разработал опытный программист Билл Уэйк. Давайте изучим их — всего принципов шесть:

• I означает Independent (независимость) — истории должны быть осуществимы, вне зависимости от обстоятельств;
• N означает Negotiable (открытость) — история должна быть открытой для обсуждения, то есть простой и понятной каждому;
• V означает Valuable (ценность) — все заинтересованные люди должны получить ценность от выполнения истории — пользователи, разработчики, владельцы проекта;
• E означает Estimable (оценочность) — история должна подходить для обсуждения и ее оценки в дальнейшем;
• S означает Small (лаконичность) — история должна иметь небольшой размер, в идеале не превышать одного сложноподчиненного предложения с простыми составными частями;
• T означает Testable (тестируемость) — чтобы завершить историю, ее нужно сначала протестировать, и она должна подходить для тестирования.

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

Шаг №1: проверьте пользовательские потребности

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

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

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

Шаг №2: создайте эпики

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

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

«— как пользователь, я хочу яркую обложку приложения, чтобы не терять его из виду на рабочем столе;

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

— как пользователь, я хочу поделиться своим профилем через QR-код, чтобы не тратить свое и чужое время на ручной поиск профиля».

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

Шаг №3: создавайте пользовательские истории на основе эпиков

Как уже сказали, на основе эпиков можно писать юзер стори, но это нужно делать правильно, с учетом потребностей отдельных пользователей. Это значит, что нужно выбрать определенный эпик, который соответствует цели спринта — например, это обновление в приложении и добавление в него новых фичей. Получается, нужно выбрать тот эпик, который включает все пользовательские пожелания относительно нововведений. Потом выбранный эпик дробится на юзер стори. Скажем, основная цель эпика была упростить способ загрузки и установки приложения на ПК в грядущем обновлении. Тогда стори будет включать мини-запросы пользователей по части загрузки — упростить процесс регистрации в приложении через авторизацию в Google или Facebook*, например.

Система составления стори наглядно будет выглядеть так:

Шаг №4: визуализация пользовательской истории

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

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

Шаг №5: проверьте все истории по критериям приемлемости

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

Рекомендации по написанию юзер стори

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

Определяем, «кто» будет вашим пользователем: 

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

Определяем, «что» нужно пользователю:

• не важно, сколько пожеланий у клиента, потому что одна история — это одно действие. Никаких исключений;
• постоянно уточняйте — если пользователю не нравится работа в профиле, попытайтесь обозначить, что именно ему не нравится. Например, «я хочу быстрее регистрироваться», «я хочу, чтобы фото в профиле не обрезалось», «я хочу более вместительный раздел с биографией» и так далее;
• не уходите в детали, которые не известны пользователю — это касается технической стороны интерфейса. Пользователя не волнует техническая сторона, а только конечный результат работы этих технических инструментов — ему нужно, чтобы приложение быстрее грузилось, а не то, какие технические составляющие за это отвечают, и как оптимизировать их работу.

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

7 примеров юзер стори и эпиков

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

Пример №1: авторизация в кабинете сайта

Сначала начнем с составления эпика, его основная тема — как быстро авторизоваться в кабинете.

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

• кто — как покупатель;
• что хочет — я хочу быстро зарегистрироваться через Google;
• зачем — чтобы быстрее перейти к покупкам.

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

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

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

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

То есть в этом пункте нужно прямо и описать действия для решения проблемы:

• убрать из формы регистрации все поля, где требуется указывать личные данные — за исключением раздела с вариантами оплаты товаров, а также номера телефона и почты пользователя;
• добавить возможность авторизации через Google или Facebook;
• добавить к кнопке регистрации ссылку с текстом на политику конфиденциальности.

Так, эпик приобретет такой вид:

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

Пример №2: как сделать меню ресторана в приложении более интересным

Подробный пример с описанием всех шагов был выше — надеемся, что логика ясна.

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

Пример №3: создание приложения под интернет-магазин косметики

Пример №4: как повысить лояльность клиентов через раздел с отзывами

Пример №5: улучшить пользовательский интерфейс приложения

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

Пример №7: улучшить безопасность приложения банка

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

Вывод

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

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

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

*запрещенная в РФ организация

Вакансии

Tik-Tok Media Buyer / Медиа баер Тик Ток (удаленно)

Медиабаинговая команда

После собеседования

Удаленно

Графический дизайнер

ONLEIX

от 50 000 ₽

Удаленно

Менеджер по размещению интернет-рекламы: Programmatic / Media buyer

AstraLab

от 50 000 ₽

Тамбов

Все объявления

Разместить