Podcast

Dobrý den, moje jméno je Jirka Vicherek.
Dobrý den všem, moje jméno je Hinek Valner.
A společně vás vítáme u nového dílu Datatolku.

Dnes naše pozvání přijal skutečně vzácný host, a tím je Radek Domín z Liftaga.
Dobrý den, ahoj.
Ahoj Radku.
Ahoj Radku.

Hned na úvod musíme říct, že Radek v Liftagu působí v roli CTO a jeho slovy tedy nepochází z datového kmene. O to je to pro nás ale vzácnější host a dnes budeme opět řešit datová témata a témata spojená s analitikou a data science.

Radku, když nepokrýváš datový kmen, odkud tedy přicházíš?

Moc rád. Liftago prochází už několik let takovou transformací. Všichni asi znají Liftago jako taxislužbu, že vidíte ty taxíky po Praze s logem Liftago na boku. Liftago už ale několik let není jenom taxislužba. Liftago je taková platforma pro sdílení přepravní kapacity. To zní hodně složitě, ale vlastně řeší jednoduchý problém, který jsem slyšel od Ondry Krátkého, když mi ho popisoval. Tak jsem vůbec nechápal, jak je možné, že to ještě neexistuje.

Protože to, co se běžně děje, je, že v Praze je spousta firem, které potřebují něco přepravovat. Tyto firmy pořád shánějí auta, protože jich nemají dost, a shánějí řidiče, protože jich nemají dost. Ale zároveň řeší problém, že nejsou dostatečně vytížené. Řidiči jsou vytížení třeba ze 60–70 %. Takže ta auta, ti řidiči někde stojí.

Liftago dělá to, že umožňuje tuto kapacitu sdílet, a někdo jiný si ji může vzít. Ukazuje se také, že všechny přepravní společnosti hodně bojují o zakázky, které jsou jako „plus jeden den“. Když si něco objednám dneska z nějakého e-shopu, tak se ty společnosti mohou přetrhnout, aby získaly zakázku a mohly mi to zítra doručit. Ale když se bavíme o tom, že bych to chtěl za hodinu, tak ty firmy naopak moc rády si pomohou, půjčí si auta, přehrají si zakázku.

To je takový zajímavý koncept, který podporuje, abychom lépe využívali přepravní kapacitu, která už existuje. A my se snažíme na to i technologicky – my nejsme další přepravní firma, ale jdeme na to přes tu technologii.

Chápu to tedy správně, že Liftago by nemělo být další konkurencí klasickým přepravním společnostem jako DPD nebo GLS, ale snažíte se...

Určitě ne, my spolupracujeme s PPL, DPD, spolupracujeme s dalšími společnostmi. Nechceme přidělávat další problém. Nemáme svá auta, kdybychom jimi zaplavili město. Ale prostě nabízíme technické řešení, jak využít kapacitu těch aut, které už tady jsou, a jak to zlepšit pro všechny.

Ukazuje se totiž, že když na to jdeme takto technologicky, můžeme zajistit, že časy přeprav jsou daleko kratší a ceny daleko nižší.

Já chci slyšet historku, jak ses dostal do Liftaga. To jsi vyprávěl tady před začátkem natáčení, a já tě schválně přerušoval, když jsi rozebíral přílišné detaily. Znělo to dost zajímavě. Po všech tvých zkušenostech, když se podíváme na Radkovo CV, je opravdu impozantní. Tak jak tě Ondřej stáhl do Liftaga?

Já moc nemám rád Vánoce a poslední smrště se snažím před Vánocemi utéct. Vždycky někam do hor, do sněhu, nebo před minulými Vánocemi jsem byl v Portugalsku. A tyto Vánoce jsme měli v plánu s rodinou – což je moje partnerka a můj syn Artur, který byl asi do měsíců v prosinci, v listopadu – tak jsme se snažili utéct na Sicílii.

Plán byl udělat měsíční roadtrip přes Itálii a skončit někde v prosinci na Sicílii, kde prostě být třeba do března a tam zůstat. No a Ondra Krátký na mě přes Tomáše Řehoře, kterému za to děkuji, dostal kontakt. Udělal na mě ten klasický trik, že mě kontaktoval a říkal: „Radku, nevíš náhodou o někom, kdo by mohl pomoct řídit můj tým? Ty znáš hodně lidí.“

A když mi popsal, co vlastně dělá a jak je zapálený, tak mě nakoupil hned, takže ještě než jsme dojeli k Neapoli, byli jsme domluvení, a u Pompejí jsme se otočili a jeli zpátky na sever.

