Ilyen az Uber belülről - a fejlesztő szemével

Hogyan kerültem ide

Kissé furcsán hangozhat, de tulajdonképpen véletlenül kerültem az Uberhez (hasonlóan ahhoz, ahogy az egyik első magyar került a Facebookhoz). Londonban éltem egy ideje, ahol korábban a Skype-nál, majd később a Skyscannernél dolgoztam változatos projekteken. Az Uber nekem szoftveres szemmel nem tűnt különösebben érdekesnek: nem hallottam arról, hogy túl sok újszerű dolgot csinálnának, például az open source térben - szemben több más, hasonlóan nagy céggel, mint például a Facebook vagy Google.

Úgyhogy nem is én jelentkeztem, hanem egy recruiter keresett meg LinkedInen, hogy nyitott lennék-e egy amszterdami mobilos pozícióra. Végül leginkább azért mondtam igent, mert kíváncsi voltam, hogy mégis milyen is a cég maga - mégis a világ leggyorsabban növő cégéről beszélünk -, illetve arra is, hogy átmennék-e egyáltalán az interjújukon.

Az Uber interjúja tipikus, "Silicon Valley algoritmikus startup interjú". Korábban a Facebooknál egy hasonló interjún már voltam pár éve - de ezeket a típusú interjúélményeket időnként nem árt felfrissíteni, még akkor sem, ha amúgy elégedettek vagyunk a jelenlegi munkahellyel. Plusz, ha az első, telefonos körön átmegyek, akkor ki mondana nemet egy amszterdami kiruccanásra?

Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.

Az interjúfolyamat nagyjából olyan volt, amilyenre számítottam és amire készültem. Ami viszont meglepetésként ért, az a csapatot hajtó vízió - amely egészen más, mint amit mindannyian ismerünk (és amit Magyarországon betiltottak). Erről érdemes pár szót szólni, hiszen a munkahely választásánál ez legalább olyan fontos szempont, mint a fizetés vagy a város. A lényeg: ami itt készül, az nem a "személyszámító Uber", hanem az Uber, mint platform, ami A-ból B-be bármit szállít, egyre több és több helyen. Embereket, autókkal (UberX). Egyszerre több embert, az autók utasterét jobban kihasználva (UberPool). Munkába be, és haza, egy havi fix árért (UberCommute). Ételt, autóval, robogóval, biciklivel (UberEats). Kis és nagy dolgokat, a boltból az otthonig (UberRush). Árut, teherautóval (lásd Otto felvásárlás).

Az amszterdami csapat feladata az egyik legfontosabb komponens, az Uber appban történő fizetés fejlesztése. A csapat alapját egy, az Uber által két éve felvásárolt mobilos cég adta, akik 10 fővel az első fejlesztők voltak az irodában. Azóta ez a csapat 40 főre nőtt, és ők felelnek azért, hogy közel 70 országban, havi több tízmillió utas gond nélkül tudjon fizetni és utazni. A fizetési folyamat minden része - a backendtől a mobilig - Amszterdamban van, egy helyen. Egy amerikai központú cégnél nem gyakori, hogy egy távoli irodának ilyen fontos szerepe van - úgyhogy elkezdett érdekelni a lehetőség.

A döntésben szintén szerepet játszott az uberes szoftveres kultúra is. A csapat komoly technológiai stacken dolgozik, amely ráadásul folyamatosan változik az igényeknek megfelelően (az Uber saját bemutatója errő itt és itt érhető el). A legfontosabb szempont az eszközválasztásnál a fejlesztői produktivitás, ezért például az iOS-es app Swiftben készül, és az androidos és iOS-es alkalmazás build rendszere is a Facebook-féle Buckkal fordul a rövidebb fordítási idő miatt. A saját készítésű eszközökből sok mindennek megnyitja a forráskódját az Uber, erre példa az okbuck, amely a Buck használatát teszi lehetővé Gradle projekteken.

Következzenek tehát az első néhány hónap benyomásai.

A kevéssel többet csinálni: always be hustling

Elsőre meglepett, hogy mennyi ember dolgozik az Ubernél (több, mint 2 000 fejlesztő), ennek ellenére sosincs elegendő ember a fontos projektekre. Az én csapatomban 15 mobilfejlesztő van, a fele Android, fele pedig iOS fejlesztéssel foglalkozik. A csapat nagy része az Uber app újraírásán dolgozott, a kisebb rész pedig egy kisebb projekten, a latin-amerikai készpénzes fizetést fejlesztették. A hosszabb távú feladatok mellett viszont folyamatosan jöttek projektek, amik vagy több százezer új utast, vagy több millió dollár bevételt jelentettek volna a cégnek.

