User Story: пора применять правильно
Мария Родина,
Senior Project Manager в gamedev-студии
Senior Project Manager в gamedev-студии
User story (пользовательская история) считается одним из самых простых способов описания бизнес-требований. Многие считают именно user story главным инструментом для продакт-менеджера: это помогает ему простыми словами объяснить разработчикам, что и зачем должно быть сделано.
Обманчивая простота
На курсах продуктового менеджмента про user story обычно рассказывают так: «это очень просто – пишите, кто вы, что вы хотите и как вы будете это использовать». И начинающие продуктовые менеджеры начинают думать, что это действительно так легко и не требует более глубокого погружения в детали.
Шаблон для пользовательской истории выглядит так:
Шаблон для пользовательской истории выглядит так:
Пример примитивный, но сразу понятно, что охотнику и молодому человеку нужны разные квадроциклы. И продавец-консультант в магазине вряд ли порекомендует таким клиентам одну и ту же модель.
На этом этапе начинающие продакты устраивают праздник. Для них обучение закончено, они идут ставить первые задачи команде. Команда в шоке.
Примеры таких историй:
На этом этапе начинающие продакты устраивают праздник. Для них обучение закончено, они идут ставить первые задачи команде. Команда в шоке.
Примеры таких историй:
Пример 1:
Как оператор колл-центра, я хочу, чтобы по отмененным заказам в CRM передавался признак declined по интерфейсу 139.
Как оператор колл-центра, я хочу, чтобы по отмененным заказам в CRM передавался признак declined по интерфейсу 139.
Разберем ошибки:
а) Оператору колл-центра не важно, какой признак передаётся в системе. Ему важно отображение статуса заказа на карточке клиента или карточке заказа, потому что он будет использовать в работе пользовательские интерфейсы, а не технические логи.
б) По такой истории разработчик будет пытаться передать статус именно по 139 интерфейсу. Правильно ли это с точки зрения архитектуры? Нет ли другого интерфейса, который уже передает нужную информацию? Этого продуктовый менеджер не знает. Оставьте технические детали на усмотрение специалистов, они могут предложить решение лучше.
а) Оператору колл-центра не важно, какой признак передаётся в системе. Ему важно отображение статуса заказа на карточке клиента или карточке заказа, потому что он будет использовать в работе пользовательские интерфейсы, а не технические логи.
б) По такой истории разработчик будет пытаться передать статус именно по 139 интерфейсу. Правильно ли это с точки зрения архитектуры? Нет ли другого интерфейса, который уже передает нужную информацию? Этого продуктовый менеджер не знает. Оставьте технические детали на усмотрение специалистов, они могут предложить решение лучше.
Пример 2:
Как владелец сайта, я хочу добавить на карточку товара красную кнопку «Купить», чтобы повысить конверсию.
Как владелец сайта, я хочу добавить на карточку товара красную кнопку «Купить», чтобы повысить конверсию.
Ошибки:
а) Что должно происходить при нажатии кнопки? Куда она ведёт?
б) «Чтобы повысить конверсию» - это не описание ожидаемого результата. Тем более, повышать конверсию можно разными способами. Лучше написать «чтобы при нажатии пользователь попадал на экран оформления заказа». История должна отражать сценарий использования.
в) Добавить кнопку вместо имеющейся? Или на карточке должно быть две кнопки? Это уже придирка, но об этом тоже было бы неплохо подумать при формулировке user story.
а) Что должно происходить при нажатии кнопки? Куда она ведёт?
б) «Чтобы повысить конверсию» - это не описание ожидаемого результата. Тем более, повышать конверсию можно разными способами. Лучше написать «чтобы при нажатии пользователь попадал на экран оформления заказа». История должна отражать сценарий использования.
в) Добавить кнопку вместо имеющейся? Или на карточке должно быть две кнопки? Это уже придирка, но об этом тоже было бы неплохо подумать при формулировке user story.
Пример 3:
Как маркетолог, я хочу добавлять к каждой покупке подарок, чтобы повысить лояльность клиентов.
Как маркетолог, я хочу добавлять к каждой покупке подарок, чтобы повысить лояльность клиентов.
К этой истории есть один комментарий, но он очень важный:
А не проще ли передать это требование складу в виде инструкции или распоряжения и отправить им подарки, предназначенные для вложения в заказ? История выглядит так, будто разработка не нужна совсем.
А не проще ли передать это требование складу в виде инструкции или распоряжения и отправить им подарки, предназначенные для вложения в заказ? История выглядит так, будто разработка не нужна совсем.
Смысл и назначение user story
Ещё Майк Кон, известный во всём мире agile-коуч, говорил, что «пользовательские истории не являются конечными требованиями к системе, и не предназначены быть полезными в конце итерации» (в книге "User stories applied"). В первую очередь, пользовательские истории нужны для того, чтобы выяснить, что нужно клиенту. Так ищутся основные боли пользователя и возможные способы их исправления.
Следующий этап – обсуждение каждой истории с заказчиком. На этом этапе каждая история детализируется до уровня, который позволит описать верхнеуровневые требования к системе. И после этого этапа для каждой истории появляется Definition of Done – критерии готовности, по которым можно понять, что требование выполнено.
Итак, три этапа:
Следующий этап – обсуждение каждой истории с заказчиком. На этом этапе каждая история детализируется до уровня, который позволит описать верхнеуровневые требования к системе. И после этого этапа для каждой истории появляется Definition of Done – критерии готовности, по которым можно понять, что требование выполнено.
Итак, три этапа:
- Пишем истории
- Обсуждаем и детализируем истории
- Определяем критерии готовности
- При необходимости, повторяем пункты 2-3 еще несколько раз.
Проверка user story
И даже после нескольких таких итераций пользовательские истории могут нуждаться в улучшении. Проверить это можно с помощью метода INVEST:
- I (Independent) – ваша история не зависит от выполнения других историй
- N (Negotiable) – вы уже несколько раз обсудили историю
- V (Valuable) – реализованная история принесет реальную бизнес-ценность
- E (Estimable) – возможно оценить трудозатраты, необходимые для выполнения истории
- S (Small) – историю можно реализовать за одну итерацию
- T (Testable) – есть понятные критерии приемки и тестовые сценарии для проверки реализации
Пример хороших user stories:
Пример 1:
Как куратор онлайн-курса, я хочу знать имя и контакты заинтересовавшихся курсом посетителей сайта, чтобы направить им по e-mail информацию о старте курса.
Пример 2:
Как пользователь мобильного приложения, я хочу на листинге видеть шильдики акций, в которых участвует товар, чтобы понимать, какие бонусы получу за покупку.
Пример 1:
Как куратор онлайн-курса, я хочу знать имя и контакты заинтересовавшихся курсом посетителей сайта, чтобы направить им по e-mail информацию о старте курса.
Пример 2:
Как пользователь мобильного приложения, я хочу на листинге видеть шильдики акций, в которых участвует товар, чтобы понимать, какие бонусы получу за покупку.
Что может пойти не так?
- Вы написали лучшую пользовательскую историю за всю вашу карьеру, она отвечает принципам INVEST, уже готовы сценарии тестирования. И в этот момент у заказчика меняются требования. Если вы оставите историю без изменений, она может не принести пользы. Не бойтесь вносить корректировки даже в идеальную user story.
- Ваша история написана хорошо, но понятна только вам и заказчику из-за использований специфических терминов, аббревиатур и сокращений. Или наоборот, после обсуждения с командой разработки появилось слишком много технической информации, которую уже не понимает заказчик. Помните, что история должна быть понятна всем.
- После детализации истории она занимает лист А4. Вы уверены, что вся информация необходима? История не должна занимать всю вашу доску с требованиями к продукту.
- Все истории понятны и достаточно детализированы, но описывают сценарии использования только для одного типа пользователей. Вспомните всех, кто будет пользоваться продуктом и на кого повлияет ваш продукт.
- Ваших историй слишком много в бэклоге, в них уже сложно ориентироваться. Старайтесь поддерживать бэклог в актуальном состоянии, вычеркивайте ненужные истории (и удаляйте их из jira/trello/etc.). Поставьте свое ограничение на общее количество пользовательских историй и соблюдайте его. Идеального числа нет, экспериментируйте.
- Вы переносите ваши истории из бэклога продукта в бэклог спринта без изменений. Помните, что для бэклога спринта каждую user story необходимо разбить на подзадачи, понятные для разработчиков. Это зона ответственности scrum-мастера, IT проджекта, архитектора или кросс-системного аналитика, в зависимости от распределения ролей в вашей компании. Подзадачи должны быть максимально чёткими и понятными для исполнителя.
- Ваш спринт целиком состоит из задач по реализации пользовательских историй. Оставляйте время для устранения багов и технического долга, чтобы не копить проблемы.
- Команда уже реализовала половину историй, а владелец продукта не провел приемку ни одной. Прогресс спринта зависит от приемки задач, не затягивайте с этим этапом. Поздняя приемка не оставляет времени на исправление ошибок, из-за этого будет расти список задач на следующие спринты, а общее количество выполненных задач при этом не изменится.
Выводы:
- Поймите, чего хочет пользователь. Обсудите и детализируйте каждое требование.
- Опишите сценарий использования в формате user story с соблюдением принципа INVEST.
- Удостоверьтесь, что история понятна и заказчику, и исполнителям.
- Самые приоритетные истории разбейте на подзадачи и включите в ближайший спринт.
- Наименее ценные истории удалите из бэклога продукта.
- Организуйте приемку выполненных историй на протяжении всего спринта.
Автор: Мария Родина, Консультант проектов в М.Видео-Эльдорадо
Больше интересного в Telegram-канале @pmclub
Больше интересного в Telegram-канале @pmclub
Понравилась статья?