No a co je pro tebe ta „big thing“, co tě donutilo otočit volant do protisměru?

Je to hlavně to, že Liftago je opravdu technologická firma. O tom říká spousta firem, ale Liftago je opravdu technologická firma, která řeší problém, který existuje, který trápí všechna města, a řeší ho tak elegantně, že je až fascinující, že tu ještě dávno nebyl. Když o tom mluvím s lidmi, říkají mi: „Počkej, to už tady musí dávno být, to přece není možné, že to funguje tak neefektivně.“

A je to tak prostě. Každý si buduje svoji společnost, každý má svoji přepravu a myslí zaměřený na sebe, a vůbec je nenapadne, že by tu přepravu nebo kapacitu mohl někomu půjčit. Takže tohle, plus Ondra a jeho zapálení – on firmu založil, provozuje ji už deset let, což je obdivuhodné. Firma přešla různé krize, včetně covidu, a pořád roste a jde nahoru. Ondra je do toho neskutečně zapálený a pořád tlačí na inovace.

Takže toho.

No a ty jsi v Liftago teď několik málo měsíců a tak i z datového pohledu – co je teď tvoje role, priorita? Říkáš, že procházíte nějakou transformací, která trvá už delší dobu?

Já jsem v Liftago tři měsíce, vlastně se tam pořád rozkoukávám. Mám velkou kliku, že jsem od Pavla Hendricha dostal vývojářský tým v skoro perfektním stavu, co tam odvádějí na práci, je až neuvěřitelné. Já jsem zvyklý být téměř krizový manažer. Hodně dobře umím, když mě hodí do nějaké firmy nebo týmu, který nefunguje jak technologicky, tak procesně, a to dokážu docela rychle spravit.

Tady to ale nebylo moc co spravovat. Spíš jsem hledal na čem stavět, a tým je velmi dobře postavený. Ta transformace, kterou procházíme v podatcích, — mimochodem náš datový tým má jen dva lidi a obě jsou ženy, což mi přijde zajímavé — se týká toho, jak se vlastně transformuje Liftago z taxíků do Liftago networku.

Když se zamyslím, jak vlastně funguje datový model pro ty taxíky, tak to vypadá tak, že uprostřed všeho je jedna jízda: někde začíná, někoho naložím, někde vysadím, jízda končí, pak ji můžu vyfakturovat, nabilancovat, zaplatit, a to je středobod všeho.

Ale v případě logistiky to takhle fungovat nemůže, už to tak nemohu chápat, protože můžu jet do depa DPD, naložit tam 40 balíků, a jet je rozvážet. Během té rozvážky můžu přivzít další balík, můžu v půlce cesty přivzít člověka, někam ho dovézt a tak dále.

Takže koncept jedné jízdy se ztrácí a to je směr, kterým jdeme, a důvod, proč musíme přepracovat celý datový model, který nám deset let dobře fungoval.

Můžeš konkrétněji rozvést, co znamená toto přepracování? Je to organizační změna? Jsou to nové technologie? Nebo je to způsob přehodnocení vývoje produktů s ohledem na datovou analýzu?

Je to všechno, co jsi zmínil. Liftago je hodně postavené na datech v tom smyslu, že děláme hodně rozhodnutí na základě dat. Několikrát za den v kanceláři slyšíš diskusi: uděláme tohle, nebo tohle, a hned někdo řekne: „Musíme se podívat na data.“

Funguje to ale tak, že datový tým je spíš továrnou na dashboardy a před ním stojí fronta lidí, kteří chtějí udělat nějaké dashboardy. Tým je pod tlakem, protože datový model je zastaralý podle toho, co jsme popsali. Nestíhá odbavovat poptávku.

Takže ta transformace je o přestavbě datového modelu, aby víc odpovídal reálnému stavu, přiblížení datového modelu na BI tomu datovému modelu, který máme v MongoDB a v provozních aplikacích, a zároveň o vybudování silného interního datového produktu, který zamezí frontě lidí, co před námi stojí.

A jak na to?

To je taky velký téma. Díky tomu, že tím teď procházím, mi došlo, že jsem tím už několikrát prošel ve své kariéře. A uvědomil jsem si, že je to téma, které se opakuje. Firmy si často nechtěně staví zdi mezi týmy – netýká se to jen datových a engineering týmů, ale i design a engineering, produkt a engineering a další. Podle mě je to vždycky špatně, ta zeď tam nikde moc nefunguje.

U dat je to pěkně vidět třeba na případech, kdy se podívám na datový model na BI a vidím, že vypadá jinak než datový model na engineeringu – nejen strukturou, ale i chápáním konceptů či pojmenováním polí.