^{Első projektem: az Uber app komplett újraírása - ezen belül a fizetési lehetőségek}

Érzésre ugyanakkor nemhogy ezekre a projektekre, de a meglevőekre sem volt elég emberünk. A legtöbb, sok millió ember által használt fejlesztésen 2-3 fejlesztőnél több nem dolgozott - mert egyszerűen nem volt több. Ennek ellenére viszont a határidők iszonyú rövidek. Az első két hónapban folyamatosan pörögtem és rengeteget dolgoztam, és még így is alig sikerült befejezni egy-két kisebb projektet (és azokat is csak csúszással). Nem igazán értettem, hogy egyrészt ennyi ember miért nem elég: más cégekhez képest a mobil csapatunk nem volt kicsi. Másrészt, ha nem elég az ember, akkor miért ilyen kevesen vagyunk, vagy miért ilyen rövid határidőkkel dolgozunk.

Az Uber egyik alapfilozofiája pont erre a szűkösségre épül: "always be hustling". Vagyis: használd előnynek azt a hátrányt, hogy nincs elég ember, nincs elég idő, nincs elég pénz. Ahol négy fejlesztő és 6 hónap kellene a projekthez: most csak 2 fejlesztő és 3 hónap áll rendelkezésre. Ez kényszert szül: a helyzet megoldásához okos ötletek, kompromisszumok kellenek.

Ez startupoknál megszokott recept, az eredménye pedig az, hogy - ha jól csinálod - akkor kizárólag a fontos dolgokra fókuszálsz, minden mást eldobsz. Az Uber még mindig hypergrowth fázisban van, úgyhogy ez a kényszer továbbra is él, és folyamatosan előnyt próbálunk kovácsolni ebből a hátrányból, pont úgy, ahogy a legtöbb startup amúgy is teszi.

Pár hónap után kattant be, hogy hogy is működik, és azóta én is tényként kezelem, hogy úgyse lesz annyi időnk, amennyi kellene. Úgyhogy minden nagyobb projektnél az első lépés a feladat lebontása, priorizálása és az egyes elemek megkérdőjelezése. Ha a projekt egy hónapig tart: mi történne, ha csak egy hetem lenne? Mit tudnék akkor megcsinálni? És ha még egy hetet kapnék? A válaszokból összeáll a prioritási lista. És ez fordítva is működik: mi az, amit első körben felesleges kifejleszteni, amíg nem megy ki élőben? Remek - akkor azokkal várjunk addig, amíg bejönnek az első eredmények.

El a fejlesztők útjából: let builders build

Az Uber a korai időktől kezdve rengeteget fektetett a belső toolingba. Debuggolni akarod, hogy mi történik, ha egy utast a Fülöp-szigeteken veszel fel? Kész erre a tesztkörnyezet, ahol (majdnem) minden külső paramétert tudsz szimulálni. Élesítenél egy új képességet, de csak egy városba, csak Uber dolgozóknak? Egy fejlett és egyedi A/B és feature flag rendszer már régóta üzemben van. Egy kicsit kutatnál, hogy megnézd, hányan mondanak le fuvarokat adott időpontban, és hogy változik hetente? Szintén egy penge belsős univerzális lekérdező rendszerrel nagyjából minden anonimizált adatot le tudsz kérdezni. Vizualizálnád ezeket az adatokat, jobb elemzésre? Erre is van rendszerünk. És ezeket nem ma építették, hanem az egyik legrégebbi rendszerek, amik az Uber kezdeteitől, már évek óta itt vannak és folyamatosan csak tovább javulnak.

^{Belső kísérleti platform - elemzéssel, vizualizációval}

A legtöbb cég spórol a belsős rendszereivel: ezek azok, amiket valaki összetákol, aztán úgy maradnak. Az Ubernél érzésre ezek a rendszerek majdnem ugyanolyan csiszoltak, mint az app, vagy a weboldal. A titok, hogy dedikált csapatok dolgoznak ezeken, főállásban. Külön CI csapat van iOS-re és Androidra, külön build csapat a fontos platformokra, külön build train csapat, és külön developer experience felelősök. És nem ülnek a babérjaikaon: pár hetente valamilyen új toolt vagy más változtatást jelentenek be, amivel még jobban, gyorsabban, könnyebben lehet fejleszteni.

