Заменяем User Story на Job Story

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

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

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

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

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

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

Когда _____, я хочу______, чтобы_______.

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

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

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

О проблеме User Story [еще раз]

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

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

Вот, как выглядит этот формат:

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

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

Посмотрев на таблицу выше, можно ли сказать, что типы пользователей «модератор» и «оценщик» добавляют красок в общую картину?

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

Вот, попробуйте. Уберите всю часть «как [тип пользователя]» и посмотрите, действительно ли вы что-то теряете. Сравните следующие высказывания:

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

Или же:

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

Неужели небо рухнуло?

Job Story: Все о контексте и причинно-следственной связи

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

Посмотрим еще раз на изображение и начнем.

Вся вышеприведенная информация очень важна, поскольку мы фокусируемся на причинно-следственной связи. Каждая Job Story должна содержать как можно больше контекста и фокусироваться на мотивации, а не только на реализации.

«Мотивации» можно заменить на «Мотивации и действующие силы». Взгляните на статью «5 советов для написания Job Story», где эта тема затрагивается непосредственно. Больше о действующих силах вы можете в этом подкасте и маленькой статье.

Давайте перепишем в Job Story некоторые примеры из таблицы пользовательских историй, которая была приведена выше, добавив к каждой мотивацию и контекст.

User Story:

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

Job Story:

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

User Story:

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

Job Story:

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

User Story:

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

Job Story:

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

Как насчет нескольких ролей и событий?

Целесообразно иногда включать некоторые роли или персонажей в часть Когда _____.

Продукты с несколькими ролями

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

Возьмем в качестве примера eBay:

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

Роли и причинно-следственные связи

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

И снова возьмем в пример eBay:

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

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

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

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

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

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

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

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