A vlastně se znova vymýšlejí všechny principy. Když přijde nová feature, tak se vymýšlí jak v inženýringu, tak v BI, přitom by to šlo kombinovat.

A toto se netýká jen Liftaga, to se děje všude. Podle mě je cesta jenom v tom to spojovat a nutit lidi, aby spolu komunikovali.

Zmiňoval jsi, že jsi toto viděl několikrát během své kariéry a máš zkušenosti z různých malých i velkých firem. Máš nějaké konkrétní příklady? Proč vznikaly ty zdi, nebo jak je možný je prorazit?

Určitě. Jeden případ je firma Merlin AI, která už neexistuje, ale tým přešel do Complete Advantage, a dělají tam pořád to samé. Pro kontext: Merlin AI je KYC řešení postavené na adverse media screeningu. To ještě možná není úplně jasné. Funguje to tak, že platforma stahuje nové články z celého světa ve spoustě jazyků, a můžete se jí ptát na nějaké jméno nebo informace o člověku. Pomocí NLP jsou články parsovány, pochopen je jejich obsah, nálada, zda jsou pozitivní, negativní, zjistí rizika, a vystaví report o rizikovosti člověka.

Typicky, když banka někomu zakládá účet, většina regulatorů očekává, že banka „bude číst noviny“. Pokud by v novinách bylo, že daná osoba má problémy s terorismem nebo praním špinavých peněz, tak to banka zjistí. Proto jsou potřeba taková KYC řešení.

A protože rozsah je obrovský, ukazuje se, že použití machine learningu a NLP je velmi dobrý případ.

Takže je to ukázka firmy, která je vysoce technologická a má machine learning hluboce integrovaný. A to, co jsem tam viděl, bylo také to, že data science část týmu byla hodně oddělená od engineering části. Hodně pomohlo, že jsme tyto části spojili, změnili procesy a zavedli Scrum nejen do inženýrské části, ale i do data science části.

Data science se tomu zčásti brání, protože se vnímají trochu jinak než programátoři a nechtějí moc připustit, že by měli chodit na stand-upy a plánování. Data scientisti často argumentují, že dělají R&D, a že jejich práci nejde takto plánovat nebo řídit. Což je ale podobné jako u vývoje software, kde se také plánuje velké úkoly rozdělené na menší části.

Takže nejde o to plánovat vše do detailu, ale rozložit složité problémy na uchopitelné části, aby bylo možné lépe reagovat na případné odchylky v odhadech a efektivněji zpracovat práci.

Kde podle tebe vzniká tento postoj data scientista? Je to stále tím, že data science a machine learning vznikaly na akademické půdě a postupně se ukazuje jejich aplikace, která není ještě úplně standardizovaná, nebo máš jiný názor?

Myslím, že to hodně souvisí s akademickou půdou. Data science jako obor je hodně akademický, zatímco software engineering je úplně naopak. Já osobně nikdy nepodal přihlášku na vysokou školu, což říkám trochu sebevědomě. Po odchodu z Microsoftu do Studious přišel novinář s článkem s názvem asi „Na vysokou nedostal“. Ukazuje to, jak odlišné světy jsou.

Je to ale blbost, protože záměr je pořád stejný. Potřebujeme pochopit, o jakých datových týmech mluvíme. Některé datové týmy slouží hlavně marketingu, produktu nebo inženýringu, tam nevím, jak velký to má smysl. Ale u těch datových týmů, které jsou kritické pro chod aplikace, má smysl přiblížit inženýring a data.

Myslím, že dobrá analogie je s jinými obory, které historicky, když se přiblížily k inženýringu, fungovaly lépe. Například QA – dříve se vše testovalo ručně, pak přišlo automatické testování a zjistilo se, že když se vývojáři zapojí do testování, má to jiný vliv, než jen úsporu peněz.

Podobně operations – dříve byli admini, kteří provozovali aplikace, dnes je DevOps standard. Ukazuje se, že když vývojáři dostanou dobrý nástrojový set, mohou provozovat aplikace sami a operations lidi se stávají specializovanými vývojáři.

Takže doufám, že toto čeká i vztah mezi data scientisty, data engineeremi, analytiky a vývojáři. Přiblížení dává smysl.

Radku, z toho, jak to popisuješ, by se mohlo zdát, že engineering je jádro těch společností a bylo by dobře, kdyby se všechny ostatní specializace přizpůsobily mu. Je zatím nějaké širší vysvětlení, proč to tak vidíš?

