Як ми за три дні розробили прототип застосунку Liki24.com

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

Я — Сергій Клєбанов, Co-Founder і CPO Liki24.com. Маю понад 12 років досвіду в IT-сфері, чотири з яких я присвятив Liki24.com. За цей час ми з командою пройшли шлях від сайту для оформлення замовлень до повноцінної HealthTech-платформи. Реалізували унікальну схему логістики, створили SaaS для страхових компаній, запустили наші продукти в Україні, Польщі, Румунії та Угорщині.

У цій статті я розповім про те, як правильний фокус і націленість на результат дають нам змогу рухатися швидко й бути гнучкими. За три дні ми з нуля розробили прототип мобільного застосунку, а впродовж місяця розвинули його до MVP та опублікували в Apple App Store і Google Play Market. Цим прикладом я хотів би надихнути читачів не відкладати свої ідеї на потім під приводом їх високої трудомісткості, а фокусуватися на найголовніших аспектах і якнайшвидше отримувати відгук від своєї аудиторії.

Передісторія

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

Через чотири роки наша платформа стала екосистемою, яка передбачає інтеграцію з понад 5 тис. торгових точок, забезпечує доступ до 50 тис. лікарських засобів і товарів для догляду за собою, а також дає змогу здійснювати інтеграцію з іншими компаніями у сфері HealthTech. Ми вибудували ланцюжок — від оформлення замовлення на сайті до отримання товару, а модель логістики охоплює збирання з декількох аптек і суттєво економить час і гроші клієнтів.

Сервіс Liki24.com швидко розвивався, реалізовував інтеграції зі страховими компаніями, логістичними операторами та маркетплейсами, але основним каналом продажів залишався вебсайт, який був нашим першим MVP.

Чому саме застосунок

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

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

Як проходила розробка прототипу застосунку

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

Декілька днів пішло на підготовку до хакатону: сформували команду та беклог завдань. До команди увійшли три frontend- і два backend-розробники, аналітик, UX/UI-дизайнер і продакт-менеджер. Усі завдання пройшли первинний аналіз та пріоритизацію. Для кожної фічі ми продумували мінімально можливий робочий функціонал. У результаті за три дні підготовки та три дні хакатону було створено робочий прототип застосунку, який давав змогу пройти авторизацію, вибрати адресу, знайти товар і оформити замовлення.

Але на цьому челенджі не закінчилися. Ми вигадали для себе новий: протягом місяця з прототипу зробити MVP і запустити його в продакшн. Нам важливо було встигнути до початку сезону, тому встановили дедлайн ― перший день осені.

Далі я розповім, який технічний стек ми використовували та які фічі стали для нас пріоритетними за цей короткий час, як ми розподілили обсяг робіт між двома етапами (створення прототипу за три дні та його еволюцію в MVP) упродовж місяця.

Наш технічний стек

Front-end мобільного застосунку ми розробляли з нуля. Використовували фреймворк React Native, оскільки інженерна команда уже мала досвід роботи з React-ом. Ми віддали перевагу кросплатформовій розробці, оскільки знали, що не потрібно буде часто використовувати апаратні функції пристрою, а також забезпечувати відгук на рівні ігор. Швидкість розробки для нас також була одним із вирішальних факторів у виборі між нативною та кросплатформовою розробкою.

Back-end більшою мірою був готовий до хакатону — бізнес-логіка оформлення замовлення вже використовувалася на сайті, а бізнес-логіка виконання замовлення була реалізована в окремій бекофіс-системі. Все, що було потрібно в бекенді на етапі прототипу й першого релізу — це зробити окремий програмний інтерфейс, адаптований під запити застосунку. Backend у нашому випадку охоплює різні сервіси із використанням кількох мов і фреймворків — .NET, PHP, TypeScript.

Онбординг клієнта

Більшість Q-Commerce застосунків пропонують клієнту розпочати шлях із онбордингу, що плавно переходить у реєстрацію або логін. Наш онбординг складається з двох частин:

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

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

Для MVP ми ускладнили реалізацію, а процес входу для клієнта натомість спростили. Тепер достатньо ввести номер телефону ― і застосунок уже може визначити, що показувати далі (екрани логіна або екрани реєстрації). Також додали:

• Можливість відновлення паролю.
• Обробку встановлених дозволів: наприклад, повторний запит доступу до геолокації, якщо клієнт спочатку заборонив використання геолокації, а потім тапнув на мапі «Моє місцезнаходження».
• Можливість розпочинати введення номера як із нуля, так і з коду оператора.

Скриншот 1: Запит на використання геолокації
Скриншот 2: Укажіть телефон

Вибір адреси доставки

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

Скриншот 3: Вибір адреси на мапі
Скриншот 4: Уведення деталей адреси

