журналист, редактор, копирайтер
User Story — один из ключевых инструментов в проектной и продуктовой разработке. C их помощью можно определить, чего на самом деле хочет пользователь, и сделать действительно классный продукт. Совместно с экспертом Эйч Ларисой Дансаруновой разбираем, как писать пользовательские истории и каких ошибок следует избегать.
Что такое User Story
Пользовательская история — это способ написания требований к продукту, который используют в разработке ПО.
Обычно User Story состоит из трех частей:
- роль (кто): пользователь продукта;
- цель (что): действие, которое хочет совершить пользователь;
- результат (зачем): что он хочет получить в итоге.
Например: «Как [клиент салона красоты], я хочу [иметь возможность записаться на стрижку через мобильное приложение], чтобы [мне не пришлось звонить]».
В рамках одного продукта можно написать много разных user story. А если у сервиса есть разные пользователи, то нужно прописать истории отдельно для каждого.
Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор Telegram-канала @ithumanwork:
«Раньше для постановки задачи в команде разработки использовались более формальные и строгие способы, например ЧТ, ЧТЗ, SRS, BRD. User Story пришли как один из способов оставаться AGILE и поддерживать непрерывную разработку. И раньше всего начали использоваться в рамках продуктового подхода. Это короткие истории, которые помогают быстро реагировать на изменения и вносить правки в продукт».
Для тех, кто хочет попасть в IT без навыков кодинга, но с реальным опытом
Зачем нужны 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 разрабатывает и доставляет функцию до пользователя.
Еще на пользовательские истории могут влиять новые законы, требования от продакт-менеджера и стейкхолдеров. Перед тем как начать формулировать саму историю, важно понять, можем ли мы вообще это реализовать технически. Для этого необходимо проконсультироваться с разработчиками».
Делайте мир удобнее. Создавайте продуманные интерфейсы сайтов и приложений без навыков программирования. IT-компании ждут вас.
Ошибки в пользовательских историях
При написании юзер стори важно избегать распространенных ошибок.
- Неправильная формулировка «почему»: третья часть User Story должна отражать ценность для клиента, чтобы разработчики точно понимали, в каком виде нужно реализовать функцию.
| Неправильно | Правильно |
| «Я как пользователь хочу иметь возможность добавить товар в избранное, чтобы не забыть его купить». | «Я как пользователь хочу иметь возможность добавить товар в избранное, чтобы возвращаться к нему, не переходя в каталог». «Я как пользователь хочу получать напоминания о понравившемся товаре, чтобы не забыть его купить». |
- Несоответствие INVEST-критериям: например, слишком или недостаточно подробная пользовательская история.
| Неправильно | Правильно |
| «Я как Петя хочу авторизоваться в приложении посредством своей почты petya123@yandex.ru, чтобы иметь доступ к личному кабинету». «Я как пользователь хочу иметь возможность авторизоваться, чтобы иметь доступ к личному кабинету». | «Я как пользователь хочу иметь возможность авторизоваться по номеру телефона в мобильном приложении, чтобы иметь доступ к личному кабинету» |
Инструменты для работы с User Story
Первые User Story появились в экстремальном программировании и записывались на «пользовательских карточках». По сути, это были обычные стикеры. Каждый участник команды мог взять листок и записать свою идею. Потом эти карточки группировали на общей доске — они всегда были на виду и помогали в разработке продукта.
Сегодня все то же самое можно делать онлайн. Для этого используют:
Лариса Дансарунова, эксперт Эйч, наставник Яндекс Практикума, автор 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. Это помогает разделить большой проект на микрозадачи и улучшает коммуникацию в команде.
