Informatika

Zseniális cikk a katonai IT projektvezetés nehézségeiről

Innovációs központ

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:

Ajánlott tartalom

Továbbiak:Informatika