Ітеративна модель розробки. 5 уроків, які ми засвоїли
Привіт, мене звати Ян Лікаренко, я продакт-менеджер у компанії Uptech. У 2018 році до нашої компанії звернувся клієнт із Каліфорнії з цікавим задумом створити застосунок для запису відео з можливістю зображення їх на мапі. Ідею клієнт уже частково провалідував, але в нас були сумніви щодо цільової аудиторії та потреб, які мав задовольняти продукт. За таких умов потрібно було вибрати модель розробки, яка б давала змогу тісно взаємодіяти з користувачами та змінювати продукт у процесі. Ітеративна модель підходила для нас якнайкраще.
Утім цей підхід має свої особливості. У статті розповім, перед якими труднощами ми постали, і поділюся уроками, які засвоїли. Матеріал буде цікавий командам, які хочуть займатися не лише технічною, а й продуктовою стороною розробки, а також підприємцям, що мають ідею, але не мають чіткого бачення продукту.
Що таке ітеративна розробка
Ідея ітеративної розробки така: замість однієї довгої послідовності дій увесь життєвий цикл продукту ділиться на кілька мініциклів (ітерацій). У кожній з ітерацій розробляється чи поліпшується окремий компонент системи, після чого він додається до раніше розробленого функціоналу.
Мініцикли повторюються, і результатом кожного є оновлена версія продукту, яка, своєю чергою, проходить тестування з користувачами. Для перевірки концепції продукт не має бути повністю готовим, достатньо реалізувати базову частину функцій.
На початку розробки ми поставили такі завдання:
- провалідувати бізнес-ідею та гіпотези з користувачами продукту;
- з’ясувати, як користувачі взаємодіють із базовим функціоналом;
- зрозуміти основні потреби аудиторії, чи справді потрібен наш інструмент;
- проаналізувати поведінку користувачів, вивести патерни.
Спочатку ми мали тільки бізнес-ідею. Завдяки ітераційному підходу виконували роботу частинами, тестували готові функції та оперативно вдосконалювали продукт на базі відгуків користувачів.
Ітеративна модель підійде для тих, хто:
- розробляє MVP-версію продукту для оцінювання концепції та пошуку product/market fit;
- працює над невеликими стартапами й поки не знає, яким має бути продукт;
- хоче створити продукт, що задовольнятиме конкретні потреби;
- зацікавлений у постійному розвитку свого проєкту.
Недоліки, які має ітеративна модель:
- не кожен клієнт погодиться на такий підхід, більшість віддає перевагу класичним методам розробки;
- потребує багато часу, тому можна не вкластися у визначений бюджет і дедлайн;
- потенційні проблеми з архітектурою, оскільки вимоги до продукту постійно змінюються. Крім того, щоб надати їй адекватного вигляду, можуть знадобитися додаткові ресурси.
Уроки, які засвоїли
Урок 1. Discovery Stage — мастхев у розробці продукту
Discovery Stage — це попередній етап, на якому виявляється цільова аудиторія, її потреби та проблеми. Основна мета — підтвердити або спростувати припущення щодо продукту та зрозуміти, чи вирішує він проблему користувача.
На початковому етапі треба скласти приблизні Customer Journey Map (CJM) і Proto Persona. Для цього необхідно досконало знати свою аудиторію: чим вона живе, з якими проблемами стикається.
Щоб скласти «персону» користувача, ми провели невелике інтерв’ю з потенційною аудиторією. Через живу комунікацію зрозуміли, що найбільше її турбує (pains) і як можемо допомогти це виправити.
Дослівно Customer Journey Map — це мапа подорожі користувача. Вона показує точки дотику людини з продуктом, тобто ті етапи, які долає користувач для досягнення своєї мети.
У нашому випадку CJM постійно оновлювалася впродовж проєкту. Ми підлаштовувалися під наших користувачів і розв’язували нові проблеми в кожній ітерації.
На базі виявлених під час інтерв’ю потреб і проблем користувачів складали гіпотези та тестували їх. Лише після цього побачили реальну картину того, хто наш користувач і які в нього потреби.
Урок 2. Розробка функціоналу не має займати багато часу
На перших спринтах розробки ми занадто уважно ставилися до всіх деталей і досконало допрацьовували всі фічі. Однак після інтерв’ю з користувачами та тестування виявлялося, що велику частину функціоналу треба змінювати та адаптувати до нових вимог. Наприклад, після перевірки прототипів ми реалізували теги та фільтрацію відео.
Уже після релізу продукту побачили, що людям важко зрозуміти, як користуватись таким функціоналом. Тому після кількох ітерацій об’єднали схожі фічі з рядком пошуку в застосунку, чим досягли поставлених метрик.
Зміна готового функціоналу може займати багато часу команди та уповільнювати роботу. З часом ми припинили так робити і стали гнучкішими.
Отже, для тестування бізнес-ідеї достатньо реалізувати лише базову частину функцій. Після тестування MVP з фокус-групою визначаються подальші вимоги до продукту. Код у такому разі не має бути на 100% ідеальним. Утім він має виконувати своє цільове призначення та давати змогу провести тестування. Про деталі дизайну можна подбати пізніше.
Наприклад, спочатку ви можете мати лише нарис функції, щоб перевірити, як нею користується аудиторія. Скажімо, прототип кнопки, що надсилає відео іншому користувачеві в чаті. Коли людина натискає на кнопку, вона бачить повідомлення про те, що функція перебуває в розробці й буде доступна найближчим часом. Отже, ви можете дізнатися, наскільки вона є запотребованою серед учасників фокус-групи, не розробляючи функціонал повністю.
Такий підхід дає можливість задати вектор розвитку продукту та зменшити витрати через попередню валідацію ідей та функцій.
Урок 3. Тісна комунікація з користувачами допомагає створити якісний продукт
Для повного розуміння потреб, патернів і звичок користувачів недостатньо лише проводити тестування user flow. Важливо створювати фокус-групи, опитувати людей особисто та збирати фідбек.
Із самого початку важливо знайти так званих early adopters — групу потенційних користувачів, які тестуватимуть застосунок і надаватимуть зворотний зв’язок. Звісно, не всі з обраних учасників точно потраплять у вашу цільову аудиторію. Втім, що раніше ви почнете тестувати гіпотези з реальними користувачами, то швидше збагнете, хто саме ваша цільова.
На перших етапах тестування нашого мобільного застосунку користувачі порівнювали його з Instagram та Foursquare. Ми зрозуміли, що результати тестування не визначають цінність продукту, а лише показують, наскільки успішно користувач рухається по флоу. Коли ж зарелізили продукт і він потрапив у реальне середовище, то побачили, що він корисний для іншої цільової аудиторії. На ній ми і сфокусувалися.
Отже, важливо з самого початку визначити свою цільову аудиторію та якомога швидше затестувати MVP-версію продукту з користувачами.
Урок 4. Потрібно сформувати з командою спільне бачення продукту
Проєкт розвиватиметься повільно, якщо команда не має чіткого бачення продукту та не знає, як рухатися далі. Тому варто долучати всіх членів команди до проведення Discovery Stage, визначення цільової аудиторії та основної проблеми, яку вирішує продукт. На основі цих даних сформуєте загальне бачення майбутнього проєкту та його функціоналу.
Tip — не варто перетворювати продукт на швейцарський ніж і наповнювати його всіма фічами, які спадають на думку. Пам’ятайте, ваш продукт — це інструмент для розв’язання проблем користувача.
Зі свого досвіду раджу створити дорожню мапу (roadmap) для кращого планування розвитку продукту. Як уже зауважували, в ітеративній моделі вимоги до продукту постійно змінюються. Завдяки roadmap можна вносити такі зміни та візуалізувати прогрес.
Дорожня мапа дасть змогу команді знати:
- у якому напрямку рухається проєкт;
- на якому етапі перебуває;
- чого треба досягти найближчим часом;
- пріоритетність завдань.
Вам і вашій команді не доведеться витрачати купу часу на планування подальших завдань. Навпаки, кожен учасник має перед собою довгострокову стратегію та може сам вносити ідеї щодо того, як швидше досягти результату. Це особливо ефективно для Agile-команди, де на кожному етапі розробки залучені спеціалісти з різних сфер.
Урок 5. Клієнт має бути на одній хвилі з вами
Необхідно насамперед пояснити клієнту методи, які використовуєте під час розробки. Якщо цього не зробити, є великий ризик, що він хаотично вноситиме правки в проєкт і вимагатиме негайних змін.
Перед розробкою ми пояснили замовнику, як будемо працювати під час спринтів і як управляти беклогом. Згодом збирали завдання у беклог і тільки після їхньої валідації та тестування починали розробку відповідно до визначеного пріоритету. Клієнт натомість вважав, що зміни до продукту мають бути миттєвими, щоб швидше задовольнити потреби клієнтів. На практиці ж це вносило деструктив у розробку й не давало змоги зробити розпочатий функціонал до дедлайну.
Як продакт-менеджер проєкту я пояснював клієнтові особливості ітераційної моделі та методологію розробки: навіщо валідувати ідею, чому важливо проводити не лише тести, а й опитування користувачів, як створювати та перевіряти гіпотези. Після кількох ітерацій ми вже працювали злагоджено.
Звісно, замовник може вносити зміни та нові ідеї. Однак кожну нову ідею ми обговорюємо командою, перетворюємо в гіпотезу, робимо прототип і тестуємо. Тільки якщо задум відповідає реальним потребам користувача, він реалізується у новий функціонал продукту.
Висновок
Ітеративна модель — це ефективний підхід до розробки продуктів із багатьма невідомими. Якщо ви маєте намір динамічно розвивати проєкт, постійно поліпшувати функціонал та адаптувати його до потреб користувачів, то це гарна альтернатива традиційній водоспадній моделі.
Ітеративна розробка не підійде, якщо:
- продуктова команда володіє експертними знаннями у сфері, й нема потреби тестувати бізнес-ідею;
- клієнт звертається до вас із попередньо добре провалідованою ідеєю продукту;
- дотримання таймлайну та бюджету є критично важливими для клієнта.
