Раньше, я уже писал о проблемах с user story (пользовательскими историями). В те времена я считал, что лучше просто попросить команду обсудить предлагаемые изменения в продукте. Стратегия была хорошей, если команда оказывала помощь, а продукт был уже зрелым. Однако теперь я работаю с новой командой и создаю продукт с нуля. В таком случае перед нами лежит чистый лист и нам непросто прийти к согласию, когда речь заходит о мотивации клиентов, событиях и ожиданиях. На сегодняшний день все изменилось. Я нашел отличный способ использовать философию Jobs To Be Done, чтобы определить функционал продукта. Сегодня мы поговорим о Job Stories.
Откуда она взялась
Эта идея пришла от очень умных ребят из Intercom. Вот что они говорят на этот счет:
Каждую задачу архитектуры мы называем Job, фокусируемся на инициирующую ее ситуацию или событие, мотивацию или цель, и получаем следующее:
Когда _____, я хочу______, чтобы_______.
Например, Когда важный новый клиент регистрируется, я хочу получать оповещения, чтобы я мог начать с ним разговор.
В этой статье я не делаю отсылки к этой конструкции, как к Job Story, но я буду называть ее именно так, чтобы иметь возможность легко ссылаться на нее в будущем.
Сегодня мы не будем тратить много времени на пояснение концепции, я просто расскажу о том, почему она мне нравится и почему она лучше, чем User Story.
О проблеме User Story [еще раз]
В целом, проблема пользовательских историй состоит в том, что они содержат слишком много предположений и мало причинно-следственной связи. Когда задача ставится в формате пользовательской истории (Как [тип пользователя], я хочу [действие], чтобы получить [результат]), отсутствует место для вопроса «почему?», по сути вы просто ограничиваетесь определенной последовательностью, вырванной из контекста.
Вот как я вижу этот формат:
Предположения и отсутствие связи между человеком и его действием.
Первая проблема заключается в том, что мы начинаем с личности, что является не лучшей идеей, затем идет действие, которое, по нашему мнению, должно быть предпринято для достижения желаемого результата. Как я уже отметил в рисунке выше, на самом деле получается разрыв между действием и личностью.
Давайте посмотрим на некоторые существующие пользовательские истории:
Пример того, как пишутся User Stories
Посмотрев на таблицу выше, можно ли сказать, что типы пользователей «модератор» и «оценщик» добавляют красок в общую картину? Во всяком случае, двусмысленности это добавляет. Мы с вами можем предложить свою собственную интерпретацию этих понятий и того, почему контекст выглядит именно так.
Вот, попробуйте. Уберите всю часть «как [тип пользователя]» и посмотрите, действительно ли вы что-то теряете. Сравните следующие высказывания:
Как модератор, я хочу создать новую игру, введя название и необязательное описание.
Или же:
Я хочу создать новую игру, введя название и необязательное описание.
Неужели небо рухнуло?
Job Story: Все о контексте и причинно-следственной связи
Формат Job Story
Основываясь на еще большем опыте использования и обратной связи, сейчас я пользуюсь немного другим объяснением. Сейчас я вижу это следующим образом.
Посмотрим еще раз на изображение и наконец начнем!
Вся вышеприведенная информация очень важна и информативна, поскольку мы фокусируемся на причинно-следственной связи. Каждая Job Story должна содержать как можно больше контекста и фокусироваться на мотивации, а не только на реализации.
Проработав с Job Story некоторое время, я поменял «Мотивации» на «Мотивации и действующие силы». Взгляните на статью «5 советов для написания Job Story», где эта тема затрагивается непосредственно. Больше о действующих силах вы можете в этом подкасте и маленькой статье.
Давайте перепишем в Job Story некоторые примеры из таблицы пользовательских историй, которая была приведена выше, добавив к каждой мотивацию и контекст.
User Story:
Как модератор, я хочу создать новую игру, введя название и необязательное описание.
Job Story:
Когда я буду готов, к тому, чтобы оценщики сделали ставку на мою игру, я захочу создать игру в понятном для них формате, так оценщики смогут найти мою игру и понять, что они могут сделать ставку.
User Story:
Как оценщик, я хочу видеть оцениваемый предмет, чтобы знать, на что я делаю ставку.
Job Story:
Когда я найду предмет, который захочу оценить, я хочу иметь возможность посмотреть на него, чтобы понимать, что тот предмет, на который я делаю ставку действительно нужен мне.
User Story:
Как модератор, я хочу выбрать предмет для оценивания или переоценки, команда видит этот предмет и может оценить его.
Job Story:
Когда у предмета нет оценки или оценка мне не нравится, я хочу иметь возможность заново запустить процесс оценки и уведомить всех, чтобы команда знала, что определенный предмет требуется оценить.
Как насчет нескольких ролей и событий?
Поскольку я получаю различные отзывы о Job Story и продолжаю с ними работать сам, я считаю целесообразным иногда включать некоторые роли или персонажей в часть Когда _____.
Продукты с несколькими ролями
Роли и персонажи наиболее полезны, когда сам продукт имеет несколько ролей, например IT-продукт (администратор, менеджер, участник) или товар с открытого рынка (покупатель, продавец). Причина и в том, что нужно всегда понимать, о ком мы говорим.
Возьмем в качестве примера eBay:
Когда покупатель уже сделал ставку на товар, он
беспокоится о том, что кто-то сделает большую ставку и хочет получать об этом уведомления, чтобы иметь достаточно времени для оценки и обновления своей собственной ставки.
Роли и причинно-следственные связи
Иногда возникают ситуации, когда Job Story описывает взаимодействие нескольких ролей за раз, создавая причинно-следственный сценарий.
И снова возьмем в пример eBay:
Когда продавец недоволен полученными предложениями и выводит свой продукт с рынка, покупатели, которые уже подали заявки, хотят немедленно получить уведомление о том, что продукт был снят с аукциона, чтобы больше не следить за его динамикой цен и искать другой аналогичный продукт.
Использование событий вместо ролей
Иногда может возникнуть ситуация, когда событие влияет на все роли или группы людей: например, необходимо получить напоминание о пароле. В этом случае нет никакой причины вводить определенную роль, вместо этого ее нужно оставить на уровне общих понятий, например «клиент» или нечто подобное (но не «пользователь»):
Когда клиент использует свое мобильное устройство и забывает пароль, он хочет иметь такой пароль, который можно было бы легко восстановить с помощью своего мобильного устройства, чтобы клиент мог продолжить вход в систему и получить доступ к своей ленте новостей.
Почему не пользователь? «Пользователь» звучит очень безжизненно и бесплодно, тогда как «клиент» напоминает вам о том, что есть люди, которым вы должны предоставить услугу и которых нужно уважать.
Определите мотивацию, а не реализацию
Job Stories хороши тем, что они заставляют нас думать о мотивации и контексте, а также снимают акцент с добавления какой-либо конкретной реализации. Часто из-за того, что люди сосредотачиваются на вопросах «кто» и «как», совсем забывая про «почему». Когда вы начинаете задумываться о «почему», ваш ум открывается для творческих и оригинальных способов решения проблемы.
Узнать больше
Your Job Story Needs A Struggling Moment (https://jtbd.info/your-job-story-needs-a-struggling-moment-c03de87c6026), 5 Tips For Writing A Job Story.
А еще можно узнать о JTBD и Job Story из моей книги When Coffee and Kale Compete.
Можете сказать ее бесплатно в PDF или купить бумажную версию здесь . А здесь вы можете заказать ее онлайн.