Mondani sem kell, nekem ez a hozzáállás erősen újszerű volt. Biztos vagyok benne, hogy sok cégnél - főleg a kisebbeknél - nem lenne értelme külön tooling csapatoknak. Viszont az Uber egészen biztosan nem tudott volna ilyen gyorsan nőni ilyen komoly belső rendszerek nélkül.

Egy lényeges hátulütője azért van ennek a céges kultúrának: sokszor a Not Invented Here szindróma köszön vissza. Mivel sok ember fő feladata a platform vagy build minél jobb optimalizálása, ezért többször egyedi eszközöket vagy könyvtárakat fejlesztünk, amik a meglevőeknél gyakran csak kicsit jobbak - vagy egyszerűen másak. Például az iOS vagy Android appban nem a beépített alaposztályokat használjuk, hanem azon felüli sajátokat, általában "U" prefixszel. A build rendszer ugyan tényleg elég jó, de teljesen egyedi fejlesztés. Amikor itt kezdtem, egy csomó mindent újra kellett tanulnom és egy csomó Uber-specifikus best practice-t vagy workaroundot használok.

Érezd a magadénak: be an owner, not a renter

Habár egy masszív cégről van szó - csak fejlesztőből több, mint 2 000 van - mégis inkább startupnak, mint nagy cégnek érzem az idő jó részében az Ubert. Ennek két fő oka van.

Az első, hogy a belsős folyamatok nem különösebben kiforrottak. Nincsen egy egységes "metodológia", amit a csapatok követnek kisebb-nagyobb projekteknél. Minden csapat eldönti, hogy mit és hogyan csinál. A Skype után, ahol az egész cég egységesen Scrumra állt át, ez egy kicsit furcsa volt. Ugyanakkor ez a hozzáállás nagy szabadságot is ad: vannak csapatok, akik Kanbanra, vannak, akik Scrumra esküsznek, de a többség leginkább egyikre se, hanem saját hatáskörben kialakítják a habitusuknak és a feladatnak megfelelő rendszert. Az egyetlen egységes processz a fejlesztőknél annyi, hogy egy projekt kezdete előtt egy részletes tervezési doksit küld a csapat az egész fejlesztői részlegnek: egy RFC-t (request for comment). Ilyenkor más csapatok hozzászólnak, kritikát fogalmaznak meg, vagy rábólintanak - és ez a folyamat meglepően jól működik.

^{Házi fejlesztések: nem csak szoftverrel foglalkozunk.}

A második, hogy habár nincsenek kőbe vésett folyamatok, ha valamit szerinted jobban lehet csinálni, akkor csak az egyénen múlik, hogy ez megváltozzon. Általános hozzáállás, hogy "be an owner, not a renter" - vagyis, ha valamit szerinted jobban lehetne csinálni, akkor vedd a kezedbe, csináld jobban, és változtass, hogy mások is kövessenek. Az emberek maguktól javítanak azon, ahogy a cég működik. Például észrevettem, hogy a kódban nagyon sok eseményt naplózunk analitikai céllal, de ezek sehol nincsenek összegyűjtve. Megemlítettem a kollegámnak, és a következő percben azt beszéltül, hogy ki lesz ennek az "ownere", aki összeszedi őket valamilyen karbantartható módon.

Körülöttem mindenki - a junior fejlesztőktől kezdve a csapatvezetőkig - folyamatosan kisebb-nagyobb dolgokat változtat és javít. Persze, van pár céges folyamat, amit követünk, de ezek sem szentírások. Gyakran megkérdőjelezzük ezeket is, illetve ha kell, és értelme van, akkor, változtatjuk (vagy legalábbis megpróbáljuk). Idővel biztosan kevesebb dolog fog változni, de amíg továbbra is gyorsan nő a cég, addig az a folyamat, ami X embernél működött, egy év múlva, 2X vagy 3X embernél már nem fog.

Lássuk a medvét: on-call, időeltolódás és stressz

Tökéletes cég illetve tökéletes munkahely persze nincs. Az Ubernél sem fenékig tejföl minden, sőt, pár dolog visszalépés az eddigi munkahelyekhez képest..

