kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Job Story
В некоторых случаях техника пользовательских историй (User Stories) не подходит для описания требований, тогда используются Job Stories. В этом уроке вы узнаете, что это такое, чем Job Story отличается от пользовательской истории и в каких случаях используются Job Stories.
Что такое Job Story
Job Story — это техника описания функций ПО, которые позволяют решить проблему пользователя в определённой ситуации.
Job Story акцентирует внимание на ситуации (причина), из-за которой нужно воспользоваться определённой функцией ПО.
Название Job Story придумал Алан Клемент, один из авторов техники JTBD (Job to be Done — «работа, которая должна быть сделана»). Job Stories основаны на JTBD, но это не одна и та же техника. JTBD предполагает, что мы покупаем товары и услуги для выполнения определённой работы, а Job Story описывает, какую именно работу будет выполнять ПО. Здесь и далее речь идёт именно о Job Story. JTBD в этом спринте не рассматривается.
Шаблон Job Story
Шаблон Job Story — это описание мотивации пользователя применять ПО для достижения желанного результата в определённой ситуации. Системный аналитик пишет шаблон Job Story от первого лица так:
- Когда (ситуация),
- я хочу (мотивация),
- чтобы (ожидаемый результат).
В оригинале шаблон выглядит так:
Ситуация
Ситуация описывает, в каких обстоятельствах находится пользователь, что стало причиной, которая толкнула его воспользоваться функцией ПО. Важно описать не проблему пользователя, а именно ситуацию, которая порождает проблему.
Разобраться с этим поможет пример с Job Story для картографического сервиса. Важная функция такого сервиса — возможность смотреть сохранённые на устройстве участки карты без соединения с интернетом. Эта история будет называться «Карты в режиме офлайн».
Ситуацию, которая легла в основу этой истории, правильно записывать так: «Когда путешествую в новой стране без доступа к интернету». Нужно избегать формулировки «когда потерялся». Слово «потерялся» указывает на описание проблемы, формулировка «когда потерялся» не даёт понять, что случилось с пользователем, в каких обстоятельствах это произошло. Вариант «путешествую в новой стране без доступа к интернету» указывает на то, что пользователь оказался в незнакомой ему стране и у него пока нет доступа к интернету. Это значит, что есть некоторое затруднение, которое может привести к проблеме — пользователь может потеряться.
Мотивация (изменение)
В этой части шаблона системный аналитик описывает, какое действие пользователь совершает, чтобы изменить ситуацию и решить проблему.
Как пользователь, который оказался в новой стране без доступа к интернету, может изменить ситуацию? Скорее всего, он хочет открыть на смартфоне карту, которая будет отображаться в офлайн-режиме.
Слово «хочу» в этой части истории можно заменить на «могу», «должен», «обязан» и другие глаголы, которые выражают отношение пользователя к изменениям.
Как и в пользовательских историях, в этой части шаблона не нужно упоминать элементы интерфейса. Проблемы пользователя решают не кнопки, а функции ПО.
Ожидаемый результат
В этой части шаблона нужно указать, что пользователь получит, когда ситуация изменится.
Чтобы сформулировать ожидаемый результат, нужно задаться вопросом: «Для чего?» Формулировки должны давать понимание, к какому результату придёт пользователь: например, сможет добраться из аэропорта до гостиницы.
Нужно избегать абстрактных формулировок ожидаемого результата. Они не позволяют понять, какую проблему пользователю удалось решить и какого результата он смог достичь. «Чтобы не теряться» — как раз абстрактная формулировка, которая не даёт понять, к какому результату пришёл пользователь.
В итоге Job Story «Карты в режиме офлайн» будет сформулирована так:
Когда путешествую в новой стране без доступа к интернету, я хочу открыть на смартфоне карту, доступную в режиме офлайн, чтобы добраться из аэропорта до гостиницы.
Чем схожи Job Story и пользовательская история
Одинаковые составляющие
Job Story так же, как и пользовательская история, состоит из 3C:
- Card (карточка).
- Conversation (обсуждение).
- Confirmation (подтверждение).
Системный аналитик записывает Job Story на карточке и обсуждает её детали с членами команды разработки и пользователями. На карточке Job Story тоже записывают примечания, критерии и сценарии приёмки, которые формулируются в ходе обсуждения. После чего системный аналитик фиксирует договорённости (подтверждение).
Полная карточка Job Story картографического сервиса будет выглядеть так:
Одинаковые преимущества
Job Stories так же, как и пользовательские истории:
- понятны как пользователю, так и членам команды;
- определяют объёмы работы над функциональностью и сроки реализации;
- используются для формирования бэклога продукта и итераций при работе в гибкой модели;
- переносят акцент с документирования требований на их устное обсуждение;
- помогают достичь единого понимания требований как со стороны пользователей, так и со стороны команды разработки.
Job Story даёт дополнительный контекст
Представьте Job Story «Карты в режиме офлайн» в виде пользовательской истории:
Как путешественник, я хочу просматривать карты в режиме офлайн, чтобы добраться из аэропорта до гостиницы.
В этой истории недостаточно контекста: неясно, зачем пользователю понадобились офлайн-карты, почему он не может использовать онлайн-карты.
Можно переписать историю так:
Как путешественник, я хочу просматривать карты в режиме офлайн, чтобы пользоваться картами без подключения к интернету.
Стало понятнее, но если вспомнить шаблон записи пользовательской истории, получится, что «пользоваться картами» — конечная цель путешественника, хотя это не так. Его цель — добраться из аэропорта до гостиницы.
Job Story даёт дополнительную информацию о ситуации и отвечает на вопрос: «Когда пользователю требуется функция?» Например, она может потребоваться:
- когда нет доступа к интернету;
- когда пользователь просматривает корзину;
- когда пользователь сделал заказ.
Job Story не содержит информации о пользователе
Пользовательская история должна начинаться с записи класса пользователя или персоны — «Как [кто?]».
Словосочетание «как путешественник» не даёт дополнительной полезной информации о пользователе. Путешественником может быть кто угодно, это слишком общее понятие. Для Job Story не так важно, какая персона или какой класс пользователя будет использовать функционал, поскольку офлайн-карты пригодятся любому пользователю, который оказался без доступа к интернету. Неважно, сколько ему лет, кем он работает и какие у него привычки.
Таким образом, Job Story смещает фокус с особенностей конкретного пользователя, на ситуацию, в которой этот пользователь находится.
Когда СА использует Job Story
Job Story нужно использовать, если:
- Пользователи продукта однородныПользователи продукта однородны, если среди них нельзя выделить специальные группы, имеющие специфические требования. Если при составлении бэклога все пользовательские истории начинаются с «Как пользователь, я…», стоит использовать Job Story, чтобы избежать постоянного дублирования неважной информации и добавить данных о контексте.
- Требование актуально для всех групп пользователейJob Story можно применить для описания требований, если описываемая функция актуальна для всех пользователей. Даже если для ПО выделили несколько целевых групп пользователей или несколько персон.
- Ситуация важнее класса пользователяИспользование Job Story добавляет ситуации, в которой находится пользователь, контекст. Если информация о том, при каких условиях произойдёт история, важнее, чем информация о том, с кем она произойдёт, нужно использовать Job Story.
Вы участник проекта по разработке нового маркетплейса. Ваш коллега, системный аналитик, собрал пользовательские требования. Он никогда не работал в гибкой модели и записал требования в свободной форме. Помогите коллеге внести требования в бэклог, указав, какие из них лучше оформить в виде пользовательских историй, какие — в виде Job Stories.
При посещении маркетплейса незарегистрированному пользователю необходимо предложить вариант быстрой регистрации по номеру мобильного телефона
Пользовательская история
Ключевое в этом требовании — то, что оно предназначено для незарегистрированных пользователей, то есть пользователей конкретного типа. Это значит, что нужно создавать пользовательскую историю.
При снижении цены товара, находящегося у пользователя в избранном, нужно оповещать пользователя по электронной почте о новой цене
Job Story
В данной истории важен контекст — «при снижении цены товара». Требование распространяется на все группы пользователей, потому необходимо использовать Job Story.
При оформлении заказа пользователю с премиальной подпиской должна отображаться в корзине сумма скидки, которую даёт эта подписка
Пользовательская история
Пользователи с премиальной подпиской — особая группа. В этом требовании важны особенности пользователя, а значит, для его описания нужно создавать пользовательскую историю.
При создании заказа необходимо уведомлять пользователя о том, что заказ успешно зарегистрирован и принят в работу
Job Story
В данном требовании важен контекст — «при создании заказа», поэтому необходимо использовать Job Story.
При проведении технических работ на маркетплейсе нужно уведомлять пользователей о том, что сервисы будут временно недоступны
Job Story
Проведение технических работ — обстоятельства, в которых находится пользователь. Поэтому здесь подойдёт описание с помощью Job Story.
Подведём итоги
В этом уроке вы познакомились с Job Story. Эта техника позволяет записывать пользовательские требования. Она описывает функциональность продукта с точки зрения того, как пользователь применяет эту функциональность в конкретной ситуации.
Как и пользовательские истории, Job Story записывают на индексных карточках, детали истории обсуждаются с пользователями и командой разработки, а договорённости фиксируются в подтверждении.
Шаблон для карточки Job Story состоит из таких элементов:
- Когда (ситуация),
- я хочу (мотивация),
- чтобы (ожидаемый результат).
Использовать Job Story для описания требований нужно, если:
- пользователи продукта однородны, среди них нельзя выделить группы со специальными требованиями;
- требование актуально для всех групп пользователей;
- ситуация, в которой находится пользователь (контекст), важнее класса пользователя.
Job Story позволяет команде, работающей в гибкой модели, определить объёмы работы над функциональностью и сроки реализации, а также сформировать бэклог продукта и итерации.
Чат поддержки