Já to takhle vidím možná proto, že týmy, se kterými pracuji, jsou ve firmách závislých na tom, že vyrábějí software. Engineering je tam středobod všeho. Umím si představit společnosti, kde je středobod data science a engineering dělá supportní řešení. To si umím představit, ale tam mi dává smysl stále více spolupracovat.

Představuji si, že tam data science tým něco zadává inženýrům a je to vlastně černá skříňka. Ale osobní zkušenost s tím nemám.

Jako CTO to vnímám tak, že centrum je engineering.

Chápeme. A když jsi byl v Merlenu a chtěl jsi bourat zdi mezi daty a engineeringem, zmínil jsi, že jsi zavedl Scrum pro obě skupiny. Byly tam další metody, kroky, nebo případné neúspěchy, kdys myslel, že to bude fungovat, ale nefungovalo?

Nejen tam, ale všude je to těžké, protože to lidi vytahuje z komfortní zóny. Když mám data inženýra a chci po něm, aby rozuměl víc backendu, protože spolupráce není jen o mluvení, ale o skutečném chápání, co ten druhý dělá...

(Tady text končí bez dokončení.)

Druhý tým. Jinak mi budou říkat, že je to nezajímá, že to akorát zdržuje. Takže je to těžké pro lidi s akademickými tituly, kteří jsou velmi dobří v něčem. A teď po dlouhou dobu jim někdo plácal na rameno, že to dělají dobře. A teď já po nich třeba chci, aby byli dobrí v úplně něčem jiném. Tak to je těžké.

To samé platí pro vývojáře. Ti jsou dobří ve vývoji softwaru a teď po nich chceme, aby začali rozumět datům. A oni narazí, protože si myslí, že rozumí datům, protože umí SQL a pracují s databázemi, ale pochopí, že svět data science je daleko náročnější.

Myslím si, že cesta je přesto překonávat s těmito lidmi jejich obavy a postupně jim ukazovat, že to pro ně není nebezpečné. Že je v pořádku, když jsem středně pokročilý vývojář, a zároveň velmi začátečník v data science, a umožní mi to rozšířit můj záběr.

Na to není žádný zázračný recept. Je to těžké, prochází to přes nějaké trapné meetingy, přes trapné retrospektivy, přes tooling. Například spojení inženýringu a designu pomohly nástroje jako Figma a designové systémy.

Myslím, že volba správného toolingu je důležitá. Nemám žádnou konkrétní radu, ale věřím, že i přes tooling se dá propojit engineering a datový tým.

Podle mého názoru je potřeba, aby všichni lidé pochopili, jaký je cíl, jak mu mohou jít vstříc a jak mu mohou přispět tím, že budou více spolupracovat. A také v čem je nebezpečí té „zóny“, která mezi nimi může být.

Radku, jak konkrétně to funguje? Co funguje a co nefunguje při zbližování těchto dvou světů?

To, co se mi osvědčilo a co teď zvažuji v Liftagu, je například požádat vývojáře, aby prováděli code review na změny, které se dějí v datech. Vyvíjíme nový datový model, je tam spousta nového kódu.

Business Intelligence analytici si sice žádají nějaký feedback od vývojářů, ale poté, co jsem to trochu propojil a požádal je, aby si vyžádali ten feedback, je to stále hodně povrchní a zaměřuje se na úroveň schémat.

Já věřím a historicky se mi to už potvrdilo, že pokud necháme vývojáře dělat code review nad pull requesty, které se týkají nového datového modelu, tak je to zároveň nechtěným způsobem přinutí, aby tomu více rozuměli, a získají mnohem větší vliv na to, jak ten datový model bude vypadat.

Možná bys to mohl ještě konkrétněji představit. Co to pro mě jako vývojáře znamená?

Dostanu úkol – udělej mi review tohoto pull requestu. Jasně, budu tam mít SQL. A řeším, jestli měním schéma nebo logiku, jestli se změní metriky, které tyhle data využívají.

Stejně jako děláš pull request na vývojářský kód, třeba v Javě, budeš dělat to samé u datového modelu. Aby ses o to mohl zajímat, musíš mít prostředí rozběhlé, musíš rozumět kódu, kontextu a požadavkům.

Když to děláš poprvé, samozřejmě nebudeš vědět, co s tím dělat, tak půjdeš za Marikou, u nás datovou inženýrkou, aby ti to vysvětlila. A příště, až dostaneš podobný pull request, tak už budeš vědět víc.

Super, co dalšího se ti osvědčilo?