Az első, az on-call/devops. Minden csapat, amelynek éles (production) fejlesztése van, maga felel azért, hogy az folyamatosan működjön. Az Ubernél ugyan már van egy Site Reliability Engineering csapat, de ettől még minden csapat on-call rotációt csinál. Vagyis, az én esetemben kéthavonta egy hétig én vagyok az on-call engineer. Ha ezalatt az appon bármilyen rendellenességet észlelünk, ami értinti a fizetést, akkor engem hívnak fel, nekem meg 10 percem van leokézni és elkezdeni megoldani a gondot. Magyarán ezen a héten mindig nálam kell, hogy legyen a laptopom és 4G lefedett helyen érdemes tartózkodnom. És persze éjjel bármikor kaphatok egy értesítést - a legutóbbi héten kétszer kellett felkelnem, két valódi riasztásra.

Az on-call / devops nem kellemes - de valahol hasznos. Az első héten, amikor on-call voltam, az első két éjszaka egy-egy fals riasztást kaptam (minden rendben volt és az emberek simán tudtak fizetni, hiába hitte a rendszer, hogy nem). A második után már elég morcos voltam hajnali 4-kor, hogy nekiálljak, és egy óra alatt átkonfiguráljam a riasztást, hogy legközelebb ne riasszon feleslegesen (de lehetőleg riasszon, ha tényleg gond van).

A második probléma (mint minden globális cégnél) az időeltolódás. Az Uber központja San Franciscóban van, több, velünk együtt dolgozó csapat is ott dolgozik. Ha velük kell egyeztetnünk, akkor videóhívás legkorábban 5-kor lehet, de inkább este 6 és 8 között. Ha pedig valamit nagyon sürgősen meg kell oldani, amit nélkülük nem tudunk, akkor van, hogy az este későbbre nyúlik. De az időeltolódás nem csak San Franciscóval gond, hanem Indiával is. A csapatunk fejleszti az összes, India-specifikus különleges fizetési megoldást is. Az ottani csapat 4 órával később van: szóval őket leginkább kora délutánig érjük el - ha délután vagy este kellene valami segítség tőlük, akkor van, hogy másnapig várnunk kell.

És végül beszéljünk a stresszről. A kevesebbel többet / "always be hustling" filozófia jól hangzik, és egészen jól is működik úgy általában. Ugyanakkor a gyakorlatban ez azt jelenti, hogy nagyon sokszor nagyon kicentizve dolgozunk. És persze elég, hogy csak egy dolog csússzon, hogy az egész projekt megboruljon. Az első pár hónapban pont egy ilyen projekten voltam: itt két héten át éjjelig melózás, hétvégén kódolós időszakunk volt. A mostani projektem jóval nyugisabb, de simán lehet, hogy megint bejön egy hajtós időszak.

A rossz hír, hogy a stressz, mint olyan, nem csak az én csapatomra, hanem az egész Uberre jellemző. A jó viszont, hogy ezt az Uber is tudja és megy az ötletelés cégen belül és cégen kívül is, hogy hogyan is kéne ezt jobban csinálni (például most bízták meg a Thrive nevű céget ennek javítására). Az én részemről ez nem volt nagy meglepetés: számítottam arra, hogy többet, és néha kevésbé kiszámíthatóan kell majd dolgoznom: az IPO előtti Facebooknál is nagyjából ugyanez történt, ahogy például egy ott dolgozó PM be is számolt róla. Viszont az "érezd magadénak" filozófia itt is ugyanúgy él, és egy csomó változtatást csapat szinten is hozhatunk (és hozunk), hogy kevesebb legyen a munkaidőn kívüli és/vagy nem tervezett munka.

Zárszó - a csapatról

Az amszterdami csapatunkban dolgozik Jordan Bonnet, az Uber első mobilfejlesztője, aki már elég sokat látott a cégnél, vagy David Ng, az OpenLabel alapítója és Tadeu Zagallo, a React Native egyik első fejlesztője is, illetve Jeff Wolski, az Uber-backend egyik formáló alakja. A csapatra pedig nem mindennapi nyomás nehezedik, a fizetési alrendszer egy-egy hibája akár több millió dolláros veszteséget is okozhat, de ugyanekkora probléma, ha csúszik a fejlesztés, és így hasonló nagyságrendű bevételtől esik el a cég - a kihívás tehát nagyon gyorsan, és nagyon pontosan dolgozni.

A cikk szerzője Orosz Gergely, az Uber mobilos szoftvermérnöke és a Tech Inspiráció blog szerkesztője, korábban a Skyscannernél dolgozott, a Skype-nál pedig az Xbox One csapat alapító tagja volt.