Як робити демо фічей, щоб після нього не залишилось питань щодо розробленого функціоналу

Привіт. Мене звуть Олена Кукліна. Я Project Delivery Manager у компанії Salesflow, яка займається автоматизацією розсилок через LinkedIn. Враховуючи, що ми — продуктова компанія, ми маємо багато департментів aka стейкхолдерів, які мають знати, як працює продукт та нові фічі, що релізяться.

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

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

Підготовка до демо

1. Заплануйте демо на зручний для всіх учасників час. Зверніть увагу на часові пояси, у яких перебувають люди, щоб нікого не пропустити.
   
   • Якщо ви виконуєте демо у своїй компанії, і ця група людей завжди однакова, створіть alias електронної пошти (наприклад, [email protected]) із попередньо визначеним списком людей у ​​ньому. Таким чином, вам не доведеться додавати їх вручну до запрошення для кожної демо.
2. Переконайтеся, що ви знаєте бізнес-контекст фічі, яку ви збираєтеся продемонструвати. В ідеалі ви повинні знати це ще до початку розробки, коли виявляєте вимоги під час оцінки. Однак всяке можете трапитись, і якщо бізнес-контекст невідомий, зберіть усю необхідну інформацію:
   
   • Яку бізнес-проблему вирішує ця фіча — це питання варто задати одному з хранителів знань. Це може бути ваш бізнес-аналітик, представник бізнесу, співробітники служби підтримки тощо.
   • Приклади поганих пояснень бізнес-контексту:
     
     • «Це обговорювалося в минулому...»
     • «Це запит від клієнта...» (без пояснення проблеми, через яку клієнт попросив імплементувати цей функціонал)
3. Підготуйте набір даних для використання під час демо. Ваш набір даних має містити дані у формі, яку використав би живий користувач. Тому обов’язково підготуйте:
   
   • Хороші дані — ідеальні життєві сценарії з даними, які не спричинять жодних помилок.
   • Погані дані — дані, які покажуть поведінку, яку побачать користувачі, коли вони введуть неправильні дані.
   • Хороші практики:
     
     • Переконайтеся, що ваш набір даних достатньо великий, щоб показати функцію в масштабі.
     • Ніколи не використовуйте дані клієнта для демо, оскільки це може спричинити різного роду ризики — безпеки, операційної діяльності, репутаціі, правові тощо.
4. Підготуйте сценарії, які ви будете показувати. Ці сценарії мають бути реальними.
5. Майте запасний план на випадок неочікуваних технічних проблем. Це може включати наявність скріншотів або попередньо записаного відео працюючого функціоналу як запасний варіант.
6. Оцініть приблизну тривалість демо. Ідеальна тривалість — 20 хвилин протягом 30-хвилинного інтервалу. Решта 10 хвилин відведіть на запитання від вашої аудиторії.
   
   • Якщо ви бачите, що демо потенційно триватиме більше 20 хвилин, розділіть його на окремі частини та заплануйте інший дзвінок.

Процес демо

1. Переконайтеся, що всі учасники присутні. Дайте людям приблизно 3 хвилини, щоб зібратися. Якщо хтось все ще відсутній, запитайте людину, яка з нею тісно співпрацює (їхнього керівника чи члена команди), чи слід на неї чекати.
2. Почніть запис дзвінка — самостійно, якщо це ваша відповідальність, або переконайтеся, що його почав призначений член команди. Записи важливі під час демо, оскільки:
   
   • вони допомагають зберегти план дій, які виникають у результаті зворотного зв’язку від аудиторії
   • запис буде збережено для історії, і люди зможуть посилатися на нього за потреби
3. Почніть із аженди дзвінка, оголосивши усі фічі, які ви збираєтеся продемонструвати під час дзвінка.
4. Під час демо певної фічі почніть із пояснення проблеми, яку вона має вирішити.
   
   • Щоб згадати, як краще презентувати проблему, яку потрібно вирішити, зверніться до пункту 2 у розділі «Підготовка до демо» вище.
5. Робіть паузи після кожного логічного сегменту, щоб кожен слухач міг поставити свої запитання.
   
   • Якщо ви не знаєте відповіді на якісь запитання, дослідіть та надішліть відповіді після демо.
