Анализ данных • 25 апреля 2023 • 5 мин чтения
User Story помогает описать функции продукта, которые нужны пользователю. Рассказываем, как освоить инструмент самостоятельно и начать применять его в работе.
Понятие User Story
User Story, или пользовательская история, помогает увидеть функции продукта глазами конечного потребителя. Основную часть User Story пишут кратко, без технических деталей и лишних подробностей. Главное — сделать фокус на целях и потребностях людей.
В основной части User Story обычно указывают:
● категорию, к которой относится пользователь;
● действие, которое он или она хотели бы совершить;
● результат, который ожидает получить пользователь после действия.
В историю обязательно включают критерии приёмки — условия, которые должны быть выполнены, чтобы история считалась завершённой.
Например, сотрудники компании «Лапки Солюшнз» разрабатывают приложение для хозяев домашних животных. Пользовательская история для будущего приложения может выглядеть так: «Из-за работы я постоянно в разъездах. Как хозяин кота, я хочу иметь приложение, которое позволит видеть моего питомца, чтобы я мог убедиться, что он выглядит счастливым и здоровым».
Для чего применяются User Stories
Пользовательские истории помогают увидеть ценность функций продукта и решить несколько задач:
1. Разложить требования на понятные и выполнимые элементы
Пользовательские истории обычно описывают не продукт целиком, а отдельные его функции. Так проще подойти к решению большой задачи. Например, разработка приложения для людей с питомцами может состоять из нескольких задач:
● Разработать безопасные и удобные регистрацию и вход в приложение.
● Спроектировать опцию создания профиля, в котором можно указать породу питомца, кличку, возраст и прививки.
● Придумать, как отслеживать активность домашнего животного.
Так работает декомпозиция: сложное задание легче выполнить, если разделить его на задачи попроще. Каждую из них потом можно описать в формате User Story.
2. Упростить оценку ресурсов для разработки
Когда требования в виде критериев приёмки описаны по одной структуре, задачи легче сравнивать между собой. Так можно оценить, насколько они сложные и сколько времени могут занять.
3. Добавить ясности всей команде
С помощью пользовательских историй коллеги могут обсудить, как будет выглядеть продукт, для кого его разрабатывают и зачем. Основную часть User Story пишут простым языком, поэтому её поймут и разработчики, и менее технически подкованные участники команды.
Научиться использовать User Story для формализации требований к продукту можно на курсе «Бизнес-аналитик». За восемь месяцев студенты научатся исследовать потребности пользователей, описывать процессы и просчитывать эффект от изменений в продукте. Чтобы начать учиться, необязательно иметь опыт в IT и уметь программировать.
Попробуйте себя в роли бизнес‑аналитика
Научитесь проводить интервью и описывать бизнес‑процессы. Пройдите бесплатную вводную часть курса.
Плюсы и минусы пользовательских историй
Как формулировать User Story
Пользовательская история состоит из нескольких частей. Разберём, как писать каждую часть User Story.
Основная часть User Story
Основную, самую лаконичную часть пишут по шаблону.
Так выглядит классический шаблон User Story. Иногда в компаниях меняют его или придумывают собственный
При работе с классическим шаблоном важно придерживаться двух правил:
1. Определить, кто будет использовать продукт и с какой целью. Целью может быть конкретная проблема или задача, которую пользователи хотят решить, или информация, к которой хотят получить доступ. Например, сотрудники «Лапки Солюшнз» провели исследование и выяснили, что хозяевам питомцев важно знать, что их любимцы каждый день съедают необходимое количество корма и пьют достаточно воды.
2. Описывая действие, которое хотел бы совершить пользователь, важно не переборщить с подробностями. Не стоит писать: «Я, как владелец животного, хотел бы получать регулярные пуш-уведомления, в которых будет информация о том, когда я последний раз кормил питомца, и напоминание, что скоро нужно покормить его снова». Обилие деталей мешает увидеть альтернативное решение. Лучше вообще избегать названий элементов интерфейса в истории.
Критерии INVEST для User Story
Написанную User Story можно оценить по шести критериям INVEST, которые сформулировал консультант и директор по развитию продукта Билл Уэйк.
Критерии INVEST помогают убедиться, что история получилась качественной и полезной. Их знание часто проверяют на собеседованиях бизнес-аналитиков
● Independent (с англ. «независимый»). В пользовательской истории лучше описывать одну или несколько независимых функций. Они должны решить проблему пользователя без помощи других инструментов. Например: «Как хозяин домашнего животного, я хочу иметь возможность записывать визиты к ветеринару, чтобы следить за здоровьем питомца и не пропускать приёмы». В этой истории описан минимум функций, которые нужны пользователю: приложение должно уметь создавать встречи с ветеринаром и напоминать о них. Эти функции не зависят от других опций и свойств приложения, поэтому их можно разработать и протестировать самостоятельно.
● Negotiable (с англ. «подлежащий обсуждению»). User Story обязательно нужно обсудить в команде и внести изменения, если потребуется. Без обсуждения есть риск, что команда разработки получит неполное представление о задаче.
● Valuable (с англ. «ценный»). В функции, которую описывает User Story, должна быть реальная ценность для пользователя. Например, возможность следить за здоровьем питомца и планировать посещение ветеринара.
● Estimable (с англ. «поддающийся оценке»). Хорошую User Story можно оценить — понять, сколько времени, ресурсов и денег займёт разработка функции.
● Small (с англ. «маленький»). История должна быть краткой и ёмкой. Объёмные истории сложнее оценить, и они могут потребовать больше ресурсов на разработку.
● Testable (с англ. «поддающийся тестированию»). С критериями приёмки команде разработки будет проще создать нужную функцию. Тестировать историю лучше за один раз — это ещё одна причина, почему в истории не должно быть много деталей.
Критерии приёмки и ограничения
Критерии приёмки добавляют независимо от формата User Story — это условия, которые должны быть выполнены, чтобы история считалась завершённой. Критерии приёмки в User Story — это требования к системе, которые помогают разработчикам создавать нужные функции.
Сотрудники «Лапки Солюшнз» поняли, что пользователи хотят следить за питанием своих животных. Для этой пользовательской истории возможно несколько критериев приёмки:
● Пользователь может добавлять информацию о питании своего питомца, включая тип корма, его количество и время суток.
● Приложение показывает, сколько корма питомец съел за день.
● Приложение позволяет устанавливать и отслеживать цели по питанию, включая ежедневные и еженедельные показатели.
Так выглядит общая формулировка критериев приёмки для User Story. Существуют разные способы их описания — глубина и подробность зависят от потребностей команды.
Ограничения показывают, как и в чём ограничены возможности продукта или функции. Они определяют, что невозможно, не разрешено или не может быть сделано в рамках конкретной истории.
Например, у функции для управления питанием животных могут быть такие ограничения:
● Приложение не позволяет загружать фото корма.
● Приложение не может автоматически корректировать рекомендации по приёму пищи на основе изменений веса или уровня активности питомца.
Примеры пользовательских историй
Использовать User Story можно не только в разработке приложений для хозяев домашних животных. Инструмент подойдёт разным продуктам: от программного обеспечения для космических спутников до сервисов доставки еды.
Сравним несколько примеров написания User Story из разных сфер.
❌ Нет | ✅ Да |
|---|---|
Как пользователь, я хочу, чтобы приложение меньше зависало. | Как пользователь, который часто пользуется приложением по работе, я хочу, чтобы при зависании системы несохранённые файлы не терялись.
Что улучшили: никто не рад, когда приложения зависают, но лучше прояснить боль пользователя. |
Я, как посетитель кафе, хочу, чтобы продукты, вызывающие аллергию, отмечали специальными цветами в меню, например молочные продукты синим, а орехи коричневым, чтобы мне было проще выбрать блюдо. | Как человек с пищевой аллергией, я хочу, чтобы опасные ингредиенты были выделены в меню. Так мне будет проще выбрать подходящее блюдо.
Что улучшили: убрали лишние детали. Конкретные цвета или элементы интерфейса стоит выбирать во время обсуждения User Story в команде. |
Как пользователь, я хочу общаться с друзьями, чтобы оставаться с ними на связи. | Как активная пользовательница соцсетей, я хочу пользоваться персонализированной лентой новостей, основанной на моих интересах и взаимодействии с друзьями, чтобы я не пропустила то, что для меня важно.
Что улучшили: учли критерии INVEST — в User Story важно описывать функцию, которую можно разработать и протестировать. |
Как офисная сотрудница, я хочу полноценно питаться на работе, чтобы быть здоровой. | Как офисная сотрудница, я хочу иметь возможность заказывать полезную еду в офис, чтобы правильно питаться, когда у меня мало времени.
Что улучшили: проблеме не хватало конкретного решения — что именно поможет пользователю правильно питаться. |
Советы эксперта по написанию пользовательской истории
1. Фокусироваться на преимуществах для пользователя. Бывает, что в User Story описывают только функциональность системы, а о том, зачем это пользователю, забывают. Нужно обязательно добавить результат или ценность для пользователя — обычно это часть с союзом «чтобы». Например, «как пользовательница соцсетей, я хочу планировать публикации на будущие даты, чтобы я могла создавать контент в соцсетях в удобное время». Так каждый член команды поймёт, зачем разрабатывают ту или иную функцию.
2. Создавать небольшие и выполнимые User Story. Не стоит писать объёмные истории, которые потребуют много времени для разработки. Допустим, сервису нужен личный кабинет. Для такой большой задачи пишут несколько небольших историй. В них можно описать, что пользователь хотел бы иметь возможность войти в свой личный кабинет или написать в службу поддержки, если войти не получилось.
3. Добавлять детали в критерии приёмки. В пользовательской истории описание будущих функций продукта должно быть общим, без деталей дизайна и разработки, например: «Как пользователь, я хочу быстро найти кнопку на главной странице, которая позволит мне зарегистрироваться на сайте». Все уточнения вносят в критерии приёмки во время обсуждения User Story в команде.
Если не получится сразу следовать всем советам, не страшно. Опыт и насмотренность позволят делать User Story понятнее и эффективнее для продукта. Первое время лучше держать в голове критерии INVEST: кратко формулировать истории, выражать ценность для пользователя, создавать истории, которые можно оценить и протестировать.
Статью подготовили:
Ольга Мазур
Яндекс Практикум
Автор курса «Бизнес-аналитик», Head of Business Analysis Samokat.tech
Автор курса «Бизнес-аналитик», Head of Business Analysis Samokat.tech
Виктория Воробьёва
Яндекс Практикум
Редактор
Редактор
Полина Овчинникова
Яндекс Практикум
Иллюстратор
Иллюстратор
Дайджест блога: ежемесячная подборка лучших статей от редакции
Читать также:
