Olyan cikk jelent meg a Katonai Nemzetbiztonsági Szolgálat Szakmai Szemléjében, hogy még mindig hangosan nevetek rajta, pedig már többször is sikerült végigolvasnom. Bihari László és Dr. Magyar Sándor: Mennyország helyett a pokolba, avagy az informatikai támogatás kihívásai című cikke olyan elképesztően finoman keserédes humorú – gyakorló IT projektvezető szemmel – és annyi igazságot sejtet, hogy mindenkinek ajánlom az elolvasását.
Úgy tűnik, hogy ez a stílus egyáltalán nem áll távol a Szakmai Szemlétől, amikor először olvastam, egyből Dr. Farkas Ádám: Gondolatok a vezetés szenvedélye kapcsán – recenzió helyett című cikke jutott eszembe, ahol meglehetősen leegyszerűsített vezetéselméleti problémák megoldásai kerültek ajánlásra – feltételezem a katonai vezetők figyelmébe.
Az új cikk tehát az informatikai támogatás problémáira próbál rámutatni, méghozzá talán nem nagy tévedés feltételezni, hogy „valódi” esetek és problémafelvetések alapján. Ez pedig nemcsak a szervezeten belül lehet érdekes, hanem általában, az állami megrendelők tekintetében a beszállítói oldalnak is. Az alábbiakban kiemelt néhány problémának ugyanis lehetnek olyan vetületei és következményei is, amelyek kihatnak a projekt egészére.
Természetesen tapasztalati úton hasonló következtetésre lehet jutni önállóan is, de talán objektívebben tanulmányozhatók ezek a problémák, amikor nem a saját projektek sikerét akadályozzák. A szerzők mindenesetre nem jelezték, hogy ha a leírtakban bárki ráismerne magára, az a véletlen műve lenne, így én sem merészkednék olyan messzire, hogy azon elmélkedjek: vajon találkoztam-e már hasonló problémákkal?
A tanulmány egyébként némileg formabontó módon úgy épül fel, hogy egy -egy problémafelvetésként értelmezhető idézetet próbál meg fejezetcímként, majd kontextusba helyezve részletesen is elemezni és megoldásokat felmutatni, így én is ebben a struktúrában idéznék belőle pár gondolatot.
„Ez egy jó program, rakjátok fel!”
- előfordulhat, hogy olvasás nélkül kerül elfogadásra a licencszerződés
- ha az igénytámasztó amennyiben nincs tisztában a fenti kérdésekkel azt látja, hogy azt a szoftvert, amit felhasználóként otthoni környezetben öt perc alatt feltelepített, az informatikáért felelős szervezeti egység még hetek elteltével sem képes rendelkezésre bocsátani
„Ezzel a programmal az egész szervezet életét meg lehet könnyíteni.”
- ha a szoftver hatással van az adott szervezet munkafolyamataira, abban az esetben új eljárásrendeket is ki kell alakítani, így előfordulhat, máshogy kell dolgozni az érintett személyeknek szervezeti egységeknek
- a fejlesztés sokkal összetettebbé válik. a felhasználó pedig azt tapasztalja, hogy az informatikusok a szoftver telepítése és használatba adása helyett megint újabb kérdésekkel jelennek meg
- a szoftver logikája eltérhet a szervezet tényleges működésétől
- ezeket az eltéréseket még a bevezetés előtt fel kell deríteni, és a káosz megelőzése érdekében el kell végezni a szükséges változtatásokat
„Olyan jó ötlet, de az informatika nem képes azt megvalósítani”
- a fejlesztések egyik gyenge pontja a felhasználói vagy vezetői igény megvalósulásának rögös útja
- az ötletek (és nem tervek) végrehajtását a vállalat szervezeti felépítésétől függően vagy a fejlesztői vagy az üzemeltetői résznek szignálják ki
- a megvalósíthatósági tanulmányok, kiviteli dokumentációk, költségvetési
tervek szerepe bizonyítottan megkérdőjelezhetetlen - keserű tapasztalat, hogy az igények felmerülésekor az igénytámasztó oldaláról a járulékos költségek a teljes életciklusra vonatkozóan „nem minden esetben” ismertek
„A szoftver/rendszer azonnal kell!”
- a rendszerfejlesztés komplex átgondolását, a futó projektek befejezését gyakran gátolja a vállalhatatlan határidők kitűzése
- optimális esetben addig nem szabad bevezetni egy rendszert, amíg annak
üzemeltetésre történő átadása meg nem valósul - ezután is egy tesztidőszakra van szükség, amíg a felhasználók és az üzemeltetők is megismerik, beletanulnak a rendszerbe
- az „azonnal” elrendelt és végrehajtott feladatok az esetek jelentős részében egyszerűsítések, vagy fontos lépések kihagyásával valósulnak meg
- ez pedig üzemeltetési, funkcionális vagy biztonsági kockázatokat okozhat, vagy szabvány (jogszabály) -megfelelőséget veszélyeztet
„Ez a projekt elsődleges prioritást élvez!”
- ritkán találkozni olyan fejlesztési igénnyel, ami nem fontos és a határidő kérdésében a befejezés dátuma nem kitűzött
- sokszor az új feladat prioritást kap, ugyanakkor nem történik az új kiemeléssel egyidejűleg a többi, már futó feladat átpriorizálása
- nem fordulhat elő, hogy az erőforrásokért küzdeni kell
- gondolni kell a láncreakcióra is, például, ha máshonnan kerül az
erőforrás elvonásra, akkor azon a területen hogyan lesz pótolva a hiányzó képesség - az IT-területnek ritkán lehet nemet mondani a kérésre, így az igénylő szervezeti egység joggal várja, hogy az informatikai terület hamarosan megoldja azt
- nem okoz senkinek „fejfájást”, ha két hétig nem kerül frissítésre egy szoftver (esetleg az információbiztonsági, kibervédelemi területnek)
„Milyen legyen a végeredmény? Legyen tökéletes!”
- ehhez hasonló mondat is elhangozhat, ami igazi kihívást jelent a
végrehajtó IT-állomány számára. - előfordulhat, hogy a projektmenedzsment módszertani ismeretek helyett a legjobb szándékkal, akarattal, a sötétben tapogatózva kezdenek neki a feladatnak, remélve a jónak gondolt elképzelés találkozását a vezetők gondolataival
- másik változat, amikor konkrét utasítások érkeznek a megvalósításra: „Legyen feltéve ez a szoftver a szerverre.” De mit kell megvalósítani? Alkalmas lesz az a hardver annyi felhasználó kiszolgálására? Egyáltalán ez a program a legjobb megoldás a céljaink elérésére? Mi a cél?
- a projektek során mindig törekedni kell az optimális megoldásra, azonban tisztában kell lenni a 100%-os rendelkezésre állás és a 100%-os biztonság elérhetetlenségével
„Írjátok meg hozzá a dokumentációt!”
- előfordulhat, hogy a dokumentáció igénye is – eltérően az ajánlásokban, szabályzókban előírtaktól – csak később fog jelentkezni a vezetőség részéről
- esetenként, amikor már tesztelés alatt van a rendszer
- hangsúlyt kell fektetni a dokumentációk véleményezésére, elfogadására
- rengeteg időt, pontosságot igényel több tíz, esetenként száz oldalas dokumentumokkal a munkavégzés
- később ezek alapján lehet a követelményeket számonkérni, eldönteni a fejlesztés sikerkritériumainak megvalósulását
„Megvan az informatikus mérnöki diplomád! Informatikus vagy, te értesz ehhez a programhoz is.”
- általános vélemény, hogy az informatikus minden programot ismer és
bármilyen informatikai rendszerrel kapcsolatos kérdésben azonnal tud segíteni - az informatikus végzettség nem tudja helyettesíteni az egyes informatikai
rendszerek, szoftverek célirányos képzéseit, tanfolyamait - az egyes szoftverekhez tartozó oktatások rendkívül költségesek
- általában ezért nincs is lehetőség minden érintett személy beiskolázására
„Az informatika már így is nagy létszámú!” „De hát kaptatok még két embert!”
- a helyzeten javíthat a létszámfejlesztés, azonban, ha „ennek farvizén” még
további munkák kerülnek átcsoportosításra, új rendszerek kerülnek beüzemelésre, akkor a leterheltség szintje hamar ugyanolyan magas lehet, mint előtte - az új munkatársak sokat segítenek hosszabb távon, de a tanfolyamok és egyéb ügyintézések miatt a kezdetben hetekig kiesnek a munkából
- az első időszakban továbbá a régi munkatársak idejét kötik inkább le addig, amíg megtanulják a helyi sajátosságokat
- ebből kifolyólag az átszervezéseknél az eredmények kezdetekben elmaradhatnak az elvárásoktól
„Azért hívlak téged, mert mást nem sikerült elérni.” „Beírtam a
hibabejelentőbe, leadtam a helpdeskre. Mikor hárítjátok el a hibát?”
- rengeteg időt köt le a felhasználókkal történő kapcsolattartás
- amennyiben nem rögzül a felhasználókban az a folyamat, hogy a szervezeti szabályzókban meghatározott eljárásrendek alapján jelezzék a meghibásodásokat, akkor további késések várhatók
- az informatikai szakemberek idejének pazarlása, ha munkaidejük jelentős
részét azzal töltik el, hogy telefonálnak. - elkerülhető lenne, ha a bejelentések tényleg a megfelelő csatornára terelődnének
- az üzemeltetés, fejlesztés végrehajtása során a hívásokra fordított idő nehezen írható be az elvégzett munkák közé
- ezek a megkeresések arra is alkalmasak, hogy kizökkentsék az
informatikust az éppen aktuális feladatból - a telefonálónak természetes, hogy a saját problémája a legfontosabb, végre elért valakit és visszajelzést vár, hogy mi okozhatja a fennakadást
Kedvenc gondolatmenetem a cikkből:
- az informatikai hibabejelentőtől, helpdesktől kapott visszacsatolás sok esetben elveszi a felhasználó kedvét, amikor meglátja, hogy esetleg több mint száz, folyamatban lévő bejelentés van az általa leadott hiba mellett
- jogosan merül fel a kérdés, hogy előrébb lehet-e azt sorolni
- ez újabb hívásokat, kérdéseket generálhat
- majd hamarosan vezetői szinten kezdhetnek tárgyalni az ügyről
- ezután érkezik a feladat közvetlenül vezetői szintről, hogy azonnal legyen
megoldva prioritással, amely terület az előzőekben már tárgyalásra került - így pedig már borulhat is a sorrend
- aki rendben rögzítette az igényét, és türelmesen várt, az hátra kerül, aki hangosan követel, annak igyekszenek végrehajtani a kérését
„Projekt lezárva, célok teljesítve.”
- ezt a mondatot várja mindenki a projekt elejétől kezdve
- az életben azok nem mindegyike jut el ebbe az állapotba
- esetenként több fejlesztésbe kell belekezdeni, mint amennyit a
szervezet képes kezelni - komoly fejtörést okoz az, hogy a régi projekteket sem sikerül lezárni érdemben
- így a régi és az új rendszerek is egy köztes állapotba fagynak bele
Utóbbi felvetés egyébként szerintem egy érdekes probléma, ami az egész IT fejlesztésre rá tud ülepedni, olyan értelemben, hogy a projektzárás pillanata gyakran összeolvad a support/szoftverkövetés tevékenységgel, és nincs is valódi sikerpillanat, amit szerintem érdemes lenne még akkor is jobban kiemelni, ha tudjuk: a műtét néha annak ellenére is sikerülhet, hogy végül a beteg meghal.
A cikkhez ITT lehet hozzászólni. Ha tetszett, ne maradj le a következőről:
