Jak tým 5 lidí spustil půjčovnu skútrů Bolt a službu sdílení aut

Dnes si lze jen těžko představit pohodlný život bez technologických zařízení Bolt. Stačí jen najít na ulici volnou koloběžku a odemknout ji prostřednictvím aplikace několika kliknutími. Magie? Ne tak docela. Především je to tvrdá práce vývojového týmu, který promýšlel každou nuanci, aby byla naše interakce se službou pohodlnější.

Zeptali jsme se Artema Vereščaky, technického vedoucího společnosti Bolt, který pracoval na pilotní verzi projektu mikromobility, na to, jak vše ve společnosti funguje. Z rozhovoru se dozvíš, jak dlouho trvalo inženýrům spustit tak rozsáhlý projekt, jaké technologie a rámce použili a jakým výzvám čelili.

Dossier

• Artem Vereščaka pracuje na vývoji systémů s vysokou zátěží pomocí algoritmů a datových struktur ve společnosti Bolt již více než 4 roky a řídí tým Rental Micromobility.
• Napsal od základu backend pro půjčování koloběžek a kol, navrhl a spustil systém sdílení aut [v testovacím režimu v estonském Tallinnu].
• Svou profesi miluje, protože mu umožňuje tvořit a uplatňovat své znalosti ve zcela odlišných oblastech: od automatizace výroby až po počítačové vidění.

Tvoje portfolio obsahuje zajímavou případovou studii o psaní backendu od nuly pro novou službu půjčování koloběžek a kol. Řekneš nám prosím o tomto projektu více? Kolik lidí bylo součástí týmu?

Do projektu koloběžek a kol jsem se zapojil hned na začátku. V té době měl Bolt několik inženýrských týmů a já jsem byl přidělen do jednoho z nich, který se jmenoval Core. O několik týdnů později se inženýři z mého týmu ujali nového projektu – půjčovny koloběžek – a rozdělili se do dalšího týmu, do kterého jsem byl také přizván.

Na prototypu pracovali tři lidé: dva inženýři z Core týmu a náš technický ředitel. Jednoduchý systém (minimum pro pilotní projekt) napsali za pouhý měsíc. Další dva lidé pracovali na straně klienta: jeden člověk na verzi pro iOS a jeden pro Android. Když jsme se rozhodli vytvořit tým, jeden inženýr z první trojice se stal vedoucím týmu projektu.

Prototyp byl co nejjednodušší. Blízký nule, ale stále ne nulový. Začali jsme s nápadem a minimální implementací naší budoucí služby. Ze zkušenosti ale mohu říci, že v některých případech je psaní projektů od nuly dokonce jednodušší, protože můžete ovlivnit zásadní rozhodnutí. V případě koloběžek Bolt jsme některé věci udělali podle zadání v prototypu, například integraci s jednotlivými zařízeními internetu věcí. A pak jsme museli vše nejen přepsat, ale provést pečlivou migraci, protože živý produkt s živými uživateli vyžaduje opatrnější přístup a prostředky.

Pokud vezmeme v úvahu práci s různými platformami (backend, iOS, Android), je obtížné určit, kolik lidí se na tom či onom podílelo. Obvykle jsme si věci rozdělovali „jak to přišlo“: neexistovalo jasné rozdělení typu „někdo píše celou architekturu a někdo celý CRUD“. Technický vedoucí měl víceméně ucelenou představu o tom, co se bude dít; zbytek týmu vzal danou funkci a udělal vše, co bylo potřeba k její implementaci (podle svých zkušeností, zájmu, dovedností a času).

Jak dlouho jste museli projekt realizovat?

Funkční produkt se objevil asi za měsíc. Měl zcela základní funkce, ale vše fungovalo. Měl jsem také zkušenosti s vývojem backendu pro sdílení aut a byl to stejný příběh, ale v tomto případě mohu upřímně říct, že jsme ho vytvořili od nuly, bez jakékoliv přípravy nebo prototypu.

Měli jsme hrubý odhad, jak dlouho nám bude vývoj trvat, ale žádný pevný termín jsme neměli. Navíc jsme po zkušenostech s koloběžkami věděli, které systémy to vzdají jako první, takže jsme práci plánovali na základě slabých míst, aby se v budoucnu dala snáze škálovat. Uvědomili jsme si také, že musíme lépe oddělit jednotlivé služby: například zohlednit skutečnost, že aplikace pro OPS (lidi, kteří servisují auta a skútry) je velkou částí práce s vlastní logikou, a vyčlenit na ni čas.

