Hirdetés
. Hirdetés

Egy mélyre süllyedt projekt - a Vasa

|

A Vasa Múzeumban járva nemcsak a hajó impozáns látványa döbbentett meg, hanem az is, hogy a hajó bő 380 évvel ezelőtti építése és a mai informatikai projektek közt milyen sok a hasonlóság. A Vasa-projekt azon jellemzőit és tulajdonságait gyűjtöttem össze, amelyek ismerete a mai IT-s projektekben is hasznosítható.

Hirdetés

Előszó
A projektmenedzsmenttel foglalkozó könyvek, jegyzetek, cikkek egy része történelmi előzményként előszeretettel hivatkozik a piramisok építésére, mint olyan projektekre, ahol rengeteg ember tervezett és menedzselt munkájának eredményeképpen egy látványos és időtálló produktum jött létre. A mai projektek és a piramisok építése közötti több ezer éves kapcsolat felemlegetése tagadhatatlanul tekintélyt és patinát kölcsönöz a projektmenedzsment szakmának, azonban informatikai projektek esetében ez a kapcsolat elég gyenge, hiszen a piramisok építésének szervezéséről, kivitelezési módjáról viszonylag kevés olyan megbízható tudás maradt fenn, amelyet át lehet ültetni a mai informatikai projektekbe. A jóteljesítési garanciák, kötbérek, Gantt-diagramok és egyéb kifinomult eszközök birtokában a mai projektmenedzserek már túlhaladottnak tekintik a „Korbácsod vízilóbőrből legyen!”-jellegű szabályokat (legalábbis a projektek elején).

Emellett nem elhanyagolható az a különbség sem, hogy a piramisépítési és az informatikai projektek karaktere jelentősen eltér: az informatikai projektek általában jóval változékonyabb, turbulensebb környezetben működnek, valószínűleg többféle kompetenciát igényelnek és ritkán tartanak több tíz éven keresztül (bár lehetnek olyanok, amelyek jó úton haladnak efelé).


Szerencsére a történelmi előzmények és a hasznos tapasztalatok keresésekor nem kell ilyen messzire visszautazni az időben, hiszen itt van például a Vasa hadihajó 1625. január 16. és 1628. augusztus 10. között futott projektje, amelynek céljáról, menetéről, környezetéről, szereplőiről és végtermékéről rengeteg információval rendelkezünk. Információink egyik forrása maga a – nagyon jó állapotban megmaradt – hajó, amely köré egy egész múzeumot építettek, valamint a projekt végén készített alapos jegyzőkönyv, amelyet a mai projektmenedzsment-terminológia alapján Post Mortemnek is nevezhetnénk, ha ez a szóhasználat –tekintettel a projektben elhunytakra – nem lenne túl morbid.

A projektről meglévő ismereteink ráadásul a mai napig is folyamatosan gyarapodnak azon kutatók jóvoltából, akik munkájuk során a legmodernebb eszközökkel olyan egzotikus vizsgálatokat is elvégeznek, mint például az utasok csontvázának vizsgálata. (Melyik mai informatikai projekt érte el a transzparencia azon szintjét, ahol még a felhasználók fogait is külön tudóscsapat vizsgálja?)

vasa
vasa

Kétségtelen, hogy a projekt nem egy kimondott sikertörténet, hiszen a hajó még a kikötőben elsüllyedt és így nem élte túl az első éles bevetését sem, de így talán még jobban is illeszkedik a mai informatikai projektekhez, mint az időtálló piramisok.

Olyan kézenfekvő a párhuzam, hogy magam csak a Vasa történetének hazai ismeretlensége miatt nem csodálkozom azon, hogy a projektre való hivatkozás nem terjedt el a honi informatikai szóhasználatban és nem hallunk időnként az alábbihoz hasonló párbeszédeket:

Sikerült a migráció? Élesbe ment végül a rendszer?
Ááááá, dehogy! A rendszer összeomlott már az első nagyobb terhelésnél. Tudod, a legjobbat akartuk, a szokásos sikerült.
Szóval ez is Vasa-projekt lett...