Taková nepříjemná věc, ale zároveň se to osvědčuje – zapojit datový stack do DevOps oncallu, do seznamu služeb, které hlídáme v rámci oncallu, a do kterého jsou zapojeni převážně vývojáři.

Standardně to funguje tak, že je skupina vývojářů, která se rotuje. Když má vývojář službu, mu v noci přijde hovor na mobil z nějakého monitoringu, že služba přestala fungovat.

Mám zkušenost, že když do tohoto oncallu zapojíme i datový stack, kde se děje spousta věcí automaticky v noci, je to pro vývojáře šok, protože tomu nerozumí a nevědí, co se děje.

Ale donutí je to to pochopit. Donutí je to komunikovat s lidmi z dat, pochopit požadavky. Většinou to pak vede k tomu, že je to motivuje i k tomu, aby pomohli to zlepšit.

Často totiž datový stack funguje, ale nedostávají se tam nejlepší praxe a designové vzory z vývojářského světa.

To mi přijde úžasné, protože mezi zhruba třiceti hosty, které jsem měl v našem podcastovém studiu, bylo téma best practices z inženýringu, softwarového světa, CICD a udržitelnosti kódu jedno z nejvýznamnějších.

Vidím to právě z této strany a přijde mi to jako velmi elegantně vyřešené, že jakmile začne něco blikat a vidíš, jak je to tam povětšinou zbastlené, líbí se mi, jak to řešíte.

Je to nepříjemné, ale vývojáři jsou vždy proti tomu, vždy jim to vadí.

Já mám jinou zkušenost s týmem, kdy ve studiu nefungovala spolupráce vývojářů a supportu. To jsou typicky dva týmy, které jsou ve velkém konfliktu.

Tak jsem zavedl rotaci vývojářů na supportu – museli zvedat hovory. To je noční můra každého vývojáře.

A co je překvapující, že se ukázalo, že vývojáři často nerozumí vlastnímu produktu.

Vývojář, který dělá třeba mobilní aplikaci, je v šoku, když mu zavolá někdo s problémem s webovým adminkem.

To samé se děje s daty – vývojáři vlastně pořádně neví, jak vypadají data, když se převedou do BI stacku.

Je tam vždycky velký odpor od těch lidí.

Ale zatím to naznačuje, že jsi hodně přísný na své vývojáře.

Právě že vůbec nejsem.

Nutím je dělat review datových modelů.

A to vůbec nejsem přísný. Díky zkušenostem vím, že to nefunguje bez vysvětlování.

Musím jim to vysvětlit, musí to pochopit a musím to tak zargumentovat, aby neměli žádný argument proti.

Z toho, co jsi vyprávěl, chápu, že logické kroky jsou zařadit datový tým pod stejný systém řízení, plánování a práci jako inženýrský tým, aby měli společnou vrstvu.

To je jedna z dalších věcí, která se mi osvědčila, i když jde o formalitu, trochu byrokracii.

Je dobré se podívat, jak funguje zadávání požadavků vývojářskému týmu.

Typicky přijde požadavek od produktu vývojářům, třeba jako tiket, ve kterém je napsané: „Umožněte novým uživatelům, kteří si stáhnou naši aplikaci, použít promo kód na první jízdu.“

Pak dlouho nic a za půl roku přijde produktový manažer za BI týmem a řekne: „Ukážte mi data, kolik lidí si stáhlo aplikaci, vyhledalo první jízdu a promo kód použilo.“

To potřebují, protože spousta těch lidí nakonec nejede, a chtějí podpořit konverzi. Nejsou si jisti, jestli můžou investovat peníze do promo kódů.

Jedna z cest je povinně zařadit do těch tiketů i BI požadavky, aby produktový manažer při zadávání funkcionality přemýšlel, jak to bude chtít vidět v reportech.

Není to byrokracie kvůli byrokracii, ale vede to k tomu, že při plánování či groomingu musí být někdo z BI týmu, protože bez toho to nefunguje.

Všechny tyto procesy nutí lidi, aby si sedli a promluvili spolu.

Je nějaká velikost organizace, od které to dává smysl, a naopak hranice, kdy to ne, protože menší týmy mají vše v hlavě?

Dnes už to nedává smysl řešit jen mentálně, chceš dokumentaci a udržitelnost od začátku.

Já jsem prošel opravdu malými týmy o dvou lidech, až po zavádění DevOps v Komerční bance s 900 vývojáři.

Velikost týmu není rozhodující. Je to individuální a záleží na tom, jaké problémy řeší.

Viděl jsem například velké týmy s desítkami lidí, kteří mají jen whiteboard a žádné složité procesy. Ani si nehrají na Scrum nebo Kanban a funguje to.

