Mi a különbség a szoftvergyártás és az alkatrész gyártás között? Mik azok a típushibák, amiket az IT-ba beleszóló más területről érkező mérnökök elkövetnek?

Mi a különbség a szoftvergyártás és az alkatrész gyártás között? Mik azok a típushibák, amiket az IT-ba beleszóló más területről érkező mérnökök elkövetnek?

A Kaizen blog-on Holden cikke inspirált, hogy írjak azokról az esetekről, amikor egy külső ember beleüti az orrát az informatikába. Nem, nem a felhasználókról van szó, hanem azokról a gépészmérnökökről, villamosmérnökről, matematikusokról, stb, akik – egyébként okos ember, a saját szakterületén profi – megpróbálják az IT-ra ráerőszakolni a saját szakterületükön bevált módszereket.

A sorozat 3 részes lesz, ebben az első részben a leggyakoribb félreértést tisztázom: miért nem működnek a gyártás során alkalmazott módszerek az IT-ban, miért nem lehet úgy szoftver gyártani, mint cipőt vagy autót.
A következő részben azt tisztázom, az IT miért nem matematika, és miért áll messze a szoftver fejlesztés az alkalmazott matematikától. A harmadik részben pedig a dolgok gyökeréhez nyúlok: miért volt az IT annak idején tiszta matematika, miért volt tiszta mérnöki diszciplína, és utána hogyan kanyarodott el ezektől a diszciplínáktól annyira, hogy ma már nincs bennük sok közös.

Eddigi pályafutásom során többször találkoztam olyan szituációval, amikor egy informatikai vezető vagy cégtulajdonos alapvetően mérnökember volt, mestere egy MÁSIK területnek. A hasonlóságok alapján úgy véle, hogy az informatika sem más, mint a többi, hogy itt is gyártástechnológiáról van szó, ez is egy gyártósor.

Az az igazság, hogy az informatika a felszínen sok hasonlóságot mutat a gyártással. Vezetői szintről nézve egy szoftver fejlesztési projekt pont ugyanolyan, mint egy új autómodell tervezése vagy egy logisztikai projekt. Az alkalmazott projektvezetési módszertan ugyanaz, a projekt fázisait is ugyanúgy hívják. Az persze vezetői szintről nem látszik, hogy amint belemegyünk a részletekbe, ott minden egészen más, azaz egy szoftver tervezése totálisan másképp történik, mint egy autó tervezése.

A zavart fokozza továbbá az, hogy az informatikában elfordulnak a gyártásra jellemző kifejezések: hiba, selejt, folyamat, tesztelés, tervezés, minőség biztosítás, modul. Van veszteség és van áramlás. A gond az, hogy ezek a kifejezések egészen mást jelentenek, és egészen másképp kell őket kezelni. Nyilván aki nem járta végig a létrát alulról kezdve, az – beülve egy IT vezetői vagy tanácsadói székbe – a dolgokat hasonlónak találja, szilárd pontokat vél felfedezni, és e hamis biztonságérzetbe kapaszkodva jogosnak érzi az általa ismert eljárásokat bevezetni.

A dolog természetes nem fog működni, de ez csak hosszú és fájdalmas küzdelem után derül ki – és emberünk akkor sem fogja érteni, hogy miért nem.

Az alábbiakban a típushibákat, gyakori téveszméket gyűjtöm össze (sajnos tapasztalatból…)

A hiba

Minden mérnöki diszciplína foglalkozik a hibával, a hiba okaival, a hiba lehetőségének minimálisra csökkentésével. Az IT-ban előfordulnak a hagyományos hiba típusok (pl folyamat hibák, emberi mulasztás, hibás komponensek felhasználása, rossz tervezés), de a dolgok savát-borsát a regressziós hibák és a komplexitásból adódó hibák jelentik.
Vagyis olyan hibák, amiket nem valaki „csinál”, hanem a legnagyobb jóindulat, a legalaposabb tervezés mellett is maguktól „előfordulnak”. Egy mérnökember gyomra nem veszi be, hogy a hibák csak úgy maguktól jönnek – ezért megpróbál fegyelmezni, folyamatokat javítani.
Esetleg célul tűzi ki, hogy teljes egészében megszünteti a hibákat – márpedig a szoftver egy olyan különleges termék, ami sosem hibamentes. Ebből aztán csúnya szélmalomharc lesz, a cél elérésére semmi esély.

Minőségbiztosítás

A minőségbiztosítás fontos mind a szoftverfejlesztés, mind az autógyártás során. De egészen más jelent, mások az eszközei. Másképp kell letesztelni egy szoftvert, mint egy alkatrészt.
Emiatt az eljárások is mások, tehát a kétféle QA nem összevethető és nem csereszavatos.

Fejlesztési folyamat vs gyártási folyamat

Messziről nézve a szoftvert is valamilyen gyártási folyamat mentén állítják elő. Ha megnézünk egy projektet vagy egy változáskérelmet, akkor annak fázisai vannak, az egyes fázisok során a feladat egyik embertől a másikhoz kerül. Az ideális gyártási folyamat valahogy úgy nézne ki, hogy „A” munkatárs csinál valamit a feladattal, az eredményt átadja „B”-nek, az megint dolgozik vele, és átadja „C”-nek, stb.
A szoftver fejlesztés viszont valahogy úgy történik, hogy „A” munkatárs elmondja, hogyan kellene a feladatot megoldani, „B” munkatárs bevállalja hogy megcsinálja, de majd konzultálnia kell „C” munkatárssal az egyik kérdésről. Tehát a munka nem folyamatszerű és nem lineáris -> „csapatmunka” a helyes kifejezés.
Arról nem is beszélve, hogy a szakma részét képezik a kreatív és maguknak való zsenik, akik képesek mindenféle standard és folyamat figyelmen kívül hagyásával is kiváló eredményt elérni (lásd hacker sztereotípiák).

Emberek vs gépek

A mérnökember technológiákkal és gépekkel dolgozik. Az IT is jelentős mértékben technológia, de az emberi tényező ugyanennyire fontos. Az informatikusok emberek, teljesítményük nagy mértékben a motivációjukon múlik. A motiválatlan és az összeszokott csapat között ÓRIÁSI a különbség.
Aki csinált már életében akár csak egyszer is informatikai projektet, az tudja, hogy a siker vagy a bukás elsősorban az ügyfélen, a felhasználókon múlik. Akik emberek. A szoftver fejlesztési projekt nem kis része pont arról szól, hogy az ügyfél emberei gyarlóságait kell tudni menedzselni.
Bizonyos szakértők odáig mennek, hogy az informatika valójában már nem is műszaki terület, sokkal inkább szociológia…

Rendszerintegráció

A műszaki területek nagy részére jellemző, ha a specifikáció szerint legyártunk egy „A” munkadarabot és egy „B” munkadarabot, akkor azok összeillesztve tökéletesen működnek. A szoftverfejlesztés az a terület, ahol ennek a tökéletes ellentéte igaz: ha két szoftver csapat külön-külön legyártotta az egyedileg tökéletes „A” és „B” modult, azok összeillesztve biztosan nem fognak működni. Nem, nem azért, mert bárki is hibázott, hanem azért, mert az informatikában a rendszerintegráció is egy önálló feladat, amit meg kell csinálni.
Mérnökember soha nem is hallott rendszerintegrációról, vagy ha hallott, akkor úgy gondolja, hogy az egy jelentéktelen kis dolog. A projekt pedig ezen vérzik el.

A javítás javításának a javítása

Minden más műszaki területen ha egy hibás alkatrészt kijavítunk, akkor az új, kijavított alkatrész pont olyan jó lesz, mint az eredeti. Mondjuk egy autómodell jól megy, csinálnak rá egy „facelift”-et, az új autómodell pont ugyanolyan biztonságos lesz és jól megy, mint elődje.
Na ez a szoftver fejlesztésnél nem igaz. A szoftver komplexitása és megbízhatósága minden egyes változással automatikusan növekszik. Ez egyre növeli az előforduló regressziós hibák esélyét. Egy idő után pedig a szoftver már nem karbantartható, újat kell csinálni.
Az új szoftver mindig jobb, mint a toldozott-foltozott.

A javítás költsége

Normális esetben egy hiba kijavításának a költsége azon múlik, hogy a hiba mennyire súlyos / milyen nagy. Szoftverek esetén bejön a komplexitás, a stabilitás, a dokumentáció megléte és a tudás megléte is. Azaz a javítás költsége sok tényezőtől függ, de úgy általában az idő előrehaladtával növekszik.

Szoftver életciklus

Habár termék életciklus más iparágakban is létezik, ott az elsősorban marketing célú. Megint egy kifejezés, ami közös, de mást jelent.
A szoftver életciklus azt jelenti, hogy a szoftver – bármilyen jól is működik – csak bizonyos ideig lehet üzemben tartani:
- Az alkalmazott technológiák elavulnak, ezért a szoftver nem üzemeltethető biztonságosan
- A korábbi pont miatt a változtatás, hibaelhárítás költsége egyre magasabb lesz, eléri egy új szoftver megírásának a költségét
- Ezzel párhuzamosan növekszik annak a kockázata, hogy a szoftveren végrehajtott változtatásoknak nem várt hatása lesz
A vállalatok a szoftver portfolió kialakításakor eleve tervezik, mennyi ideig használják a szoftvert, mennyi ideig és milyen technológiák alkalmasak a fejlesztésre.

A ciklusidő csökkentés

Tipikus hiba, hogy az informatikához nem értő mérnökember a ciklusidő csökkentésével igyekszik hatékonyságot növelni. Az ellenkező hatást fogja elérni vele: a rövid ciklusidő azt jelenti, hogy jól megfontolt nagyobb fejlesztések helyett sok kis változtatás lesz, ami egyre jobban csökkenti a stabilitást és a fenntarthatóságot.
Általában azok a szoftverek stabilabbak, amiket eleve jól írtak meg, és csak kevésszer nyúltak hozzá.

Áramlás

Az IT 2 olyan fő folyamatot tartalmaz, ahol felfedezhető az áramlás: a hibabejelentés és a változáskérelem. Ezért akadnak olyanok, akik érvényesnek vélik az áramlással kapcsolatos elveket.
Nincs igazuk: itt nem a termék áramlik, hanem a feladatok. A termék ugyanaz marad, legfeljebb sokszor módosítjuk. A szoftver fejlesztés valójában egy 1 darabos áramlás igen hosszú ciklusidővel.

Az informatikai tapasztalat

Az IT-ban a tapasztalat jelenti az értéket. Tudásra, lexikális tudásra, folyamat ismeretre is szükség van, de az informatikust az informatikai tapasztalat teszi informatikussá. A sikeres informatikus tapasztalt, tehát nem az a lényeg, mennyire okos, ügyes vagy szép, hanem hogy tisztában van-e az adott komponens, programozási nyelv, adatbázis motor, stb nyűgjeivel, csinált-e már projektet az adott területen.
Azok a mérnökök, akik egyébként okosak, ügyesek, és más területen bevált módszereket hoznak az IT-ba, nekik minden van, csak informatikai tapasztalat nincs. 3-5 év sem mindig elég ahhoz, hogy az ember átlássa a dolgokat. Ennél kevesebbel pedig tisztán vakrepülésről van szó. Aki megírta a „hello world” programot és otthon maga telepítette a számítógépét, biztosan van véleménye az IT-ról, de még nem áll azon a szinten.

A specifikáció

Ha valami kulcsfontosságú egy informatikai projektben, az a specifikáció. Azaz pontosan és részletesen tudni, mit kell csinálni és mik a sikerkritériumok. Kívülállók úgy gondolják, hogy elég annyit mondani a fejlesztőknek „csináljatok egy szép web lapot” vagy „a szoftver képes legyen számlákat nyomtatni”, és ezzel kész. Pedig nem, 1000 apró részlet és kérdés van még. A jó specifikáció elkészítése önálló szakterület az informatikán belül (rendszerszervező), amit nem célszerű elhanyagolni. Már csak azért sem, mert ha a specifikáció hibás, akkor azt csak vérrel-verejtékkel-óriási pluszmunkával lehet csak javítani.

Veszteség

Mint mindenhol máshol, az IT-ban is létezik veszteség. Azonban ezek a veszteségek hasznosak a célokat tekintve, és a veszteség eltávolítása veszélybe sodorná az informatikát.
Például az igazán veszteség nélküli programozás az lenne, ha minden kódsort egyszer, és csak egyszer írnánk meg, utána pedig nem változtatnánk. Ezzel szemben bizonyos módszertanok (pl agilis vagy iteratív fejlesztés) eleve arra épít, hogy a programot többször újraírjuk menet közben, ezáltal egy jobb-stabilabb kódot hozva létre. Ez több munkát jelent, amit a kevesebb hibajavítással és változáskérelemmel nyerünk vissza.
A prototípus fejlesztés eleve egy tervezetten veszteséges tevékenység, amikor egy döntést megelőzve előre kódolunk, csak hogy megnézzük milyen lesz, és hogy erre az alapra elkezdhessünk építkezni. Sok esetben a prototípust kidobjuk és újat csinálunk – ami teljesen normális.
Szóval aki veszteséget keres, találni is fog, el is tudja távolítani, de a beteg résszel együtt az egészséges szervet kis kivágja.

Talán ennyi érv elég is lesz, hogy meggyőzzem az egyszeri mérnököket - ha a sors szeszélyénél fogva IT területre sodródtak, akkor vegyék tudomásul: ez egy másik szakma. Tessék alulról elkezdve megtanulni, vagy ha valaki rögtön menedzserként kezd, akkor tessék mindent vakon elhinni az informatikus beosztottaknak. Így kevesebb a kár, mintha valaki nekiállna megreformálni a szoftverfejlesztést…