User story или пользовательская история — это небольшой текст в формате пожелания, который помогает выяснить, кто такой пользователь, что он хочет и какова его цель. Стори используются чаще в сфере разработки приложений, софтов, ПО или инструментов. Их основная функция в том, чтобы помочь команде разработчиков создать такое приложение, которое удовлетворит пожелания большинства пользователей. В статье подробнее поговорим про юзер стори, их структуру, а также дадим семь примеров для понимания.
О том, как продвигать свои приложения в Google Play и AppStore, можно узнать из нашего канала в Телеграм, а еще больше интересных новостей мы публикуем здесь.
Пользовательские истории — это номинальное требование от пользователя с описанием его конечной цели. То есть стори не являются технической документацией — это чаще неформальный или деловой текст, который понимает каждый человек в отделе. Сам текст оформляется на карточках и содержит основные тезисы — считается, что истории должны быть максимально краткими и понятными, чтобы никто не сидел над их расшифровкой долго.
Прежде чем рассказать о структуре юзер стори, важно понять, для чего они вообще нужны и по каким правилам работают. Отвечаем — многие топовые компании по разработке ПО, игр или приложений работают по методике Scrum, которая основывается на образе мышления Agile.
Scrum — это что-то из мира практики, то есть метод помогает усовершенствовать работу в отделе. Сама методика подразумевает, что нужно постоянно обучаться и подстраиваться под изменчивые процессы — причина в том, что задачи в мире разработчика постоянно меняются, порой на полностью противоположные. И нужно быть к этому готовым — методика Scrum и обучает, как к этому быть готовым.
Agile — это образ мышления, один из принципов которого и базируется на идее совершенствования и умения подстраиваться под изменения. По сути, чтобы понять принципы Agile наглядно и внедрить их в работу, можно начинать с внедрения Scrum в работу и в жизнь — это будет первым шагом перестроить свое мышление.
Agile-разработка в целом — это все этапы разработки по порядку. Каждый этап перетекает в другой, и так по кругу. Наглядно это выглядит так:
Scrum предполагает эмпирический подход к работе, когда с помощью определенных примеров человек обучается всему практическим путем. Поэтому у метода есть своя структура — она состоит из трех артефактов: бэклог продукта, бэклог спринта и инкремент.
Бэклог продукта — это по сути список задач, которые нужно выполнить за все время. Обычно такой список составляют менеджеры проектов или продуктов и включает в него буквально все актуальные задачи отдела.
Бэклог спринта — это более краткий список задач, которые нужно выполнить во время текущего спринта. Спринтами в разработке называют отрезки времени, в период которых нужно выполнить насущные задачи — обычно он длится до двух недель, но иногда его урезают до недели. Все насущные задачи во время спринта обычно и включают разбор и обработку пользовательских историй для улучшения продукта. Стори подбирают не хаотично — сначала определяют цель текущего спринта, затем подбирают пользовательские истории, которые отвечают такой же цели.
Инкремент — это уже готовый продукт по итогам каждого спринта, обычно он демонстрируется на митапах внутри команды.
Попасть в крутую IT-компанию или команду можно, отправив Резюме в наш раздел или изучив свежие Вакансии, где публикуются открытые позиции проверенных работодателей.
По итогу можно сказать, что юзер стори — это по сути единица в большой системе работы над созданием, тестированием и подготовкой продукта. Хоть это всего лишь крошечная часть процесса, она имеет важное значение, так как помогает выяснять желания и цели целевой аудитории. То есть в перспективе — делать продукт совершенным.
Пользовательские истории, как уже сказали, много значат для отдела разработки и выпуска удачного продукта. Поэтому их нужно создавать вдумчиво и кропотливо, но при этом понятно и просто. Разберем, насколько вообще важны юзер стори — для этого рассмотрим их преимущества.
| Помогают сосредоточиться на пользователях — несмотря на наличие списков, которые включают все актуальные задачи команды, пользовательские истории помогают их уточнять и сосредотачивать именно на пользователях. |
| Улучшают сотрудничество и взаимодействие внутри команды — во время составления юзер стори, а также в процессе спринтов команда прилагает все свои общие усилия, что прийти к общей цели. |
| Побуждают творческое мышление — чтобы добиться цели пользователя, нужно применять различные методы работы. В этом плане себя может проявить каждый сотрудник — это серьезно развивает творческое и критическое мышление. |
|
Увеличивают мотивацию — если команда все делает правильно и в итоге добивается хорошего результата, это мотивирует работать еще лучше и усерднее. |
Ценность юзер стори разобрали — теперь можно подробнее изучить, как они пишутся, и что собой представляет их структура.
Структура юзер стори едина для каждой — она состоит из трех частей:
Таким образом, структура приобретает следующий вид:
| Как пользователь, я хочу действие, чтобы выгода/цель |
Например, как покупатель, я хочу использовать на сайте магазина корзину, чтобы товары, которые я хочу купить, хранились в одном месте.
Или — как пассажир, я хочу видеть всех таксистов поблизости в приложении, чтобы выбрать более подходящий вариант.
Хватает пары фраз, чтобы написать такую карточку — в ней обозначают, кто целевой клиент, чего он хочет, и какую выгоду получает.
Чтобы написать хорошую историю, важно руководствоваться принципами и использовать основные шаги, которые чаще применяют в большинстве компаний.
Принципы написания юзер стори называют INVEST — их разработал опытный программист Билл Уэйк. Давайте изучим их — всего принципов шесть:
Если руководствоваться этими принципами, получится учесть мелкие детали при написании стори. Но это не все, что используют при подготовке истории руководители проектов, — для ее написания мы собрали последовательность четких шагов. Давайте с ними ознакомимся.
Шаг №1: проверьте пользовательские потребности
Это привычный шаг для всех, кто создает продукты для пользователей, — составить портрет своей целевой аудитории. Обычно он включает серьезный анализ потребностей, места работы, целей в жизни. Но это потом — сначала нужно подготовить портрет целевого клиента. Портрет клиента — это частично вымышленный персонаж, который и является идеальным пользователем продукта. На этом этапе обычно выясняется, кто клиент, чем он занимается, сколько зарабатывает, его пол, наличие семьи и так далее.
Например, если магазину детских игрушек нужно выяснить, кто их целевая аудитория. Один сегмент — это стопроцентно мамы, у которых не так давно появился ребенок, они замужем, сидят в декрете и не имеют дохода. Список можно продолжать, чтобы сузить аудиторию, а также продумывать и другие сегменты — скажем, покупать игрушки могут и беременные девушки, которые только ждут рождения ребенка. И ситуация внутри семьи, как и потребности, будут несколько другими, чем у мамы с детьми.
Когда портрет продумали, можно идти и углубляться в анализ — здесь важно выяснить, с какими проблемами может сталкиваться пользователь, чем поможет продукт для решения этой проблемы. На этом этапе хорошо работают опросы и интервью — это помогает получить реальную информацию от целевой аудитории, а также улучшить ее портрет в целом.
Шаг №2: создайте эпики
Эпики — это по сути те же истории пользователей, но они включают несколько и содержат описание функционала приложения и его задач. Обычно эпики используют, чтобы не перегружать список с общими задачами. Когда приходит время создания юзер стори, то эпики дробят на эти истории.
Это может выглядеть как обычный список из историй пользователей:
«— как пользователь, я хочу яркую обложку приложения, чтобы не терять его из виду на рабочем столе;
— как пользователь, я хочу автоматический скроллинг видео, чтобы не тратить время на перелистывание;
— как пользователь, я хочу поделиться своим профилем через QR-код, чтобы не тратить свое и чужое время на ручной поиск профиля».
Впоследствии эпики разделяют на несколько карточек, чтобы работать над ними. Если бы это делали сразу, список задач бы увеличивался из-за большого количества актуальных историй. Это может сбивать с толку сотрудников.
Шаг №3: создавайте пользовательские истории на основе эпиков
Как уже сказали, на основе эпиков можно писать юзер стори, но это нужно делать правильно, с учетом потребностей отдельных пользователей. Это значит, что нужно выбрать определенный эпик, который соответствует цели спринта — например, это обновление в приложении и добавление в него новых фичей. Получается, нужно выбрать тот эпик, который включает все пользовательские пожелания относительно нововведений. Потом выбранный эпик дробится на юзер стори. Скажем, основная цель эпика была упростить способ загрузки и установки приложения на ПК в грядущем обновлении. Тогда стори будет включать мини-запросы пользователей по части загрузки — упростить процесс регистрации в приложении через авторизацию в Google или Facebook*, например.
Система составления стори наглядно будет выглядеть так:
Шаг №4: визуализация пользовательской истории
Чтобы было удобно обращаться к историям в любое время, их нужно правильно визуализировать. Обычно для этого используются многофункциональные инструменты по управлению проектом в команде. Так любой член команды может зайти в систему и посмотреть стори и любые пометки к ней от коллег.
Проще всего визуализировать через такие инструменты, где предусмотрено создание досок и карточек. Например, это может быть привычный всем Trello, за рубежом нередко используют Kanban.
Шаг №5: проверьте все истории по критериям приемлемости
Критерии или принципы для составления и использования историй мы обсудили выше, но список этих принципов — не догма. Можно вносить корректировки, использовать только часть или добавлять свои критерии. В любом случае важно, чтобы каждая история соответствовала критериям — была понятной, краткой и четкой, в ней присутствовала определенная цель, которой нужно добиться и так далее.
Чтобы быстрее пройти по всем этапам написания, можно использовать несколько рекомендаций — они касаются определения пользователя, а также его запроса.
Определяем, «кто» будет вашим пользователем:
Определяем, «что» нужно пользователю:
Напоследок: все этапы работы важно обсуждать в коллективе, поэтому после написания пользовательских историй нужен серьезный мозговой штурм — так каждый из отдела сможет высказать свои мысли по поводу истории.
Без примеров сложно разобраться в тонкостях, поэтому давайте разберем семь примеров эпиков и вытекающих из них пользовательских историй.
Пример №1: авторизация в кабинете сайта
Сначала начнем с составления эпика, его основная тема — как быстро авторизоваться в кабинете. 
После уточнения темы можно накидывать варианты того, с чем возникли или могут возникнуть проблемы у пользователя:
Первая история есть — теперь можно добавить еще несколько, если в этом есть необходимость. Например, как клиент магазина для взрослых, я хочу не указывать личные данные при регистрации, чтобы сохранить свою конфиденциальность.
Следующий пункт каждого эпика — это пояснения к теме. Необязательно включать этот пункт, но для понимания контекста он необходим. Здесь нужно обозначить, с чего вообще решили, что пользователь сталкивается или может столкнуться с этой проблемой. Варианты могут быть такие:
К пояснениям можно приложить ссылки или скрины с ответами пользователей в опросе, например. И после этого можно переходить к финальному шагу — обозначить границы эпика. Обозначение границ помогает задать путь к решению проблемы для разработчиков и отдела в целом.
То есть в этом пункте нужно прямо и описать действия для решения проблемы:
Так, эпик приобретет такой вид:
|
Тема: как быстро авторизоваться в кабинете
История 1: как покупатель, я хочу быстро зарегистрироваться через Google, чтобы быстрее перейти к покупкам.
История 2: как клиент магазина для взрослых, я хочу не указывать личные данные при регистрации, чтобы сохранить свою конфиденциальность.
Примечания:
Задачи, за которые выходить не нужно:
|
Соответственно те пункты, в которых говорится об истории пользователей, потом и берутся за основу для карточек пользовательских историй.
Пример №2: как сделать меню ресторана в приложении более интересным
Подробный пример с описанием всех шагов был выше — надеемся, что логика ясна. 
Поэтому далее будем показывать только то, как выглядит финальный вариант эпика и историй:
|
Тема: как сделать меню ресторана N в приложении живым и цепляющим
История 1: как менеджер ресторана, я хочу видеть больше фотографий блюд в меню, чтобы привлечь больше клиентов.
История 2: как покупатель, я хочу видеть, что я заказываю, чтобы не ошибиться с выбором.
История 3: как постоянный клиент, я хочу видеть все скидочные предложения, которые мне положены, чтобы не пропускать дни акций.
Примечания:
Задачи, за которые не нужно выходить:
|
Пример №3: создание приложения под интернет-магазин косметики
|
Тема: оснастить приложение дополнительными фичами, которые облегчат выбор косметики клиентам
История 1: как покупатель косметики, я хочу видеть, как она будет выглядеть на мне, чтобы правильно подобрать тон или текстуру.
История 2: как частый покупатель, я хочу видеть все варианты актуальных скидок на товары, чтобы не пропустить их.
История 3: как оптовый покупатель, я хочу получать все предложения на почту, чтобы вовремя заказать товары по сниженной цене.
Примечания:
Задачи, за которые не нужно выходить:
|
Пример №4: как повысить лояльность клиентов через раздел с отзывами
|
Тема: добавить на сайт компании-поставщика продуктов для кафе и ресторанов раздел с отзывами
История 1: как владелец кафе, я хочу знать, как отзываются о поставщике продуктов коллеги, чтобы оценить качество продуктов и сроки доставки.
История 2: как сотрудник санитарной службы, я хочу знать реальные отзывы покупателей, чтобы дать начальную оценку их качеству.
История 3: как розничный покупатель, я хочу понимать, что за продукты я покупаю, чтобы знать, стоит заказывать или нет.
Примечания:
Задачи, за которые не нужно выходить:
|
Пример №5: улучшить пользовательский интерфейс приложения
|
Тема: улучшить пользовательский интерфейс приложения: работа с текстом, плашками, формами и шрифтами
История 1: как пенсионер, который занимается с помощью этого приложения, я хочу без проблем читать текст, чтобы не приближать постоянно телефон к глазам и не надевать очки.
История 2: как человек без медицинского образования, я хочу понимать эффективность программы и иметь возможность связаться с экспертом, чтобы задать ему все вопросы.
История 3: как человек, который следит за своим питанием и водным балансом, я бы хотел видеть, сколько я пью воды регулярно и сколько вешу, чтобы следить за своим здоровьем полноценно.
Примечания:
Задачи, за которые не стоит выходить:
|
Пример №6: добавить плейлист в приложение, который можно пополнять через поиск
|
Тема: добавить возможность поиска музыки, создать плейлист и возможность добавлять в него музыку
История 1: как любитель слушать музыку постоянно, я хочу иметь возможность создавать и пополнять свой плейлист любимыми песнями, чтобы слушать их в любое время.
История 2: как пользователь, я хочу интерфейс попроще, чтобы сразу находить свои плейлисты и искать новую музыку в этом же разделе.
Примечания:
Задачи, за которые не нужно выходить:
|
Пример №7: улучшить безопасность приложения банка
|
Тема: улучшить настройки безопасности в приложении банка N
История 1: как клиент банка, я хочу видеть проверку личности по отпечатку пальца, чтобы точно знать, что никто не залезет в это приложение.
История 2: как представитель банка N, я хочу убрать возможность восстановления пароля по почте или номеру телефона, чтобы клиенты лично на сайте банка или в офисе меняли эти данные.
Примечания:
Задачи, за которые не нужно выходить:
|
Подтянуть навыки в IT, прокачаться в написании пользовательских историй можно, пройдя доступные онлайн-курсы. В нашем разделе Образование собраны только лучшие проверенные программы.
Вывод
User story — это эффективный инструмент для организации работы внутри IT-отдела. Но система может подойти для команд из любых сфер, в которых требуется решать много сложных задач быстро.
Главное не только выучить всю механику, — как составлять эпики, а потом истории — но и войти в контекст вместе с командой: устраивать регулярные собрания по обсуждения всех историй, эпиков, целей и задач.
Для внедрения такой методики нужно хорошо освоить навык анализа аудитории, а также запомнить структуру историй и эпиков. Кроме того, необходимо обоюдное участие всей команды и ее заинтересованность, а еще софт, в котором можно будет визуализировать все задачи и истории.
*запрещенная в РФ организация
