Сім кроків до досконалої епіки, або Як продакт може спростити життя розробникам

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

Привіт! Я — Марія Бандерс, продуктова менеджерка в компанії AMO. У AMO Apps, що спеціалізуються на Health & Fitness ніші, я працювала над запуском застосунку для жінок HARNA.

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

Для кого буде корисна ця стаття:

  • перш за все для стартапів та нових продуктів, що спеціалізуються на мобільних застосунках або створюють вебсервіси B2C/B2B для користувачів;
  • для продактів-початківців;
  • для команд, де ще не до кінця налагодили процеси idea → design → development → production.

Чому продуктова документація потрібна:

  • голова продакт-менеджера не має бути єдиним джерелом інформації про продукт, який ви робите;
  • має бути джерело правди — зафіксована письмово інформація про те, як має працювати додаток;
  • якісна продуктова документація допомагає QA/розробникам ефективніше та швидше проводити тестування;
  • хороша документація покращить порозуміння продуктової та технічної команд, зменшить кількість запитань і неоднозначності у виконанні задач.

Змоделюємо всі кроки для покращення епіки

Пропоную розібрати всі рекомендації покроково на практичному прикладі — опишемо частину функціоналу відеоплеєру для перегляду тренування у застосунку HARNA.

Відмовтесь від написання продуктової документації у форматі User-Story.

Ризиково описувати це в першому ж кроці, бо ця порада суперечить більшості посилань на першій сторінці у Google — але як є.

Подивімось на відеоплеєр:

Ви можете написати:

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

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

Як користувачка, я...

Але чи потрібна ця інформація розробнику? Чи зручно з неї розуміти, як має працювати плеєр? Скільки часу піде на те, щоб відкинути одноманітні вступи?

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

Тоді альтернатива:

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

Максимально продумайте й опишіть можливу поведінку користувача.

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

Деякі загальні приклади залежностей:

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

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

У цьому разі маємо такі залежності:

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

Пропишимо це в епіку:

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

Якщо користувачка під час перегляду знаходиться на першій вправі, що починається з таймкоду 00;00;00;00, натискання на кнопку Prev запускає відео тренування з самого початку.

На всіх інших вправах натискання на кнопку Prev включає таймкод початку попередньої вправи.

Для локалей за винятком англійської — кнопки Prev та Next без тексту, аналогічний функціонал зберігається лише на стрілочках назад/вперед.

Якщо користувачка переглядає останню вправу, кнопка Next закінчує воркаут.

Прописуйте приклади.

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

Нехай користувачка переглядає тренування тривалістю 5:25 хвилин, що містить наступні таймкоди:

00;00;00;00 Squats Preview

00;00;25;00 Squats

00;01;25;00 Rest

00;02;25;00 Squats

00;03;25;00 Rest

00;04;25;00 Squats

В момент відео 00;00;10;00 користувачка переглядає вправу Squats Preview. Натискання на кнопку «Prev» запустить відео з 00;00;00;00.

Якщо користувачка в момент відео 00;00;10;00 натисне «Next», відео запуститься з початку наступної вправи — 00;00;25;00.

В момент 00;05;00;00 користувачка знаходиться на останній вправі Squats. Натискання «Prev» відкриє попередню вправу — це Rest з початком в 00;03;25;00.

Якщо в момент 00;05;00;00 натиснути на «Next», воркаут закінчиться — адже наступної вправи вже немає.

Вставляйте до опису посилання на дизайн, а не скрини.

Як у Confluence, так і в Notion можна зручно імпортувати посилання на потрібні екрани у Figma. Це зручніше як для роботи з вашою документацію, так і для того, щоб у випадках, де «щось змінилось і не помітили», це виявили значно швидше (приклад: написали епіку, віддали розробникам, а десь в процесі реалізації змінили дизайн).

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

Приклад, як виглядають вставки з Figma у вигляді preview в Notion-документації:

Пишіть епіку англійською (або перекладайте на англійську для фінальної документації).

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

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

Зробіть епіку читабельною.

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

Дайте вичитати епіку QA, якщо вони є у команді.

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

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

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

Порівняймо нашу епіку «до» і «після»:

(*) Бонус: як структурувати документацію.

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

Для «відеоплеєру» у продуктову документацію входить не тільки перемикання між вправами, а і перехід в landscape вручну та поворотом телефона, налаштування звуку, описані точка входу/виходу з екрана тощо.

Функціонал одного екрану/одного flow краще описувати на окремих сторінках і за потреби робити посилання між ними. Приклад — епіка для «Налаштувань», епіка для «Онбордингу», епіка для «Головного екрану в застосунку» із посиланням на «Відеоплеєр» у місці, де описується точка входу у початок тренування.

