Як працює застосунок Uklon зсередини. Ексклюзивне інтерв’ю з Романом Петриком, Chief Product Officer Uklon

Як рейтинг впливає на якість поїздок, на скільки можуть підвищуватися ціни під час повітряної тривоги та як команда розробляє нові фічі — про це та багато іншого SPEKA розпитала Chief Product Officer Uklon Романа Петрика.

Від пошуку Product Market Fit до впровадження нового інклюзивного функціоналу, гейміфікації та розширення екосистеми Uklon — в ексклюзивному інтерв'ю.

Роман Петрик — Chief Product Officer в Uklon, відповідає за визначення продуктової стратегії та розвиток портфелю продуктів.

Свою кар’єру в Uklon Роман розпочав у 2018 році як бізнес-аналітик у команді мобільного застосунку Uklon (Rider App). З часом він перейшов на позицію Product Owner, згодом — VP of Product. Посаду Chief Product Officer займає з 2023 року. 

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

Почну з того, що у межах IT-дивізіону в Uklon працюють 12 продуктових команд. Кожна з цих команд має свою зону відповідальності. 

Цю команду ми запустили у 2022 році. Спочатку вона працювала тільки на rider-напрямок. А всі тести були спрямовані на Android-платформу, оскільки швидше тестувати гіпотези саме на ній. У разі успішного тесту ми масштабували гіпотези на iOS-користувачів.

Одна із основних метрик команди — Opportunity Size, після того як ця метрика показала окупність команди в декілька разів ми ухвалили рішення масштабувати команду Growth. Додали ще одного розробника, і тепер у нас паралельно запускаються тести для Android- та IOS-користувачів.

З осені 2025 року ми ще більше розширимо команду, і вона валідуватиме різні гіпотези і на driver-напрямку.

Перший. Нову ідею може розглядати Product Owner, яку він знайшов під час discovery-фази. Це тренди, дослідження ринку, аналіз прямих та непрямих конкурентів, обов’язково user-тестування з нашими користувачами. Є окремий флоу спілкування як з райдерами, так і з драйверами: аналіз їхніх потенційних болей та потреб, аналіз відгуки в AppStore та Google play.

Другий. У нас є відкрита позиція для всіх тімейтів команди — кожен може запропонувати свою ідею, далі вона аналізується. На discovery-фазу залучаються за необхідності певні представники команди — продакт-овнери, бізнес-аналітики, дизайнери, обов'язково data-аналітик, з технічної сторони — архітектор та тех.ліди.

На етапі discovery триває розроблення самої ініціативи, можливе напрацювання дизайну й обов’язково аналіз від data-аналітиків: які у нас поточні показники, як розроблений функціонал може вплинути на основні показники.

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

Перший — які мають основний вплив на ревеню.

Другий  — які покращують нашу ефективність, дають змогу скоротити витрати компанії.

Третій та четвертий, їх можна об'єднати, — це attractive і must-be features.

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

Використовуємо квартальне планування: перед стартом кварталу всі ці ініціативи проходять scoring-сесію. Score визначається на основі впливу ініціативи на досягнення основних цілей компанії на рік.

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

Залежно від функціоналу ми можемо ухвалювати різні рішення. Деякі ми можемо розкатати через А/В-тест. Деякі рішення можемо масштабувати по містам, щоб зробити поетапну розкатку. А деякі одразу впроваджувати на всіх користувачів.

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

Якщо говорити про Growth команду, то розвиток цього напрямку був пріоритетний, поки не почалась повномасштабна війна. З її початком, команда Growth спрямувала фокус на більш пріоритетні речі. Такі як, більше інвестувати в допомогу у поточній ситуації, запуск класу «Волонтер» та «Евакуація», перші етапи «Підписки на донат» — ми надавали можливість підтримувати публічні всеукраїнські збори, наприклад, збір фонду «Сергія Притули» на супутники, а також «Люті пташки», «Рій помсти», «Підсвіти ворога» тощо.

