Egy hypergrowth cég belülről: az Uber a fejlesztő személvel

Milyen lehet a világ legértékesebb startupjánál dolgozni? Pár hónapja még csak beszámolókat olvastam mások tapasztalatairól, hogy milyen a napi munka az Ubernél. Pár hónapja kezdtem az amszterdami irodában mobil fejlesztőként dolgozni, amennyire én tudom, az első magyar szoftverfejlesztőként. Most első kézből mesélem el, hogy milyen volt az elmúlt időszak. Pörgős, néhol stresszes, sokat tanulós - és helyenként teljesen más, mint amire számítottam.

Hogyan kerültem ide

Lehet, hogy furcsán hangzik, de elég 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 akkoriban nem igazán 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 csak a világ egyik leggyorsabban növő cégéről van szó -, 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úkat időnként nem árt felfrissíteni. Plusz, ha az első, telefonos körön átmegyek, akkor ki mondana nemet egy amszterdami kiruccanásra?

Az interjú folyamat nagyjából az volt, amire számítottam (és amire készültem). Ami viszont elkezdte felkelteni a figyelmemet az a rengeteg energia, ami az amszterdami Uber irodából áramlott. Az itt dolgozó emberek nem arról a személyszállító Uberről beszéltek, amit mindannyian ismerünk - és amit Magyarországon mellesleg betiltottak. Sokkal inkább az Uberről, mint platformról, 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). Mindezt egyre olcsóbban és egyre csak jobban.

Amszterdamban az Uber egyik ütőere, az appban való fizetés fejlesztése zajlik. Két éve az Uber felvásárolt egy mobilos céget, 10 fővel, akik 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íz millió utas gond nélkül tudjon fizetni - és utazni. A fizetési folyamat minden része - a backendtől a mobilig - mind 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.


Az Uber amszterdami irodája

Az Uberes szoftveres kultúra is megdobta az érdeklődésemet, miután többet tudtam meg az itt dolgozóktól. Elég komoly technológiákkal dolgoznak, amit folyamatosan változtatnak az igényeik szerint (részletek erről, itt és itt). Mobilon az eszközöket is elsősorban a produktivitás alapján választják: iOS-en Swift-ben fejlesztenek, és mind az iOS-es, mint az Androidos build system buck-ra áll átt, a gyorsabb fordítási idő miatt. Emellett elég sok fejlesztésüket open source-olják, hogy mások is hozzáférjenek, használják, és változtathassák.

Szóval végül fejest ugrottam a lehetőségbe. Néhány hónap után pedig ez a benyomásom a cégről és az itteni munkáról.

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

Elsőre meglepett, hogy több, mint 2,000 fejlesztő dolgozik az Ubernél... és hogy érzésre még sincs elég ember a fontos projektekre. Az én csapatomban 15 mobilfejlesztő volt, a fele Android, fele pedig iOS. A nagy részünk az Uber app újraírásán dolgozott, a kisebb rész pedig a Latin-Amerikai készpénzes fizetést fejlesztették. Viszont emellett 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.

Az első projektem: az app újraírása (ezen belül is a fizetési funkcionalitás)

Érzésre ugyanakkor nemhogy ezekre a projektekre, de a meglevőekre sem volt elég emberünk. A legtöbb projekten, amit több millió ember használ, 2-3 fejlesztőnél több nem dolgozott - mert egyszerűen nem volt több. A határidők viszont mind iszonyú rövidek voltak. 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 alapfilozófiá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ő van, és 3 hónapunk. beszéljünk arról, hogy hogyan lesz mégis kész. Ez startupoknál egy recept, amit a kényszer szül - 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 - 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 bármi nagyobb projektbe kezdek, egyből lebontom, prioritizálom és megkérdőjelezem, hogy biztos, mindenre szükség van-e. 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? Szuper, akkor megvan a prioritizált lista, amivel kezdek. Mi az, amit első körben felesleges lefejleszteni, 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ő eszközökbe. Debuggolni akarod, hogy mi történik, ha egy utast a Fülöp-szigeteken veszel fel? Erre van egy frankó teszt környezet, ahol (majdnem) mindent tudsz szimulálni. Kiadnál egy új funkcionalitást-t, de csak egy városban, csak Uber dolgozóknak? Egy fejlett és egyedi A/B tesztelő és kísérletező (experimentation) 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, adatok vizualizációjá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? Dedikált csapatok dolgoznak ezeken, fő állásban. Külön Continous Integration (CI) csapat van iOS-re és Androidra, külön build csapat a fontos platformokra, külön app tesztelésért és kiadásért felelős csapat (a build train csapat), és külön fejlesztői produktivitásért felelős arcok (developer experience csapat). É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.

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 egy csomó ember fő feladata a platform vagy build minél jobb optimalizálása, ezért egy csomószor egyedi eszközöket vagy könyvtárakat fejlesztünk, amik a meglevőeknél gyakran csak kicsit jobbak - vagy másak. Például az iOS vagy Android appban nem a meglévő alaposztályokat használjuk, hanem azon felüli, sajátokat, általában "U" prefixxel. A build rendszerünk ugyan tényleg elég jó, de teljesen egyedi. Amikor itt kezdtem, egy csomó mindent újra kellett tanulnom és egy csomó Uber-specifikus módszert vagy best practice-t használok.

Nem csak szoftvert fejlesztünk

