A címet elolvasva talán az a klasszikus vicc ugorhat be, amikor parasztbácsi az állatkertben áll a zsiráf ketrece előtt, és azt mondja: Má’ pedig ilyen állat nincs is!. Az autóipar a legtöbb ember számára egy merev, szabályozásokkal teli iparágat jelent, ahol alapvetően csak kis változások vannak a környezetben. Autóipar alatt most nem a különböző kényelmi és szórakoztató funkciókat ellátó ún. infotainment-rendszerekre gondolok, hanem a komolyságot megkövetelő biztonságkritikus-rendszerekre, mint a fékvezérlés, elektronikus kormányrendszer, menetstabilizátor, etc.
Simon Gábor (thyssenkrupp Components Technology Hungary Kft.) publicisztikája
Tíz évvel ezelőtt ez az állítás még igaz is volt. Akkoriban alig volt az autókban pár tíz darab elektronikus vezérlőegység (ECU – Electronic Control Unit), amik ráadásul egyszerűbb hardver és szoftver architektúrával rendelkeztek. A megrendelő autógyárak (OEM – Original Equipment Manufacturer) által adott követelménycsomagok konzisztensek voltak, és minimálisan változtak a fejlesztési idő alatt. A projektek indulása előtt már betonba voltak öntve a szállítási határidők, amiken nem lehetett változtatni. Mindez hangosan kiált egy tradicionális projektmenedzsmentért, és valóban ezt is alkalmazták a beszállító cégek.
Azonban az évek során változás történt mind a beszállítói, mind a megrendelői oldalon. A beszállító cégek azzal szembesültek, hogy a feléjük leadott kezdeti követelmények már nem olyan egységesek és világosak, mint korábban. OEM oldalon folyamatosan fejlődnek az autótípusok, ami miatt nagyon gyakoriak a fejlesztés közbeni új igények, illetve a meglévő igénypontok változtatása. Az új követelményeket már nem lehet lefedni egyszerűbb rendszerekkel, szükség van a bonyolultabb, sokkal komplexebb hardver és szoftver architektúrák, mechanikai rendszerek kialakítására. Ezek kifejlesztése új terület, sok esetben amolyan előfejlesztés jellegű feladat, ami azt eredményezi, hogy nem lehet előre megtervezni a projektet úgy, mint korábban.
Megjelentek új irányzatok is, mint az önvezető autók megalkotása, ami miatt szintén rengeteg új aspektus jött be. Ez pedig az ECU-kat vezérlő szoftver rendszerekre ró extra feladatokat, ami pedig drámai komplexitásnövekedést okoz. Ennek következménye, hogy már nem lehet az alrendszerek közötti kapcsolatokat (interfészeket) hatékonyan előre definiálni, szükség van a menet közbeni folyamatos finomításokra. Szemfüles módon észrevehetjük, hogy az új helyzet elmozdult a prediktív (a projektet előre megtervezik, majd a tervek alapján folyamatosan végrehajtják, végül az elkészült terméket tesztelik) állapotból az iteratív és inkrementális (a projektet lebontják kisebb, ismétlődő fázisokra, amiknek része a tervezés, végrehajtás, tesztelés, és ezek a rövidebb ideig tartó ciklusok lépésről lépésre állítják elő a terméket) irányba.
Más frontokon is történtek változások az elmúlt időszakban. Ma már nem léteznek local hero-k, azaz olyan emberek, akik egyszemélyben mindent is meg tudnak oldani. Ez bizony a fentebb említett komplexitás növekedés egyik velejárója. A projektmenedzser sem képes már központosítottan, egyszemélyes hatalommal minden igényt kielégíteni, a teljes projektet egyedül irányítani. Neki is szüksége van egy vagy több jól működő, önálló csapat támogatására.
Elmondhatjuk, hogy a csapat szerepe exponenciálisan felértékelődött a projektek esetében. Már nem csak egyszerű végrehajtó szereppel bírnak, hanem egy-egy terület kapcsán döntéshozókká, felelősökké válnak. Vége annak az időnek, amikor mindenért a projektmenedzser volt a felelős, ő hozta meg a döntéseket, és viselte azok következményeit. Ez az egész menedzsment dolog már elosztott rendszerben működik. Mindenki egy célért küzd, mindenki számíthat a másik támogatására, és mindenki kiveszi a részét a munkából, felelősségből, döntésekből. Manapság egy projekt akkor tud sikeres lenni, ha rendelkezik olyan csapattal vagy csapatokkal, akik széles tudással rendelkeznek, képesek önállóan döntéseket hozni, kisebb-nagyobb feladatokat önjáró módon megoldani.
A technikai komplexitás kivitelezése sem valósítható meg már lineáris módon, szükség van az iteratív megközelítésre, ráadásul sok különböző elem fejlesztését kell összehangolni. Ezt nagyban segíti, ha rövidebb fejlesztési ciklusokban tervez a projekt. Az is egy jól megfigyelhető trend, hogy egyre kevesebb az ún. legacy felhasználás, azaz a régi és jól bevált dolgok ismételt beépítése az újabb termékekbe. Helyette egyre több a még nem látott és alkalmazott fejlesztések használata. Ezek miatt pedig szintén nem lehet hosszú távra, részletesen előre tervezni, mivel nem ismertek még az újítások hatásai, használhatóságuk és eredményességük. A végső felhasználásra is alkalmas elemek iteratív módon készülhetnek csak el.
Ha figyelmesen átbogarásszuk a fenti változásokat, akkor észrevehetjük, hogy van már olyan jól használható projektmenedzsment modell, amely segít adaptálódni a megváltozott körülményekhez. Ez pedig az agilis termékfejlesztés. Most nem célom bemutatni, hogy mit is jelent ez pontosan, akit érdekel, számos helyen utánaolvashat. A lényeg, hogy bizony az autóiparnak is észre kell vennie, hogy új szelek fújnak, és ha tartani szeretné az irányt és a sebességet, netán még rá is kapcsolna egy kicsit, akkor új vitorla után kell nézni. Szerencsére van már használható vitorla, ami képes befogni az új szelet, a kérdés, hogy időben sikerül-e lecserélni a régit.
Végezetül jó példaként álljon itt a Tesla cég, aki egy meglehetősen fiatal vállalat az autóiparban, mégis rövid időn belül igen meghatározó és vezető pozícióba került a régi motorosokkal szemben. A Teslánál vérbeli agilis szemlélet szerint történik a fejlesztés, és ezt nyíltan hirdeti is magáról. Mostanáig bejött nekik.
