Як команда з 5 людей запустила сервіс з оренди самокатів і каршерингу Bolt

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

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

Досьє

• Артем Верещака 4+ роки працює над розробкою високонавантажених систем із застосуванням алгоритмів і структур даних у Bolt та керує командою Rental Micromobility.
• Написав з нуля backend для оренди самокатів та велосипедів, спроєктував та запустив систему каршерингу [в тестовому режимі в Таллінні, Естонія].
• Любить свою професію за те, що вона дозволяє творити й застосовувати свої знання в абсолютно різних сферах: від автоматизації виробництва до Computer Vision.

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

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

Над прототипом працювало 3 людини: два інженери з Core-команди та наш CTO. Вони написали просту систему (bare minimum для пілота проєкту) буквально за місяць. Над клієнтською частиною працювало ще двоє: одна людина над iOS-версією та одна — над Android. Коли вирішили створити команду, 1 інженер із першої трійки став тім/техлідом проєкту.

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

Якщо брати до уваги роботу з різними платформами (backend, iOS, Android), то тут складно визначити, скільки людей займалося тим чи іншим. Зазвичай ми ділили речі «як піде»: не було чіткого розділення на кшталт «хтось пише всю архітектуру, а хтось — весь CRUD». Більш-менш повне уявлення про те, що буде, мав техлід; решта команди брала фічу і робила все, що потрібно для її реалізації (залежно від досвіду, зацікавленості, навичок та часу).

Скільки часу ви мали на реалізацію проєкту?

Робочий продукт з’явився приблизно за місяць. Там були досить базові функції, але все працювало. Я ще мав досвід розробки бекенду для каршерингу, з ним така ж сама історія, але в цьому випадку я чесно можу сказати, що ми створювали його «з абсолютного нуля», без підготовки та прототипу. Далі говоритиму про нього.

Ми мали приблизні оцінки, скільки часу нам знадобиться на розробку, але жорсткого дедлайну не було. До того ж, навчені досвідом із самокатами, ми знали, які системи «здадуться» першими, тому планували роботу з огляду на слабкі місця, щоби це було легше скейлити (масштабувати) в майбутньому. Також ми зрозуміли, що потрібно краще відокремлювати сервіси: наприклад, врахувати те, що застосунок для OPS (людей, що обслуговують машини та самокати) — це велика частина роботи зі своєю логікою, і виділити на це час.

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

Загалом від ідеї проєкту до запуску пройшло близько 3 місяців. За цей час ми мали нагоду спокійно обговорити деталі архітектури, але загальний rush, звісно, відчувався. Ми залежали від декількох сотень автівок (для проєкту), через простій яких ми втрачали гроші, а також від медіа, де мали анонсувати нову фічу. Звісно, ми зрізали кути, де могли, але намагалися триматися здорового глузду і не прибивати нічого цвяхами намертво. Попри відсутність чітких дат релізу команді вдалося за досить короткий час зробити життєздатний варіант та запуститися в Таллінні. В перший день ми нічого не дороблювали та навіть не фіксили баги — натомість допомагали розвозити автівки по місту та обклеювали їх стікерами.

Розкажіть детальніше, з яких етапів складається запуск такого сервісу (планування, збір даних, архітектура) та скільки часу займає кожен етап?

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

У випадку з Bolt ми мали уявлення, який результат хочемо отримати, що маємо зараз, на які моменти варто звернути увагу та куди залучити більше ресурсів. Після утвердження загальної архітектури ділили проєкт на модулі (досить великі частини роботи) і виконували це. Зазвичай ми не проводимо багато часу за плануванням — особливо коли це щось нове. Короткі брейншторм-сесії, обмін думками з колегами, загальні діаграми — і до роботи. Якщо маєш гарно налагоджену комунікацію всередині команди, все робиться просто та швидко.

Підсумовую: поділу беклогу на етапи, які йшли один за одним, теж не було. Кожен модуль розвивався окремо: якісь модулі йшли швидше, інші — повільніше, залежно від проблем, які виникали у процесі та складності модуля.

Команда робота та ваша злагодженість у процесах вражає. А що входило до ваших задач?

В різні періоди роботи над micromobility (сюди входять і оренда самокатів, і каршеринг) мої задачі відрізнялися. Треба розуміти, що система замовлення, яка має купу власної логіки «під капотом», — не єдиний фокус уваги: окрім неї є світ OPS та система, яка слідкує за самокатами, «спілкується» з ними, збирає патерни поведінки. Зараз у нас майже 4 команди, які займаються цими речами. А тоді було 4 людини. Щодо розробницьких задач, то тут, як завжди, стандартний набір: продумати архітектуру, написати код, написати тести, задеплоїти, моніторити. Але до цього у нас, зазвичай, додається «продуктова» частина: розробник бере участь в обговореннях, пропонує ідеї. Не виконує роль PM’а, проте максимально залучений у процес.