É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 ember 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. Egy Skype után, ahol az egész cég például egységesen scrum-ra állt át, ez egy kicsit furcsa volt. Ugyanakkor egy csomó szabadságot is ad: vannak csapatok, akik kanbanra, vannak, akik scrumra esküsznek, de a többség leginkább egyikre se, hanem kialakítják, hogy hogy dolgoznak. Az egyetlen egységes processz a fejlesztőknél annyi, hogy egy projekt kezdete előtt egy részletes tervezési doksit kikü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.

A második, hogy habár nincsenek kőbe vésett folyamatok, ha valamit szerinted jobban lehet csinálni... akkor a csak rajtad áll, hogy jobban csináljuk-e. Á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 egy csomó analytics eseményt loggolunk, 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.

Győzzön a legjobb ötlet, még ha ez nem is kellemes: mertitocracy and toe-stepping

Voltál már olyan helyzetben, hogy jó okod volt, hogy nem értettél egyet egy döntéssel, de a csapat, vagy a főnök mégis keresztülvitte? Az Ubernél az egyik alapérték, hogy tegyünk meg mindent azért, hogy a legjobb ötlet győzzön, még ha valaki másnak a "lábára" rá is kell egy picit lépned. Vagyis még akkor is hozd elő az (ellen)véleményedet, ha ez azt jelenti, hogy valaki mással szemben fogsz állni.

Mit is jelent ez? Sok cégnél a csapatmunka a konfrontálódás minimalizálását jelenti. Itt a csapatmunka azt is jelenti, hogy amíg nem értesz egyet egy döntéssel, addig kultúrátlan és objektíven, de vitázz, és győzz meg másokat, vagy ők téged. Mindezt függetlenül attól, hogy neked és nekik milyen a cégbeli poziciód és kapcsolatod.

Egy példa erre: a csapatom egyik szolgáltatásával fellépett egy gond, ami miatt egy ideig nem működött megfelelően. Miután megtaláltuk és kijavítottuk a hibát, annak rendje s módja szerint megvizsgáltuk, hogy miért történt ez, és hogy hogyan tudjuk legközelebb elkerülni. Egy dokumentumot csatoltunk az esetehez, amit minden fejlesztő a cégnél megnézhet (postmortem dokumentációt). Egy másik csapatból egy junior fejlesztő erre írt, hogy szerinte az általunk javasolt lépések nem garantálják, hogy a hiba nem ismétlődik meg, és ő mélyebbre ásna a helyünkben. Ezt a kérdést annyival lezártuk, hogy a csapatunk elég alaposan átvitatta, és szerintünk elég jó lenne. De ő újranyitotta, hogy ő nem ért egyet velünk, mert szerinte márpedig akkor is újra megismétlődne ez az eset.

Úgyhogy nekiálltunk átrágni, hogy mit csinálhattunk volna - és tényleg igaza volt, további megelőző lépéseket kellett bevállalnunk, hogy ez ne forduljon elő többet. Azért valahol kellemetlen, hogy egy csapaton kívüli ember hívja fel a figyelmünket arra, hogy valamit kihagytunk - és ráadásul finoman a lábunkra is lépett egyúttal. De igaza volt, és a végén a rendszerünk jobb lett, mintha nem a legjobb ötlet, hanem például a szenioritás vagy a mi csapatunk véleménye "győzött" volna.

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

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

Az első, az on-call / devops. Minden csapat, akinek production-ban van rendszere, 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 rotationt csinál. Vagyis, az én esetemben kéthavonta egy hétig én vagyok az on-call engineer. Ha ezalatt a mobil 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 - ugyanakkor 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 az időeltolódás. Az Uber központja San Franciscoban van, és egy csomó csapattal innen dolgozunk. Ha velük kell dumánlunk valamikor, 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 meg 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, Indiában használt 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.


Amerikától Indiáig fejlesztünk - néha az időeltolódással is meg kell küzdenünk

És akkor 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 csapatom, hanem az egész Uberre jellemző. A jó viszont, hogy ezt az Uber is tudja és megy a brainstorm cégen belül és cégen kívül is, hogy hogyan is kéne ezt jobban csinálni (cégen kívül most fogadták fel a Thrive nevű céget). 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

Ami összességében a legnagyobb hatással van rám, az az itt dolgozó emberek, és az, hogy tőlük mennyit tudok tanulni. A csapatomban dolgozik Jordan, az Uber első mobilfejlesztője (aki elég sok mindent látott itt...), David, aki egy startup alapítója volt a Silicon Valleyben, Tadeu Zagallo, a React Native egyik első fejlesztője, vagy Jeff, aki 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. És persze folyamatosan keresünk új embereket az amszterdami irodában: mind Android, iOS, backend és product területen. Ha érdekelne több részlet bármelyik nyitott pozicióról, nyugodtan írj a gergely (kukac) uber (pont) com címre.

A cikk szerkesztett változata a HWSW-en jelent meg: Ilyen az Uber belülről - a fejlesztő szemével

Orosz Gergely

Csapatvezető az Ubernél. Korábban a mobil és full stack mérnök a Skyscannernél és JP Morgannél, a Skype-nál pedig az XBox One csapat alapító tagja volt.

Rendszeresen új, inspiráló és érdekes sztorival jelentkezünk a szoftverfejlesztés világából.
Következik: 4 évet dolgoztam a Facebooknál. Ezt a 4 fontos dolgot tanultam itt meg.
Iratkozz fel a hírlevélünkre - és elsőként értesítünk az új szorikról.
A kommenteket a Disqus jeleníti meg