Історії користувача vs. Історії роботи (User vs. Job Stories)

Сьогодні спробуємо розширити горизонти завдяки перекладу від Mariia Slobodian статті про один з альтернативних способів запису вимог – Job Stories

Що краще використати в проекті – user story чи job story? Zander Pease дає поради продакт-менеджерам, як поєднати ці два підходи для отримання максимальної користі в роботі над продуктом. 

Одним із найважливіших умінь для створення продукту є здатність мислити та комунікувати з точки зору проблем користувачів, а не рішень. Переваги є багатогранними: ваші колеги-інженери та дизайнери запропонують кращі рішення, якщо вони орієнтуються на чітко визначені проблеми; колеги з бізнесу можуть зробити корисний внесок лише тоді, коли вони розуміють питання “Чому ми це створюємо?”. Тому, як би це не було спокусливо, негайна розробка рішень, як правило, призводить до хаосу і, в кінцевому підсумку, до зниження якості продукту.

До теми: Гайд по User Stories для Junior BA

Цей пост ознайомлює з користувацькими історіями (user stories) та історіями роботи (job stories), їх відмінностями і тим, як їх використовувати продакт-менеджеру. Хоча багато хто надає перевагу одному з цих підходів до документування вимог, я вважаю, що обидва підходи корисні, якщо використовувати їх у відповідному сценарії.

Визначення

User story, як правило, будується наступним чином:

“Як ПЕРСОНАЖ, я хочу ДІЯТИ, щоб отримати РЕЗУЛЬТАТ”.

Job story дещо додає до цього:

ПЕРСОНАЖ: “У СИТУАЦІЇ я хочу МОТИВАЦІЮ, щоб досягти РЕЗУЛЬТАТУ”.

Основна відмінність полягає в тому, що job stories включають СИТУАЦІЮ користувача як контекст того, чому ваш персонаж отримує бажаний результат.¹ User story включає припущення про наміри вашого персонажа; job story пояснює ці припущення.²

Розгляньмо приклад людини, яка купує продукти з доставкою на Whole Foods Market від Amazon.com:

User Story

Як покупець продуктів, я хочу бачити товари, які я вже купувала раніше, щоб додати їх до свого кошика.

Job Story

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

Job story в цьому прикладі набагато більше розповідає про мотивацію покупця: вона, як правило, купує продукти щотижня; є товари, які вона постійно купує, але часто не звертає на них уваги; найкращий час для нагадування про ці товари – безпосередньо перед оформленням замовлення. Зауважте, що в ідеальному світі “Покупець продуктів” – це повноцінний персонаж, який використовується на всіх етапах розробки вашого продукту, наприклад, “Анна” – це 35-річна жінка з вищою освітою і доходом 100 тис. доларів, її продуктові потреби становлять … і т.д.

Зверніть також увагу: User Flows. Як ця техніка допомагає в роботі над проєктами

Job stories походять з Jobs-To-Be-Done (JTBD), маркетингової концепції продукту, яка стверджує, що клієнти хочуть купити результат, або “покращення” у своєму житті, а не набір функцій. За їхніми словами: “Робота, яку потрібно виконати – це процес, через який проходить споживач щоразу, коли він прагне змінити свою поточну життєву ситуацію на бажану, але не може, тому що існують обмеження, які його зупиняють”.

Як застосовувати в продукті

Моє емпіричне правило полягає в тому, щоб використовувати job stories до розробки рішення та user stories після розробки рішення. Інакше кажучи, job stories важливі під час роботи з командою над визначенням проблеми (не формулюючи рішення). Але після того, як ви пройшли стадію проектування, user stories більш ефективні для опису рішення.

Для прикладу, розгляньмо скорочений варіант процесу розробки продукту. Ваша команда починає з порожнього шаблону Product Requirements Document (документа з вимогами до продукту). Першим кроком є визначення job stories та критеріїв успіху (наприклад, метрик або KPI) для продукту. У цьому повинні брати участь усі стейкхолдери: ви, дизайнери, інженери, QA, колеги з бізнесу тощо. Цей процес гарантує, що всі мають спільне бачення щодо того, чого ви намагаєтеся досягти для бізнесу та кінцевого користувача (користувачів).

Після того, як ці історії визначені, можна переходити до етапу дизайну (проектування). Цей етап має включати численні дослідження користувачів, генерацію ідей, макети, проектні воркшопи з усіма стейкхолдерами тощо. У міру того, як ваша команда наближається до фінальних версій дизайну, ви маєте використовувати ці job stories як орієнтири.

Нарешті у вас є фінальний дизайн проекту.³ Це ефективне, дієве рішення для job stories. Щоб почати розробку, вашій команді потрібно розбити проект на керовані, пріоритезовані частини (тобто тікети). У вас можуть бути десятки тікетів для одного проекту! Правильний рівень абстракції для тікетів – це user story. У той час як job story призначена для розуміння і використання всіма стейкхолдерами, лише вашим інженерам (і дизайнеру, який підтримує процес розробки) потрібне розуміння user stories.

User story забезпечує досягнення визначеного користувачем результату в кожній виконаній частині роботи, при цьому довіряючи вашій команді інженерів з’ясувати, як найкраще спроектувати рішення в коді. У той же час, інженерам не потрібно перечитувати мотивацію користувача для кожного окремого тікета. Багато тікетів будуть деталізованими і дуже специфічними для реалізації продукту: “Як покупець продуктів, коли я натискаю кнопку “Оформити замовлення”, я переходжу на проміжну сторінку, яка показує мені картки попередніх придбаних товарів, щоб я міг додати їх у свій кошик, перш ніж перейти на сторінку оплати”.

Ось і все! Тепер ви знаєте, як і коли використовувати job stories та user stories у процесі розробки продукту.

¹ Можна умовно поставити знак рівності між поняттями ДІЯ і МОТИВАЦІЯ.

² Зауважте, що я формулюю job story з використанням першої особи як ПЕРСОНАЖА. Альтернативним способом може бути заміна “Я” на ПЕРСОНАЖА – однак на мій погляд, так втрачається перевага бачення від першої особи, яка ставить себе на місце користувача.

³ Загальне застереження: я значно спростив наведену вище історію. У результаті досліджень користувачів можуть бути запропоновані зміни до початкових job stories. Я також не вказав, звідки беруться ці job stories (імовірно, це поєднання досліджень користувачів, стратегії продукту та OKR на бізнес-рівні).