User Story — как писать и зачем использовать

Зачем использовать User Story

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

• помогает понять пользователя, его потребности;
• обозначает ценность приложения и его параметров;
• помогает расставить приоритеты в задачах.

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

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

User Story в отделе продаж

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

User Story следует применять и в других ситуациях. Например, один из вариантов использования User Story: собирать мнения клиентов и улучшать продукт. Допустим, в компанию звонит клиент и говорит, что ему не хватает возможности получать уведомления из приложения на почту.

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

В отделе продаж User Story становится ключевым инструментом для формирования глубокого понимания клиентов, улучшения коммуникации между отделами и повышения эффективности продаж.

User Story в отделе PR

В сфере PR User Story используют для демонстрации продукта. Пользовательские истории помогают вызвать эмоциональный отклик у аудитории, так как с их помощью удается продемонстрировать прогресс работы над продуктом.

Есть и другие задачи, которые решает User Story в сфере PR:

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

2. Подчеркивает ключевые моменты и достижения бизнеса. С помощью создания User Story о разработанных функциях, можно построить PR-кампанию продукта.

3. Помогает укрепить бренд, User Story лучше выделяет уникальные черты и ценности компании. Рассказывая о бренде через призму пользовательских историй, вы создаете прочные связи с покупателями.

User Story как инструмент для увеличения ценности продукта

User Story помогает определить, в чем ценность продукта для клиентов. На эту же задачу направлен другой инструмент — JTBD — «Jobs to be done». Это фреймворк, который позволяет понять, какие  возможности продукта решают проблему пользователя.

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

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

При написании User Story делают акцент на определенных этапах разработки, которые связаны с конкретными задачами. JTBD охватывает весь процесс взаимодействия пользователя с продуктом, начиная от возникновения проблемы и заканчивая ее решением.

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

Важно использовать User Story и JTBD на этапе тестирования продукта. User Story помогает создать сценарии для его тестирования, а JTBD — проверить, насколько продукт действительно решает задачи пользователей.

User Story в Agile

Что такое Agile? Это гибкое управление проектами посредством разделения их на несколько этапов — спринтов. User Stories используют в Agile подходах, чтобы определить важные характеристики продукта для клиентов. Принципы Agile направлены на удовлетворение потребностей пользователей, а для этого нужны User Story: они помогают разобраться в желаниях пользователей.

User Stories в рамках мышления Agile также помогают сократить время на создание продукта. Вместо многостраничных документов с требованиями к программному обеспечению, команда разработчиков описывает понятные пользовательские истории, обсуждает их. Это экономит время.

Причем истории можно применять в нескольких методиках Agile: Kanban или Scrum. Kanban — это способ постановки задач на канбан-доске, который помогает визуализировать процесс работы.

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

Чтобы решить, какой функционал разрабатывать прежде всего, в Kanban и Scrum используют истории пользователей.

Критерии User Story

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

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

Пользовательская история должна быть:

1. Independent — независимой. Не нужно смешивать вместе сразу весь функционал — это основное правило формулировки User Story. Независимость истории указывает на то, что она должна описывать только одну функцию. В примере ниже история слишком обширная.

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

✔️ Как пассажир, я хочу выбирать такси разного класса в приложении.

✔️ Как пассажир, я хочу подключать разные способы оплаты.

✔️ Как пассажир, я хочу бронировать поездку заранее.

2. Negotiable — обсуждаемой. Сотрудники обсуждают User Story, чтобы доработать текст и передать в отдел разработки актуальную информацию о нужных параметрах.

3. Valuable — ценной. User Story должна нести ценность продукта или его функции. Значимость выполнения истории указывают в самом конце. В плохой пользовательской истории ценность равна действию пользователя. Например, я хочу вызвать такси, чтобы вызвать такси. В этом примере есть действие, но нет ценность истории.

✔️ Как пассажир, я хочу выбирать такси разного класса в приложении, чтобы выбирать уровень комфорта.

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

