Анна Мининкова, менеджер мобильной аналитики в JetSmarter, написала колонку специально для Нетологии о том, как использовать пользовательские истории для разработки требований продукта.
Пользовательская история — это легковесный инструмент для документации пользовательских требований к разработке продукта. История описывает функциональность системы с точки зрения пользователя с определенной ролью и целью этой системы.
Как роль/персона юзера я что-то хочу получить с такой-то целью.
Часто команды задаются вопросом: зачем работать над документацией вообще, если можно просто создать задачи в трекере и сразу начать внедрять новый функционал?
Но основная задача любой документации — выявить и описать потребности пользователя, для которого разрабатывается продукт. Она создана не столько, чтобы описать всё, что должен делать продукт, сколько чтобы убедиться, что команда знает, зачем пользователю продукт и как именно он будет им пользоваться. Невнимание к этой разнице в целях очень часто приводит к тому, что продукт работает «как написано», но не приносит никакой пользовательской ценности.
И если формат традиционной нарративной функциональной спецификации позволяет легко потерять ценность за событие «по нажатию на кнопку X должно происходить событие Y», то формат пользовательской истории: «Как роль/персона пользователь я что-то хочу получить с такой-то целью», позволяет команде задуматься над этой ценностью на самом раннем этапе.
История — это не продукт размышлений одного бизнес-аналитика или менеджера, который, как мог, попытался зафиксировать всё множество особенностей продукта или функционала, который нужно спроектировать.
История — это результат обсуждения команды разработки и бизнес-пользователей, который фиксируется в максимально ненагруженной форме.
Обсуждения позволяют избавиться от ложного представления о том, зачем разрабатывается новый функционал и кто им будет пользоваться. Вдобавок к этому истории позволяют продумать тестирование и ограничения системы на ранней стадии разработки.
Пользовательская история включает в себя следующие элементы:
Как писать пользовательские истории
В идеальном случае черновая пользовательская история должна быть написана внутренним или внешним бизнес-пользователем, который заказывает разработку нового продукта или функционала у команды, а после коллаборативно разбирается вместе с командой разработки.
Текст истории должен объяснять действия пользователя, его потребность и результат, на который он надеется.
Как роль/персона юзера я что-то хочу получить с такой-то целью.
Чтобы понять, хорошей ли получилась пользовательская история очень удобно использовать следующий чек-лист:
- Разработка этой истории относительно независима. Чем больше программных зависимостей и ограничений, тем сложнее будет спланировать разработку такой истории.
- Ценность. Финальная часть конструкции «я хочу что-то получить с такой-то целью» должна содержать цель, которую вся команда признает важной и осмысленной.
- История должна быть легко оцениваема. Если она слишком большая или слишком размытая, чтобы оценить, то ее стоит разбить на меньшие части.
- Разработка не должна занимать больше недели. Иначе ее придется дробить на составляющие.
- Критерии приемки должны быть довольно четкими, чтобы по ним можно было протестировать продукт.
Распространенные ошибки в пользовательских историях
История для пользователя
Пример: «Как пользователь я хочу управлять отображением спецпредложений, чтобы удалять неактуальные и устаревшие».
Что не так с этой историей? Все важные части, кажется, на месте, но присмотревшись ближе, мы не знаем, для кого мы проектируем эту историю. Возможно, наш пользователь — администратор системы, которому нужно премодерировать показ спецпредложений от рекламодателей? Или, возможно, он рекламодатель, которому нужно управлять показом спецпредложений в списке?
У этих пользователей будут совершенно разные ожидания от системы. Ошибка этой истории — невнимание к роли пользователя в ней.
История для разработчика
Пример: «Как разработчик я хочу перейти на программную библиотеку Х, чтобы у меня была последняя версия библиотеки Х»
Часто такие истории пишутся, чтобы объяснить, что нужно сделать в рамках технического долга и рефакторинга, и здесь уже команда выступает непосредственным заказчиком. Однако, убедить бизнес в необходимости такой истории будет очень сложно, ведь на словах она не создает никакой ценности для пользователя. Как же с ней быть, если задача действительно нужная и полезная?
Необходимо посмотреть на то, что делает библиотека Х для конечного пользователя продукта. К примеру, она позволяет быстрее создавать спецпредложения и убирает задержку после их создания. Тогда история может звучать так:
«Как рекламодатель я хочу, чтобы в системе не было задержек после создания спецпредложений, чтобы я мог быстрее работать с большим объемом спецпредложений».
Перепишите ее с пользовательской точки зрения: «Как рекламодатель я хочу, чтобы система позволяла создавать мне папки, чтобы я мог быстрее работать с большими списками объявлений»
Технические заметки к этой истории могут выглядеть следующим образом:
- «Отрефакторить механизм добавления спецпредложений».
- «Обновить версию библиотеки, отвечающей за анимации добавления спецпредложений».
При этом к такой истории гораздо проще написать критерии приемки:
- «Пользователь не должен видеть задержки после создания спецпредложения при нормальной скорости интернета».
Никакой бизнес-ценности для пользователя
Пример: «Как администратор системы я хочу чтобы у меня была возможность сортировать спецпредложения».
Вроде бы все на месте, кроме ценности для пользователя. Зачем администратору сортировать спецпредложения? Не понимая какая цель у сортировки, нельзя сформулировать и дальнейшие требования к ней, а история теряет смысл.
Практические советы по написанию пользовательских историй
- Выбирайте в пользу разбивки истории на мелкие составляющие вместо одной громоздкой.
- По возможности избегайте технического жаргона в историях — особенно если впоследствии вашим бизнес-пользователям нужно будет приоритезировать истории.
- Избегайте обсуждения конкретных UI элементов. История должна оставаться актуальной, даже если визуальная реализация меняется.
- Обязательно оценивайте усилия по разработке истории.
- История должна приводить к понятному и ценному результату.
Порочные практики
- Формализм
Иногда бизнес-пользователи из лучших побуждений пишут огромные подробные истории. В этом случае команда часто сдается и пропускает обсуждения, видя, что все нюансы «кажутся» освещенными. Как результат, часть требований теряется, ведь один человек редко может охватить абсолютно все детали.
- Отсутствие обсуждений
Без обсуждения истории с командой очень легко пропустить мелкие детали или создать неправильное представление о задаче. Лучше потратить время на старте, когда не написано ни строчки кода, чем спохватиться в середине проектирования.
-
Перевес в пользу технических историй
Если при планировании вы видите, что у вас готовы только истории технического плана, то в итоге может получиться, что истории реализованы, а продуктовой ценности совсем мало. Желательно соблюдать баланс между техническими историям, которые часто делаются для внутренних пользователей системы и теми, которые создаются для конечных пользователей продукта.
Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.