Крім того Uklon долучався внесками на підтримку ЗСУ в зборах «Дронопад» (1 млн грн), «Морський бій» на 35 морських дронів Sea Baby (5 млн гривень) та збір на бойові роботи в межах збору Atlas та UNITED 24 (3 млн грн).

Проте ще на початку 2022 році у нас була чітка мета і план запустити цю команду.

Що стосується метрик, тут пропоную розглянути не тільки Growth, а всі команди.

У кожної команди є свої ключові метрики, на які вона впливає. Наприклад, для райдерської команди це такі продуктові метрики як взаємодія користувача з нашим застосунком: час створення замовлення.

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

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

Підписуйтеся на наші соцмережі

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

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

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

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

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

Дуже класний кейс: нещодавно ми запустили клас «Швидкий пошук», і він нам показав, що багато користувачів готові заплатити більше, щоб виїхати швидше.

Тобто ти, замовляючи той самий «Стандарт», погоджуєшся, що якщо знайдеться машина класу «Комфорт» або «Бізнес», ти готовий заплатити на N гривень більше, щоб якомога швидше доїхати з точки А в точку Б.

Ринок, тренди плюс ми використовуємо підходи Data Informed і Data Driven. Бо інтуїтивно не можна виїхати, треба підкріплювати свою думку даними, адже все вартує коштів.

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

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

Запустили ми цей клас у четвертому кварталі 2024 року. На розробку витратили орієнтовно 1 місяць або 4-5 тижнів. До розроблення функціоналу були залучені 5 команд. Основна робота була на команді райдера і команді, яка відповідає за логіку розподілення замовлень.

Чому з точки зору UI були дуже багато проведено роботи? Оскільки раніше користувачі їхали з точки А в точку В, тобто маршрут складається щонайменше з двох точок, то тут є тільки одна. Тобто тобі треба, щоб приїхав водій, допоміг прикурити або замінити колесо, і після цього ти вже можеш продовжувати свою поїздку. Тому певні моменти потрібно було доопрацювати.

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

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

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

Додатково з командою Data Science аналізуємо коментарі до замовлень. Коли створюєш замовлення, ти можеш додати у коментар короткий текст.

Багато хто вказує, що заїзд у двір ліворуч чи праворуч, або просять запаркуватись біля під’їзду. А деякі з користувачів замовляли клас «Стандарт» або «Комфорт»  і писали, що їх треба прикурити або відбуксувати. Так само ми знайшли Product Market Fit.

Тут є ще класний кейс. Під час COVID-19 все позакривалося, люди боялись виходити на вулицю, і ми побачили, аналізуючи коментарі, що багато хто замовляє доставку продуктів додому, вказуючи у коментарях, що треба купити у магазинах. Ми бачили, що водії стоять біля супермаркетів, купують ці продукти і привозять замовникам. Такий аналіз дозволив нам зрозуміти необхідність запуску доставки.

Як я казав, в рамках IT-дивізіону є 12 продуктових команд. Структура будь-якої продуктової команди складається з Product Owner, бізнес-аналітика, дизайнера і розробників.

За «Автопідмогу» відповідали 5 команд:

У нас застосовується динамічне ціноутворення. Максимальний поріг залежить від міст — для Києва, це х3,5 раза. В деяких містах показник становить х3 або х2,5 рази.

Для Києва найвищий, бо це столиця?

Тут банальне співвідношення попиту і пропозиції.

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

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

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

Клас «Жіночий» — це насамперед надання жінкам можливості отримати роботу в рамках рейд-хелінг-сервісу.

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

 Якщо раніше кількість водійок становила менше 0,5%, то ціль на поточний рік — вийти на показник приблизно 5% від активної бази всіх водіїв. Натепер цей показник — 2,6-2,7%. 

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

Другий момент, наскільки популярна послуга: ми бачимо, що багато жінок розміщують клас «Жіночий» як заплановану поїздку на 21:00 чи 22:00. Впродовж дня також є замовлення, і ще багато хто замовляє жіночий клас, ближче до настання комендантської години.