Spuštění služby sdílení aut Bolt bylo ve srovnání se skútry složitější: museli jsme nastavit ověřování řidičských průkazů a lépe se připravit na spuštění, protože v té době už byl Bolt rozpoznatelnou značkou, kterou jsme nemohli zklamat napůl fungujícím prototypem.

Od nápadu na projekt do jeho spuštění uplynuly celkem asi 3 měsíce. Během této doby jsme měli možnost v klidu probrat detaily architektury, ale celkový spěch byl určitě cítit. Byli jsme závislí na několika stech autech (pro projekt), kvůli kterým jsme přišli o peníze, a také na médiích, kde jsme museli oznámit novou funkci. Samozřejmě jsme šetřili, kde se dalo, ale snažili jsme se zachovat zdravý rozum a nic nepřibíjet. Přestože nebylo jasné datum vydání, podařilo se týmu v poměrně krátké době vytvořit životaschopnou verzi a spustit ji v Tallinnu. První den jsme nic nedokončili, dokonce jsme ani neopravovali chyby – místo toho jsme pomáhali rozvážet auta po městě a lepit na ně samolepky.

Můžeš nám podrobněji popsat, z jakých fází se skládá spuštění takové služby (plánování, sběr dat, architektura) a jak dlouho jednotlivé fáze trvají?

Nejprve je třeba si ujasnit, jak si představuješ výsledek. Musíš jasně rozlišovat mezi tím, jaká by měla být minimální funkčnost, a tím, co „by bylo hezké, ale může počkat“. Dále následuje typický knižní přístup: vytvořit produkt, iterovat a vylepšovat.

V případě Bolta jsme měli představu o tom, jakého výsledku chceme dosáhnout, co máme nyní, jakým bodům bychom měli věnovat pozornost a kam přilákat další zdroje. Po schválení celkové architektury jsme projekt rozdělili na moduly (poměrně rozsáhlé části práce) a realizovali je. Plánováním obvykle netrávíme mnoho času – zejména když jde o něco nového. Krátké brainstormingy, výměna nápadů s kolegy, obecné diagramy – a pak se pustíme do práce. Pokud máš v týmu dobrou komunikaci, jde všechno rychle a snadno.

Shrnuto: nedošlo k rozdělení nedodělků do etap, které by na sebe navazovaly. Každý modul byl vyvíjen samostatně: některé moduly šly rychleji, jiné pomaleji, v závislosti na problémech, které se v procesu vyskytly, a na složitosti modulu.

Týmová práce a provázanost vašich procesů je působivá. Jaké byly tvoje úkoly?

V různých obdobích, kdy jsem se zabýval mikromobilitou (sem patří jak půjčovny koloběžek, tak sdílení aut), byly mé úkoly různé. Musíš pochopit, že objednávkový systém, který má pod kapotou spoustu vlastní logiky, není jediným středem zájmu: existuje také svět OPS a systém, který monitoruje koloběžky, „komunikuje“ s nimi a shromažďuje vzorce chování. Nyní máme téměř 4 týmy, které se těmito věcmi zabývají. Tehdy to byli jen čtyři lidé. Co se týče vývojových úkolů, existuje standardní sada úkolů: promyslet architekturu, napsat kód, napsat testy, certifikovat a monitorovat. Obvykle k tomu ale přidáváme „produktovou“ část: vývojář se účastní diskuzí a nabízí nápady. Nehraje roli PM, ale zapojuje se do procesu, jak jen to jde.

Například v rámci sdílení aut jsem si vzal několik modulů a pracoval na nich. První byl modul s částí vozového parku – jde o vše, co souvisí s auty: jak o nich shromažďujeme informace, jak je přizpůsobujeme. Dále jsem strávil hodně času nad modulem ověřování uživatele, aby člověk úspěšně prošel všemi fázemi: od spuštění aplikace až po větu „vše je v pořádku, vezmi auto a jeď“. Napsal jsem také modul o cenách: jak vypočítáváme cenu pronájmu konkrétního vozu. Při práci s jednotlivými moduly jsme od začátku procházeli procesem „vývoje“.

V jakém jazyce (jazycích) byl backend napsán?

Celý backend Boltu je napsán v jazyce TypeScript a běží na Node.js (kromě části věnované datové vědě). Stejně tomu bylo i zde, bez výjimky. Pro některé interní skripty jsem stále používal Python – velmi zřídka a za účelem automatizace něčeho pro sebe.

Jaké technologie a rámce jste použili při vývoji backendu půjčovny koloběžek?

Nepoužíváme mnoho externích frameworků nebo technologií, protože máme spoustu věcí napsaných sami. To nám dává větší kontrolu: můžeme si interní frameworky přizpůsobit podle sebe a někdy můžeme napsat něco, pro co zatím neexistuje žádná knihovna. Jako standardní knihovny jsme použili Express.js a Jest, ale samozřejmě jsme si je upravili podle svých představ.