Naopak v menší firmě Showbiz na Slovensku, kde jsem byl před Lifetag, bylo třeba zavést procesy, protože 4–5 lidí si moc nerozumělo.

Asi podobný případ je Lifetag, kde data a práce s nimi jsou klíčovou kompetencí a největším potenciálem růstu firmy.

Je to tak. Máme data z vysokých milionů jízd za posledních 10 let a plány, jak je využívat.

Máme malý datový tým – dvě dámy, data inženýrku a BI analytičku.

Je evidentní, že musíme stavět na těchto lidech. Dokončit nový datový model a začít experimentovat s AI modely, protože v této oblasti zatím jen lehce experimentujeme.

Cítíme, že nám AI může výrazně pomoci.

Můžeš být konkrétnější, co znamenají tyto experimenty?

V současnosti máme jediný experiment v rámci AI s firmou, která nám s tím pomáhá.

Je to model, kterým se snažíme optimalizovat aukční systém ve FTagu.

Očekáváme, že zvýšíme ukazatel „order to ride“, tedy počet objednávek, které vedou k tomu, že lidé skutečně jezdí.

Model nám pomáhá přiřazovat správné řidiče a taxíky lidem, kteří se pravděpodobně objednají.

My uvnitř firmy nemáme skoro žádné zkušenosti s AI a chceme tuto kapacitu budovat.

Vidíme, že AI může posílit náš core business a model.

Jsem ve fázi hledání řešení, jak dál experimentovat s dalšími modely a zároveň zvyšovat kapacitu týmu.

Pokud chceme mít směr, musíme rozumět alespoň tomu, jaké problémy jsou vhodné pro AI a které ne.

Pociťujete tlak zvenčí, že jako technologická firma musíte experimentovat s AI?

Samozřejmě je tlak z venku obrovský.

Třikrát týdně se někdo ptá, zda používáme ChatGPT.

To je zajímavé, že do teď to tak přímo nepadlo.

Máme připravené scénáře a směry, kam chceme jít.

Chceme být lepší v predikci krátkodobých, real-timeových kapacit, které zatím vůbec nepredikujeme a nemáme nástroje na jejich sledování a odhad.

Například víme, že když začne pršet, zhorší se v Praze provoz a změní se poptávka po taxících.

Když je nehoda, což se snadno zjistí, taky se poptávka změní.

To vůbec nyní nevyhodnocujeme.

Je tam příležitost předávat tyto informace řidičům.

Stále trváme na tom, že Liftag je platforma a marketplace.

Nikdy nebudeme technologií, která řidiči říká: „Jdi sem, teď tam.“ Optimalizace bude spíše poskytování užitečných informací.

Třeba info, jestli už má smysl odjet, protože za půl hodiny už se nebude jezdit, nebo jestli má ještě chvíli vydržet, protože začne pršet nebo je nehoda na trase.

To mi dává velký smysl.

Dále zvažujeme využít veřejně dostupné informace o dění v Praze, abychom dokázali předpovědět zvýšenou poptávku.

Řidiči by pak mohli dostat doporučení, aby se přemístili na místo třeba končícího koncertu.

Pracujeme také na modelech churnu pasažérů – chceme pochopit, kdy uživatelé přestanou službu používat.

Je to složitější než u SaaS služeb s předplatným.

U nás uživatelé mají různé vzorce chování: někdo používá službu jednou či dvakrát měsíčně už pět let, jiný dvakrát denně a najednou jednou týdně.

Tato změna chování pro nás znamená churn, tedy odchod uživatele.

Detekce této změny a reakce může pomoci pochopit důvody odchodů.

Máte persony podchycené? Snažíte se je držet, posunují se?

Persony jsou pro nás aktuální téma.

Snažíme se je vydefinovat, ale máme analýzu trochu zaseklou.

Liftag je velmi složitý business – B2B i B2C.

Jsme partnery firem, kterým vozíme zaměstnance namísto vlastní flotily.

Vozíme různé typy klientů – strojíce, cargo, pacienty na klinické testy.

Kdo je vlastně náš zákazník, jak funguje churn, které jsou persony – tohle při definování person vede ke vzniku stovek papírů a person.

Ale směřujeme k tomu, aby nám modely pomohly vydefinovat hlavní persony a kdy mezi nimi uživatelé přecházejí.

Mně vždy připadalo legrační, že Liftag nedělá optimalizaci dopravy jako hlavní věc.

V našem byznysu je ale agent, tedy člověk, velmi silný faktor.