Вибір способу отримання замовлення

Одна з ключових відмінностей вебсайту і застосунку — це порядок дій. На сайті клієнт спочатку наповнює кошик, а потім вибирає відповідний спосіб отримання. Q-Commerce застосунки сформували у клієнтів звичку спочатку вибирати адресу, далі торгову точку серед доступних, а потім додавати товари конкретної торгової точки до кошика. В нашому додатку порядок дій є таким:

• вибір адреси доставки;
• вибір способу отримання — планова або термінова доставка;
• відображення товарів і цін, доступних для вибраного способу отримання.

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

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

Скриншот 5: Вибір способу доставки
Скриншот 6: Стрічка з товарами і приміткою «Доступно в режимі „Планова“»

Вибір товарів

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

Скриншот 7: Пошук з автодоповненням
Скриншот 8: Стрічка з товарами

Оформлення замовлення

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

Для релізу MVP протягом місяця ми додали можливість вибирати спосіб отримання «Планова доставка», для якої знадобилися такі фічі:

• Вибір відділення Нової Пошти або Укрпошти: ми вже мали інтеграцію з API поштових операторів і реалізували можливість пошуку відділення за їх довідниками в межах вибраного клієнтом населеного пункту;
• Вибір вікна доставки для опції «Кур’єр Liki24.com»;
• Вибір способу оплати — карткою або готівкою під час отримання. Для оплати карткою ми використовували WebView, який показує форму платіжної системи, з якою ми також мали інтеграцію для оплати на сайті. Реалізовувати власну платіжну форму ми не могли, оскільки це вимагало проходження сертифікації PCI DSS, а прив’язка картки з оплатою за токеном вимагала більше часу, ніж було в нашому розпорядженні: розробкою цієї фічі ми займаємось вже зараз.

Скриншот 9: Оформлення замовлення

Аналітика

Для вебсайту вже була налаштована аналітика в Google Analytics 4. Для застосунку використовували Google Firebase, що дало змогу збирати події вебсайту та події застосунку в межах одного продукту, але різними стрімами. На етапі прототипу реалізували можливість збирати івенти, доступні з коробки Google Firebase, такі як перегляд екрану, логування результатів пошуку, додавання до кошику, оформлення замовлення. До релізу MVP налаштували низку власних подій для повноти картини: наприклад, додали трекінг попереджень, помилок валідації, показу ботомшитів і вибраних у них опцій.

Push-сповіщення

Для надсилання сповіщень ми використовували інтеграцію з Firebase Cloud Messaging. Використання FCM стало логічним продовженням кросплатформного підходу — дало можливість налаштовувати відправлення повідомлень для двох платформ в одному продукті. Базові можливості FCM добре підходять для відправки як тригерних, так і промо розсилок: є інтеграція з Google Firebase, який ми використовували для аналітики. На етапі прототипу нам було достатньо перевірити, що push-сповіщення підключені коректно і відправляються на пристрій, тому ми додали лише одне повідомлення — «Замовлення оформлено», яке прив’язали до події успішного розміщення замовлення в бекофіс-системі. До релізу MVP ми додали можливість відстежувати статус замовлення в застосунку та розширили набір повідомлень. Наразі ми продовжуємо роботу над екраном відстеження замовлення: хочемо дати змогу відстежувати переміщення кур’єра на мапі, переходити до застосунку поштового оператора за сформованою ТТН і багато іншого.

Скриншот 10: Push-сповіщення «Замовлення оформлено»
Скриншот 11: Push-сповіщення «Замовлення отримано»

Білд і публікація застосунку

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

• Managed Workflow — для проєктів із використанням лише JavaScript і TypeScript кода. Включає в себе можливість побудови білдів за допомогою Expo Build Service;
• Bare Workflow — дає змогу додавати кастомний native код для керування native залежностями, а побудова білдів відбувається за допомогою сервісу EAS Build.

Спочатку ми використали Managed Workflow, очікуючи, що це заощадить наш час, оскільки в цій парадигмі фреймворк Expo сам займається побудовою версій для iOS та Andriod, а інженер налаштовує єдину конфігурацію для двох платформ. Ми налаштували публікацію, але коли спробували підключити Firebase аналітику та Firebase Cloud Messaging, виявили те, що бібліотеки React Native Firebase несумісні з Expo Build Service. Довелося перейти на підхід Bare Workflow і налаштувати публікацію з використанням сервісу EAS Build.

Коли можливість запустити застосунок на iOS через TestFlight була готова, ми вирішили, що для прототипу цього буде достатньо. А публікацію версії для Android реалізували без проблем через декілька днів після хакатону.

Від чого повністю відмовилися

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

Що в цьому складного

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

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

Отриманий результат

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

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