Вебинары Разобраться в IT Реферальная программа
Программирование Аналитика Дизайн Маркетинг
05 Июн 2024
9 мин
224

User Story и как её написать: Полное руководство

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

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

Что такое User Story

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

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

Над IT-проектами работают очень разные специалисты. В том числе тестировщики, которые находят ошибки и неточности на сайтах и в приложениях. Если вы усидчивы и внимательны к деталям, обучиться на тестировщика будет гораздо проще. В онлайн-университете Skypro вам помогут получить базовые навыки для работы и найти место, где начнется ваша новая карьера.

Для чего нужны User Story

Пользовательские истории нужны, чтобы:

  • понимать потребности пользователей;
  • согласовывать работу разработчиков и заказчиков;
  • расставлять приоритеты при разработке продукта;
  • составлять план разработки (roadmap);
  • тестировать удобство продукта для пользователя;
  • оценить качество разработки;
  • подготовить техническое задание для подрядчиков.

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

User Story можно сформулировать так:

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

Когда пользовательская история сформулирована так, команда разработки понимает, из чего состоит запрос будущего клиента. На основе запроса формирует функции приложения:

➡️ Пользователь выбирает счет, с которого переведет деньги.
➡️ Пользователь выбирает счет, на который переведет деньги.
➡️ Пользователь вводит сумму перевода.
➡️ Пользователь добавляет описание или комментарий к переводу.
➡️ После перевода видит сообщение об успешной транзакции.
➡️ На телефон приходит уведомление, что перевод прошел.

Из этого функционала приложения команда разработки формирует свои задачи:

🟢 Разработать интерфейс выбора счетов отправителя и получателя.
🟢 Реализовать ввод суммы и описания перевода.
🟢 Интегрировать возможности, чтобы проводить транзакции.
🟢 Создать процесс, который выводит сообщения в приложении.
🟢 Настроить отправку уведомлений после перевода.

Так User Story помогает команде четко понять, что нужно реализовать и почему, и наметить конкретные шаги для достижения цели.

Бесплатные курсы и IT-профессии с нуля
Изучите актуальные инструменты и станьте кандидатом № 1 у работодателей.
Подробнее
Бесплатные курсы и IT-профессии с нуля

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

Сначала нужно определить, кто будет пользоваться конечным продуктом и какие у этой аудитории потребности. Для этого:

  1. Изучите рынок, на котором вы планируете продвигать продукты или услуги. Проанализируйте конкурентов и их клиентов.
  2. Соберите информацию о потребностях, предпочтениях и проблемах вашей целевой аудитории. Для этого используйте опросы, фокус-группы, интервью, аналитику данных.
  3. Разделите данные по сегментам: демографическим характеристикам (возраст, пол, доход), психосоциальным (интересы, ценности, образ жизни) и поведенческим (покупательское поведение, предпочтения).
  4. На основе данных сформируйте портреты целевой аудитории. Опишите их демографические характеристики, интересы, потребности и мотивацию покупать ваш продукт.

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

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

Можно использовать такой шаблон:

Как [тип пользователя], я хочу [функциональность], чтобы [цель/причина].

Например:

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

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

Критерии INVEST для User Story

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

Критерии User Story формулируют по принципу INVEST. Разберем каждый из них.

  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 Story для проектов

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

Гибкость и адаптивность

Пользовательские истории формулируют максимально коротко, поэтому их легко адаптировать под изменения на рынке.

Близость к пользователям

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

Простота обслуживания

Истории легко формулировать, использовать и менять. Работа с ними — это всегда про высокие скорости и удобство для команды.

Этапность работы

User Story помогают разбить проект на мелкие этапы, облегчают планирование проекта и управление им.

7 полезных советов по написанию пользовательской истории

Воспользуйтесь нашими советами, чтобы создавать эффективные и рабочие User Story.

1️⃣ Всегда ставьте себя на место пользователя. Используйте язык, который понятен вашей аудитории, и описывайте, что именно он хочет сделать и почему это важно.

2️⃣ Используйте формат «Как [пользователь], я хочу [функциональность], чтобы [цель]». Этот шаблон помогает структурировать историю и ясно выражать потребности пользователя и цель проекта.

3️⃣ Старайтесь сделать историю краткой и понятной. Она должна фокусироваться на одном аспекте функциональности вашего проекта.

4️⃣ Вовлекайте всю команду, когда пишете и уточняете User Story. Так все участники проекта будут хорошо понимать, что им нужно сделать.

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

6️⃣ Пользовательские истории не должны быть статичными. Регулярно пересматривайте и уточняйте их на основе обратной связи от команды и аудитории. Учитывайте изменение требований на рынке.

7️⃣ Дополнительно объясняйте контекст и мотивацию пользователя. Это помогает команде разработки лучше понимать, почему определенная функция важна для аудитории и как она вписывается в общий пользовательский опыт.

7 распространенных ошибок при составлении User Story

Вот семь распространенных ошибок и способы, как их избежать:

1️⃣ Слишком много деталей — перегруженная история с техническими деталями и узкой спецификой.

✅ Фокусируйтесь на описании потребностей пользователя, а технические детали оставляйте для обсуждения в команде.

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

2️⃣ Нет ценности для пользователя.

✅ При обсуждении старайтесь понять, что важно для команды, а что — для аудитории.

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

3️⃣ Слишком большие истории — и их невозможно реализовать в рамках короткого рабочего цикла.

✅ Разбивайте большие истории на более мелкие и управляемые, а глобальную цель держите в голове как основной ориентир.

Вместо «Как администратор, я хочу управлять всеми аспектами группы в социальной сети» пишите «Как администратор, я хочу добавлять новых пользователей в группу в социальной сети».

4️⃣ Непонятные критерии — команда не понимает, когда историю можно запускать в работу.

✅ Включайте в работу четкие и измеримые критерии для каждой User Story.

Добавьте к User Story «Как пользователь, я хочу видеть историю своих покупок» такие критерии:

  • История показывается в хронологическом порядке.
  • Покупки группируются по дате.

5️⃣ Фокус на реализации, а не на потребностях пользователя.

✅ Всегда держите во внимании, для кого вы делаете итоговый продукт.

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

6️⃣ Игнорирование совместной работы команды.

✅ Пишите истории так, чтобы в процессе участвовали все участники проекта. Проводите регулярные совместные встречи, чтобы обсуждать и уточнять детали историй.

7️⃣ Нет контекста.

✅ Включайте в историю объяснение, почему каждая функция важна для пользователя.

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

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

Главное о пользовательских историях

🟣 Пользовательская история, или User Story — это краткое описание функций или задачи с точки зрения конечного пользователя.
🟣 Пользовательские истории помогают команде разработки понять потребности пользователей, согласовать работу с заказчиками, приоритизировать задачи, составить план разработки, протестировать удобство продукта, оценить качество разработки и подготовить техническое задание для подрядчиков.
🟣 Формулировать User Story удобно по такому шаблону: Как [тип пользователя], я хочу [функциональность], чтобы [цель/причина].
🟣 Используйте принцип INVEST, чтобы оценить пользовательскую историю на работоспособность и эффективность. Это значит, что User Story должна быть краткой, независимой, ценной и тестируемой. А еще такой, чтобы ее можно было оценить и менять в процессе работы.

Добавить комментарий