Skip to end of metadata
Go to start of metadata

Összeomlott a tűzoltók új riasztási rendszere...

A tűzoltóság szerint ez csak tesztüzem volt, az Erőgazdálkodási és Riasztási Információs Rendszer (ERIR) új változatát hivatalosan kedden helyezték üzembe.

Egyébként – szokás szerint – annyi történt, hogy a győztes cég megnyerte valamilyen "oknál" fogva a munkát, amelyet azonnal kiadott valamelyik projektcégének, a projektcég kiadta a megszokott fejlesztő cégének, a megszokott fejlesztő cégnek éppen nem volt elegendő fejlesztője, vagy a szabad fejlesztők éppen nem értettek ehhez a területhez, esetleg még az is előfordulhat nem ritkán, hogy egyátalán nem csináltak még ilyen munkát. Ebből következően a fejlesztő cég körülnézett a piacon és hamar-hamar-gyorsan-gyorsan felvett mindenféle gyütt-ment olcsó embert az utcáról projektmunkára, esetleg egy-két szakértőbb embert architect pozícióra – de ez ritka dolog egy ilyen projektben, általában a fejlesztő cég valamelyik – szakmából 5-15 éve kikopott – vezetője a fő-fő architect... (smile)

Ha mindez megvan, akkor sejthető, hogy a tápláléklánc alján már csak a pénz felének a harmada létezik kézzelfogható formában. Ekkor indul be a tényleges munka, amelyet így már alapból 1-2 hónap csúszás jellemez, de a projektvezetők optimisták, hiszen annyi ember dolgozik a projekten, hogy szinte egymást akadályozzák a munkában, így a projektre tervezett idő első fele szép és lassú munkával el is telik.

Persze a megbízó egyre idegesebben toporog, mivel nem lát semmi terméket, ezért a beszállító elkezdi használni a "szerkezetkész" fogalmat, amely ebben az esetben azt takarja, hogy valami GUI építővel összedobnak gyorsan pár képernyőt, amelyen lehet kattintgatni, de a dolog mögött még nincs üzleti logika – lévén a színfalak mögött már harmadszor térnek át gyökeresen más keretrendszerre, mivel az előzőekkel nem tudtak egy-egy feladatot megoldani, a vállalkozói réteg mélysége pedig rengeteg információt torzít el, a fejlesztők sokszor rá se ismernének a megrendelő igényére.

Amint a projekt tervezett idejének a felén túlhalad az idő, a projektvezetők kezdenek idegesek lenni, mivel az alsó szinten a pénz 90 százaléka már elfogyott, de felmutatható prototípus még messze nincs, pedig lassan felhasználói teszteket kellene futtatni. Ekkor a középső projektcég – mint vízzáró réteg – a pánikhangulat elkerülése végett elkezdi akadályozni a kommunikációt a tényleges munkát végző és a pályázatot nyerő cég között. Eközben végtelen prémiumot kezd ajánlani a fejlesztő cég vezetőinek, ha időre sikerül befejezni a feladatot, miközben a megbízótól időt próbálnak szerezni, például arra hivatkoznak, hogy az élesbe helyezéskor erős napfolttevékenység várható, ezért el kell azt halasztani legalább két hónappal.

A fejlesztő cég vezetői a végtelen prémiumok csábító ígéretére elkezdik bevezetni a 16 órás munkanapot, illetve a "minden nap hétköznap" nevű játékot, igyekeznek rábeszélni a projektmunkára beszervezett embereket arra, hogy a karácsony csak egy napos, illetve szombatra és/vagy vasárnapra is bevezetik a szabadság fogalmát. Ha az utolsó senki fejlesztők zúgolódnak, akkor apró hibákra való tekintettel példát statuálnak és kirugnak pár embert, akiket már úgysem tudtak volna kifizetni pénz hiányában.

Ahogy sejthető, a projekt nem fejeződik be határidőre, mivel a tesztek során kiderül, hogy tíz párhuzamos felhasználót már nem bír el a combos szerverpark, s ekkor a fejlesztők fele mindenféle cache megoldások integrálásával kezd bajlódni a saját területén. Amikor már száz párhuzamos felhasználót is elbír a rendszer a terheléses teszteken, akkor kiderül, hogy a fejlesztői gépen fejlesztett és tesztelt alkalmazás furán viselkedik cluster alapokon, mivel az újonnan belépő felhasználók adatai valahogy keverednek a már belépett felhasználók adataival. Ekkor a fejlesztők fele azzal kezd foglalkozni, hogy az rendszerbe került tucatnyi cache megoldások tartalmát összehangolja, hogy elosztott környezetben is tudjon futni a szoftver. Ezek után kiderül, hogy az alkalmazás elkezd memóriát fogyasztani, s az éles terhelés esetén naponta két újraindítással lehetne csak üzemeltetni.

Nagyjából három hónapos késés után kezd a projektet megnyerő cég vezetője rendszeres látogatásokat tenni a helyszínen, hogy jelenlétével és csoki-üdítő-gyümölcs-vacsora kombinációval munkára bírja az alja népet, de a fejlesztők már régen lemondtak arról, hogy valaha működni fog az a kódhalmaz, amelyet most írnak át ötödszörre.

Minden egyes új build után a tesztelők először azt mondják, hogy mehet a dolog, így összetrombitálják a sajtót, hogy most fog élesbe menni ez a nagyszerű termék, amelyhez foghatót még nem látott a világ, amikor valamelyik fejlesztő talál egy végzetes hibát, amely éles üzemben katasztrófát idézne elő. Ez megy hétről-hétre, a sajtó már csak ásít az újabb próbálkozásra, a projekten dolgozók pedig napról-napra fogynak.

Előbb-utóbb elérkezik az a pont, amikor a projektet – függetlenül annak állapotától – élesbe kell tenni. A projektmunkára szerződött fejlesztők ekkor már legalább kétszer lecserélődtek új arcokra, akiknek fogalma sincs már arról, hogy bizonyos sorok miért vannak bizonyos helyeken a forráskódban, s már csak egy maroknyi keménymag küzd azzal, hogy élesíthető állapotba kerüljön a kódhalmaz. A projektvezetésre átragad a fejleszők letargiája, és "nekünk már úgyis mindegy" alapon rábólintanak az élesítésre, az önéletrajzokba pedig változatos hazugságok kerülnek, mintpéldául "az utóbbi két évben háromszor volt négytalálatosom a lottón, és most fogyott el a pénz".

A kitett build látszólag egész jól viseli a terhelést és a felhasználók érdeklődését, amikor kiderül, hogy olyan részen van hiba, amelyet senki nem tesztelt és/vagy a teszteset rossz volt, így a visszaálláson kezd gondolkodni a döntési gépezet, a menedzsment pedig egy jól hangzó érvet vesz elő: ez csak egy éles tesztüzem volt.

A mese természetesen kitalált történet, a valósághoz semmi köze nincs. (smile)

      
      
Page viewed times
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))