A Vasa-projekt rövid története
A XVII. században a katonailag egyre erősebb és politikailag egyre jelentősebb Svéd Királyság ambíciózus uralkodója, II. Gusztáv Adolf a 30 éves háború és a Lengyelország elleni harcok miatt 4 hadihajót rendelt a korszak egyik messze földön híres hajóépítő mesterétől. A 4 hajó közül az első a Vasa nevet kapta, és elvárás volt vele szemben, hogy a korszak legnagyobb tűzerejével bíró hadihajója legyen, a tengeri csatákban már pusztán óriási méretével is félelmet és rettegést keltsen, emellett megjelenésével kifejezze a feltörekvő svéd királyság gazdagságát és nagyságát. A grandiózus terv három évvel később aztán grandiózus hajót eredményezett: a kétszintes fedélzeten elhelyezett 64 ágyú olyan tűzerővel rendelkezett, amelynek a korszakban nem volt párja, és amely egymagában felért például az ellenséges lengyel flotta teljes tűzerejével; méretei alapján a legnagyobbak közé tartozott, és a hajó díszítésénél sem kímélték a költségeket, amit a hajón elhelyezett kb. 7000 (!) aranyozott vagy festett szobor is jól jelez.

Nos, ez a már építése alatt is híressé vált csatahajó 1628. augusztus 10-én szellős, szép időben hatalmas ceremónia közepette kihajózott első útjára, majd a díszsortűz eldördülését követően egy erősebb szellő hatására – a több ezres ünneplő tömeg szeme láttára – még a kikötőben megdőlt és az ágyúnyílásokon beömlő víz hatására egész egyszerűen elsüllyedt. A Vasa háromévnyi tervezési és kivitelezési munka, irdatlan költségek és közel 50 ember halála árán mindössze 1300 métert volt képes megtenni.

Könnyű lenne párhuzamot vonni a Vasa és egy hasonló idő alatt elkészülő, jelentős költségű és az üzembe helyezést követően órákon belül térdre rogyó informatikai rendszer között, de ez a párhuzam csalóka lenne, mert a XXI. század informatikája sajnos sokkal-sokkal kegyetlenebb. Egy tisztességesen elsüllyedő hajóval ellentétben a rossz informatikai rendszerek alatt nem nyílik meg csak úgy a szerverterem álpadlója és nem nyeli el őket a föld, hanem alattomosan a helyükön maradnak, s minden nap újabb és újabb kínokat okozva, migrációról migrációra sodródva szívják ki az üzemeltetők és fejlesztők utolsó csepp vérét, valamint emésztik fel a rendelkezésre álló OPEX -forrásokat. Ráadásul amíg az elsüllyedt hajókhoz csak a rémtörténetekben tartozik élőhalott személyzet, addig az informatikai rendszereknél ez a valóságban is megtörténik, ahogy arról a szerverteremben görnyedt háttal csoszogó, a kialvatlanságtól kigúvadt szemű üzemeltetők vagy az éjszaka közepén füstös, sötét dohányzóhelységekben kiüresedett tekintettel maguk elé meredő és érthetetlenül motyogó ügyfélszolgálatosok is naponta tanúskodnak.

A projekt főbb jellemzői
A végeredményt ismerve meghökkentőnek tűnhet, de a projekt szerencsés csillagzat alatt látta meg a napvilágot, és kezdetben semmi nem predesztinálta erre a dicstelen végre. Tekintsük hát át a Vasa projekt főbb jellemzőit!

A szponzor elkötelezett volt. Az 1620-as években az ambiciózus II. Gusztáv Adolfot több cél is motiválta. Egyrészt biztosítani akarta trónját unokatestvérével, az akkor éppen a lengyel trónon ülő és korábban a svéd trónt is birtokló III. Zsigmonddal szemben, aki nem tett le arról, hogy újra svéd király legyen. Másrészt az akkor csak regionális szereppel bíró királyságot az európai nagyhatalmak közé kívánta emelni, harmadrészt pedig a protestánsok oldalán be kívánt szállni az akkor zajló – és számos magyar vonatkozással is bíró – 30 éves háborúba.
Korán felismerte, hogy céljai eléréséhez szüksége van a megfelelő tengeri tűzerőre is, amelyet híressé vált mondása is jól tükröz: „A királyság boldogulása – az Úr után – a hajóhadtól függ”.

Elég erős felcsapás ez, manapság kevés IT-projekt projektindító dokumentumában találkozunk ilyen erőteljes kijelentésekkel és a szponzor ilyen fokú elkötelezettségével.

A szponzor céltudatos volt. II. Gusztáv Adolf, a „Hatalmas” nemcsak elkötelezett, hanem igencsak céltudatos is volt. Kitűnő érzéke volt ahhoz, hogy a nagyívű célokat lefordítsa a konkrét cselekedetek szintjére és zseniális volt a megvalósítási képessége is. Céljai eléréséhez sikeresen kiépítette erősen centralizált államgépezetét és erre alapozva királyságát a történelem egyik legmilitárisabb birodalmává alakította. Megújította a hadviselés módját, és korát meghaladó módon integrálta a különböző fegyvernemek együttműködését, amellyel nemcsak a „modern hadviselés atyja” jelzőt érdemelte ki, hanem később olyan hadvezérek néztek fel rá, mint például Napóleon vagy Patton tábornok.

A hajóhad fontosságának felismerését is konkrét lépések követték: a meglévő flotta megerősítéséhez leszerződött a korszak egyik legjobb, messze földön híres hajóépítő mesterével négy óriási tűzerejű hadihajó elkészítésére. A 4 hajó közül az első a Vasa nevet kapta.

A szponzor bőséges erőforrásokkal rendelkezett. A hatalmas tűzerejű hajók hatalmas erőforrásokat igényeltek, és ezt az uralkodó biztosította is. A hajóépítéshez szükséges és igen értékes tölgyfákat törvénnyel védte, és a Vasa építéséhez 1000 ilyen fát biztosított. A hajóépítő mester 400 ember munkája felett rendelkezhetett. A hajó összköltségét 40.000 dalárra becsülik, ami komoly terhet jelentett a svéd birodalom költségvetésének is, de II. Gusztáv Adolf, az „Arany Király” ezt sem sajnálta.

Látható, hogy a projekt mögött nem csak egy „wannabe”, hanem egy valóban potens, erőforrásokkal és jogkörökkel bíró szponzor állt, amely valószínűleg sok mai, a nagyvállalatok különböző szervezeti egységeinek huzavonáiba és ellentmondásos elvárásaiba belefásult projektmenedzser megkérgesedett szívét dobogtatja meg.

vasa_1
vasa_1

A hajó kivitelezése kivételesen precíz volt. A projekt szomorú végét ismerve fájó megemlíteni, hogy a kivitelezés igen precízre és példaértékűre sikeredett. Érdemes tudni, hogy az 1600-as években az ágyúkat egyszer használatos öntőmintákkal készítették, így az ágyúk méreteiben akár jelentős eltérések is lehettek. A Vasa ágyúinak jelentős részét még a XVII. században kiemelték a tengerből (megmentve ezzel a víz alatt rájuk váró biztos enyészettől), és így képet alkothatunk a kivitelezés precizitásáról: a 46 újonnan gyártott nehéz ágyú belső furata szinte milliméterre pontosan ugyanakkora volt. A hajó 333 évet feküdt a tenger fenekén, de a hajótest kiemelésekor az ágyútalpakat példás rendben lekötözve a helyükön találták meg, a ballasztkövek szintén rendezett csomagokban a helyükön sorakoztak.

Melyik mai projektmenedzser ne hatódna meg, ha projektjén a gondosság ilyen fokát tapasztalná?

Ennyi pozitívum után joggal merülhet fel a kérdés, akad-e egyáltalán bármilyen apró párhuzam is a Vasa-projekt és egy mai informatikai projekt között. Akad – és az alábbiakban sorra vesszük azokat a tényezőket is, amelyek a Vasa elsüllyedéséhez vezettek.

A körülmények kedvezőtlen változása miatt a projektre háruló határidős nyomás jelentősen megnőtt. A hajó építéséről szóló szerződés 1625-ös aláírását követően a svéd flottát zsinórban érték a szerencsétlenségek. A rigai kikötőben egy hirtelen támadt vihar 10 hadihajót süllyesztett el. 1627-ben a svéd és lengyel flotta ütközetében a lengyelek elfoglalták a svéd zászlóshajót, egy másik hadihajót pedig csak azért nem ért hasonló sors, mert legénysége még időben felrobbantotta. 1628-ban egy újabb zászlóshajó süllyedt el a gdanski öbölben egy viharban, míg egy másik hajó a Stockholm környéki szigetvilágban futott zátonyra. Ezen események nem nyugtatták meg az ambiciózus és akaratos királyt, aki a hajó mihamarabbi vízre bocsájtását folyamatosan, sürgető levelekben követelte. II. Gusztáv Adolf, „Észak Oroszlánja” pedig nem az az ember volt, akinek alattvalói szerettek ellentmondani.

A szponzor kézi vezérlésre váltott és olyan műszaki döntéseket hozott, amelyek jelentősen növelték a projekt bukásának kockázatát. A modern hadviselés atyjaként is emlegetett Gusztáv Adolf kiemelkedően tehetséges hadvezér volt, ám hajótervezői képességeinek korlátait nem ismerte fel és direkt módon többször is belenyúlt a hajó építésébe. A források megoszlanak azzal kapcsolatban, hogy milyen változtatásokat rendelt el; az elterjedt vélekedés szerint meghosszabbíttatta a hajót, beépíttetett egy második hajófedélzetet és többször is átterveztette az ágyúk elrendezését. Mindezen változtatások megemelték a hajó súlypontját és jelentősen rontották a stabilitását.

A mai informatikai projektek egy része rendelkezik valamilyen változáskezelési (CR) folyamattal, amely biztosítja a változtatási kérések hatásainak, költségeinek átgondolását, kiértékelését, a kérésről szóló döntés meghozását és a meghozott döntésről a projekttagok megfelelő tájékoztatását. Sajnos a Vasa-projekt nem volt ilyen szerencsés helyzetben: ha volt is ilyen mechanizmus a projektben – vélhetően nem volt –, akkor az nem működött megfelelően, ami egy kellően autoriter és korlátozást nehezen tűrő szponzor esetén kevésbé meglepő.

A tervek nagy kockázatot rejtettek. Napjainkban természetesnek vesszük, hogy egy hajó leendő viselkedése és stabilitása már a tervezési fázisban jól előre jelezhető, ugyanakkor az 1600-as években egészen más volt a helyzet. Az akkori hajóépítő mesterek nem voltak birtokában azoknak a műszaki és tudományos ismereteknek, amelyek segítségével a hajók stabilitása megfelelő pontossággal tervezhető lett volna. A hajók tervezésével kapcsolatos ismeretek akkortájt féltve őrzött titokként apáról fiúra szálltak és néhány ábrában, illetve tapasztalati úton szerzett számokban öltöttek testet. Minden hajó az előzőeken szerzett tapasztalatok alapján épült, és minden hajó egy új kísérletnek számított. Ennek megfelelően ebben a korban sokat számított a hajóépítő mester múltja, korábbi tapasztalata. A holland Henrik Hybertsson nagyon tapasztalt és jó nevű hajóépítőnek számított, aki korábban több sikeres hajót is épített, azonban a Vasa oly mértékben eltért a korábban építettektől és oly sokszor változott építés közben, hogy az a jelek szerint már meghaladta a mester képességeit. A mai számítások azt mutatják, hogy a Vasa súlypontja olyan magasra került, hogy már egy erősebb szél is meg tudja billenteni. Ha ezt az instabilitást a fedélzeten lévő terhek, ágyúk nem csökkentik, hanem még fokozzák is, akkor az eredmény előre borítékolható.

Mielőtt azonban továbblépnénk azzal, hogy mindössze egy szerencsétlen tervezési hiba történt, vegyük észre, hogy maga a tervezési folyamat is komoly hiányossággal bír. Miért lenne ugyanis szükségszerű, hogy egy tervezési hiba a projekten „végiggördüljön” és végül a projekt teljes kudarcát okozza? Amit láthatunk, az nemcsak egy tervezési hiba, hanem a folyamat alkalmatlansága arra, hogy egy ilyen hibát kijavítson.

A tervező akkoriban ugyanis egyedül dolgozott: megfelelő tudású szakmai közönség hiányában nem volt arra lehetősége, hogy terveit, ötleteit megvitassa, illetve a gyenge pontok beazonosításában külső szem segítse. Emellett a tervező nem is volt arra kényszerítve, hogy terveit egy kompetens szakmai stáb előtt megvédje, csökkentve ezzel a hibázás eshetőségét. Ez a fajta kontroll nélküli szakmai autoritás magában hordozza azt, hogy rejtve maradnak azok az – egyébként korán és kevés energiával felfedezhető – hibák, amelyek a projekt későbbi fázisában aránytalanul nagy károkat vagy akár a projekt kudarcát is okozhatják.

