Maxym Zosуm

Story Mapping

Zosym Maxym -

Метод упорядкування історій користувачів для створення більш цілісного уявлення про те, як вони вписуються в загальний користувацький досвід (UX). Розташовані на горизонтальній осі, основні етапи подорожі клієнта (іноді позначені як епічні, іноді ні) розташовані в хронологічному порядку на основі того, коли користувач виконує конкретне завдання відносно його загального робочого процесу з продуктом.

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

Story Mapping зазвичай робиться на стіні (або підлозі) за допомогою клейких нотаток або індексних карток і багатьох стрічок. Зазвичай, вся команда визначає та узгоджує основні кроки подорожі користувача, а потім розподіляє історії користувачів під ними.

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

Навіщо використовувати Story Mapping?

Картування історій служить декільком ключовим цілям.

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

По-друге, вона також може виявити прогалини у функціональності або області, на яких слід зосередитися, оскільки вона може візуально підкреслити прогалини у користувацькому досвіді.

Нарешті, Story Mapping також може бути чудовим інструментом для визначення пріоритетів як для MVP (мінімум, необхідний для досягнення загальної мети), так і для наступних релізів (чого не вистачає, що повинно/повинно/може бути там).

Звичайно, найчастіше картування історій використовується як альтернатива "плоскому" управлінню відставанням, коли кожен елемент розглядається у вакуумі, а не у візуальному, загальному контексті. Впорядкування відставання без контексту може спрацювати, але ви втрачаєте шанс побачити зв'язок і важливість кожного елемента для загального шляху.

Яка історія картування історій?

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

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

Хоча Джефф почав представляти цю концепцію світу ще у 2005 році, офіційну назву "story mapping" вона отримала лише у 2008 році. Однак за десятиліття, що минуло з моменту її впровадження, вона була прийнята багатьма прихильниками гнучких підходів і включена в численні інструменти та програмні рішення для команд розробників продуктів.

Як працює Story Mapping?

Основою Story Map є основний набір кроків, які користувач повинен виконати, щоб досягти своєї мети. Під кожним кроком містяться деталі для кожного з більших кроків ("великим" кроком може бути "оформлення замовлення", тоді як менші кроки нижче можуть включати введення/вибір адреси доставки, вибір способу доставки, введення/вибір способу оплати, підтвердження відправлення, відправлення деталей відправлення тощо).

Що дійсно робить Story Mapping ефективним, так це його опора на візуальну складову як частину інтерактивного, спільного процесу. Перегляд PowerPoint або в JIRA - це пасивний досвід, який, в кращому випадку, викличе сильну реакцію аудиторії - я згоден, я не згоден, це неправильно і т.д. - але рідко призводить до реальної розмови.

Story Mapping є інклюзивним та інтерактивним.

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

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

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

Story Mapping ніколи не бувають "готовими".

Story Mapping - це безперервна робота, що триває. По мірі того, як завершуються певні етапи, визначаються пріоритети для нових і додаються додаткові етапи. Тим часом, відгуки користувачів та конкурентний аналіз виявляють нові вимоги.

Таким чином, незалежно від того, чи залишаєте ви свою Story Map в актуальному стані, чи оновлюєте її, чи періодично перебудовуєте з нуля, основа та ключові кроки залишаються частиною процесу.

Регулярна переоцінка вашої Story Map є корисною і рекомендованою. Ви можете або залишити її на стіні назавжди, або періодично відтворювати, що саме по собі може бути корисною вправою.

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

Коли варто використовувати Story Mapping?

Чудова річ про Story Mapping полягає в тому, що ви можете почати використовувати його на будь-якій фазі життєвого циклу продукту.

  • Працюєте над MVP? Story Map - це відмінний спосіб визначити мінімальний функціонал, необхідний для тестування вашої концепції. Вона не дозволить вам "забути" про критичні частини користувацького досвіду, які ви могли б ігнорувати.
  • Намагаєтеся зрозуміти, як поліпшити версію 1.0? Карта історії може візуально відобразити всі потенційні поліпшення, які ви можете додати, і допомогти вашій команді якісно обговорити, що найбільше вплине на ваших користувачів.
  • Управління вашим беклогом викликає все більше занепокоєння? Карти історій допомагають приборкати відставання, надаючи кожному елементу певний контекст і змушуючи розставляти пріоритети і групувати їх з огляду на загальну картину; крім того, вони можуть висвітлити прогалини, які ви могли б ніколи не помітити в іншому випадку.
  • Розгалужуєтесь з новим розширенням продукту? Story Map проілюструє те, що у вас вже є, а також відсутні елементи, які вам знадобляться для того, щоб нова функціональність працювала так само добре, як і ваша поточна пропозиція.

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

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

Які існують способи використання Story Mapping для визначення пріоритетності ініціатив дорожньої карти?

Story Map є чудовим вкладом у процес складання дорожньої карти. Коли кожна потенційна функція вже відображена на карті і визначена за пріоритетами, ви можете об'єднати найбільш пріоритетні функції у випуски, виходячи з пропускної здатності вашої команди і частоти випусків.

Оцініть речі за розміром

Заповніть вашу Story Map, розташувавши менші елементи зверху донизу за ступенем важливості. Потім, співпрацюючи з розробниками продукту, визначте для кожного пункту відносний рівень зусиль (level of effort - LOE). Це можуть бути людино-години, дні або тижні, або ви можете використовувати іншу систему, яка дасть керівнику продукту уявлення про те, скільки часу займе кожна річ.

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

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

Наприклад, у вас може бути команда розробників з п'яти осіб і цикл випуску, в якому кожен розробник має 50 людино-годин на розробку нових функцій, що дає вам 250 годин для роботи.

Розподіл завдань

Тепер, озброївшись "бюджетом" розробки, рейтингом кожного елемента і вартістю LOE для кожного елемента, ви маєте достатньо інформації, щоб почати розподіляти елементи по випусках для вашої дорожньої карти. На цьому етапі Story Map вже виконала більшу частину важкої роботи, і ви, по суті, працюєте зверху вниз від основи, щоб побачити, скільки ви можете вмістити в кожен реліз.

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

Останній підхід може мати сенс для продукту на стадії становлення (коли ви просто намагаєтеся створити базовий рівень функціональності) або коли продукт вже досить зрілий.

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

Визначення результатів

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

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

Ітерація на виду

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

Це дозволяє швидко виводити нову функціональність на ринок, водночас удосконалюючи дизайн і виконання на основі відгуків користувачів. Це також скорочує кількість спринтів, які "закладають фундамент", але не приносять жодної реальної користі кінцевим користувачам.

Story Mapping - один з багатьох інструментів визначення пріоритетів

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

Однак, Story Mapping не є швидким процесом - зрештою, ви мапуєте кожну історію користувача (user story), і вам знадобиться відповідний фізичний простір для цього. Можливо, вам доведеться переконати керівництво в тому, що це корисне використання часу кожного з нас, а не їх звичайне заплановане програмування.

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

Інші методи визначення пріоритетів продукту (Prioritization Frameworks):