Má velkou svobodu, přesně jak jsi říkal o marketplace, vybírá si zakázky, bere či nebere, kdy se mu vyplatí jet.

Jak s touto komplexitou pracujete, když to nejde optimalizovat jako u robotů?

Snažíme se pochopit řidiče jako lidi, ne jenom jako zdroje.

Netlačíme na cenu, protože konkurence nás převálcuje.

Tlačíme na kvalitu.

Mnoho našich řidičů jsou velmi zkušení taxikáři, kteří to dělají dobře, kteří jezdí trvale na stejných trasách, mají dlouhodobé zkušenosti…

Skvělí řidiči, jsou to jako řemeslníci. A my se od nich máme hodně co naučit. Myslím, že by byla velká chyba, kdybychom si mysleli, že tady zapneme nějaký e-model a najednou tomu řidiči přesně řekneme, co má dělat. Myslím, že bychom velmi narazili. Už po těch třech měsících, co jsem tady a co jsem se bavil s pár desítkami řidičů, si myslím, že bychom opravdu narazili. Myslím, že je potřeba do toho jít s pokorou a pochopit, že přes všechny data, která máme, přes veškerou technologii a přes ty e-modely, které plánujeme, jsou to pořád naši partneři – řidiči –, kteří většinou velmi dobře vědí, co dělají. Mají to natrénované. Jejich vnitřní model v hlavě, mentální model, je natrénovaný ze stovek a stovek hodin praxe.

Je to tak, ale někdy je potřeba – a takhle o tom uvažujeme – aby ty modely neměly dané, že to funguje tak, jak aplikace, ale měly by dávat informace těm řidičům, díky kterým jsou schopni se sami rozhodnout. My například, když jsme začali vozit balíčky, delivery, tak pro velkou část taxikářů je to skoro urážka. „Já vozím lidi a teď chcete po mně, abych někam vezl nějakou myš nebo zásilku, to je jako urážka.“ A když těm lidem ukážeme na datech, jak se jim zvedne – my tomu říkáme earning per hour, tedy ukazatel – protože cena za kilometr nebo cena za minutu je sice fajn, ale nakonec může řidič přijít večer domů a zjistit, že se moc nevydělal. Když ale počítáme hodnotu „earning per hour“, je to pro ně srozumitelnější a my jim můžeme vysvětlovat, že v určitých částech dne, kdyby třeba nikam nejeli, tak se jim vyplatí přepravit nějaký balíček. Nebo že třeba vezmou tenhle balíček, díky kterému se dostanou na místo, kde končí koncert v Holandě, kde bude poptávka jinde. Takto k tomu přistupujeme.

Myslím si, že spojení BI (business intelligence) a našich partnerů, tedy řidičů, je klíčové a je potřeba to dělat dobře. Zdá se mi, že většina věcí, o kterých jsi mluvil, se týká vlastně taxíků a přepravy osob, toho klasického Liftaga, ne Liftago Network. Jak vám do toho „network“ hází vidle? Je ta abstrakce vlastně zjednodušující, protože se nemusíte dívat na sedm různých případů použití, ale je to jednotná logika? Nebo je to naopak mnohem komplexnější problém?

My to chápeme tak, že pro Liftago Network je Liftago vlastně první klient. Liftago využívá velkou část funkcí Liftago Network a takto si představujeme, že další partnerské služby budou Liftago Network využívat. Jsme tedy v pohodě s tím, že přijde někdo další a založí další Liftago, které poběží na naší platformě Liftago Network. A je jedno, jestli bude vozit balíčky, lidi, jídlo, nebo cokoliv dalšího, to už je vcelku jedno.

Pro Liftago Network je důležitá právě ta komplexita, ta „chytrost“, tedy dobré využívání dat. Protože v taxících vozíte člověka z místa A do místa B, ale aby to v Liftago Network fungovalo, musí to být dobře optimalizované. Nevyjde mi, když vezu jednu myš někam do Podolí, protože to nedává ekonomický smysl. Můžeme být sebechytřejší a prodávat to sebeúžasněji, ale nedává to ekonomický smysl. Díky datům, která máme, a když se s nimi naučíme dobře pracovat a předávat je řidičům, můžeme optimalizovat a tím zvyšovat výdělky řidičů. Nejednou nevozím jednu myš, ale na jednom kufru deset balíků. A jakmile vím, kde mám vysadit ten první, tak jdu nabrat další. Pak to začne dávat smysl.

