top of page

Раскрытие потенциала пользовательских историй: 7 секретов мастерства


Four people in a library setting discuss plans on a table covered with paper and sticky notes. A woman in green points at the paper.

Пользовательские истории — один из самых известных инструментов в Agile. Они служат фундаментальными строительными блоками, направляющими процесс разработки на создание ценности для пользователей и клиентов.

Форматирование задач в виде «Как <пользователь>, я хочу <достичь цели>, чтобы <получить ценность>» кажется простым, особенно при разработке приложений или создании веб-сайтов. Например: «Как пользователь приложения для бронирования путешествий, я хочу получать рекомендации по местным ресторанам, чтобы сделать своё путешествие более приятным».


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

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


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



  1. Не зацикливайтесь на шаблоне


Agile-инструменты, включая классический шаблон пользовательской истории («Как <пользователь>, я хочу <достичь цели>, чтобы <получить ценность>»), созданы для помощи, а не для усложнения работы. Для многих строгий след этому шаблону кажется искусственным и громоздким. К тому же, он довольно длинный, а при использовании таких инструментов, как Jira, текст часто обрезается, что затрудняет обзор множества историй.


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



  1. Начните с «Кто»


Пользовательские истории — это, прежде всего, о «пользователе» (это даже в названии!). Так что главный вопрос: кто ваш клиент? Это звучит очевидно, но понимание этого крайне важно.


Ваш продукт или услуга предназначены не для всех людей на планете. Так кто же ваши пользователи? Это могут быть широкие категории или узкие ниши. Обратите внимание на возраст, географию, этап жизни — студенты, родители, пенсионеры? Учитывайте и уникальные особенности, такие как иностранные пользователи или люди с особыми потребностями.


Ваш «пользователь» может быть даже внутри вашей компании. Например, если вы создаёте инструмент для другой команды, они — ваши клиенты. Если вы управляете финансами компании, то ваш клиент — вся компания. Но не забывайте: даже когда вы работаете с внутренними клиентами, конечный пользователь (тот, кто покупает продукты вашей компании) тоже должен быть в фокусе.


Разберитесь с тем, «кто» ваш пользователь. Это как задать направление в GPS: без этого усилия могут быть потрачены впустую.



  1. Определите их цели


Двигаясь к «Что» в пользовательской истории, мы находим часть «Я хочу...<достичь цели>». Вы не обязаны следовать этому формату, но ясность — это ключ. Задача — понять реальные потребности клиента, встать на его место, почувствовать, чего он хочет достичь. Формулировка «Я хочу» — это инструмент для создания эмпатии, делая запросы клиента более ощутимыми.


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

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



  1. Оцените ценность


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


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


Ценность играет ключевую роль при решении, на чём сосредоточиться в первую очередь. Хотя определить её может быть не всегда просто или объективно, важно постараться максимально ясно описать ценность каждой пользовательской истории. Это поможет лучше сравнивать и расставлять приоритеты, основываясь на выгодах для клиентов.



  1. Определите критерии приемки


Пользовательские истории редко обходятся без критериев приемки — это своего рода продолжение истории, где уточняется, что именно продукт должен делать и в каких сценариях. Классический шаблон выглядит так: «если... когда... тогда...», где сценарий разбивается на предпосылки («если я новый клиент»), триггеры («когда я покупаю продукт впервые») и пост-функции («тогда мне предлагают скидку на членство в программе лояльности»).


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


Если вам не нравится этот шаблон, можно заменить его списком пунктов, описывающих желаемые изменения продукта или процесса. Например, если вы создаёте приложение для путешествий и ваша пользовательская история звучит как: «Как частый путешественник, я хочу видеть статус своей страховки во время поездок, чтобы чувствовать себя в безопасности и при необходимости приобретать дополнительную страховку», критерии приемки могут включать:


  1. Список страховых компаний, с которыми у меня есть договоры.

  2. Тип и покрытие каждой страховки в зависимости от страны.

  3. Выделение пробелов и рисков.

  4. Предложения по дополнительным страховым планам.


(Кстати, если вы разрабатываете такое приложение, дайте знать — я стану вашим первым лояльным пользователем!)



  1. Оставьте «Как» профессионалам


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


Однако важно помнить, что реализация — то есть «как» выполнить историю — это задача команды разработки. Существует множество способов реализации, каждый со своими нюансами, затратами и преимуществами. Будь то автоматизация процесса или включение ручных элементов, выбор зависит от возможностей команды и целей проекта.


Гибкость — это ключ. Шаблоны и правила — это лишь рекомендации, а не строгие требования. В некоторых ситуациях может понадобиться уточнить детали реализации во время планирования, и это нормально. Но помните, что предоставление команде свободы действий часто приводит к более эффективным и изобретательным решениям. Поэтому, где возможно, доверьте «как» своей профессиональной команде.



  1. Убедитесь, что история соответствует критериям INVEST


При написании пользовательских историй полезно использовать концепцию INVEST в качестве руководства (а не строгого правила). INVEST — это акроним, описывающий характеристики хорошей пользовательской истории:


  • (I)ndependent: История должна быть независимой, предоставляя ценность клиенту без зависимости от выполнения другой истории.

  • (N)egotiable: Детали реализации должны оставаться гибкими, позволяя команде выбирать оптимальные стратегии для достижения результата.

  • (V)aluable: Каждая история должна нести явную ценность. Если история не приносит пользы, стоит пересмотреть её необходимость.

  • (E)stimable: Хорошая история — это та, объём работы по которой можно оценить. Оценка не обязательно нужна всегда, но история должна быть достаточно ясной для этого.

  • (S)mall: Истории должны быть краткими и сфокусированными, чтобы их было проще выполнять и проверять. Маленькие истории позволяют быстрее получать обратную связь от клиентов.

  • (T)estable: У каждой истории должны быть чёткие критерии, по которым можно определить успех её реализации.


Использование INVEST как внутреннего чек-листа помогает создавать более точные, понятные и ориентированные на ценность пользовательские истории.



Пользовательские истории — это мощный инструмент в Agile, помогающий командам создавать продукты, которые действительно отвечают нуждам клиентов. Но их использование иногда кажется сложным из-за жёстких шаблонов и множества правил.


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


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

 
 
 
bottom of page