Анна Мининкова, менеджер мобильной аналитики в JetSmarter, написала колонку специально для Нетологии о том, как использовать пользовательские истории для разработки требований продукта.

Пользовательская история – это легковесный инструмент для документации пользовательских требований к разработке продукта. История описывает функциональность системы с точки зрения пользователя с определенной ролью и целью этой системы.

Как <роль/персона юзера> я <что-то хочу получить> <с такой-то целью>.

Часто команды задаются вопросом: зачем работать над документацией вообще, если можно просто создать задачи в трекере и сразу начать внедрять новый функционал?

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

И если формат традиционной нарративной функциональной спецификации позволяет легко потерять ценность за событие «по нажатию на кнопку X должно происходить событие Y», то формат пользовательской истории: «Как <роль/персона пользователь> я <что-то хочу получить> <с такой-то целью>», позволяет команде задуматься над этой ценностью на самом раннем этапе.

История — это не продукт размышлений одного бизнес-аналитика или менеджера, который, как мог, попытался зафиксировать всё множество особенностей продукта или функционала, который нужно спроектировать.

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

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

Пользовательская история включает в себя следующие элементы:

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

Как писать пользовательские истории

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

Текст истории должен объяснять действия пользователя, его потребность и результат, на который он надеется.

Как <роль/персона юзера> я <что-то хочу получить> <с такой-то целью>.

Чтобы понять, хорошей ли получилась пользовательская история очень удобно использовать следующий чек-лист:

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

Распространенные ошибки в пользовательских историях

История для пользователя

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

Что не так с этой историей? Все важные части, кажется, на месте, но присмотревшись ближе, мы не знаем, для кого мы проектируем эту историю. Возможно, наш пользователь — администратор системы, которому нужно премодерировать показ спецпредложений от рекламодателей? Или, возможно, он рекламодатель, которому нужно управлять показом спецпредложений в списке?

У этих пользователей будут совершенно разные ожидания от системы. Ошибка этой истории — невнимание к роли пользователя в ней.

История для разработчика

Пример: «Как разработчик я хочу перейти на программную библиотеку Х, чтобы у меня была последняя версия библиотеки Х»

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

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

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

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

Технические заметки к этой истории могут выглядеть следующим образом:

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

При этом к такой истории гораздо проще написать критерии приемки:

«Пользователь не должен видеть задержки после создания спецпредложения при нормальной скорости интернета».

Никакой бизнес-ценности для пользователя

Пример: «Как администратор системы я хочу чтобы у меня была возможность сортировать спецпредложения».

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

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

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

Порочные практики

Формализм

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

Отсутствие обсуждений

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

Перевес в пользу технических историй

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

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

Читать еще

Обучение

Бесплатный курс «Adobe Photoshop: основы для веб-дизайнера»
Программа обучения «Проектирование интерфейсов: UX-дизайн от стратегии до тестирования»
Программа обучения «Веб-дизайнер: эффективный сайт от идеи до реализации»