Продакт-менеджер компанії Uptech Ян Лікаренко у своїй статті розказує історію продукту Yaza для американського ринку, для створення якого команда використовувала ітеративну та інкрементну модель.

Про проект

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

Головною задачею проєкту якраз і була валідація такої ідеї та концепту на реальних користувачах. 

Якщо ж говорити про бізнес-цілі більш детально, то на період розробки й бета-тесту їх було декілька: 

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

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

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

Що таке ітеративна та інкрементна розробка? 

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

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

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

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

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

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

В який випадках ітеративна розробка є корисною? 

  • Бізнес-вимоги до кінцевої версії заздалегідь відомі та зрозумілі.
  • Проект середнього-великого розміру (тривалістю 3-6 місяців)  і має багато невідомих складових.
  • Основна задача продукту відома, в той час коли деталі ще мають бути віднайдені.
  • Це — MVP версія, спрямована на валідацію гіпотези і пошуку Product Market Fit.

Переваги інкрементної розробки: 

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

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

Ітеративна та інкрементна розробка на практиці

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

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

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

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

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

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

Dual track mode в такому випадку забезпечує continuous user research і швидку валідацію гіпотез. Отримуючи фідбек, без затримок ви можете робити клікабельний прототип і тестували його з користувачами. Після цього можна дизайнити ваші фічі й передавати їх у розробку. У такому стилі, але з певними покращеннями продовжуємо рухатися протягом усього проекту. 

Переваги Dual track: 

  • він об’єднує дослідження і розробку, які працюють паралельно;
  • дослідження продукту дозволяє перевірити ідеї, перш ніж взяти їх в розробку;
  • dual track дає можливість командам розробників бути впевненими, що вони будують правильні речі;
  • перш за все, dual track означає, що ви можете швидко та ефективно робити вдосконалення продукту.

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

Зміна концепцій

Доставка функцій частинами та швидкі ітерації дадуть вам змогу не тільки додавати нові функції, але й покращувати старі й змінювати заплановані. Ось як це відбувалось на проекті Yaza:

version 0.1 ->

Ми стартували зі світлої теми інтерфейсу. Загальна ідея полягала у фокусуванні уваги користувача на головному екрані. Ми давали можливість записувати контент і розміщувати його на карті.

version 0.5 ->

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

Завдяки цьому нам вдалося суттєво покращити наявний концепт: ми відійшли від закритого типу системи до відкритого, тобто тепер наш контент став вільним для перегляду, а не закритим/захованим у місцях (мітках) на карті. 

version 0.8 ->

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

Release version ->

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

Результати роботи

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

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

Я б радив використовувати такий підхід тим, хто:

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