У каршерингу, наприклад, я взяв собі декілька модулів і працював над ними. Першим був модуль із fleet-частиною ― це про все, що пов’язано з автомобілями: як збираємо інформацію про них, як кастомізуємо. Далі ― витратив багато часу на модуль верифікації юзерів, щоби людина успішно подолала всі етапи: від запуску застосунку до фрази «все гаразд, беріть авто та їдьте». Ще писав модуль про ціноутворення: як саме ми вираховуємо ціну оренди під конкретне авто. Під час роботи з кожним модулем ми проходили «розробницький» шлях спочатку.

Якою мовою (мовами) був написаний бекенд?

Весь бекенд у компанії Bolt написаний на TypeScript, а працює на Node.js (окрім дата-саєнс частини). Тут було все те ж саме, ніяких винятків. Для деяких внутрішніх скриптів я ще використовував Python ― дуже рідко і з метою автоматизувати щось для себе.

Які технології та фреймворки ви використовували для написання бекенду оренди самокатів?

Ми не використовуємо багато зовнішніх фреймворків чи технологій, адже в нас є чимало «самописних» речей. Це дає більше контролю: ми можемо підлаштувати внутрішні фреймворки «під себе», а іноді — написати щось таке, для чого ще не придумали бібліотеку. Зі стандартних бібліотек ми використовували Express.js​ та Jest, але, звісно, модифікували їх, як нам хотілося.

Як ви забезпечували масштабовність бекенду в процесі розробки?

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

Що було найскладнішим у роботі: забезпечити взаємодію між бекендом та сторонніми сервісами (наприклад, оплатними системами), створити правильну архітектуру чи щось інше?

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

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

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

Як ви оцінюєте свій результат?

Я вважаю, у нас вийшов класний продукт, яким користуються люди. Нам вдалося його досить швидко заскейлити, водночас перейти на все «своє» (свої самокати, свій IoT-девайс, свої внутрішні процеси). Я люблю те, над чим працюю, тому результат оцінюю досить високо.

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

Чи були якісь факапи, якими ви можете поділитися?

Звісно, були речі, які ми зараз зробили б інакше.

Факап №1: самокати в Парижі

Перший запуск micromobility був у Парижі, ми поставили там самокати й почали оперувати, але віддаленість локації впливала на процеси. Тож згодом, коли ми запустили сервіс у Таллінні, стало зрозуміло, що звідси треба було починати. Це дозволило скоротити feedback loop та оперативно виявляти й розв'язувати проблеми. Ну і ще дуже багато наших самокатів у Парижі просто вкрали.

Факап №2: перевірка документів

Сервіс каршерингу запустили вже в Таллінні. Але тут була інша проблема: ми погано обрали компанію, яка перевіряла документи. Комунікація з ними була дуже натягнутою, всі справи йшли повільно. Попри все ми запустилися і зрозуміли, що це була помилка. На щастя, в Естонії є компанія Veriff, яка робила те, що нам було потрібно, тому ми досить швидко інтегрувалися із «сусідами».

Я б не сказав, що у нас були серйозні технічні факапи. Наша архітектура дозволила нам бути гнучкими та швидкими. Ми не додавали ніяких fancy-технологій на старті, а намагалися зробити простіше. Баги після релізу, звісно, з’являлися, але це частина нормального процесу.

Поділіться ще кейсами, якими ви пишаєтеся.

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

Кейс №1: інтегрували скутери та ІоТ-девайси напряму в наш бекенд.

Для цього ми взяли протокол зі світу ІоТ, з яким мало хто працює, і тепер використовуємо його більше, ніж просто для звʼязку з девайсами в самокатах. Більше про цей випадок я писав у статті на Medium.

Кейс №2: інтегрували зарядні станції в наш бекенд і логіку роботи із цими станціями.

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

Проблеми, з якими стикається розробник, коли запускає новий продукт з нуля

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

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

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

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

Чи користувалися ви алгоритмами та структурами даних, коли працювали над своїми проєктами? Як вони допомагають пришвидшити процес розробки на практиці?

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

Алгоритми та структури даних — це не про знання теорії, великої кількості структур і вміння написати алгоритм Крускала або Борувки з голови, а про те, як ми думаємо і що розуміємо.

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

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

Проблеми «вилізають», як тільки ви починаєте скейлити невеликий проєкт. Embedded systems, frontend, backend, SRE — у всіх різні критичні точки, і популярні фреймворки не завжди справляються. Починаючи від повільного пошуку самокатів навкруги вас чи адреси місця, куди ви хочете поїхати, до розрахунку коштів, які витрачаються на це, — все має бути оптимізованим. Чим оптимальніша ваша система, тим більше ви можете обходитися без додаткових технологій, а значить, економити гроші й собі, і користувачам.

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

На момент приєднання до Bolt (Taxify) я мав 2.5–3 роки досвіду у 2 компаніях. Це плюс, але не панацея. Я зустрічав людей із незначним технічним бекграундом, які виконують задачі краще, ніж досвідчені розробники, адже тут радше потрібно вміння створювати щось нове, а не виконувати таски, які тобі розписали. Шукати шлях до рішень самостійно — те, що цінують у великих компаніях.

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

Чи використовуєте ви штучний інтелект у розробці бекенд-частини? Чи можна застосовувати стандартні алгоритмічні підходи для роботи з ML-алгоритмами?

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