A mai informatikai projektek egy részére szintén jellemző, hogy a gyors fejlődés miatt olyan technológiákat, módszereket használ vagy olyan új eszközökre, programverziókra, illetve ezek olyan kombinációjára építkezik, amelyekről még viszonylag kevés tapasztalat áll rendelkezésre, és így komoly műszaki kockázatot vállalnak fel. Ha egy ilyen projektben nincs olyan ellenőrző mechanizmus, amely az egyes terveket, ötleteket szakmailag validálná, és a projektvezető elfogadja azt, hogy a projektben vannak érinthetetlen szakértők, guruk, „techno-papok”, akiknek szava kinyilatkoztatás, döntéseik pedig megkérdőjelezhetetlenek, akkor a Vasa projektjéhez hasonló kockázatot vállal fel, ami az architektúra review-k, code review-k stb. korában abszolút nem szükségszerű.

Az ilyen helyzeteket az sem menti, ha a „guru” előéletével, korábbi nagyszerű projektjeivel és briliáns szakmai döntéseivel próbálják magyarázni – a Vasa kapcsán láthatjuk, mit jelentett az, hogy a mester korábban csak jó hajókat tervezett és nemzetközi hírnévre tett szert: csak annyit, hogy lehetőséget kapott arra, hogy egy minden addiginál nagyobb projekten hibázhasson.

Valószínűleg nem segítette a projektet, hogy a szakmai vezetésben komoly törés történt. Hybertsson, a hajóépítő mester 1627-ben meghalt és helyét a kevesebb tapasztalattal rendelkező segédje, Hein Jakobsson vette át. A hajótest ekkor már készen volt, így utódjára a felső fedélzet, a hajóorr és a kötélzet befejezése maradt. Egy megfelelően dokumentált projekt életében egy szakértő kiesése általában nem okoz végzetes károkat, mert az elkészült anyagok kellő támogatást nyújtanak az új projekttagnak a projekt megfelelő folytatásához, azonban a tudásukat féltő és azt titokként őrző mesterek korában ilyen dokumentációk, tervek nem léteztek. Az elkészített tervek csak olyan szintűek voltak, hogy csupán az eredeti tervező fejében lévő tudással együtt voltak használhatók.
A mester halála és a megfelelő tervek hiánya együttesen azt eredményezték, hogy a mester helyét átvevő, tapasztalatlanabb utód olyan helyzetbe került, hogy a hajó befejezéséhez a tervek csak minimális segítséget nyújtottak.

Számomra kérdéses, hogy a személycsere önmagában mennyire érintette hátrányosan a Vasa-projektet, viszont érdemesnek tartom a jelenséget megemlíteni, mert ez a fajta „hidegváltás” sajnos sok mai informatikai projektre is jellemző: a vezető szakértőt, architectet, vezető fejlesztőt, adatbázis-szakértőt, legacy gurut stb. átallokálják más projektre vagy egyéb ok miatt távozik a projektből, és ekkor derül ki, hogy munkáját az újonnan beugró projekttag nem tudja megfelelően folytatni. Ennek oka lehet az új projekttag kevesebb tapasztalata (gyors emberpótlásoknál ez könnyen előfordulhat), de a jelenség előfordulhat abban az esetben is, ha az új projekttag rendelkezik a kellő tapasztalattal, viszont nem kapja meg a sikeres folytatáshoz szükséges információkat. Ez utóbbi esetekben ráadásul gyakran kiderül, hogy a transzparens, mások által is érthető és elfogadott tervek, projekttermékek, programkódok helyett a korábbi guru csak átláthatatlan, érthetetlen, és így újratervezést, újraírást igénylő workaroundokat, quick&dirty megoldásokat és „maszatolásokat” hagyott hátra. Vegyük észre, hogy a külső tényezők szerencsétlen alakulásán túl ilyenkor a folyamat hibájáról is szó van: a projekteknek lehet, hogy minimális vagy (elhalálozás esetén) zéró ráhatásuk van arra, változik-e a projektstábjuk, viszont a jól dokumentált, szakmailag transzparens projektek ellenállóbbak a stáb változásaival szemben.

