User Story — инструкция по применению
Как правильно формулировать пользовательские истории? Третья статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
→ Аудио-версию этой статьи вы можете прослушать на канале Listen IT
User Story (пользовательская история) — короткая формулировка намерения пользователя и того, что продукт должен сделать для него.
Для чего применяется User Story?
- Для описания элементов бэклога
- Для лучшего понимания пользователей
- Для описания требований к продукту на понятном для всех языке: пользователей, разработчиков другие заинтересованных лиц
- Для вовлечения в процесс разработки пользователей и заинтересованных лиц
- Для построения User Story Mapping
Как формулировать User Story?
User Story — это ответы на 3 вопроса, связанные в одно предложение:
- Что это за пользователь?
- Какое действие он хочет выполнить в продукте или какой результат от продукта хочет получить?
- Зачем это ему?
Как <роль или тип пользователя>,
я хочу/могу <выполнить действие или получить результат>,
чтобы <получить ценность>
Еще 50 инструментов для владельца продуктаОписания продуктовых практик и подходов, сгруппированные по 7 темам
Темы: анализ рынка, сегментация, описание и исследование клиентов, проектирование решений, управление бэклогом, управление продуктом, метрики.
Примеры пользовательских историй
И ещё немного примеров:
Как <пользователь соцсети>, хочу <видеть в ленте только позитивные посты>, чтобы <не портить себе настроение>
Как <гипертоник>, я хочу <нормализовать давление на весь день>, чтобы <не измерять его в течение дня>
Как видно из примеров, ценность User Story как инструмента в том, что он очень универсален — вы можете использовать для лучшего понимания пользователей в абсолютно любой сфере.
Хорошая пользовательская история
INVEST — критерий хорошей истории:
Independent — независимая от других историй, то есть истории могут быть реализованы в любом порядке
Negotiable — обсуждаемая, отражает суть, а не детали; не содержит конкретных шагов реализации
Valuable — ценная для клиентов, бизнеса и стейкхолдеров
Estimable — оцениваемая по сложности и трудозатратам
Small — компактная, может быть сделана командой за одну итерацию
Testable — тестируемая, имеет критерии приемки
Эти критерии не всегда достижимы, но чем больше историй будут им удовлетворять, тем более гибким будет ваш процесс разработки продукта.
Мы учим формулировать User Story на тренинге «Владелец продукта: краткий курс выживания».
P.S.: Серию статей про продуктовые инструменты Роман Баранов и Дмитрий Кустов пишут, используя технику pair writing.
Подключайтесь к Telegram-каналу, где мы делимся практиками и опытом.
Представьте, что инопланетяне хотят создать продукт для людей, который изменит их жизнь. Проблема в том, что они никогда не взаимодействовали с нами, а только наблюдали издалека. В нашем мире важно познакомиться с клиентами, понять их потребности и предложить решения — для этого существует подход кастдев (customer development, CustDev). В статье я объясню, что такое кастдев, как его проводить и какие этапы важны, а в конце приведу пример компании Dropbox, которая вовремя изучила обратную связь от пользователей и запустила классный продукт, который действительно нужен людям.
Рассказываем, что такое продуктовая Гемба и как этот метод помогает создавать лучшие продукты, а также делимся пошаговым гайдом, чтобы реализовать его на практике
Какие навыки необходимы Владельцу Продукта на старте, какие компетенции понадобятся для дальнейшего роста в профессии, и можно ли освоить их самостоятельно