6. Якщо під час підготовки демо виявлені баги, це цілком нормально, тому не треба їх приховувати. Краще показати баг і сказати: «Дивиться, тут є цей баг. Ми знаємо про нього і працюємо над його фіксом» ніж приховати баг, а хтось інший знайде його та повідомить як про щось, що було пропущено.
7. Якщо під час демо-версії виявлені нові помилки, не панікуйте — таке трапляється і це цілком нормально.
   
   • Не зупиняйте демо заради негайного дослідження проблеми. Це створить незручність, оскільки люди просто сидітимуть і дивитимуться на ваш екран, не знаючи, чи продовжується демо чи ні.
   • Скажіть щось на зразок «Я перепрошую. Це не було виявлено, коли я готувався до демо. Ми розслідуємо та виправимо це до релізу».
   • Продовжуйте демо за планом.
   • Якщо проблема блокує флоу, який є частиною демо, і немає швидкого обхідного шляху, який би розблокував вас, скористуйтеся одним зі способів нижче щоб продемонструвати роботу фічі:
     
     • Якщо заплановане інше демо, включіть відсутній флоу у нього.
     • Якщо демо не заплановано, запишіть відео працюючого функціоналу та надішліть його у загальний канал у месенджері компанії.

Після демо

1. Після завершення демонстраційної частини дзвінку і отримання відповідей на всі запитання промовте вголос усі пункти плану дій, щоб усі знали, що від них потрібно, і коли очікувати вирішення проблем, які могли виникнути під час демо.
   
   • Це можете зробити ви або особа, яка за це відповідає (наприклад, PM або BA).
2. Попрощайтеся на позитивній ноті ;)
3. Надішліть підсумок дзвінка у загальний канал у месенджері компанії.
   
   • Це можете зробити ви або особа, яка за це відповідає (наприклад, PM або BA).
4. Завжди шукайте фідбек на свої навички проведення демо. Для цього проведіть коротку ретроспективу після дзвінка з командою, щоб обговорити, що вийшло добре і що можна було б покращити для майбутніх демо.

Чекліст для проведення якісного демо

Чекліст для підготовки до демо

Планування демо

1. Заплануйте демонстрацію на зручний для всіх учасників час.
2. Якщо демонстрація призначена для внутрішньої групи, створіть alias електронної пошти для постійних учасників.

Розуміння бізнес-контексту

1. Переконайтеся, що ви знаєте бізнес-контекст функції.
2. Визначте бізнес-проблему, яку вирішує функція.
3. Підтвердьте контекст у бізнес-аналітика, представника бізнесу або служби підтримки, якщо потрібно.

Підготовка набору даних

1. Підготуйте набір даних, який відображає реальні сценарії користування фічею.
2. Додайте хороші дані, які представляють ідеальні випадки використання.
3. Додайте погані дані, щоб продемонструвати обробку помилок та edge cases.
4. Переконайтеся, що набір даних достатньо великий, щоб показати об’єкт у масштабі.
5. Не використовуйте реальні дані клієнта, щоб уникнути безпекових, операційних або юридичних ризиків.

Підготовка сценаріїв

1. Створюйте сценарії, що відображають ситуації з реального життя.
2. Оцініть тривалість демо (ідеально — 20 хвилин протягом 30-хвилинного інтервалу).
3. Якщо демо перевищує 20 хвилин, розділіть його на кілька сеансів.

Чекліст для процесу демо

Початкове налаштування

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

Демо в процесі

1. Почніть із аженди, у якому перелічено всі фічі, які будуть показано.
2. Для кожної фічі почніть із пояснення проблеми, яку вона вирішує.
3. Якщо необхідно, зверніться до бізнес-контексту.
4. Зробіть паузу після кожного логічного сегмента, щоб дати змогу поставити запитання.

Обробка помилок

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

Чеклист дій після демо

Завершення демо

1. Проговорить план дій та хто за них відповідальний, щоб переконатися, що всі знають, що від них очікується.
2. Закінчіть сесію на позитивній ноті.

Подальше спілкування

1. Надішліть підсумки демо в загальний канал у месенжері.
2. Включіть план дій, відповідальних та очікуваний графік вирішення.

Проведення ретроспективи

1. Заплануйте коротку ретроспективу з командою після демо, щоб отримати зворотній зв’язок для майбутнього вдосконалення навичок проведення демо.

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

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