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

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

Привіт! Я — Марія Бандерс, продуктова менеджерка в компанії 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, менше відволікаючись на тисячі запитань з функціоналу, який продумували день/тиждень/місяць назад.

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