✔️ Как пассажир, я хочу бронировать поездку заранее, чтобы быть уверенным, что получу машину к определенному времени.

4. Estimable — оцениваемой. Каждую User Story необходимо оценивать, чтобы понять, сколько ресурсов и времени потратим на разработку, сколько нужно сотрудников, денег. Давайте оценку историям до того, как запустить их в работу.

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

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

• Пользователь выбирает один из пяти классов автомобилей в приложении.
• Приложение показывает стоимость поездки для каждого класса авто.
• В приложении можно выбрать конкретную марку авто.

Как формулировать User Story

Чтобы писать User Stories, выполняют шесть шагов:

1. При создании User Story изучают целевую аудиторию, создают описание пользователя. Для составления User Story уделяют внимание пожеланиям клиентов, поэтому их потребности важно изучать. Для создания хороших User Stories проводят опросы и исследования целевой аудитории.

2. При подготовке истории прописывают эпики. Эпик — это описание более крупных параметров, чем в пользовательских историях. То есть эпик может состоять из нескольких историй. Например, как пассажир, я хочу выбирать такси разного класса в приложении, смотреть их стоимость и писать комментарии водителю. Здесь три истории, которые собраны в эпик.

3. Разбивают эпики на User Story, выбирая, какие истории важнее всего. Например, в нашем примере выше получается три пользовательские истории.

✔️Как пассажир, я хочу выбирать такси разного класса в приложении.

✔️Как пассажир, я хочу смотреть стоимость такси разного класса.

✔️Как пассажир, я хочу писать комментарии водителю.

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

5. Визуализируют работу с User Story. Для этого часто используют канбан-доски, диаграмму Ганта.

6. Проверяют результат по критериям приемки и тестируют продукт.

Шаблон User Story

Написать историю легко с помощью шаблона User Stories, который складывается из нескольких частей:

1. Роль или категория пользователей — «Как»

2. Действие — «Я хочу»

3. Ценность — «Чтобы»

Как пользователь приложения, я хочу быстро регистрироваться через VK, чтобы сэкономить время на регистрацию.

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

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

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

Подытожим: что такое User Stories и зачем их использовать

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

2. User Story (пользовательская история) помогает определить потребности клиента. Остальные задачи, решаемые User Stories: разработка гипотез о пожеланиях пользователей по функциональности продукта, приоритезация задач.

3. User Stories используют не только для разработки программ, но и для того, чтобы выстраивать стратегию развития продукта. Этот инструмент может служить мостом между отделами продаж и разработки, так как он помогает изучить вопросы и пожелания клиентов.

4. User Story может быть использована в Agile. Например, в методике Scrum, которая основана на работе спринтами. В этом случае команда разработчиков составляет бэклог — список задач, и сотрудники по очереди их выполняют. В течение одного цикла — две-три недели — команда работает над одним параметром. Чтобы установить, какой функционал нужно запустить в первую очередь, работают с User Stories: истории пишутся и обсуждаются.

5. User Stories должны соответствовать шести критериям: быть независимыми, ценными, обсуждаемыми, поддающимися оценке, маленькими, тестируемыми. Это нужно учесть при написании истории. Данные критерии называют INVEST, это аббревиатура от названия каждого критерия.

6. Каждая User Story формулируется по шаблону: «Роль или категория пользователей — “Как” + Действие, “Я хочу” + Ценность, “Чтобы”».

Можем сделать вывод, что User Story — это инструмент, помогающий описать потребности клиентов. Кто-то считает истории полезным инструментом, который можно использовать только в разработке, но это не так. Истории нужно внедрять в дизайне, производстве товаров, отделах продаж и в сфере PR, чтобы доносить ценность продукта до целевой аудитории. Чтобы писать истории, исследуют пожелания клиентов: проводят опросы, интервью. Создание User Story происходит по шаблону.