Határidő és költségkeret tartása a minőség kárára kell, hogy váljon?
- Folyamatfejlesztes
- May 2, 2019
- 2 min read
Multinacionális környezetben általában minden fejlesztést projektekben hajtanak végre, hogy a dedikált költségkeretet biztosítani tudják. A céldátum fixálásával elkészíti a projektvezető a projekttervet, ami tartalmazza az elérendő célhoz vezető összes feladatot a felelősökkel, mérföldkövekkel. Minden feladatnak megvan a határideje, amire azt el kell végezni.
A projektvezető biztosítja tehát a feladatok határidőben történő elvégzését és a meghatározott költségkeretet, de vajon hogyan biztosítható a minőség?
A gyakorlat szerint a projekt sikerességét meghatározott mérőszámokkal fejezik ki, amit vagy a projekt megbízója és/vagy a projektcsapat állít össze – jobb esetben - meghatározott dimenziókban. Általános projekt cél a határidőben és megadott költségkereten belüli leadás.
A minőségi mutatószámokat viszont nem ilyen egyszerű kitalálni.
Ha szoftver fejlesztése a “leszállítandó termék”, ott meghatározható például az átadást követő, a szoftverre bejelentett hibák száma. Ez már egy elég egzakt mutatószám ugyan, de mi minősül ilyen esetben még megfelelőnek? A 10 darab bejelentett hiba? Vagy a 132? Ez függ a bevezetett szoftver nagyságától, bonyolultságától, hogy mennyi szakterület használja, mennyire komplex…stb.
A lényeg, hogy egy rendszerfejlesztésre lehet “hibákat” lejelenteni, azokat rögzíteni egy olyan rendszerben, amit később le lehet kérdezni. Riportok állíthatók össze egy-egy projekt hatékonyságáról és azokat egymással összenézve, talán közelebb juthatunk a megoldáshoz úgy, hogy persze súlyozzuk a bejelentett hibák számát a projekt összetettségével.
Egy szoftver bevezetésével a folyamatok is biztosan változni fognak. Akár a meglévő folyamatok automatizálása a cél, akár fejlesszük is a folyamatokat a projekt alatt, hogy hatékonyságot érjünk azzal el: mindig változni fognak a folyamatok.
Az első esetben (amikor csupán a jelenlegi folyamatot automatizálják) akkor történhet nem várt változás, amikor valamire mégsem gondoltak és azt próbálják valahogyan megoldani.
A második esetben (amikor a folyamatot ténylegesen fejlesztik) azért, mert eleve megváltozott a működés.
Hogyan biztosítható egyáltalán az, hogy a folyamatokban bekövetkezett változást is a minőségi mutatók körébe soroljuk, és ne essen áldozatul a határidő/költség oltárán?
Ha szorul a hurok, mindig a minőség az, ami kimarad, mert az kevésbé látható rögtön.
Sokan nem vesznek tudomást arról, hogyha a folyamatok minőségével nem foglalkoznak, hiába szállítják le a projektet határidőben, és a költségkeretet tartva, hogyha utána olyan tűzoltást kell elvégezni, ami ebből a hiányból származik.
Sokszor költségesebb a folyamatfejlesztés hiányából eredendő problémákat megoldani, mintha korábban arra ténylegesen időt és költséget szántak volna. Hiába adják le a szoftvert, ha a projekt a szűkös határidő miatt nem tette lehetővé a folyamat fejlesztését és a számos akadályt újonnan létrehozott excel táblázatokban, vagy plusz ellenőrzési körökkel …stb. (tehát több mudával) próbálják orvosolni. Ezekkel senki nem számol már utólag. Lezárták a projektet, akár még sikeresnek is mondták ezektől a bakiktól függetlenül. Ezek azonban hosszú távon biztosan nem térülnek meg!
Ha a projektvezető érdekeiben továbbra is a minőség marad alul, kell egy olyan szerep, aki a minőségért felel.
Valaki, aki csak ezt a célt biztosítja, láthatóvá teszi a minőségi eredményt!
Azért fontos, hogy csak ez a cél legyen hozzá dedikálva, mert így nem lehet elporlasztani más cél teljesítésével. Ez lenne alapvetően a folyamatfejlesztő az új világban, aki a projektvezetővel egy szinten a felsővezetésnek riportolja, hány millió forintot spórolt a folyamat fejlesztésével a csapat az x és az y projektben is!
Ehhez viszont hozni kell ezeket a számokat a folyamatfejlesztésekből és ehhez az kell, hogy a projektvezetővel valóban egy szinten legyen a folyamatfejlesztő. Máskülönben a fentebb hierarchiai szinten lévő vezető érdeke fog érvényesülni.
תגובות