INFORMATIKAI PROJEKT MANAGEMENT A GYAKORLATBAN
Miért buknak el gyakran az informatikai fejlesztések?
Érdekes tény, hogy a Standish Group CHAOS legutolsó jelentése szerint az IT fejlesztési projektek 60-70%-a kudarcba fullad vagy komoly kihívásokkal küzd.
A Standish Group a projekteket három kategóriába sorolja, ez alapján az IT fejlesztésekre az alábbi számok jellemzőek:
- Sikeres (Success - ~30-35%): Határidőre, költségkereten belül, és a kért funkciókkal készült el.
- Kihívásokkal küzdő (Challenged - ~50-55%): Elkészült, de túllépte a költségvetést, a határidőt, vagy kevesebb funkciót tartalmazott a tervezettnél.
- Kudarc (Failed - ~15-20%): A projektet törölték, vagy soha nem használták.
A tisztán sikeres projektek aránya irreálisan alacsony. Ezen belül még érdekesebb, hogy a kis projektek sikerrátája jóval magasabb (akár 60-70%), míg a nagy, komplex projekteknél ugyanezek a számok a sikertelen vagy elcsúszott projekteket jelölik. Ennek megfelelően a kisebb fejlesztésekre jellemző Agile projektek kétszer olyan sikeresek, mint a hagyományos, Waterfall módszerrel készülő nagy volumenű fejlesztések.
A magyarországi helyzetről sajnos nincs átfogó statisztika, de tapasztalataink alapján a helyzet nálunk is hasonló: a KKV-k körében is jellemző a kontroll nélküli terjedelemnövekedés, az alulbecsült költségvetés és a tisztázatlan követelmények problémája.
Ezek az adatok rávilágítanak arra, hogy az IT-fejlesztés rendkívül komplex folyamat, ahol a tervezés és a felhasználói igények pontos ismerete kiemelten fontos, míg a konkrétan meghatározott célok-, és a megfelelő kommunikáció hiánya súlyos pénzügyi kockázatot jelent. Tehát a probléma NEM technikai.
A CHAOS jelentések és más iparági elemzések szerint a kudarcok hátterében leggyakrabban pont ezek az okok állnak:
- Hiányos követelmények (Poor requirements): Nem tisztázott, mit kellene pontosan építeni.
- Felhasználói bevonás hiánya (Lack of user involvement): A fejlesztők nem a felhasználók valós igényeinek megfelelő terméket készítenek.
- Irreális elvárások és határidők (Unrealistic expectations): Túl rövid határidők, vagy túl alacsony költségkeret.
- A "scope creep": A projekt céljainak és terjedelmének folyamatos, kontrollálatlan bővülése.
- Menedzsment támogatás hiánya.
A fentiek tükrében az alábbi szempontrendszert érdemes figyelembe venni egy fejlesztési projekt esetén.
1. ELŐZETES HATÁSTANULMÁNY
Milyen rendszereket, felhasználói csoportokat érint, milyen más alkalmazásokkal kell integrálódnia, milyen felhasználói és üzleti igények merülhetnek fel, milyen a reális időkeret és milyen a reális költség?
2. HOZZÁÉRTŐ PROJEKT MANAGER
Az ideális projekt manager nem admin és nem informatikus. Rendelkezik technikai háttértudással (érti a kódot), üzleti érzékkel (tud priorizálni), és kommunikációs híd (lefordítja a tech nyelvet az üzletnek, az üzleti igényeket a fejlesztőknek) funkciót tölt be a megrendelő és a fejlesztői gárda között. Egyszerre látja át az összképet és a technikai részleteket. Nem engedi az irreális elvárásokat a projektre húzni, sem pedig a fejlesztőket "eldriftelni" érdektelen optimalizálásokba, így képes megvédeni a fejlesztési időt az irreális elvárásokkal és a felesleges feature-kérésekkel szemben (scope őr). Ha egy fejlesztés mögött olyan projekt manager van, aki nem tud kódot olvasni, vagy sosem volt technikai szerepben, a bukás kockázata jelentősen megnő.
3. PROAKTÍV REDUNDÁNS TERVEZÉS
Az informatika két alappillére a proaktivitás és a redundancia. Ebben az esetben proaktivitás alatt azt értjük, hogy egy projektben fel kell készülni minden eshetőségre: előre kell tervezni és gondolkozni. (Mi történik, ha egy kulcsember kiesik a fejlesztői gárdából? Mi történik, ha egy vendor csődbe megy? Hogyan oldjuk meg, ha szállítási problémák adódnak? ) A legtöbb projekt NEM készül fel ezekre. Aztán amikor bekövetkezik, mindenki meglepődik.
A redundanciát sokan felesleges költségnek tekintik, holott ez a biztosítéka a folytonos működésnek. Tipikus kockázat az egyetlen külső szolgáltatótól vagy beszállítótól való függőség.
Megoldás: Minden kritikus elemhez (infrastruktúra, személyzet, vendor) fallback opciót kell rendelni, azaz mindig legyen B (Backup) terv.
Példa 1 – Kulcsember kiesik:
Egyetlen fejlesztő ismeri a legacy kódot, akit elüt az autó: a projekt megáll. Ezért: legalább 2 fejlesztő minden kritikus modulhoz
Példa 2 – Vendor csőd:
Egyetlen cloud provider: ha megszűnik a szolgáltatás, vagy hirtelen drasztikus áremelés történik: nincs B terv. Ezért: Multi-cloud stratégia vagy on-premise fallback opció is.
4. KÖZÉP-HOSSZÚ TÁVÚ FEJLESZTÉSEK ELŐNYBEN RÉSZESÍTÉSE
A megrendelők többsége a gyors (ezáltal rövidtávú) megoldásokat részesíti előnyben. Ezek azonban csak átmeneti „hotfix”megoldások, kérdéses a fenntarthatóságuk, ár-érték arányuk emiatt jóval magasabb, mint egy közáptávú, fenntartható és jövőálló megoldásnak. Érdemes magunknak feltenni a kérdést: Ez a megoldás 1 év múlva is működik majd, vagy újra kell csinálni?
Ugyanez a helyzet a hosszútávú megoldásokkal: egy nagyon nagy léptékekkel fejlődő, szinte naponta új kihívásokkal szembenéző területen nehéz megjósolni merre tartunk majd 4-5 év múlva. Kérdéses, hogy ez ilyen projekt néhány év múlva is tartani tudja-e a lépést a technika fejlődésével.
Ezért az informatikai fejlesztések során előnyben kell részesíteni a középtávú megoldásokat. Egy 6-18 hónapos fejlesztés elég rugalmasságot, skálázhatóságot, ugyanakkor már fenntartható architektúrát biztosít.
5. CÉLTARTALÉK (BUDGET BUFFER)
A pont elég erőforrás egyenlő a projekt halálával. Olyan ez, mint az építkezés. Minimum 20%-os idő és költségtartalékkal kel számolni minden egyes fejlesztés esetében. Egy jogszabályváltozás, áremelés, beszállítói hiány radikális ártöbbletet eredményezhet. Ezért inkább a projekt legyen kisebb, mintsem céltartalék nélkül indítsunk el egy fejlesztést.
6. VALÓSÁGHŰ KÖLTSÉGVETÉSI TERVEZÉS
Az 5. ponthoz kapcsolódik az alulbecsült költségvetések gyakori problémája. A céltartalék képzés pont arra alkalmas, hogy a nem várt nehézségeken átsegítse a projektet. Milyen plusz költségek merülhetnek fel? Licencek, tesztelés, oktatás, migráció, support, karbantartás, harmadik féltől származó adatimport, legacy rendszer integráció.
Két gyakorlati példa:
- VMWare tulajdonosváltás – teljesen más piaci pozicionálás, hatalmas áremelés
- API integration – adatformátumok nem kompatibilisek egymással, kiegészítő licenszelésre van szükség
Megoldás: A fejlesztői becslést megszorozzuk minimum másféllel, optimális esetben kettővel. Ha így is belefér a költségvetésbe (+ céltartalék), akkor reális a projekt. Enélkül szinte garantált a bukás.
ÖSSZEFOGLALVA: Egy IT projekt sikere NEM a legütősebb technológiai környezeten (tech stack) múlik, hanem az átgondolt tervezésen, a reális elvárásokon és a proaktív kockázatkezelésen. A fenti szempontok alkalmazásával drasztikusan csökken a bukási arány kockázata.
VÉSZJELEK – Amikor a projekt veszélyben van:
„Majd menet közben kitaláljuk” – nincs pontosan definiált feladatkör (scope)
„Pont elég pénz van” – nincs céltartalék
„A fejlesztők megoldják” – nincs projekt manager
„Nem kell tesztelni, úgyis működni fog” – nincs QA tesztelési terv
„A felhasználói vélemények nem kellenek, elég, ha majd használják” – nincs felhasználói bevonás
Az Agilis és a Waterfall módszer összehasonlítása
Miért sikeresebbek az agilis projektek?
Agile (Agilis módszertan):
- 2-4 hetes sprintekben készül a termék, minden sprint után lehet módosítani, finomítani
- 2 hetente látható eredmény, tesztelhető verzió: korai hibafelismerés
- Folyamatos piaci alkalmazkodás, felhasználói visszajelzések gyors integrálása
- Folyamatos együttműködés a fejlesztők az üzletág és a végfelhasználók között.
- Kisebb méret, kisebb scope, kevesebb bukott funkció, ritkább a "total failure"
- A fejlesztők számára 2 hetente látható eredmény: magasabb motiváció és csapatmorál → kevesebb hiba
Ezzel szemben a
Waterfall (Vízesés modell):
- Hosszú fejlesztési ciklus: 12-24 hónap, gyakran túllépi az idő-, és költségkeretet.
- Minden előre megtervezett, ezért sokszor rugalmatlan és merev, nehezen alkalmazkodik a megváltozott piaci körülményekhez.
- A felhasználók csak a fejlesztés végén látják a terméket, nincs lehetőség a felhasználói visszajelzések integrálására. Csak a projekt végén derül ki, hogy működik-e.
A Waterfall modell fix szabályozási környezetben működik jobban. Olyan esetekben, ahol:
- FDA validáció szükséges (például orvostechnikai szoftver)
- Teljesen ismert követelmények: "Építsd újra pontosan ugyanazt" projektek
- Külső audit követelmény: Banki core rendszer, ahol minden lépést dokumentálni kell előre
De még ezekben a projektekben is egyre több cég "hibrid agilis" megközelítést használ