V tomto kontextu, Radku, co jsi teď popsal – konkrétní problémy Liftago jako taxi služby v kontextu platformy Liftago Network a možné použití AI k optimalizaci nebo vylepšení fungování celého systému – jaký máš přístup k řešení? Řešíš to přes jednotlivé dílčí problémy, tedy nejdříve taxi službu, balíčky apod., nebo se rovnou zaměřuješ na abstrakci a řešíš to na obecné úrovni přípravy všeho?

Myslím si, že není jiná cesta než řešit dílčí problémy, ale pořád mít v hlavě ten velký cíl a stále si připomínat, co vlastně budujeme a kam směřujeme. Nemůžeme najednou předstírat, že budujeme něco odshora dolů, a přitom zapomenout na řidiče, kteří pro nás jezdí, a na lidi, kteří si přes nás posílají balíčky. Je tedy třeba řešit jednotlivé malé problémy, ale zároveň se neustále vracet k tomu, čeho chceme dosáhnout. Pořád si připomínat, že jde o optimalizaci přepravy v Praze a o vytváření marketplace, kde se efektivně obchoduje nabídka a poptávka.

Máte v systému nebo v tom procesu nějaké hodnoty typu OKR, podle kterých prioritizujete, zda se něco týká Liftago Network, nebo je to jenom pro Liftago app?

OKRka se snažíme zavádět právě teď. V naší firmě už párkrát proběhla. Máme tři pilíře, tři základní sloupy, na kterých vše stojí. První pilíř je Liftago. To je to, z čeho Liftago vzešlo, a tam se snažíme řešit problémy jednotlivých zákazníků. To nutně nemusí být jen taxíky, klidně to mohou být i dovezené balíčky. Ukazatel pro tento pilíř je, kolik problémů vyřešíme za měsíc jednomu člověku. Snažíme se toto číslo zvyšovat.

Druhý pilíř je Liftago Network, kde jsme se rozhodli soustředit na to, kolik si vydělávají řidiči. Věříme, že pokud budeme této hodnoty víc dosahovat, Liftago Network poroste.

A třetí pilíř, tomu říkáme „Team“, což jsme vlastně my sami. Je to proto, abychom nezapomněli, že to není jen o byznysu, ale že jde o nás lidi. Pod touto třetí kategorií skrýváme právě naši spokojenost. Zabýváme se hodně štěstím ve firmě, snažíme se snižovat stres. Sledujeme, jestli jsou lidé v Liftago vystresovaní, nebo ne, a pracujeme na vzdělávání. To je ten třetí pilíř.

To je krásné, vložit mezi ty dva produkty vlastně tým. Trochu jsi mě tady dojal a šokoval. Každopádně moje poslední otázka, kterou jsem si tady oblíbil, souvisí s kódem a Matrixem. Jak se stalo, že Miu se stal vyvoleným a neuvěděl ten kód pod světem? Co tě naučilo Liftago, nebo tvoje předchozí zkušenosti? Co teď vidíš, když jdeš po pražské ulici a zahlédneš taxík? Vidíš, jak někdo objednává Uber? Vidíš, jak někde čeká na balíček DPD? Co zatím všechno vidíš? Jaká je tvoje profesní deformace?

Je fakt, že jsem si začal všímat prázdných aut, která stojí, protože si myslím, že každé prázdné auto, které stojí a nikam nejede, je kapacita, která by se dala využít. A kdykoliv vidím taxi, které je zaparkované, nebo dodávku, která je zaparkovaná a nic nevozí, vidím to jako nevyužitou kapacitu pro network. To se týká i ride-sharingových aut a všelijakých dalších.

Dokážu si představit, že těch kapacit je v tom městě daleko víc, které tam už jsou a možná tam překáží – ať už na silnici, nebo na parkovacím místě –, ale mohly by někomu sloužit. Nejsem žádný úplný zelený fanatik, ale přijde mi to prostě hloupé, že v tom městě stojí prázdná auta, nebo jezdí prázdné dodávky, které jsou vytížené, anebo vidím taxíky, které jedou prázdné a přemisťují se. To je hloupé a měli bychom to vyřešit.

Takže moc děkujeme, držíme nám všem palce, aby ve městech bylo čím dál méně prázdných aut.

Děkujeme moc, Facku.

Já vám moc děkuji za pozvání, hezký den.

A to je všechno. Díky, že jste doposlouchali další díl Datatolku. Děkujeme také našim partnerům – Big Hubu, Vypnoutu, Mantě, Notinu, Atakámě, GMBimu, Seznamu.cz a MUSE. Pokud vás zajímají další informace ze světa datových technologií a československé datové scény, navštivte naše stránky datatolk.cz. Nechť vás provází data.