Szkóp menedzsment

Mivel ma már meggyőződésem, hogy szoftverfejlesztési projektet vízesés modellel csak véletlenül lehet sikeresen megvalósítani, sokat gondolkodom azon, hogy az adaptív módszertanok alkalmazásának előnyei hogyan világíthatók meg a legjobban az üzleti döntéshozók előtt. Mitől sikeres a fejlesztési projekt az én fogalmaim szerint? Nagyjából ezeknek a feltételeknek a teljesülése esetén:

• A rendszer az előre meghatározott időben használatba vehető (azaz valós üzleti célokat szolgál és használható)
  
• A rendszer megrendelője úgy érzi, hogy nagyjából a kapott értéknek megfelelő árat fizette meg
  
• A projekt megvalósítása a fejlesztő cég számára is tisztességes, (fair) haszonnal jár
  
• A megrendelő és a beszállító a későbbiekben is szívesen dolgozik együtt
  

Elsősorban olyan projektekben gondolkodom, ahol a rendszer fejlesztője egy versenyeztetés során kiválasztott külső cég és nem belső erőforrás. Ilyen környezetben a projekt sikerének talán legizgalmasabb fokmérője az utolsó pont. Ha a partnerek legközelebb is egymást választják egy új fejlesztési projektben, akkor legalábbis azt elismerik, hogy mindketten mindent megtettek a siker érdekében és ennek elmaradása valami máson múlott. De mi ez a más? Sok projektvezető szkópnak szereti ezt nevezni. Hányszor hallottuk már ezeket a mondatokat: "a szkóp kézben tartása a projekt sikerének kulcsa" vagy "ezzel a problémával most nem foglalkozunk, mert nem tartalmazza a szkóp"? Gyakorlatilag nincs olyan projektstátusz-megbeszélés, ahol ne hallanám a szkóp kifejezést legalább 3-szor. És sokszor teljesen más jelentéssel. Néha a cél helyett alkalmazzák, néha a ráfordítás jelentését fedezem fel benne és sokszor valamilyen módon a funkcionalitáshoz van köze. Pedig ezek a fogalmak nem egy rendszerbe tartoznak. Ez a legnagyobb bajom a szkóppal.

Eredetileg az angol "scope" szó leginkább behatárolást, kiterjedést jelent. A szkóp kézben tartása tehát azt jelenti, hogy a projektnek szigorúan a megfogalmazott keretek között kell maradnia. De milyen keretek között? Az eredetileg megfogalmazott célokat kell tartani? Akkor miért nem hívjuk célnak? Az eredetileg megcélzott felhasználói kör igényeit kell kielégíteni? A projekt indításakor elképzelt szolgáltatásoktól nem szabad eltérni? És még sorolhatnám... Ezek közül egyedül a cél az, ami nagyjából jól ismert lehet a projekt elején, az összes többi bármikor változhat. Itt visszautalnék a döntéselméleti fejtegetésemre. Hiszem, hogy a szoftverfejlesztés a rosszul struktúrált helyzetek kategóriájába tartozik, tehát a projekt elején nem világosak az elvárásaink, azokat a megoldás keresése során folyamatosan alakítjuk ki. A megoldást valamilyen olyan helyzetre keressük, amivel elégedetlenek vagyunk. (Lassú ügyintézési folyamat, túl nagy a raktárkészlet stb.) A cél tehát ennek az elégedetlen állapotnak megszűntetése. Az elején van egy elképzelésünk arról, hogy az adott problémát milyen okozó tényezőkre vezethetjük vissza, és ezeket hogyan fogjuk megoldani. Ezek az elképzelések aztán erősen meghatározzák, hogy hol határoljuk be a projektet, azaz mi tartozik szkópba. Ehhez aztán foggal körömmel ragaszkodnak a projektvezetők.

Az eredmény az, hogy sokszor az eredeteli problméma megoldásához olyan kérdésekkel kellene foglalkozni, amik az előzőleg a nagy gondossággal (és jó sok munkával) meghatározott projekthatárokba nem férnek bele. Ez persze senkinek nem jó. Nem jó a megrendelőnek, mert nem arra költi a pénzét, amire kellene. Nem jó a fejlesztőnek sem, mert azon kívül, hogy sikertelen projekten dolgozik semmi nem garantálja számára, hogy a meghatározott projekt szkóp keretein belül nem lehet határtalan erőforrásigényű feladatatot generálni. A két partner viszonya csak a résztvevők empátiáján, szakértelmén és üzleti erkölcsén múlik azzal a feltétellel, hogy mindketten belátják: igen, sajnos az elején rosszul határoztuk meg a szkópot, a sikertelenségért egyikünk sem okolható...

A megoldás erre a problémára az lehet, ha ragaszkodunk a projekt eredeti keletkeztetési forrásához: a helyzethez, amellyel elégedetlenek vagyunk. Eldöntjük, hogy mennyi pénzt ér meg nekünk ennek a problémának a megoldása, megvizsgáljuk, hogy mi az az időtáv amin belül ezt meg kell oldani és ezeket rögzítjük. A többit már egy olyan csapatra kell bízni akiről elhisszük, hogy képest a problémára megoldást találni és azt meg is valósítani. A szkóp meghatározására meg nem érdemes időt szánni, annyival is később kezdünk el az érdemi kérdésekkel foglalkozni. Kérdezzük inkább ezt: ha a felvetett észrevétel mennyiben szolgálja a problémát okozó helyzet megoldását? Mert csak ez számít...