Тому що ми розуміємо, що є питання безпеки та особистого комфорту, і не всі жінки хочуть замовляти звичайне таксі о 22:00-23:00. Вони будуть себе відчувати значно впевненіше та спокійніше, коли їх повезе жінка. До речі, це також торкається й очікувань деяких жінок-водійок, яким комфортніше возити саме жінок-райдерок.

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

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

Усі команди розуміли, що треба запускати «Програму лояльності». Якісь елементи «Програми лояльності» ми досліджували, вони були у наших непрямих конкурентів.

У 2021 році ми провели загальний міжкомандний воркшоп, де були представники ІТ-дивізіону, маркетинг-команди та інші фахівці. Під час воркшопу ми сформували загальне бачення програми лояльності. Після цього розпочався етап розробки. Повномасштабне вторгнення цей етап трошки заморозив, але потім ми до нього повернулися. 

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

Ми зробили трохи складний функціонал (з більшим переліком послуг на MVP-версії). Ми врахували цей досвід і всі команди налаштовані на те, щоб йти поетапно від proof of concept, тобто тестування, валідація гіпотез, після цього запуск MVP-рішення. Якщо MVP успішний, переходимо до наступного етапу — впровадження повноціного функціоналу.

Від першого варіанта функціоналу пройшло вже три основні ітерації оновлення.

Розділимо ситуацію на два блоки. Перший блок — водійський рейтинг.

Чим загрожує низький рейтинг водію? Водію можуть не відкриватись певні класи і він не зможе виконувати ці послуги. Якщо водій учасник програми брендування, то у нього буде челендж виконати стільки-то замовлень і він зможе отримати додатковий бонус. Але якщо його рейтинг буде менший за певну визначену оцінку (4.8-4.9, залежно від регіону), то цей бонус він не отримає. Тобто це можливість контролю якості надання послуг. 

Якщо рейтинг водія 4,5 або менше, то ми можемо відключити його від сервісу. Компанія Ulkon зацікавлена у наданні якісних послуг як з боку райдера, так і водія. Якщо рейтинг настільки низький, це свідчить про те, що є питання до водія. З ним або проведуть розмову та зрозуміють причину або його потрібно відключати — для нас це буде найпростіший і найкращий спосіб. Водії зобовʼязані дотримуватись етикету поведінки партнерів-водіїв  Uklon. Бували випадки, коли водію відключали доступ до сервісу на декілька днів з обовʼязковою вимогою пройти додатково наш освітній курс щодо належного етикету та надання сервісу райдерам. Ми дуже зацікавлені в тому, щоб підіймати якість сервісу, який надають наші водії, адже всі вони потім формують ставлення до нашого бренду і компанії, хоча водії і не є працівниками Uklon.

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

Якщо рейтинг нижче 4,6, то може бути довге очікування. Бо для водіїв у деяких кейсах це замовлення стає необов’язковим. Але чесно скажу, минулого місяця я виконував п’ять замовлень в ролі водія. Брав замовлення райдера, у якого було менше 50 поїздок і у нього оцінка була 4,5. Сказати, що це замовлення було негативне? Ні, замовлення абсолютно нормальне. Я просто спокійно приїхав, забрав райдера, привіз його додому і ми попрощалися.

Рейтинг як пасажира, так і водія рахується на основі 40 останніх поїздок. Аналізуючи, як саме здійснювались розрахунки, ми шукали схеми, як можна покращити розрахунок рейтингу.

Буквально місяць тому ми впровадили новий функціонал, який дозволяє нам менше або взагалі не враховувати оцінки водіїв-детракторів — це ті водії, які виставляють за кожну поїздку негативну оцінку, тобто від 1 до 3. Якщо у водія з його останніх 50 поїздок 20% оцінок негативні, його оцінка не буде враховуватись цьому райдеру.

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