A sikertelen stabilitási teszt el lett hallgatva. A korszak hadihajói – beleértve a sikeres, bevált hajókat is – közismerten instabilak voltak, ezért a gyártási fázist követően általában egy stabilitási tesztnek vetették alá. Így történt ez a Vasával is, amely nem sokkal az indulást megelőzően, 1628 nyarán átesett ezen a teszten – és megbukott rajta. A teszt során 30 ember rohant a fedélzeten oda-vissza, de az ellenőrzést vezető Fleming admirális a 3. kört követően leállította a tesztelést, mert félő volt, hogy a hajó felborul. S noha az admirálisnak joga lett volna a sikertelen teszt alapján a hajó indulását megvétóznia, ő mindössze annyit jegyzett meg, hogy „Bárcsak itt lenne a király!” és engedélyezte a kihajózást. Az admirálisnak nem volt elég bátorsága ahhoz, hogy közölje a türelmetlen és követelőző királlyal, hogy az elkészült és irdatlan költségekbe kerülő hajó nem megfelelő, és ezzel egyrészt lehetetlenné tette, hogy a hibát javítani lehessen, másrészt hozzájárult ahhoz, hogy a hajó alkalmatlansága a lehető legszélesebb plénum – sok ezer ünneplő – előtt a lehető legmegdöbbentőbb módon derüljön ki.

A kurázsi hiánya azért is fájó, mert a hajó stabilitásának utólagos javítása nem volt teljesen reménytelen: a Vasával párhuzamosan épült testvérhajó, az „Apple” mindössze annyiban tért el a Vasától, hogy 1,5 méterrel szélesebb volt, és későbbi testvéreivel együtt olyan jól bevált, hogy 1660-ig a svéd flotta gerincét alkották. A később készített, a Vasához hasonló tűzerejű angol hadihajók megfelelő stabilitását pedig olyan „trükkökkel” biztosították, amelyek a Vasa esetében is használhatók lehettek volna: a nehéz ágyúkat alulra, a könnyebbeket felülre helyezték el, és a felső szinten lévőket közelebb helyezték a hajó középvonalához.

A sors furcsa fintora, hogy más tartalommal ugyan, de a mai informatikában is ismert a stabilitási teszt fogalma. Sok projekt esetében azonban nincs is lehetőség arra, hogy ennek eredményét elhallgassák, mert ezeket a teszteket pénz, idő vagy akarat hiányában el sem végzik. Természetesen nem minden IT-projekt esetén indokolt a stabilitási teszt elvégzése, de azoknál a projekteknél, ahol lenne értéke, de mégsem történik meg, ott a Vasához hasonlóan azt kockáztatják, hogy a rendszer alkalmatlansága rejtve marad, és csak a nagy plénum előtt kerül napvilágra.

A kihajózást nyitott ágyúnyílásokkal végezték el. A XVII. századi hajók esetében szokás volt, hogy a kockázatok csökkentése végett az első úton csukott ágyúnyílásokkal haladtak, hogy a kapitány és a legénység kitapasztalhassa a hajó viselkedését, karakterét. Söfring Hansson kapitány a díszsortüzet követően azonban nem záratta be az ágyúnyílásokat, és ez azt eredményezte, hogy ezeken keresztül a hajó második megdőlését követően hatalmas mennyiségű víz özönlött be.

A nyitva hagyott ágyúnyílásokon keresztül láthatóak voltak a félelmetes tűzerejű ágyúk, amelyek minden bizonnyal nagyon imponálóak lehetett és méltán töltötték el büszkeséggel a nézők kebelét, azonban hozzájárult ahhoz is, hogy a hajót gyorsan elérje dicstelen vége.

A felelős keresése
Érdemes nyomon követnünk a projekt sorsát a hajó elsüllyedését követően is, mert itt is találhatunk párhuzamot a mai IT-projektekkel.
II. Gusztáv Adolf bizonyos volt afelől, hogy a katasztrófát a gondatlanság és hanyagság okozta, és követelte a felelősök példás megbüntetését. A hajó kapitánya a Vasa elsüllyedését követően már 12 órán belül ott állt a királyi palotában és záporoztak rá a Birodalmi Tanács kérdései: „-Részeg volt?! -Nem rögzítette megfelelően az ágyúkat?!”

A kapitány ártatlannak vallotta magát, és elmondása szerint senki nem volt részeg a fedélzeten, és vágják fel akár 1000 darabra, ha volt rosszul rögzített ágyú a fedélzeten. A szerencsétlenség okaként a hajó instabilitását nevezte meg, amely miatt egy kisebb szél is elegendő volt a hajó megborításához.
A hajó megmaradt legénysége megerősítette a kapitány állításait, és kitartottak amellett, hogy a hajón senki nem követett el hibát: a fedélzeten senki nem volt részeg, a Vasa maximális ballaszttal közlekedett és az ágyúk megfelelően rögzítve voltak (a ballasztra és az ágyúk rögzítésére vonatkozó állítások igazságáról 1961-ben a hajótest kiemelését végzők saját szemükkel is meggyőződhettek). A baleset okának ők is egyértelműen a hajó instabilitását nevezték meg.

