Hódítanak mostanában az agilis módszertanok, meg a laza munkamódszer, a két hétről két hétre tervezés. Remek dolgok ezek, de mi a francot csináljon az, akinek odatolják az arcába, hogy: “Itt van tesvérem, 34,5 millióból szeptember 1-re legyen kész az új biszbaszrendszer, különben a beled kitapossuk! Mer’ indul ám a marketing kampány hozzá, az már hétszentség. Hogyhogy miért nem kérdeztünk meg téged? Miér’, te marketinges vagy? Nem? Naugye, hát azért.”

Hebeghet az ember kicsit, hogy dehát a szoftverfejlesztés nem ilyen, meg hogy ez csak egy becsült költség, de sajnos nem mindenkinek vannak olyan megértő felettesei vagy megrendelői, akik ezekre a finomságokra nyitottak lennének. Belengetik a korbácsot, te meg hevesen bólogatva iszkolsz a csapatodhoz közölni az örömhírt, hogy már megint jobban tudta nálatok valaki, mikorra mit mennyiért kell megcsinálnotok.

Bele lehet persze keseredni a dologba, és  fásultan várni a teljesíthetetlen határidőt, de van ennél jobb megoldás, kiút a csapdából: nem egyszerű, de ki lehet belőle mászni győztesen!

Azon nem érdemes egy percig sem gondolkozni, hogy vajon megcsinálható-e a fix feltételek mentén a projekt, mert nem csinálható meg. Illetve úgy biztosan nem csinálható meg, hogy mindenkit tökéletesen és maradéktalanul kielégítsünk a megoldással. Mi akkor a teendő, hogy projektünket azért legalább többé-kevésbé sikeresnek nevezhessük a végén? Vizsgáljuk meg a három fix paraméterünket, az árat, a határidőt és a terjedelmet egyenként, és meg fogjuk találni a megoldást!

A határidő
A határidő egy viszonylag könnyen érthető dolog: az évek, hónapok és napok egymásutániságát már 8 éves korában felfogja egy átagos képességekkel megáldott ember. Sajnos ez azt is jelenti, hogy nagyon könnyű észrevenni, ha a projektünk nem szállít időre. Lehet egy ideig magyarázni, hogy persze rajtunk kívül álló okok miatt, meg a másik a hibás hogyrohaggyonmeg, de az időhúzásos taktikával általában csak késleltetni tudjuk a tragédiát. Nincs mese, a határidővel nem nagyon tudunk játszani, más megoldást kell keresnünk ha boldog megrendelőre vágyunk.

A költség
A pénz mennyisége, illetve elfogyás ténye szintén nem egy túl bonyolult dolog: vagy elfogyott, vagy nem. Ha elfogyott és újra kérünk, akkor az biztosan megint el fog fogyni. Aztán megint kérni kell. Aztán az is elfogy. És így tovább, ki tudja meddig. Van ennél idegesítőbb dolog, amikor annyi minden másra is el lehetne költeni azt a pénzt az informatika helyett? Például masszázsfotelekre a menedzsmentnek, vagy egy rohadt nagy tengervizes akváriumra lila tengeri csigákkal. Érezzük ugye, hogy van fontosabb dolog a projektünknél: ne feszítsük hát a húrt a büdzsé terén.

A szkóp
Vagy más néven terjedelem: ez egy sokkal-sokkal kifinomultabb és komplexebb dolog, mint az előző kettő. Arról van ugye szó, hogy mit is tudjon a rendszer, amit megvalósítunk. Hogy hol érjen véget, mit oldjunk meg benne, és mit ne. Ennek a tulajdonságnak nincs semmilyen mérőszáma, és nem is írható le egyszerűen, nagy szerencsénkére! Minimum egy sokoldalas dokumentum kell ahhoz, hogy definiáljuk a projekt szkópját pontosan, de sokat írni fárasztó, ezért a sok tíz- meg százmilliós projektek terjedelmének meghatározása általában ilyesmi szokott lenni:

1. Automatizálja széles körűen a könyvelést
2. Kezelje a felhasználók adminisztrációját
3. Váltsa ki a papír alapú szerződéskötést

Ez egzakt? Ez pontos? Dehogy is! Ezeket ezerféleképpen lehet értelmezni, hála legyen a Teremtőnek! Azt ellenőrizni, hogy a tervezett funkcionalitást szállítja-e a projekt, bizony nem annyi, mint összehasonlítani két dátumot vagy pénzösszeget.

Itt rejlik hát a dolog nyitja, figyeljetek, a megoldás a három fix problémájára a következő:

Ha fix áron, határidőre és terjedelemben kell szoftvert szállítanod, akkor az a feladatod, hogy az adott határidőre és pénzből csinálj valami értelmeset, és a végére győzd meg a megrendelőt, hogy jó lesz neki az, amit kapott.

Ez azért nem annyira nehéz, mint amilyennek tűnik, legközelebb meg is mutatjuk, hogyan érdemes ezt csinálni!