Заменяемая История Пользователя Историей Работы

Всем привет. Перевели еще один интересный материал для студентов курса «Продакт-менеджер ИТ-проектов» .

Приятного чтения

Заменяемая история пользователя историей работы

Ранее я уже писал о проблемы С история пользователя (пользовательские истории).

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

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

Однако сейчас я работаю с новой командой и создаю продукт с нуля.

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

Сегодня все изменилось.

Я нашел отличный способ использовать философию Jobs To Be Done для определения функциональности продукта.

Сегодня мы поговорим о Job Stories.



Откуда она взялась

?Эта идея пришла от очень умных ребят из Внутренняя связь .

Вот что они говорят по этому поводу: Мы называем каждую архитектурную задачу Job, фокусируемся на ситуации или событии, которое ее инициирует, мотивации или цели, и получаем следующее: Когда _____, я хочу ______ к _______. Например, когда регистрируется новый важный клиент, я хочу получить уведомление, чтобы я мог начать с ним разговор.

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

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



О проблеме с пользовательской историей [еще раз]

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

Когда задача ставится в формате пользовательской истории ( Как [тип пользователя] я хочу, чтобы [действие] получило [результат] ), здесь нет места вопросу «почемуЭ», по сути вы просто ограничены определенной последовательностью, вырванной из контекста.

Вот как я вижу этот формат:

Заменяемая история пользователя историей работы

Предположения и отсутствие связи между человеком и его действием.

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

Как я отметил на рисунке выше, на самом деле результатом является разрыв между действием и личностью.

Давайте посмотрим на некоторые существующие пользовательские истории:

Заменяемая история пользователя историей работы

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

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

Вот, попробуй.

Удалить всю часть "нравится [тип пользователя]" и посмотрите, действительно ли вы что-то упускаете.

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

Или: Я хочу создать новую игру, введя название и необязательное описание.

Небо упало? История работы: все о контексте, причинах и следствиях

Заменяемая история пользователя историей работы

Формат вакансии Основываясь на еще большем опыте и отзывах, я теперь использую немного другое объяснение.

я вижу это сейчас следующим образом .

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

Каждая история работы должна содержать как можно больше контекста и фокусироваться на мотивации, а не только на реализации.

Поработав некоторое время с Job Story, я изменил «Мотивации» на «Мотивации и силы».

Взгляните на статью «5 советов по написанию истории о работе» , где эта тема затронута непосредственно.

Вы можете узнать больше о нынешних силах здесь.

подкаст и маленький статья .

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

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

История пользователя: Как оценщик, я хочу видеть оцениваемый объект, чтобы знать, на что ставлю цену.

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

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

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

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

Продукты с несколькими ролями Роли и персонажи наиболее полезны, когда сам продукт имеет несколько ролей, например, ИТ-продукт (администратор, менеджер, участник) или продукт открытого рынка (покупатель, продавец).

Причина в том, что мы всегда должны понимать, о ком говорим.

В качестве примера возьмем eBay: Когда покупатель уже сделал ставку на товар, он обеспокоен тем, что кто-то предложит высокую цену, и хочет, чтобы его уведомили об этом, чтобы у него было достаточно времени, чтобы оценить и обновить свою собственную ставку.

Роли и причинно-следственные связи Иногда возникают ситуации, когда Job Story описывает взаимодействие нескольких ролей одновременно, создавая причинно-следственный сценарий.

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

и ищите другой аналогичный товар.

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

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

Почему не пользователь ? «Пользователь» звучит очень безжизненно и стерильно, тогда как «клиент» напоминает вам, что есть люди, которым вам нужно оказывать услугу и которых нужно уважать.

Определите мотивацию, а не реализацию.

Истории вакансий хороши тем, что заставляют нас задуматься о мотивации и контексте и снимают акцент с добавления какой-либо конкретной реализации.

Часто потому, что люди сосредотачиваются на вопросах «кто» и «как», совершенно забывая о «почему».

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

Узнать больше Вашей истории работы нужен трудный момент (https://jtbd.info/your-job-story-needs-a-struggling-moment-c03de87c6026), 5 советов по написанию истории работы.

Вы также можете узнать о JTBD и Job Story в моей книге «Когда кофе и капуста конкурируют».

Вы можете сказать это бесплатно в формате PDF или купить бумажную версию.

Здесь .

А Здесь Вы можете заказать его онлайн.

Теги: #Управление продукцией #дизайн #управление продукцией #jtbd #Работы, которые необходимо выполнить #Инновации

Вместе с данным постом часто просматривают: