2021 márciusában részt vettem a Business Agility Institute által szervezett Business Agility Conference eseményen, ahol több inspiráló előadást is láttam. Az egyik leginkább megragadó Joe Justice Agile Hardware előadása volt. Joe 2020-ban dolgozott a Tesla agilitással foglalkozó részlegén és az ott szerzett tapasztalatait osztja meg ebben az előadásban. Az alábbiakban írok pár gondolatot, hogy engem mik fogtak meg abban amiről beszélt.

A Elon Musk pont most márciusban lett a bolygó leggazdagabb embere 197 milliárd dolláros vagyonnal. Szegény Jeff Bezos az Amazon gazdája azóta is a sarokban sírdogál, hogy ilyen csúnyán leelőzték (ő csak 189 milliárd dollárt tudott összekuporgatni). Ennek a vagyonnak jelentős része nyilván a Tesla-ból származik. A cég magas értéke természetesen a körülötte és gazdája körül kialakult hisztériával és eltorzított várakozásokkal is összefügg, de még ezek mellett is négyszeres szorzót mutat Joe prezentációja. Rákerestem erre azért, ma amikor a cikket írtam, és bár azóta kicsit visszaesett az összeg 800 milliárdról 660-ra, még így is a következő játékos (Toyota) értékének háromszorosa a Tesla piaci értéke. Korábban a Toyotát tartottuk a lean/agilis kultúra fellegvárának, akkor hogy történhetett meg, hogy egy Tesla így elhúzott mellette?

Szellemiség

A Tesla jó példája annak, hogy mennyire fontos és mélyen gyökerező dolog a vállalati kultúra, ahol az alapelvek stabilok, kimunkáltak, a vezetők valóban élik azokat és puszta hangoztatásuk helyett ténylegesen azokra épül a szervezet működése. Ezáltal létre jön egyfajta szervezeti immunrendszer ami csak a vele azonos DNS-ű működéseket tűri meg magában.

Elon Musk fenti gondolata (“Pace of innovation is all that matters in the long run”) nem foglalja tökéletesen össze mitől lett a tesla ennyire sikeres, de Joe szerint jól érzékelteti azt a szervezeti kultúrát ami a vállalatot átjárja. Ez a kultúra sok minden másban is tetten érhető.

A Teslán nincs visszapillantó

A Teslában nincs olyan szervezeti egység ami a konkurencia elemzésével, piackutatással foglalkozna. Ez elsőre furának hangzik, de Elon szerint nincs rájuk szükség. Ennek az a nagyon egyszerű oka, hogy szerinte ha valamit meg lehet csinálni jobbra (“physically possible”), akkor azt meg is kell. Nem köt kompromisszumokat ezen a téren. Ha van egy ötleted, hogy mivel tudod jobbá tenni a terméket, akkor azt kötelező megcsinálni. Ha így működünk, nincs miért a visszapillantó tükörbe nézni – hogy hol tartanak a versenytársak – mert biztos, hogy a lehető legnagyobb sebességgel haladunk a cél felé, nincs lehetőség jobban felgyorsítani.

Érdemes ezt a fenti hozzáállást összevetni azzal amit gyakran tapasztalunk a nagyvállalati működésben: Hibajegy halmok, technikai adósság, megkövesedett átmeneti megoldások. Mind a spórolás és hatékonyság jegyében. De ezen túl is, mindannyian láttuk már, ahogyan fontos funkciók fejlesztési igényei lesüllyednek a feneketlen backlog tengermélyére, és soha nem kerülnek legyártásra, csak azért, mert az – amúgy okkal – populista termékmenedzsment szerint nem kérték elegen. A Tesla által bizonyított valóság az, hogy jóval többet érdemes költeni a minőségre és az innovációra, de ez csakis hosszú távon térül meg. Rövid távon, a frissen jött Product Director számára, aki két évet tervez ebben a pozícióban eltölteni, ezek csak viszik a pénzt és ha ilyenekre költene, csökkenne az idei profit. Ő márpedig nem ellensége saját magának, így kecses mozdulattal rántja ezeket a tételeket a lista aljára, majd amikor két év múlva exitál, utána a vízözön. Teljesen érthető és súlyosan toxikus jelenség.

Mert nem hagyták jóvá

Csinálnám én ami helyes, de nem hagyják jóvá! Akkor menj a Teslába dolgozni, mert náluk (szinte) nincs is olyan, hogy jóváhagyás. Sőt, “radical empowerment” van. Az alap hozzáállás az, hogy ha már egy vagyonért finanszírozunk téged, aki a szakmád egyik kiemelkedő szakértője vagy, akkor igazán hülyék lennénk, ha nem azt csinálnánk, amit mondasz. A szervezeti struktúra lapos, nincsenek Vice President-ek és egyéb végtelen vízfej hierarchiák. Nincsenek sarok-irodák és titkárnők. A vezetők a szerelőcsarnokban dolgoznak és autót építenek. Elon Musk maga is autókat rak össze, részt vesz a napi munkában. Amikor belépsz a cégbe elmondják, hogy bármire szükséged van – robotra, járműre, földterületre, akármire – vegyél. Kapsz egy bankkártyát és gyerünk. Hihetetlen, nem? Pedig működik. Valamiért a dolgozók nem lopják szét a Teslát. Nem a haverjaiknak szerveznek okosba túlárazott bizniszt. Helyette ha valami költség felmerül odamennek a társaikhoz és jó alaposan átbeszélik velük, hogy mire gondoltak és kikérik a véleményüket, mert nagyon nem szeretnének csalódást, kárt okozni a szervezetnek azzal, hogy valami hülyeséget vettek. Trust & Empowerment. Náluk nem csak világító neon betűkkel kiírt enteriőr dekoráció.

Hatékonyság

Párhuzamos sávok

“How much of this can we do in parallel?” Joe szerint minden meeting kezdetekor ezt kérdezte Bill Gates amikor a Bill and Melinda Gates Foundation-ben Joe korábban nála dolgozott. Hasonló véleményen van szerinte Jeff Bezos is, aki azt állítja, hogy 6 főnél több nem tud hatékonyan megbeszélést tartani. Joe előadásától függetlenül, Jason Fried is említi a Remote című könyvében, hogy nem létezik olyan, hogy egy órás meeting. Ha öten ülnek ott, akkor az egy öt órás megbeszélés. A szervezeti működésben a megbeszélés messze a legdrágább tevékenység, épp ezért csak nagyon hatékonyan és alapos felkészüléssel szabad csinálni. Ugyanígy a csapatméretek is rendkívül fontosak, a kommunikáció hatékonyan tartása tekintetében, hiszen egy csapat tagjai tulajdonképpen folyamatos “megbeszélésben” vannak egymással. Ezek az összefüggések leginkább Brooks törvény néven lettek közismertek, de az alábbi ábra talán szépen szemlélteti hogyan növekszik a komplexitás a résztvevők számának arányában:

Érdemes a fenti kapcsán elgondolkodni, hogy mi az ár/érték aránya a nagyvállalatokban annyira divatos “All hands” eseményeknek, ahol egy vezetőt hallgat száz dolgozó, illetve a véget nem érő heti Sync eseményeknek ahol tíz ember hallgatja, ahogyan kettő megbeszél valamit, amit chaten is meg tudtak volna. Melyikünk ne dolgozott volna tizen-sok-fős csapatokkal, amik valahogy nem akartak sehogy sem sikeresek lenni. Hány videókonferencián vettél már részt, ahol kikapcsoltad a kamerát és amikor porszívózás vagy mosogatás közben váratlanul megszólítottak, csak késve válaszoltál, mert vissza kellett jönnöd a másik szobából a géphez, de inkább azt hazudtad, hogy elfelejtetted, hogy le vagy némítva.

Lego autók, lego gyárból

A Tesla nem csak hogy lego autókat gyárt, de maga a gyár is legoból épült. Átlagosan modellenként heti 27 hardware frissítést végeznek. 3 órás a gyártás kibocsátási ciklusa (release cycle). Ne felejtsük el, hogy itt fizikai eszközökről beszélünk, autókról, amik a nagyobb autógyáraknál általában modellenként 3-5 éves projekek szoktak lenni. Mint az újlenyomatok, szinte nincs két egyforma Tesla, mert folyamatosan fejlesztik őket és a fenti ciklusok szerint állandó átalakulásban vannak. Hogy lehetséges ez? Moduláris architektúrával. Az egyik csapat felel az első ütközőkért, a másik a felfüggesztésért, a harmadik fékezést vezérlő rendszerért, és így tovább. Az egyes modulok interfészei/API-jai definiáltak, hardware szinten is és ezekben ritkán következik be változás. Így az egyes modulokat folyamatosan lehet egymástól külön, párhuzamosan fejleszteni.

Ez önmagában impresszív de itt nem álltak meg. A szoftverfejlesztésben közismeret branching technikát is megvalósították. Mivel az egész gyár teljesen automatizált, telepítettek fizikai router-eket, amik képesek a futószalagról pontosan egy darab kocsit egy új irányba, egy másik gyártósorra küldeni, majd az ott végzett munkálatok befejezése után visszaintegrálni a sorba. Amikor ezzel a technikával egy “pilot line”-nak nevezett gyártósorra leválasztanak egy kocsit, elkezdik kipróbálni rajta a kívánatos változtatásokat és ha azok beválnak – amit természetesen robotok által végzett automata fizikai tesztelés ellenőriz – akkor szépen, fokozatosan felbővítik az új gyártósor kapacitását és átterelik ide a forgalmat, míg végül ez lesz a fő gyártósor és a korábbit lebontják és a felszabaduló eszközökből újabb pilot vonalat építenek újabb hipotézisek validálására. Így a gyártás egyetlen pillanatra sem áll meg és közben mégis folyamatosan fejlődik. How agile is that?

Joe szerint az egész gyár tulajdonképpen egy élő szervezetre hasonlít, ami sejtekből (lean manufacturing cells) szerveződik össze és folyamatos átalakulásban, evolúcióban van. A működése nem lineáris, hanem elosztott és párhuzamos, ahol egyes fázisokon akár többször is végig haladhat egy elem ha szükséges valamit újra gondolni.

További érdekesség, hogy a gyártás során szinte nem használnak beszállítókat, hanem amit lehet helyben gyártanak alapanyagokból. A prototipizáláshoz ha kell nyomtatnak alkatrészeket. Ennek az az oka, hogy a beszállítók túl lassuak. Amennyi idő alatt megrendelnék, leszállítanák, hibajavítanák az adott alkatrészt (lead time), annyi idő alatt a Tesla harmincháromszor legyártja magának (cycle time).

Robotok az emberek ellen

Hogyan lehet ilyen gyorsan és flexibilisen gyártani? Automatizálás, automatizálás, automatizálás. Hitvallásuk szerint: automatizálj amit csak lehet. Gondoljunk csak az innováció sebességéről szóló nyitó gondolatra! A Continuous Integration / Continuous Delivery (CICD) fontosságát nem kell bemutatni a szoftverfejlesztéssel foglalkozók számára. A Teslában abban hisznek, hogy ugyanezt a megközelítés a hardware világában is alkalmazni kell, méghozzá a lehető legnagyobb mértékben. Korábban lehetett hallani olyan híreket is, hogy bizonyos folyamatokat túlautomatizáltak, mert ennyire komolyan vették az elvet. Bár ezekről a komplex folyamatokról kiderült, hogy az ember még mindig jobb bennük, de vajon az általunk ismert cégek közül hány olyan van, ahol még szoftveres szinten sincsenek kielégítő DevOps vagy CICD megoldások. A Tesla ugyanezeket a koncepciókat kimaxolta még hardware szinten is! “If something is difficult, do it all the time” vallja Joe, vagyis ha valami nehezen megy, akkor az folyamatosan kell csinálni. Folyamatosan pedig akkor lehet, ha minimális gondozást igényel az adott folyamat (Automatizálás).

Vessük össze ezeket a gondolatokat is a tapasztalatainkkal, amikor heteket kell várni például egy komplex szoftver következő release-ére. Bizony ritkán járnak a release train-ek mifelénk és sokat késnek is. Vagy egy friss élményem, amikor hozzáférést kérek bizonyos rendszerekhez, várni kell, újra kérem, adnak, rosszul, újra kérem, újra rosszul adnak, és így tovább, míg végül 2 hónapos kálvária eredményeként sikerül mindenkinek jól beállítani. Ehhez képest a Teslában az IT osztály saját maga által vállalat SLA hozzáférések beállítására… dobpergés… öt. Öt micsoda, nap? Perc. A kérés elküldésétől számított 5 perc múlva él a hozzáférésed. Ízlelgessük kicsit…

Zárszó

Összességében számomra a Tesla bizonyítja, hogy azok az elvek amiket rég óta hirdetünk a Lean/agilis közösségekben nagyon is működnek és nem csak elméletben. Nagyon jól látszik, hogy mennyire megéri egy hosszú távú stratégia megvalósításához ezeket az elveket követni és valóban agilis, változásra optimalizált struktúrákat építeni, még a fizikai gyártás világában is, amely terület talán méltatlanul kevesebb fókuszt kapott az utóbbi időben az agilis szoftverfejlesztés térhódításával.

A fentiek nem adják át az előadás teljes anyagát, csak az engem megérintő, számomra fontosabb témákat emeltem ki belőle. Ha felkeltette az érdeklődésedet, javaslom nézd meg az előadást is, nem hosszú (30 perc) és érdekesen, élvezhetően beszél benne Joe (angolul). Maguk a diák kicsit furcsák nekem, a banner hirdetések világa jut eszembe róluk, mert a legtöbb oldal nem hagyja ki a lehetőséget, hogy Joe nagyszerűségét reklámozza, illetve design szempontból is reprezentálja az evolúciós megközelítés korai szakaszait, de ezektől eltekintve az összélmény nagyon kellemes. Ajánlom szeretettel!

Amennyiben csatlakoztál már a Slack csoportunkhoz, és a fenti cikk kapcsán felmerült benned valamilyen gondolat vagy kérdés, itt tudod megosztani a közösséggel!

A prezentációs diasor, PDF formátumban (27 MB) letölthető innen: Agile Hardware @ Business Agility Institute