Jak jste během vývoje zajistili škálovatelnost backendu?

Škálovatelnost nelze zajistit jednou provždy – neustále na ní pracujeme. Pomohly nám zde standardní mechanismy: asynchronní zpracování, cachování, sharding a samozřejmě správné oddělení modulů.

Co bylo na práci nejtěžší: zajištění interakce mezi backendem a službami třetích stran (například platebními systémy), vytvoření správné architektury nebo něco jiného?

Bolt je poměrně velká společnost, takže rozhodnutí, jako jsou platební systémy, se přijímají na úrovni interní platformy. To znamená, že neintegrujeme přímo, ale máme připravené jednotné řešení, které všichni ve společnosti Bolt používají. A řešení, která lze sjednotit, je celá řada. To je velmi užitečné.

V našem případě jsme ponechali jedinečnou interakci mezi backendem a zařízeními a integraci s externími datovými systémy (některá města sbírají data o tom, jak jsou koloběžky využívány, prostřednictvím nás a konkrétních platforem).

Podle mého názoru je nejtěžší najít správné kompromisy a sestavit skvělý tým. Vše ostatní se dá snadno vyřešit.

Jak hodnotíte své výsledky?

Myslím, že máme skvělý produkt, který lidé používají. Podařilo se nám ho poměrně rychle rozšířit a zároveň přejít na vše „naše“ (naše koloběžky, naše zařízení IoT, naše interní procesy). To, na čem pracuji, mě baví, takže výsledek hodnotím poměrně vysoko.

Oceňuji i to, že náš produkt pomáhá řešit více globálních problémů než jen vydělávat peníze. Snažíme se ovlivňovat výstavbu a plánování měst prostřednictvím spolupráce s místními úřady, zlepšováním služeb a školením uživatelů. Samozřejmě máme spoustu míst, která by se dala udělat lépe, ale dokonalý systém nikdy nespatří světlo světa, protože se to nestihne. V živém produktu se vždy najde něco, co budete chtít vylepšit.

Můžeš se s námi podělit o některé problémy, které jste museli řešit?

Samozřejmě, že některé věci bychom teď udělali jinak.

Chyba № 1: koloběžky v Paříži

První spuštění mikromobility proběhlo v Paříži, kde jsme instalovali koloběžky a zahájili provoz, ale odlehlost místa ovlivnila procesy. Takže později, když jsme službu spustili v Tallinnu, bylo jasné, že musíme začít odsud. To nám umožnilo zkrátit smyčku zpětné vazby a rychle identifikovat a řešit problémy. A spousta našich skútrů byla v Paříži jednoduše ukradena.

Chyba № 2: ověřování dokumentů

V Tallinnu jsme spustili službu sdílení automobilů. Vyskytl se zde však další problém: vybrali jsme špatnou společnost pro ověřování dokladů. Komunikace s nimi byla velmi napjatá a vše šlo pomalu. Přesto jsme službu spustili a zjistili, že to byla chyba. Naštěstí v Estonsku existuje společnost Veriff, která dělala to, co jsme potřebovali, takže jsme se rychle integrovali k našim „sousedům“.

Neřekl bych, že jsme měli nějaké vážné technické problémy. Naše architektura nám umožnila být flexibilní a rychlí. Na začátku jsme nepřidávali žádné módní technologie, ale snažili jsme se, aby to bylo jednoduché. Po vydání se samozřejmě objevily chyby, ale to je součást normálního procesu.

Poděl se i o případy, na které jste hrdí.

Při práci na produktech mikromobility a sdílení jízd jsme měli spoustu zajímavých technických případů a je těžké si je všechny najednou zapamatovat.

Případ № 1: integrovali jsme koloběžky a zařízení internetu věcí přímo do našeho backendu.

Za tímto účelem jsme převzali protokol ze světa internetu věcí, se kterým pracuje jen málokdo, a nyní jej používáme nejen pro komunikaci se zařízeními v koloběžkách. Více jsem o tomto případu napsal v článku na serveru Medium.

Případ č. 2: Do našeho backendu jsme integrovali nabíjecí stanice a logiku práce s těmito stanicemi.

V poslední době se zaměřuji na interní systémy a technické aspekty, o které je těžké se podělit bez tříhodinové prohlídky jádra. Některé moduly, které jsem vyvinul pro interní použití, se v rámci společnosti vyvinuly a nyní na nich pracují samostatné týmy. Je příjemné vidět, že funkce, na které jste tvrdě pracovali a kterou jste pilotovali, je nyní škálovatelná.

