Всем привет. Перевели еще один интересный материал для студентов курса «Продакт-менеджер ИТ-проектов» .
Приятного чтения
Ранее я уже писал о проблемы С история пользователя (пользовательские истории).
В то время я подумал, что лучше просто попросить команду обсудить предлагаемые изменения в продукте.
Стратегия была хороша, если ее поддерживала команда и продукт был зрелым.
Однако сейчас я работаю с новой командой и создаю продукт с нуля.
В этом случае перед нами чистый лист, и нам сложно прийти к согласию, когда речь идет о мотивации клиентов, событиях и ожиданиях.
Сегодня все изменилось.
Я нашел отличный способ использовать философию Jobs To Be Done для определения функциональности продукта.
Сегодня мы поговорим о Job Stories.
Откуда она взялась
?Эта идея пришла от очень умных ребят из Внутренняя связь .Вот что они говорят по этому поводу: Мы называем каждую архитектурную задачу Job, фокусируемся на ситуации или событии, которое ее инициирует, мотивации или цели, и получаем следующее: Когда _____, я хочу ______ к _______. Например, когда регистрируется новый важный клиент, я хочу получить уведомление, чтобы я мог начать с ним разговор.
В этой статье я не называю эту конструкцию «Историей работы», но буду называть ее так, чтобы можно было легко обращаться к ней в будущем.
Сегодня мы не будем тратить много времени на объяснение этой концепции, я просто расскажу о том, почему она мне нравится и почему она лучше, чем пользовательская история.
О проблеме с пользовательской историей [еще раз]
В общем, проблема пользовательских историй в том, что они содержат слишком много предположений и мало причинно-следственных связей.Когда задача ставится в формате пользовательской истории ( Как [тип пользователя] я хочу, чтобы [действие] получило [результат] ), здесь нет места вопросу «почемуЭ», по сути вы просто ограничены определенной последовательностью, вырванной из контекста.
Вот как я вижу этот формат:
Предположения и отсутствие связи между человеком и его действием.
Первая проблема заключается в том, что мы начинаем с индивидуума, который не лучшая идея , затем следует действие, которое, по нашему мнению, следует предпринять для достижения желаемого результата.
Как я отметил на рисунке выше, на самом деле результатом является разрыв между действием и личностью.
Давайте посмотрим на некоторые существующие пользовательские истории:
Пример того, как пишутся пользовательские истории
Глядя на таблицу выше, добавляют ли типы пользователей-модераторов и оценщиков красок к общей картине? В любом случае это добавляет двусмысленности.
Мы с вами можем предложить свою интерпретацию этих понятий и того, почему контекст выглядит именно так.
Вот, попробуй.
Удалить всю часть "нравится [тип пользователя]" и посмотрите, действительно ли вы что-то упускаете.
Сравните следующие утверждения: Как модератор, я хочу создать новую игру, введя название и необязательное описание.
Или: Я хочу создать новую игру, введя название и необязательное описание.
Небо упало? История работы: все о контексте, причинах и следствиях
Формат вакансии
Основываясь на еще большем опыте и отзывах, я теперь использую немного другое объяснение.
я вижу это сейчас следующим образом .
Давайте еще раз взглянем на изображение и, наконец, начнем! Вся приведенная выше информация очень важна и информативна, поскольку мы фокусируемся на причине и следствии.
Каждая история работы должна содержать как можно больше контекста и фокусироваться на мотивации, а не только на реализации.
Поработав некоторое время с Job Story, я изменил «Мотивации» на «Мотивации и силы».
Взгляните на статью «5 советов по написанию истории о работе» , где эта тема затронута непосредственно.
Вы можете узнать больше о нынешних силах здесь.
Давайте перепишем некоторые примеры из таблицы пользовательских историй выше в историю работы, добавив к каждому мотивацию и контекст. История пользователя: Как модератор, я хочу создать новую игру, введя название и необязательное описание.
История работы: Когда я буду готов к тому, чтобы оценщики сделали ставки на мою игру, я хочу создать игру в понятном им формате, чтобы оценщики могли найти мою игру и знать, что они могут сделать на нее ставку.
История пользователя: Как оценщик, я хочу видеть оцениваемый объект, чтобы знать, на что ставлю цену.
История работы: Когда я нахожу товар, цену которого хочу оценить, я хочу иметь возможность взглянуть на него, чтобы знать, что товар, на который я делаю ставку, действительно является тем, что я хочу.
История пользователя: Как модератор, я хочу выбрать элемент для оценки или изменения оценки, команда увидит этот элемент и сможет оценить его.
История работы: Если у элемента нет рейтинга или рейтинг мне не нравится, я хочу иметь возможность перезапустить процесс оценки и уведомить всех, чтобы команда знала, что определенный элемент нуждается в оценке.
Как насчет нескольких ролей и событий? Поскольку я получаю разные отзывы о «Истории вакансий» и продолжаю работать над ней сам, я считаю уместным время от времени включать в нее некоторые роли или персонажи частично Когда _____ .
Продукты с несколькими ролями Роли и персонажи наиболее полезны, когда сам продукт имеет несколько ролей, например, ИТ-продукт (администратор, менеджер, участник) или продукт открытого рынка (покупатель, продавец).
Причина в том, что мы всегда должны понимать, о ком говорим.
В качестве примера возьмем eBay: Когда покупатель уже сделал ставку на товар, он обеспокоен тем, что кто-то предложит высокую цену, и хочет, чтобы его уведомили об этом, чтобы у него было достаточно времени, чтобы оценить и обновить свою собственную ставку.
Роли и причинно-следственные связи Иногда возникают ситуации, когда Job Story описывает взаимодействие нескольких ролей одновременно, создавая причинно-следственный сценарий.
Давайте снова возьмем eBay в качестве примера: Когда продавец недоволен полученными предложениями и отзывает свой товар с рынка, покупатели, которые уже подали заявки, хотят быть немедленно уведомлены о том, что товар снят с аукциона, чтобы им больше не приходилось следить за движением его цены.
и ищите другой аналогичный товар.
Использование событий вместо ролей Иногда может возникнуть ситуация, когда событие затрагивает все роли или группы людей: например, вам необходимо получить напоминание пароля.
В этом случае нет смысла вводить конкретную роль, вместо этого ее следует оставить на уровне общих понятий, например «клиент» или что-то подобное (но не «пользователь»): Когда клиент использует свое мобильное устройство и забывает свой пароль, ему нужен пароль, который можно легко восстановить с помощью мобильного устройства, чтобы клиент мог продолжать входить в систему и получать доступ к своей ленте новостей.
Почему не пользователь ? «Пользователь» звучит очень безжизненно и стерильно, тогда как «клиент» напоминает вам, что есть люди, которым вам нужно оказывать услугу и которых нужно уважать.
Определите мотивацию, а не реализацию.
Истории вакансий хороши тем, что заставляют нас задуматься о мотивации и контексте и снимают акцент с добавления какой-либо конкретной реализации.
Часто потому, что люди сосредотачиваются на вопросах «кто» и «как», совершенно забывая о «почему».
Когда вы начинаете думать о том, «почему», ваш разум открывается творческим и оригинальным способам решения проблемы.
Вы также можете узнать о JTBD и Job Story в моей книге «Когда кофе и капуста конкурируют».
Вы можете сказать это бесплатно в формате PDF или купить бумажную версию.
Здесь .
А Здесь Вы можете заказать его онлайн.
Теги: #Управление продукцией #дизайн #управление продукцией #jtbd #Работы, которые необходимо выполнить #Инновации
-
Программы Награждений: Этика
19 Oct, 24 -
Взлом Iphone: Активация. 2 Способа.
19 Oct, 24 -
Миграция С Sccm 2007 На Sccm 2012\1511
19 Oct, 24 -
Audio.js — Слушайте Музыку В Любом Браузере
19 Oct, 24 -
Прибыльный Open Source – Правильно Ли?
19 Oct, 24