User Stories vs Job Stories

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

Ее хочет приобрести ваша знакомая, ей 21 год, студентка истфака, любит собак и катается по выходным на велосипеде. Она не замужем, снимает квартиру с подругой.

Что из этого повлияло на её решение о покупке?

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

Что объединяет этих людей? Имеет ли значение, кто они?

Об этом размышляем в сегодняшней статье.

Разберем два похожих инструмента, User Stories и Job Stories, и расскажем, как их применять и когда стоит выбрать один, а когда — второй.

Job Stories

Начнём с теории работ.

Заходят молодая мама, проджект-менеджер и студент в кофейню. Это не анекдот, это реальная ситуация. Заходят и покупают большой капучино. Почему они это делают?

Молодая мама плохо спала ночью, потому что ребёнок заболел, а утром нужно бежать по делам — оформлять разные документы, чтобы устроить его в садик.

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

Со студентом всё понятно — он просто тусил. Но сейчас торопится на пары, ему нужно просидеть в универе до шести вечера, а потом работать официантом.

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

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

Однако при взгляде на ситуацию с такого ракурса можно заметить, что у горячего кофе есть неочевидные конкуренты. Это апельсиновый фреш в соседнем смузи-баре и холодный бассейн в фитнес-клубе неподалёку. А ещё энергетик или Сникерс в супермаркете. Все эти товары обеспечат прилив энергии разной продолжительности.

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

Её можно использовать при разработке нового продукта или крупной функциональности.

При формулировании используются Job Stories, которые имеют следующий формат:

Давайте обратимся к студенту, который стоит в очереди за кофе.

А теперь к проджекту.

И к маме:

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

Давайте отпустим наших персонажей по их делам, а сами поговорим про более сложные примеры.

P.S.: Вы продаёте камеру, помните? Так вот, её «нанимают на работу», когда в жизни происходит что-то особенное, чтобы запечатлеть яркий момент навсегда.

Job Stories в продуктах

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

Недавно мы задумались о его развитии и задали себе вопрос: кто захочет купить продукт?

И поняли, что здесь имеет значение не кто, а зачем. Чего хотят наши пользователи? И у нас получились вот такие разные истории:

После этих историй мы поняли, что именно нам нужно:

• Чтобы было дешево и работало «из коробки»;
• Чтобы можно было настроить систему под свой процесс без дорогостоящей заказной разработки;
• Чтобы был эксперт, который подскажет, какие процессы нужно автоматизировать.

А также поняли, что это разные рыночные сегменты.

Вывод: Используйте Jobs to be done, когда вы в начале разработки продукта и ищете его ценность — работу, на которую его наймут ваши пользователи. Или когда проектируете новую большую фичу. Обратите внимание, что это работает при условии, когда не важна персона /роль вашего пользователя или в вашем продукте всего одна пользовательская роль.

Но что же делать, когда роли всё-таки имеют значение?

User Stories

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

У нее схожий с Job Stories формат. На первый взгляд два этих подхода мало отличаются.

Однако, так как это артефакт Agile, с ними очень удобно работать в продукте.

Описав пользовательские требования в таком формате, легко составить User Story Map, разбив разработку на итерации и расставив приоритеты. Эти же истории можно передать команде разработки, чтобы верхнеуровнево оценить трудозатраты — в майках или стори поинтах.

Предположим, мы разрабатываем приложение для доставки еды. В таком сервисе у нас планируется три пользовательских роли — это заказчик, курьер и ресторан.

У них у всех разные цели и, соответственно, разные потребности. Job Stories в таком случае не подойдут. А вот User Stories подойдут идеально. Давайте посмотрим, как можно сформулировать их требования:

Насколько выполнимо это требование, предстоит решить команде разработки, но потребность пользователя понятна.

Оценка качества User Story

У пользовательской истории есть критерии качества. Они называются INVEST:

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

Negotiable — отражает суть, а не детали реализации, не содержит конкретных шагов реализации.

Valuable — имеет ценность для клиента (это именно пользовательское требование, которое вы выкристаллизовали, например, из глубинных интервью), бизнеса и стейкхолдеров.

Estimable — может быть оценена по сложности и трудозатратам, хотя бы верхнеуровнево.

Small — может быть сделана командой за одну итерацию (спринт или релиз).

Testable — имеет критерии приёмки, так называемые Definition of done.

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

Расскажите, а как вы применяете JTBD и User Stories в своих продуктах?