Problémy, se kterými se vývojáři potýkají při zavádění nového produktu od nuly

• Nadměrné inženýrství
  Perfekcionismus často stojí v cestě práci – podle mého názoru byste měli hledat střední cestu.
   
• Komunikace s týmem nebo produktem
  Pokud chcete vytvořit něco dobrého, musíte pracovat jako tým.
   
• Špatný výběr technologie
  Technologie nám pomáhá něčeho dosáhnout, ale neměla by být konečným cílem. Zeptejte se sami sebe, proč tento nástroj potřebujete, a nevybírejte si něco nového jen proto, že je to cool.
   
• Nejistota
  Na začátku musíte být připraveni rychle postupovat a neohlížet se zpět navzdory neznámému. Neztrácejte mnoho času zbytečnými věcmi.

Na základě svých dosavadních zkušeností nám řekni, jaké otázky by měly být zváženy před zahájením vývoje.

Obvykle se snažím projekt nebo funkci hned analyzovat, abych pochopil, jaké jsou naše limity, co zanedbáváme a jaké jsou naše cíle. Když víte, co se od vaší práce očekává, je snadné vymyslet nejlepší způsoby, jak ji provést. U pilotních projektů je důležitá rychlost a snadnost. U technických úkolů je důležitá stabilita a porozumění. Přístup k takovým úkolům se liší.

Proto bych vám doporučil věnovat pozornost očekáváním (čeho chceme dosáhnout) a cílům (proč), a teprve potom hledat způsoby. A také si uvědomte, že kód píšeme pro lidi, protože stroj udělá cokoli, co uspokojí kompilátor, ale člověk ne.

Používali jste při práci na svých projektech algoritmy a datové struktury? Jak v praxi pomáhají urychlit proces vývoje?

Ano, samozřejmě. Jak jsem řekl, ve společnosti Bolt používáme spoustu hotových (nebo částečně hotových) řešení. Abyste je mohli správně použít, musíte pochopit, jak vše uvnitř funguje (alespoň přibližně).

Algoritmy a datové struktury nejsou o znalosti teorie, velkém množství struktur a schopnosti napsat z hlavy Kruskalův nebo Borůvkův algoritmus, ale o tom, jak myslíme a čemu rozumíme.

Ve většině případů chápu, jak některé struktury fungují, a to mi umožňuje rychleji najít řešení a vyřešit problémy.

Co by se v projektu změnilo, kdybyste nepoužili algoritmické znalosti? Pocítil by koncový uživatel rozdíl (např. měl by problémy s funkčností webu apod.)?

Problémy se objeví, jakmile začnete stavět malý projekt. Vestavěné systémy, frontend, backend, SRE – všechny mají různé kritické body a populární frameworky si s nimi ne vždy poradí. Od pomalého vyhledávání koloběžek ve vašem okolí nebo adresy místa, kam chcete jet, až po výpočet peněz, které za to utratíte, vše musí být optimalizováno. Čím lepší je váš systém, tím více se obejdete bez dalších technologií, což znamená, že můžete ušetřit peníze sobě i svým uživatelům.

Jaké zkušenosti si myslíte, že musíte mít, abyste tak rozsáhlý úkol dobře zvládli? Kolik let zkušeností jste měli v době realizace projektu v oblasti půjčování koloběžek?

Když jsem nastoupil do společnosti Bolt (Taxify), měl jsem za sebou 2,5–3 roky zkušeností ve dvou společnostech. To je výhoda, ale ne všelék. Setkal jsem se s lidmi s malým technickým vzděláním, kteří podávali lepší výkony než zkušení vývojáři, protože musíte být schopni vytvořit něco nového, a ne plnit úkoly, které vám byly přiděleny. Hledání vlastních řešení je něco, co velké firmy oceňují.

Náš tým se skládá z lidí s různými zkušenostmi, a to jak z hlediska množství, tak z hlediska specifik práce (různé programovací jazyky, různé technologie), ale každý vývojář se ujme jedné funkce a udělá ji od začátku do konce, bez ohledu na její velikost. A dosavadní zkušenosti s tvorbou nových řešení se hodí.

Používáte při vývoji backendu umělou inteligenci? Umíte aplikovat standardní algoritmické přístupy pro práci s ML algoritmy?

Obecně se jedná o velmi široké téma. Mohu říci, že používáme určitý počet ML modelů, které nám pomáhají předvídat různé věci. V souvislosti s koloběžkami používáme ML ke zlepšení bezpečnosti, zlepšení cen a optimalizaci umístění koloběžek v různých městech. Ve společnosti Bolt máme samostatné inženýry, kteří modely vyvíjejí, a pak toto řešení integrujeme do produktu.