User Story: кто пишет пользовательские истории и зачем это надо

Что такое User Story

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

Обычно User Story состоит из трех частей: 

• роль (кто): пользователь продукта;
• цель (что): действие, которое хочет совершить пользователь; 
• результат (зачем): что он хочет получить в итоге.

Например: «Как [клиент салона красоты], я хочу [иметь возможность записаться на стрижку через мобильное приложение], чтобы [мне не пришлось звонить]».
В рамках одного продукта можно написать много разных user story. А если у сервиса есть разные пользователи, то нужно прописать истории отдельно для каждого.

Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор Telegram-канала @ithumanwork:

«Раньше для постановки задачи в команде разработки использовались более формальные и строгие способы, например ЧТ, ЧТЗ, SRS, BRD. User Story пришли как один из способов оставаться AGILE и поддерживать непрерывную разработку. И раньше всего начали использоваться в рамках продуктового подхода. Это короткие истории, которые помогают быстро реагировать на изменения и вносить правки в продукт».

Зачем нужны User Story

User Story используют в работе бизнес-аналитики, продакт-оунеры и проджект-менеджеры. Они помогают:

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

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

Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор Telegram-канала @ithumanwork:

«User Story кратно увеличивает скорость работы команды. Можно написать короткую пользовательскую историю вместо длинного ТЗ на десять страниц. При этом User Story будет содержать все важные требования, которые необходимо учесть в процессе разработки. 

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

Читайте также:

UI-тестирование: что это и как его провести

Характеристики хорошей User Story

Правильная User Story соответствует критериям INVEST:

• Independent (независимая): может быть реализована в любом порядке. Плохо, если задача А не может быть запущена в работу без задачи Б. В этом случае их нужно объединить в одну большую независимую историю. 
• Negotiable (обсуждаемая): отражает суть запроса, а не дает конкретную инструкцию, как выполнить задачу. Команда должна иметь возможность обсудить детали.
• Valuable (ценная): несет пользу клиентам, бизнесу и стейкхолдерам. Если в пользовательской истории нет ценности, то нет смысла ее выполнять;
• Estimable (оцениваемая): по формулировке истории можно оценить объем работы. Если не получается, то, скорее всего, в ней есть ошибки.
• Small (компактная): ее можно быстро реализовать. Некоторые команды устанавливают временные рамки, какое максимальное количество времени можно потратить на одну юзер стори.
• Testable (тестируемая): ее можно проверить на практике. 

Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор Telegram-канала @ithumanwork:

«При составлении пользовательской истории можно ориентироваться на критерии INVEST. Однако на практике некоторые истории сложно подвести под какие-либо критерии. 

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

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

Как писать User Story

Чтобы создать юзер стори:

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

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

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

Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор Telegram-канала @ithumanwork:

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

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

Ошибки в пользовательских историях

При написании юзер стори важно избегать распространенных ошибок.

• Неправильная формулировка «почему»: третья часть User Story должна отражать ценность для клиента, чтобы разработчики точно понимали, в каком виде нужно реализовать функцию.

Неправильно	Правильно
«Я как пользователь хочу иметь возможность добавить товар в избранное, чтобы не забыть его купить».	«Я как пользователь хочу иметь возможность добавить товар в избранное, чтобы возвращаться к нему, не переходя в каталог». «Я как пользователь хочу получать напоминания о понравившемся товаре, чтобы не забыть его купить».

• Несоответствие INVEST-критериям: например, слишком или недостаточно подробная пользовательская история.

Неправильно	Правильно
«Я как Петя хочу авторизоваться в приложении посредством своей почты petya123@yandex.ru, чтобы иметь доступ к личному кабинету». «Я как пользователь хочу иметь возможность авторизоваться, чтобы иметь доступ к личному кабинету».	«Я как пользователь хочу иметь возможность авторизоваться по номеру телефона в мобильном приложении, чтобы иметь доступ к личному кабинету»

Инструменты для работы с User Story

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

Сегодня все то же самое можно делать онлайн. Для этого используют:

• сервисы для управления проектами: Jira, Trello;
• виртуальные доски: FigJam, Pruffme, Unidraw и др.

Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор Telegram-канала @ithumanwork:

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

Еще иногда используют доску Miro или ее аналоги. Это тоже инструмент с достаточно простым интерфейсом. Там можно составить карту пользовательских историй, а затем внести ее в Jira».

Советы по улучшению User Story

Чтобы ваши User Story всегда были точными и актуальными:

• Составьте User Story Map

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

Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор Telegram-канала @ithumanwork:

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

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

• Напишите критерии приемки

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

Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор Telegram-канала @ithumanwork:

«Критерии приемки позволяют проверить, правильно ли работает User Story. Например, наша пользовательская история звучит так: “Я как пользователь хочу иметь возможность авторизоваться посредством своего номера телефона, чтобы посмотреть уроки в приложении”. Тогда самый простой критерий приемки — возможность ввести номер телефона и пройти авторизацию. 

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

• Пересматривайте бэклог

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

Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор Telegram-канала @ithumanwork:

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

Примеры пользовательских историй 

User Story всегда зависит от конкретного продукта. Например, в сфере B2B часто можно выделить конкретного пользователя:

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

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

«Я как пользователь хочу видеть краткое описание каждого товара в каталоге (производитель, габариты, материал), чтобы понимать, какие карточки мне изучить подробнее».

Отличительная особенность мобильных приложений в том, что они предоставляют пользователю быстрый доступ из любой точки. Это тоже будет отражено в User Story:

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

Главное о User Story

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

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

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