Ezt követően a hajó még élő építői kerültek a kérdések kereszttüzébe, de ők is ártatlanságukat hangoztatták mondván, hogy – az időközben meghalt – hajóépítő mester utasításait követték, emellett a hajó méretei megfelelnek a király által meghatározottaknak.
Az ide-oda tologatott felelősség így elérte magát a királyt is. A tévedhetetlen uralkodó képbe kerülését követően a vizsgálat további menetéről nem sokat tudunk, és az ügy végül felelős megállapítása és büntetés nélkül, az „Úr tette volt!” konklúzióval zárult.

Manapság egy informatikai projekt kudarcát meglehetősen nehéz eladni az „Úr tette volt!” magyarázattal, így az ilyen indoklások helyét elfoglalták a kívülállók számára nehezen érthető szakszavakkal teletűzdelt érvelések.

Számomra az egyik legemlékezetesebb ilyen „techno-mágikus” magyarázat egy, a vállalat szinte teljes egészére kiható incidens után hangzott el, amikor az adatbázis-adminisztrátorok azzal a magyarázattal álltak elő, hogy „Elszabadult a script”. Látható, hogy az Úr szerepét egy másik transzcendentális entitás, a „Script” vette át, amelynek az egyszerű földi halandók értelemszerűen teljesen ki vannak szolgáltatva.

Informatikai tanulságok
A kellemes, szellős időben a Vasa fedélzetén kihajózók a melengető napsütést élvezve valószínűleg nem is sejtették, hogy hamarosan egy nagyszerű projekt dicstelen végének lesznek szereplői.
Valószínűleg így van ezzel jónéhány, a release-hez közeledő informatikai projekt résztvevője is.

Hogyan ismerhetnék fel menet közben, hogy projektjük egy modernkori, IT-s Vasa-projektté alakul át?

A Vasa-projekt tapasztalatai alapján annyit mondhatunk, hogy ha a projektre nehezedő határidős nyomás olyan mértékűvé válik, hogy az ellehetetleníti a hatékony munkát, és rendszeressé válik a workaround-megoldások használata, az improvizálás és állandósul a kapkodás, a tűzoltás;

1, ha az autoriter és türelmetlen szponzor mindenkin és minden szabályon átnyúlva szakmai döntéseket kezd el hozni és nem is hajlandó az ezzel kapcsolatos szakmai érveket, javaslatokat meghallgatni;

2, ha a projekt alapjait olyanok fektették le, akik szava megkérdőjelezhetetlen volt és a tervek emiatt nem is lettek megfelelően validálva;

3, ha a projektstábban jelentős a fluktuáció és az újonnan belépők vagy nem elég tapasztaltak , vagy nem állnak rendelkezésre a gördülékeny folytatáshoz szükséges tervek, dokumentációk;

4, ha a menet közben felmerülő problémák indoklásánál feltűnően megnő a földi halandókon túlmutató, megfoghatatlan entitások súlya, ha úgy érezzük, hogy mindenféle mágikus hatalommal bíró Elszabadult Scriptek, Integrációs Problémák, Legacy Korlátozások és egyéb, Ghostbustersbe illő szellemek költöztek a projektbe és hatásuk egyre csak nő;

5, ha funkcionális, stabilitási stb. tesztek eredményei a rendszer komoly hiányosságait jelzik, de ezek a szőnyeg alá vannak söpörve;

6, ha a rendszer élesítésekor a gondosságot, óvatosságot a hurráoptimizmus helyettesíti („hogyne sikerülne!”),

akkor készüljön fel, hogy Ön valószínűleg egy informatikai Vasa-projekt résztvevője.

Vegyen egy mély levegőt, tegye fel az úszószemüvegét és készüljön a landolásra!

Hirdetés
0 mp. múlva automatikusan bezár Tovább az oldalra »

Úgy tűnik, AdBlockert használsz, amivel megakadályozod a reklámok megjelenítését. Amennyiben szeretnéd támogatni a munkánkat, kérjük add hozzá az oldalt a kivételek listájához, vagy támogass minket közvetlenül! További információért kattints!

Engedélyezi, hogy a https://www.computertrends.hu értesítéseket küldjön Önnek a kiemelt hírekről? Az értesítések bármikor kikapcsolhatók a böngésző beállításaiban.