×

Чим корисна для продакт-оунерів «Мапа історій користувача». Огляд книги

Вітаю! Мене звати Євген Грішенко, я Product Owner в компанії SciPlay. Раніше я вже ділився своїм оглядом корисної для геймдев-спеціалістів книги A Theory of Fun for Game Design. А у цьому матеріалі хочу поговорити про книгу «Мапу історій користувача» (User Story Mapping).

Якби мене запитали яку одну книгу має прочитати продакт-оунер/менеджер початківець, то я б назвав саме цю книгу. Так, багато хто скаже про «Ощадливий Стартап» Еріка Ріса чи «Від нуля до одиниці» Пітера Тіля, які вважаються настільними книгами продакт-менеджерів чи стартаперів, але саме ця книга дає те, чого, на мою думку, не вистачає іншим книгам. А саме — чіткий та зрозумілий алгоритм як працювати із розробкою продукту на будь-якій стадії його життєвого циклу, не обов’язково зі стартапом, а навіть із величезним та громіздким ентерпрайзом, або, як би це кумедно не звучало, навіть із вашою вранішньою рутиною.

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

Чи буде ця книга цікава тільки менеджерському складу команд, тобто людям, що приймають рішення по тому, що буде розроблятися в продукті? Аж ніяк. Інформація, що в ній міститься, буде цікава розробникам, які зможуть навчитися ставити правильні питання своїм менеджерам, тестувальникам, які краще стануть розуміти бізнес-кейси для тестування, бізнес-аналітикам та UX-дизайнерам, які зможуть краще почати розуміти свого «клієнта».

Мапа допомагає не тільки пройти по шляху, а й визначити його

Мапа — це дуже корисна річ в будь-якій сфері нашого життя. Насправді це може бути мапа мандрівки, мапа дослідження, мапа покупок у супермаркеті.

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

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

Або ж просто, що кожна історія має містити «business value», цінність для бізнесу. За цією досить розмитою фразою можна багато чого сховати, і, зазвичай, за нею мають на увазі, що ми маємо отримати якийсь видимий шматочок функціональності, із яким би міг взаємодіяти фінальний користувач продукту, якби ми його посилили за поточний білд із розробки.

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








Важка правда

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

На жаль, навіть після шаленого успіху книги «Ощадливий Стартап», ще дуже і дуже багато компаній працюють по тому принципу, що перший реліз повинен бути великим. З максимумом функціональності, адже, а як раптом, користувач чогось не знайде, та покине програму?

Насправді як показує практика, та досвід автора книги «Мапа історій користувача», все навпаки. Чим раніше вийде хоча б якась версія програми, яку зазвичай називають MVP (minimal viable product) тим раніше користувачі нададуть фідбек, тим раніше можна отримати перші метрики та скоригувати власну стратегію бачення розвитку продукту, а може й навіть повністю його скасувавши. А в деяких випадках, може вистачити усього 5 днів на тестування гіпотези.

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

На жаль, для українських «продуктологів» все ще є викликом одна із технік роботи із потенційними клієнтами, така я безпосереднє спілкування, чи збір фокус груп. Адже продукти із якими ми працюємо здебільшого скеровані на західну аудиторію і інсайти, які ми можемо отримати від спілкування в Україні можуть разюче відрізнятися від тих, які б ми отримали у Франції, чи США, вже не кажучи про те, що у нас немає локальної культури подібних взаємодій та опитувань.

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

А як же розробляти ігри?

У ігробуді найбільш розповсюдженим документом, який описує все, що відбувається в грі є дизайн документ гри (game design document), в якому міститься опис усіх механік, візуального стилю, настрою гри, дизайну рівнів і т.д. Однак, немає одного узгодженого стандарту такої документації, та у різних розробників, чи то відповідальних за ДДГ осіб, цей документ може мати абсолютно різний вигляд.

Так, у першій ітерації ДДГ GTA лише 12 сторінок, а у Doom їх 79 ДДГ мають абсолютно різний рівень деталізації та пропрацювання.

Саме тому, хоча ДДГ і є «найголовнішим» документом під час розробки гри, але він не може слугувати основою для «технічної» частина, тобто для безпосередньо розробки. При цьому мапа історій, знову ж таки, стає вкрай помічним інструментом для візуалізації саме процесу розробки — яку функціональність у якому порядку додавати, як гравець буде із нею взаємодіяти тощо.

У поточних умовах, коли значна частина команд працює віддалено і немає можливості знаходитися в одній кімнаті, щоб дійсно мати змогу працювати із паперовими стікерами, помічними інструментами стають Miro та Lucid Chart та їм подібні. З власного досвіду можу зазначити наскільки легше стає комунікація із командою та планування спринтів, коли є змога показати на борді не тільки картки з описом функціональності, а і той взаємозв’язок, який між ними є.

І в результаті...

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

На додачу до самої мапи історій, автор розповідає про додаткові інструменти, які допомагають взаємодіяти із розробкою — дизайн-мислення, «ощадливу» розробку, та інші.

Саме тому, тому що ця книга дає огляд працюючих інструментів для щоденного використання я вважаю її такою цінною, більш значущою для початківців ніж прочитання окремої книги з кожної цих тем, що були згадані вище. Адже, хай, Lean Startup і розкаже про дух стартаперської спільноти, як ніяка книга ліпше, але «Мапа історій користувача» розкаже вам як працювати щоденно із високою ефективністю.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному2
LinkedIn

Схожі статті



Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за статтю. Підкажете де можна придбати книгу?

Судячи з усього — ніде)
Два дні вже намагаюсь знайти і безрезультатно. Прийдеться йти в книжковий і замовляти...

Підписатись на коментарі