Автор статьи
Чтобы сделать действительно хороший продукт, нужно не только писать код, но и понимать потребности своих пользователей. Для этого в разработке используют User Story — небольшие истории, описывающие желания и действия пользователя с точки зрения его потребностей.
Что такое User Story
Пользовательская история (User Story) — это инструмент, который используется в разработке для описания функций программного обеспечения с точки зрения конечного пользователя.
Её пишут простым, понятным языком, чтобы разработчики и другие члены команды понимали, зачем нужна эта функция и как она поможет пользователю.
User Story выражается в формате:
Как [роль пользователя], я хочу [выполнить конкретное действие], чтобы [достичь какой-то цели]
Стандартная пользовательская история — это короткое предложение, в котором указаны пользователь, функция и ожидаемый результат.
Читайте также: «Геймификация в бизнесе: как вовлекать клиентов через игру»
Для чего применяются User Stories
Пользовательские истории — помогают команде смотреть на продукт с точки зрения конечного пользователя и не упускать его из виду из-за многочисленных операционных процессов. Они помогают ориентироваться в проекте, определять какие задачи делать в первую очередь и разбивать их на более мелкие части.
Их цель — показать, чем функция программы полезна для пользователя. Разберемся, зачем нужны пользовательские истории и чем они полезны.
Для команды разработчиков:
- Понимание целей. Помогают команде разработчиков четко понять цели продукта и его функциональность с точки зрения пользователя.
- Сосредоточенность на задачах. Делят разработку на короткие, понятные задачи. Это облегчает планирование, реализацию и контроль над проектом.
- Коммуникация. Используют простой язык, понятный всем членам команды. Это улучшает коммуникацию и сотрудничество.
- Гибкость. Помогают команде адаптироваться к новым требованиям, потому что пользовательские истории легко изменять и дополнять по мере развития проекта.
Для заказчика:
- Понимание продукта. Помогают заказчику лучше понять, каким будет продукт и как он будет удовлетворять его потребности.
- Влияние на продукт. Заказчик может участвовать в создании пользовательских историй и влиять на изменения в продукте.
- Оценка прогресса. Помогают заказчику следить за ходом разработки и оценивать прогресс.
- Управление рисками. Создание и обсуждение пользовательских историй на ранних этапах позволяет выявить и минимизировать риски.
Недостатки пользовательских историй
Выше мы рассказывали о пользе пользовательских историй, а теперь разберем их недостатки.
- Меньше внимания к важным деталям. Пользовательские истории фокусируются на функциональных требованиях и из-за этого могут упускать важные нефункциональные требования, например, производительность, безопасность, долговечность и т.д.
- Сложности в больших проектах. Пользовательские истории просты и сосредоточены на одной функции. Когда проект становится сложнее, таких историй становится слишком много, и управлять ими становится сложнее.
- Недостаточное количество деталей. Пользовательские истории описывают действия без деталей, это может привести к разным интерпретациям в команде. Без обсуждения деталей это часто приводит к ошибкам в разработке продукта.
Читайте также: «10 идей для рилс»
Как формулировать User Story
Пользовательскую историю можно создавать разными методами. Давайте разберем основные среди них.
Создание User Story по методу 3W
Разработать хорошую пользовательскую историю — просто. Главное иметь в виду при ее составлении: кто (who), что (what) и почему (why) использует конкретную функцию. Эти три «W» создают прямую связь между ролью, функцией и пользой, необходимой пользователю.
Кто (Who)
В пользовательских историях этот вопрос обычно относится к любому, кто может взаимодействовать с продуктом. В список могут входить существующие и потенциальные клиенты, владельцы бизнеса, сотрудники
Подумайте, на кого повлияет эта функция и задайте себе и команде вопросы, чтобы определить пользователя:
- Для кого мы создаем эту функцию? Например, для менеджеров, дизайнеров, маркетологов.
- Какие функции продукта ему нужны? Например, возможность создавать отчеты, планировать задачи, анализировать данные.
- Какие основные характеристики у пользователя? Например, возраст, профессия, уровень владения технологиями.
В одной истории может быть несколько персонажей, особенно, если ваша целевая аудитория разнообразна. В этом случае нужно ответить на эти же вопросы, только для каждого персонажа.
Что (What)
Определите, чего ждет каждый пользователь.
Создавайте короткие пользовательские истории без подробных описаний по типу: одна история → одно действие.
При изучении целей конечного пользователя учитывайте вопросы:
- Чего хочет добиться пользователь с помощью этой функции? Например, упростить работу с данными, быстрее выполнять задачи, улучшить коммуникацию с коллегами.
- Как новая функция поможет пользователю достичь своих целей? Например, упростит процесс передачи данных, даст возможность переписываться прямо под задачами.
Важно сосредоточиться не на технических деталях, а на реальной пользе для пользователя.
Почему (Why)
Это касается конечной ценности продукта, которую получит пользователь. Это последний вопрос, на который нужно ответить.
Подумайте, как новая функция вписывается в общую картину развития продукта, и как она поможет достичь ваших целей.
Задайте вопросы:
- В чем ценность этой функции? Например, повышает ли она производительность, улучшает ли пользовательский опыт, делает ли продукт более привлекательным.
- Какую проблему решает эта функция? Например, решает ли она проблему с неэффективным обменом информацией, устраняет ли проблему с неудобным интерфейсом.
Цель — определить, насколько важна эта функция для достижения общих целей проекта.
Создание User Story по методу 3C
Рон Джеффрис, один из создателей XP, предложил практический подход к работе с историями, который расширяет метод 3W. Его метод основан на трех элементах, которые начинаются с буквы «С». Он фокусируется на трех этапах ее разработки.
Карточка (Card)
Это описание юзер-стори из 1−2 предложений, которое содержит цель и краткую информацию о более детальных требованиях.
Раньше эти описания создавали на стикерах от руки, а сейчас — в специальных программах. Обычно для этого используют таск-менеджеры и собирают карточки на одной доске. Так получается user story map или карта пользовательских историй.
С помощью карточек удобно планировать работу. На них можно добавлять краткие заметки: приоритет, примерную стоимость
Не пишите в карточке все детали — только самое важное, чтобы обозначить задачу и дать команде общее понимание цели.
Когда пользовательская история готова к реализации, карточку передают разработчикам.
Читайте также: «Как в разы поднять конверсию сайтов и приложений»
Обсуждение (Conversation)
Карточка — только начало. Для создания истории нужно провести детальное обсуждение с разработчиками, чтобы все понимали задачу и ее нюансы.
Коммуникация — важный момент работы с пользовательскими историями. На этом этапе команда обсуждает детали истории, уточняет требования и стремится к общему пониманию.
Обсуждения начинаются с оценки истории на ранних этапах планирования и заканчиваются детальным разбором, когда она берется в работу.
В процессе коммуникации:
- Уточняются детали юзер-стори. Какие действия должен выполнять пользователь, какие данные ему необходимы, какие ограничения нужно учитывать.
- Вырабатывается общее видение того, как история будет реализована.
- Обсуждаются подходы к тестированию и приемке истории.
Подтверждение (Confirmation)
Даже после всех обсуждений могут оставаться вопросы, верно ли вы понимаете задачу. Чтобы убедиться, что все сделано правильно, нужно все проверить и подтвердить.
Подтверждение или критерии приемки — это набор условий, которые должны быть выполнены, чтобы юзер-стори считалась завершенной. Это своего рода «доказательство», что история соответствует требованиям заказчика.
Критерии приемки обычно составляет владелец продукта, но они могут уточняться и дополняться в процессе планирования командой.
Разработчики используют эти критерии для создания приемочных тестов. После завершения разработки получившийся продукт должен успешно пройти все тесты. Это подтвердит, что продукт реализован правильно.
Цель разработчиков — показать, что продукт проходит все критерии и этапы приемки.
Что можно использовать в качестве критериев:
- Тесты. Автоматизированные или ручные для проверки функциональности юзер-стори.
- Документация. Как пользовательская история работает, какие данные и алгоритмы используются.
- Демонстрация. Как юзер-стори функционирует в реальной среде.
Когда все три «С» пользовательской истории выполнены, функция считается завершенной и может быть запущена.
Пример:
- 3W: Как пользователь (Who), я могу добавить товар в корзину (What), чтобы оформить заказ (Why).
3C:
Карточка: Как пользователь я могу добавить товар в корзину, чтобы оформить заказ.
Коммуникация: Обсуждается, как пользователь будет добавлять товар в корзину (кнопка, форма), какие типы товаров будут поддерживаться, как будет выглядеть корзина, как пользователь может удалить товары из корзины
Подтверждение:
- Добавленный в корзину товар отображается в списке.
- Пользователь может удалить товар из корзины.
- Корзина сохраняется между сессиями.
Критерии INVEST
Хорошая пользовательская история должна соответствовать 6 критериям.
INVEST — это набор принципов, которые помогают создавать эффективные и ценные пользовательские истории.
INVEST расшифровывается:
- I — Independent (Независимые). Каждая история должна быть независимой от других. Это значит, что ее можно разрабатывать и тестировать отдельно, не влияя на другие истории.
- N — Negotiable (Обсуждаемые). Пользовательские истории нужно обязательно обсуждать и, если понадобится, корректировать. Важно, чтобы все участники проекта могли внести свои предложения.
- V — Valuable (Ценные). Каждая история должна приносить реальную ценность пользователю. Она должна решать конкретную проблему или улучшать определенный элемент продукта.
- E — Estimable (Оцениваемые). Хорошую историю можно оценить с точки зрения времени и ресурсов, необходимых для ее реализации.
- S — Small (Маленькие). История должна быть краткой и емкой. Большие истории сложно оценить и они требуют больше ресурсов на разработку.
- T — Testable (Тестируемые). Истории должны быть тестируемыми — иметь четкие критерии приемки, чтобы можно было проверить правильность реализации.
Epic user story
Помимо обычных user story бывают epic user story.
Это общая пользовательская история, которая описывает широкий функционал или набор функций, которые нужно реализовать в продукте.
Пример:
Как пользователь, я хочу планировать путешествия, чтобы найти идеальные варианты по доступной цене
Epic можно разбить на несколько обычных user stories:
- Как пользователь, я хочу создать профиль путешественника, чтобы указать свои предпочтения.
- Как пользователь, я хочу ввести критерии поиска (дата, место, бюджет), чтобы найти варианты путешествий.
- Как пользователь, я хочу сравнить предложения от разных туроператоров, чтобы выбрать лучший вариант.
Примеры user story
Напоминаем — user story должна быть написана в формате:
Как [роль], я хочу [действие], чтобы [результат].
Это позволит вам создавать понятные истории, которые будут легко восприниматься всеми членами команды.
Рассмотрим несколько примеров пользовательских историй.
Для приложения по доставке еды.
Epic: Как пользователь, я хочу легко заказывать любимую еду из разных ресторанов, чтобы получить вкусный обед или ужин, не выходя из дома.
User Story:
- Как пользователь, я хочу создать аккаунт, чтобы заказывать еду из любимых ресторанов.
- Как пользователь, я хочу добавить продукты в корзину, чтобы сделать заказ.
- Как пользователь, я хочу получить уведомления о статусе моего заказа, чтобы знать, когда ждать доставки.
- Как пользователь, я хочу оставить отзыв о заказе, чтобы поделиться своим опытом.
- Как пользователь, я хочу отслеживать историю своих заказов, чтобы видеть, что я заказывал ранее.
Для онлайн-магазина.
Epic: Как пользователь, я хочу легко находить и покупать нужные мне товары онлайн, чтобы сэкономить время и покупать товары в комфорте.
- Как пользователь, я хочу просматривать каталог товаров, чтобы найти интересующие меня продукты.
- Как пользователь, я хочу добавить товары в корзину, чтобы сделать заказ.
- Как пользователь, я хочу получить информацию о доставке и оплате, чтобы убедиться, что заказ оформлен правильно.
- Как пользователь, я хочу отслеживать статус заказа, чтобы знать, когда ждать доставки.
- Как пользователь, я хочу вернуть товар, если он мне не подошел.
Для приложения для обучения.
Epic: Как студент, я хочу получить доступ к качественному образовательному контенту и инструментам, чтобы эффективно учиться и развивать свои знания и навыки.
- Как студент, я хочу просматривать список курсов, чтобы найти подходящий для меня.
- Как студент, я хочу смотреть видеоуроки, чтобы учиться новому.
- Как студент, я хочу проходить тесты и получать обратную связь, чтобы проверить свои знания.
- Как студент, я хочу общаться с преподавателем, чтобы получить помощь с уроками.
Главные мысли
- Пользовательские истории пишут простым языком, чтобы члены команды понимали, зачем нужна эта функция и чем она поможет пользователю. Они помогают команде смотреть на продукт глазами конечного пользователя. В отличие от ТЗ, юзер-стори легко изменять и дополнять по мере развития проекта.
- Метод 3W помогает новичкам сформулировать хорошую юзер-стори.
- Метод 3C охватывает весь жизненный цикл пользовательской истории и помогает понять ее цель.
- Критерии INVEST помогают создавать эффективные пользовательские истории.
- Чтобы описать широкий набор функций, которые нужно реализовать в продукте, используют epic user story, которые также охарактеризовывают функционал продукта в одном предложении. Но для детализации эпики разбивают на отдельные юзер-стори.
И напоследок: подписывайтесь на телеграм-канал Awake Journal 🔥 Там вы найдете анонсы новых статей о маркетинге, разработке и управлении, чтобы узнать, как эффективнее развивать ваш бизнес в digital ❤️
на журнал
