Команда не может работать над проектом вслепую. Ей важно понимать, для чего, а главное — для кого она делает этот проект и чем он поможет людям. Для этого и нужна User Story — пользовательская история. Разберем, как ее формулировать и использовать в работе.
Что такое User Story
User Story (пользовательская история) — это краткое описание функций или задачи с точки зрения конечного пользователя. Пользовательские истории помогают команде разработки лучше понять потребности и ожидания пользователей, грамотно планировать и приоритизировать задачи.
Стандартная User Story состоит из трех частей: описание пользователя, действия и желаемый результат. Этот инструмент помогает командам разработки смотреть на продукт глазами пользователя и не терять главное из виду из-за множества операционных процессов.
Над IT-проектами работают очень разные специалисты. В том числе тестировщики, которые находят ошибки и неточности на сайтах и в приложениях. Если вы усидчивы и внимательны к деталям, обучиться на тестировщика будет гораздо проще. В онлайн-университете Skypro вам помогут получить базовые навыки для работы и найти место, где начнется ваша новая карьера.
Для чего нужны User Story
Пользовательские истории нужны, чтобы:
- понимать потребности пользователей;
- согласовывать работу разработчиков и заказчиков;
- расставлять приоритеты при разработке продукта;
- составлять план разработки (roadmap);
- тестировать удобство продукта для пользователя;
- оценить качество разработки;
- подготовить техническое задание для подрядчиков.
Возьмем пример из реальной работы: разработчики создают мобильное приложение для банка. Одна из главных задач — функция перевода денег между счетами.
User Story можно сформулировать так:
Как пользователь интернет-банка, я хочу переводить деньги между своими счетами в мобильном приложении, чтобы управлять финансами было удобно.
Когда пользовательская история сформулирована так, команда разработки понимает, из чего состоит запрос будущего клиента. На основе запроса формирует функции приложения:
➡️ Пользователь выбирает счет, с которого переведет деньги.
➡️ Пользователь выбирает счет, на который переведет деньги.
➡️ Пользователь вводит сумму перевода.
➡️ Пользователь добавляет описание или комментарий к переводу.
➡️ После перевода видит сообщение об успешной транзакции.
➡️ На телефон приходит уведомление, что перевод прошел.
Из этого функционала приложения команда разработки формирует свои задачи:
🟢 Разработать интерфейс выбора счетов отправителя и получателя.
🟢 Реализовать ввод суммы и описания перевода.
🟢 Интегрировать возможности, чтобы проводить транзакции.
🟢 Создать процесс, который выводит сообщения в приложении.
🟢 Настроить отправку уведомлений после перевода.
Так User Story помогает команде четко понять, что нужно реализовать и почему, и наметить конкретные шаги для достижения цели.
Как формулировать User Story
Сначала нужно определить, кто будет пользоваться конечным продуктом и какие у этой аудитории потребности. Для этого:
- Изучите рынок, на котором вы планируете продвигать продукты или услуги. Проанализируйте конкурентов и их клиентов.
- Соберите информацию о потребностях, предпочтениях и проблемах вашей целевой аудитории. Для этого используйте опросы, фокус-группы, интервью, аналитику данных.
- Разделите данные по сегментам: демографическим характеристикам (возраст, пол, доход), психосоциальным (интересы, ценности, образ жизни) и поведенческим (покупательское поведение, предпочтения).
- На основе данных сформируйте портреты целевой аудитории. Опишите их демографические характеристики, интересы, потребности и мотивацию покупать ваш продукт.
Анализом целевой аудитории в IT занимаются сразу два специалиста: аналитик данных и интернет-маркетолог. Первый собирает информацию, фильтрует ее и передает дальше, чтобы на основе данных интернет-маркетолог мог принять решения и выбрать дальнейшую стратегию продвижения продукта.
Затем можно формулировать пользовательскую историю. Важно определить конкретные шаги, которые помогут дойти до результата, и убедиться, что история понятна для всех членов команды.
Можно использовать такой шаблон:
Как [тип пользователя], я хочу [функциональность], чтобы [цель/причина].
Например:
💬 Как пользователь интернет-магазина, я хочу добавлять товары в корзину, чтобы делать покупки онлайн.
💬 Как менеджер по работе с клиентами, я хочу фильтровать их по категориям, чтобы быстро находить нужные контакты.
💬 Как пользователь интернет-магазина, я хочу добавлять товар в избранное, чтобы потом быстро находить его.
💬 Как создатель группы в соцсети, я хочу видеть список администраторов, чтобы понимать, у каких людей есть доступ к моей группе.
Подробности в формулировках не так важны, как конкретика: User Story должна быть максимально прозрачной, чтобы команда фокусировалась только на важном.
Критерии INVEST для User Story
У каждой пользовательской истории должны быть критерии приемки — условия, при которых она будет считаться рабочей. Это помогает разработчикам и тестировщикам точно понять, что нужно сделать, чтобы достигнуть цели.
Критерии User Story формулируют по принципу INVEST. Разберем каждый из них.
- Независимость (Independent)
User Story должна быть самостоятельной и независимой от других историй, чтобы ее можно было реализовать и протестировать отдельно. Так проще планировать задачи и управлять ими. - Переговороспособность (Negotiable)
User Story должна быть открыта для обсуждения и изменений. Ее важно детализировать до мельчайших подробностей на начальном этапе — тогда команда сможет адаптировать нужное в процессе разработки. - Ценность (Valuable)
User Story должна приносить ценность пользователю. Этот критерий помогает сосредотачиваться на самых важных аспектах проекта. - Возможность оценить (Estimable)
User Story должна быть достаточно понятной, чтобы команда могла оценить объем работы и время на реализацию. Это помогает грамотно распределять ресурсы внутри коллектива. - Краткость (Small)
User Story должна быть достаточно сжатой, чтобы ее можно было реализовать в рамках одного подхода к задаче. Если пользовательская история слишком большая, нужно разбить на части поменьше. - Тестируемость (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 должна быть краткой, независимой, ценной и тестируемой. А еще такой, чтобы ее можно было оценить и менять в процессе работы.
Добавить комментарий