Ми також до кожної епіки додаємо high-level description — що описано на сторінці та бізнесовий короткий key value — для чого ми цей функціонал робимо.

Summary

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

  • нові члени команди (як продуктової, так і технічної) легше зможуть розібратися з тим, як працює продукт;
  • ви маєте зафіксований source of truth того, як має працювати продукт;
  • робота у парі Product + QA допоможе зменшити кількість кейсів, де щось у додатку ламається, бо не закладали якісь сценарії поведінки, і це не доведеться продумувати і фіксити в гарячці перед релізом;
  • розробникам не потрібно буде вгадувати та перепитувати, що ви мали на увазі усно презентуючи дизайн нового функціоналу;
  • продуктова та технічна команда — on the same page у тому, що відбувається у продукті;
  • віддаючи гарно пропрацьовану задачу в розробку, ви можете зосередитись на підготовці наступних фічей/аналітиці/user interview/etc, менше відволікаючись на тисячі запитань з функціоналу, який продумували день/тиждень/місяць назад.

Відкрита до питань та обговорення як запропонованого, так і інших, альтернативних принципів створення продуктової документації :)

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному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

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

OMG

Відмовтесь від написання продуктової документації у форматі User-Story

Дивіться щоб взагалі описувати User Story ви маєте знатись на Методі Персон. Найкраща книга яка описує цей метод — Це безцелер Алана Купера «Психлікарня якою керують пацієнти» (провокуюча назва)
www.amazon.com/...​um-Products/dp/0672326140
(як я знаю є обов’язковим матеріалом для співробітників Apple)
Коротко — програма має проектуватись відповідно до вимог. Вимоги формуються відповідно до процесів які автоматизуються, а для цього ви маєте мати чітке розумінні хто та як користуватиметься ПЗ. Тому маючи перелік таких користувачів системи, фіксовний, ви можете записати що вимагається автоматизувати — які конкретно процеси.
Формат опису історії теж заявився не на пустому місці, справа в тому — що ви можете починати зі стану Tabula rasa, коли у вас нема ще ніякого дизайну, та навіть скетчів і т.п. І ви з командою продумуєте як спроектувати користувацький інтерфейс таким чином, щоби людині яка буде користуватись софтом це буде зручно, а не переробляти мало не усе після UX/UI, End-To-End та інших форм тестування коли з’ясується, що дизайн не зручний. Записуючи користувацьку історію ви надаєте ключову інформацію для проектування. Звісно це далеко не єдиний з доступних методів, попередні державно-віськові методи конструктивно-водопадного підходу (за авторством Генрі Форда) вимагали довгих фаз аналізу та проектування з тисячами сторінок документації, що часто призводило до витрачання великих коштів без отримання результатів крім томів документації. Це почали обходити саме ітеративними підходами.
Профільні спеціалісти, з розробки дизайну і т.п. легко вже маючи таку інформацію — хто як і для чого користується системою яку розробляють (або підтримують), зможуть спроектувати систему, відповідно реалізувати її в коді і відтестувати — значно швидше і дешевше ніж експериментальним підходом до розробки.
Як це робиться теж є в купі книг та навчальних матеріалів, вивчають в університетах тощо. Одна з відоміших книг де вже описується як це роби — Роберта Мартіна (дяько Боб) Clean Architecture. Так само Exteam Programing Кента Бека тощо.

Як застосувати Ваш коментар для

Для кого буде корисна ця стаття:

перш за все для стартапів

?

Це виглядає як суха теорія, яка має мало спільного з реальною розробкою.

Набути власних знань, замість використання чужих коштує доволі дорого. Звісно методологія розробки ic.pics.livejournal.com/...​/68035718/427/427_600.jpg та проектування i.pinimg.com/...​bd757f217e437e263218f.jpg в усьому світі превалює, це реалії.
Це усе таки світ бізнесу, а не інженерів. Тим не менше є такі компанії як Apple, а є «Рога та копита інкорпорейтет». Так от кого треба брати за взірець ???

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

Змішалося усе, і коні, і люди.

Дякую за запитання!

У всіх командах, де працювала, саме на продакт менеджерах стояла задача опису задачі і підготовки функціоналу з ідеї та дизайну в розробку. Далеко не у всіх невеликих командах — та і насправді не всіх великих — є окрема роль BA, в обовʼязки якого це входять ці задачі :)

Щодо User story — вважаю, що це не найвдаліший спосіб описати функціонал для розробників, який все ж використовують у деяких командах. У статті наводжу його як приклад та пропоную, як це можна робити інакше.

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