Vízió - a projekt céljának meghatározása

Egy fejlesztési projekt elindítása előtt a legfontosabb feladat a valós üzleti cél meghatározása. Ez meglehetősen triviálisnak hangzik, ugyanakkor igen ritkán lehet találkozni világos célmeghatározásokkal. A tapasztalatom az, hogy az üzleti megrendelők sokkal több időt fordítanak a követelmények definiálására, mint a projekt céljainak meghatározására. Ez a projekt elején nem tűnik túl nagy problémának, viszont a megvalósítás során, amikor az összegyűjtött követelmények kielégítéséhez szükséges ráfordítások láthatóan messze meghaladják a rendelkezésre álló kereteket, valami alapján priorizálni kell. Ekkor jönne jól világosan látni a célokat. A projekt indítását minden esetben egy világos víziónak kellene megelőznie. A vízió kialakításához nyújtanak segítséget a következő kérdések.

Mit fogunk csinálni?

Próbáljuk meg megfogalmazni néhány mondatban, hogy mi lesz a projekt eredménye! Például: interneten elérhető biztosítási alkusz szolgáltatást fogunk megvalósítani, mely lehetővé teszi az ügyfelek számára, hogy egyetlen információs forrásból tájékozódhassanak az összes biztosító, összes biztosítási termékéről. A szolgáltatáson keresztül az ügyfelek összehasonlíthatják az azonos célú biztosítási termékek kondícióit, kiválaszthatják a számukra legkedvezőbbet és azonnal szerződést is köthetnek.

Miért indítjuk el a projektet?

Fontos, hogy meg tudjuk határozni, hogy nekünk, akik beruházunk ebbe a fejlesztésbe mi a célunk. Fontos, hogy ne keverjük a különböző érintettek érdekeit! Mi, akik áldozunk arra, hogy időt és pénzt fordítunk erre a projektre mi a célunk? Például: a piaci verseny növekedésével a biztosítási szolgáltatások értékesítésén realizálható árrés folyamatosan csökken. Annak érdekében, hogy a cég nyereséget növelni tudjuk, jelentős ügyfélszám növekedést kell elérnünk, ami a jelenlegi személyes értékesítői bázissal nem lehetséges...

Kik számára készítjük?

Fontos, hogy be tudjuk azonosítani azt a kört, akik számára a szolgáltatás értéket fog teremteni. Például: azoknak, az átlagosnál magasabb jövedelmű, elfoglalt magánszemélyeknek nyújtunk szolgáltatást, akik számára fontos, hogy biztosítási ügyleteiket a nap 24 órájában intézni tudják. Itt nem magunkra kell gondolnunk, azt, hogy nekünk miért érdemes belevágni a projektbe, már meghatároztuk az előző kérdésben. A termék szolgáltatásainak célcsoportjának jó meghatározása számtalan termékjellemző kialakításában segít.

Mi fog megváltozni, ha végzünk?
Általában minden beruházás érdekében valamiről le kell mondanunk (például pénzről). Ezt azért vagyunk hajlandóak megtenni, mert a jelenlegi állapottal elégedetlenek vagyunk. Fontos, hogy meg tudjuk határozni, hogy mi a problémánk a jelenlegi helyzettel. Min akarunk változtatni? Például: a jelenlegi szolgáltatás szerkezete olyan, hogy a biztosítási ajánlatok a biztosítók szerint vannak rendezve, ezért az ügyfeleknek minden biztosító ajánlatait végig kell nézniük ahhoz, hogy megtalálják a számukra legkedvezőbbet. Sokszor olyan biztosítók ajánlatait is végig kell nézniük, akik az általuk keresett terméket nem is kínálják. Mivel a keresés időigényes és kényelmetlen, a látogatottsági statisztikák alapján a látogatók 90%-a 2 perc böngészés után elhagyja az oldalt. Az új szolgáltatás bevezetése után másfél percen belül releváns ajánlatokat fogunk tudni nyújtani az ügyfeleknek.

Mi szolgáltatja az értéket?

Meg kell tudnunk határozni azt, hogy a projekt milyen érzékelhető előnyöket fog biztosítani az érintettek számára. Ilyen érték lehet például az, hogy a felhasználók számára garantáltan másfél percen belül releváns ajánlatot tudunk biztosítani. Ha jól meghatároztuk a célcsoportot (pl. elfoglalt emberek), akkor könnyebb a legfontosabb termékjellemzőket beazonosítani.

Honnan tudjuk, hogy végeztünk?

A fejlesztési projektek egyik jellemzője, hogy mindíg lehetne jobb az elkészült termék. Valamikor azonban mégis élesbe kell állítani. Mikor legyen ez a pont? Meg lehet határozni akár több mérföldkövet is, a lényeg, hogy definiáljuk azokat a kritériumokat amiknek meg kell felelnie a terméknek amikor a felhasználók számára elérhetővé tesszük. Például: a termék első verzióját akkor állítjuk élesbe, amikor az életbiztosításokhoz kötődő összes terméket képes kezelni és sikeresen végrehajtottuk rajta az 1000 felhasználót szimuláló teljesítménytesztet, valamint az 50 fő bevonásával végrehajtott használhatósági tesztet.

A fentiek természetesen csak kitalált példák, de reményeim szerint segítenek megérteni, hogy miért tartom annyira fontosak a valós célok pontos meghatározását. Azon túlmenően, hogy segít a valóban fontos követelmények meghatározásában, ez a legjobb módja annak, hogy a projektet megvalósító team kreativitását kiaknázzuk. Ha mindenki számára világos, hogy miért kezdtük el a fejlesztést, a legváratlanabb forrásokból kaphatunk remek ötleteket. A vízió meghatározása és jó kommunikálása a legjobb módja annak is, hogy a ki nem mondott (tacit) elvárásokat "kitalálják" a rendszer megvalósítói.

Valós projekt sikerkritériumok

A leggyakoribb kérdésem a projektmenedzserek és az ügyfeleink felé egy projekt elindításakor, hogy "mitől fogod úgy érezni, hogy sikeres volt a projekt?". Ez nyilván nagyon általános kérdés és csak arra jó, hogy elindítson egy párbeszédet a projekt valós céljainak pontosabb meghatározásához. /Ez a projekt vizionálás kezdete, ami egyébként önmagában megér egy bejegyzést./ Ez mindíg a szépreményű kezdeti időszak témája. Ahogy a projekt halad előre, és a realitás könyörtelenül megmutatja magát egyre inkább ez a kérdés kerül előtérbe: "mi a fontosabb?". Ambler W. Scott "véletlenül" erről a kérdésről is rendelkezik adatokkal, ami igencsak elgondolkodtató a módszertani kérdések szempontjából. A felmérés során közel 600 válaszadó véleményét vette figyelembe, olyanokét, akik különböző IT projektek kulcsszereplői. A kérdés központi témája ez volt: hogyan definiáljuk a sikert?

Ebben a bejegyzésben erősen a saját szemüvegemen keresztül foglalom össze az eredményt, ezért akit mélyebben érdekel a téma, annak érdemes az eredeti cikket elolvasnia.

Én kifejezetten az üzleti megrendelők által megfogalmazott prefernciákra fókuszáltam, elvégre az ő igényeik kielégítése miatt dolgozunk. A grafikonból látszik, hogy a válaszadók döntő többsége fontosabbnak tartja az aktuális üzleti célok elérését, mint a projektterv betartását. Számomra a következtetés elég egyértelmű: mindaz, amire a kezdeti követelményspecifikáció, és testvérei (funkcionális specifikáció, részletes projektterv stb.) koncentrálnak, valójában nem a legfontosabb kérdések. Ezzel persze nem azt állítom, hogy teljesen értelmetlenek ezek a prediktív projekttermékek, mindössze arra szeretném felhívni a figyelmet, hogy a helyükön kell őket kezelni. Ezek ugyanis végsősoron csak eszközök, amiket nagyon okos emberek arra találtak ki, hogy rendszerezett módon megjelenítsék a projekthez kapcsolódó fontos információkat. De nem szabad hagyni, hogy eltereljék a figyelmet a lényegről, ami a működő, valós célokat támogató, használható rendszer.

Előzetes követelményelemzés

Az előzetes követelményelemzést gyakorlatilag az előrejelezhetőség iránti jogos igényünk miatt alkalmazzuk. Végsősoron logikus feltételezés, hogy ha tudom azt, hogy mire van szükségem, akkor el tudom képzelni, hogy azt hogyan valósítom majd meg. Ezt az elképzelést aztán konkrét tervekké tudom formálni, amikből előrejelezhetem a projekt várható pénzügyi és egyéb kereteit. Annak érdekében, hogy az előrejelzésem a lehető legpontosabb legyen, annyi információt próbálok begyűjteni a megvalósítandó rendszerről, amennyit csak lehet. Ez a gondolat motiválja az új szoftver kifejlesztése és bevezetése előtt álló szervezeteket arra, hogy a projektet megelőzően hónapokat, akár éveket töltsenek a követelmények részletes meghatározásával. Nem egy olyan projekttel találkoztam, ahol az előkészítési fázis elvitte a projektre rendelkezésre álló idő felét, vagy akár kétharmadát is. A probléma ott van, hogy ezzel alig jutottak közelebb az összehasonlítható ajánlatokhoz, vagy a pontosabb becsléshez. Az előrejelzhetőségről szóló előző bejegyzésemben ennek a hátteréről írtam.

Ha az előzetes követelményelemzés hasznát vizsgáljuk, az eredmény sajnos még ennél is kiábrándítóbb. Nemcsak, hogy nem jutunk sokkal közelebb a projekt kereteinek megbecsléséhez, de még abban sem lehetünk biztosak, hogy az elvárásainkat kellő alapossággal megismertük. A Standish Group által közölt "Chaos report" ebben a kérdésben is elgondolkodtató eredményre jutott. Azt vizsgálták, hogy az előzetes követelményelemzés alapján fejlesztett rendszerek funkcióit milyen arányban használják a valóságban. (Részletesebben Ambler W. Scott ír a témáról) A jelentés konklúziója elég nyilvánvaló:

• Az elkészült funkciók közel 2/3-át soha, vagy nagyon ritkán használják
• A gyakran, vagy állandóan használt funkciók az összes szolgáltatás 20%-át teszik ki

Ez az eredmény pénzügyi szemléletre fordítva azt jelenti, hogy az előzetes követelményspecifikáció alapján fejlesztett rendszerekre fordított költségek legalább fele teljesen kidobott pénz, azaz tiszta veszteség. Megítélésem szerint a veszteség még ennél is nagyobb, ugyanis a követelményspecifikációban rögzített, de nem megvalósított funkciók különböző tervekben történő részletes kidolgozásának költségei itt nem látszódnak.

Ez a pazarlás egyébként kódolva van a bemerevített (prediktív) szoftverfejlesztési módszertanok alkalmazása során. Mivel a szállító kötve van a szerződésben vállalt költség és időkeretekhez, ezért erős változáskezelési eljárásokat alkalmaz annak érdekében, hogy a követelményspecifikációban megfogalmazott funkciókon kívül semmi új ne kerülhessen a projekt szkópjába. Ezt a megrendelő nyilvánvalóan csak úgy tudja kezelni, ha a követelményspecifikációban minden elképzelhető igényt rögzít. Olyanokat is, amikre egyébként nincsi is szüksége. Ki tudja, még jól jöhet... A változáskezelési eljárások alkalmazásának van még egy kellemetlen hatása: a megrendelőt távol tartja attól, hogy a később felismert (esetleg fontos) igényeit beépíthesse a rendszerbe.

A tervezhetőség csapdája

A fix árú, részletes követelmény-specifikációval lefedett szoftverfejlesztési projektek többnyire kudarccal végződnek. Régóta foglalkoztat az a kérdés, hogy ez a kudarc eleve kódolva van abban a megközelítésben, amikkel a fejlesztéi projeketeket kezeljük, vagy egyszerűen csak ilyen gyakran követünk el hibákat a projektek megvalósítása során. Én azt gondolom, hogy az első állítás van közelebb a valósághoz. Ambler W. Scott írt egy kiváló cikket erről a témáról "Is Fixed-Price Software Development Unethical?" címmel. A bejegyzésben alapvetően az említett cikkben leírt gondolatmenetet követem, némileg átfogalmazva és részben átstrukturálva.

Fontos leszögezni, hogy semmi probléma nincsen a fix költségvetésű projektekkel. A költségvetési keret rögzítése üzletileg indokolt, racionális és minden szempontból elfogadható. A probléma ott kezdődik, amikor a termék jellemzőit, a fejlesztés árát és a határidőt egyszerre rögzítjük, azaz a projektet bemerevítjük. Ez ugyanis a projektet minden rugalmasságától és adaptivitásától megfosztja, a feleket bizalmatlan légkörbe taszítja és végső soron drasztikusan növeli a projekt kockázatát.

Miért kell a rögzíteni a projekt jellemzőit?

A megrendelő szempontjából a projekt-parmétereinek bemerevítésének több, önmagában elfogadható és magyarázható oka van. Ezek közül a legfontosabbak az alábbiak:

• A projekt pénzügyi kockázatának csökkentése. A megrendelők gyakran gondolják, hogy ha a fejlesztő céget egy fix árú, fix követelményrendszerű szerződésbe kényszerítik, akkor a projekt pénzügyi kockázatát a fejlesztőre háríthatják.
• Összehasonlíthatóság, és a legjobb ajánlat kiválasztása. A követelményspecifikációról azt gondolják, hogy megteremti az ajánlatok összehasonlíthatóságát, ezáltal lehetővé teszi, hogy a legelőnyösebb ajánlatot választhassák ki.
• A beszállító kényszerítése a maximális teljesítményre. Azáltal, hogy az ajánlattevő fejlesztő cégektől megvalósítási terveket kér be, a megrendelőnek elvileg lehetősége van arra, hogy ezeknek a terveknek a betartására kényszerítse a vállalkozót. Ettől azt lehet várni, hogy a fejlesztő cég minden tőle telhetőt megtesz annak érdekében, hogy projektet a legjobb tudása szerint leszállítsa.
• Az árak csökkentése. Azáltal, hogy "ugyanarra" a termékre több ajánlattevőt versenyeztet meg, árversenyt generálhat, melyben a lehető legalacsonyabb szállítási árat érheti el.
• Költségvetés tervezés. A részletes, követelmény-specifikáció alapján készített árajánlatok lehetővé teszik, hogy a megrendelő éves költségtervet készítsen az IT projektekre vonatkozóan, mivel a projekttervekben jól láthatóak a fizetési mérföldkövek, illetve az azokhoz kapcsolódó fix kiadások.

Összességében tehát a rendszerfejlesztési projekteket megelőző követelmény rögzítési és tervezési szakasz célja a pénzügyi és funkcionális tervezhetőség megteremtése, a versenyhelyzet megteremtése a legjobb ajánlat kiválaszthatóságának érdekében, valamint a beszállító kényszerítése a maximális teljesítményre. A tradicionális projekt megközelítés alapján ennek a legjobb módja logikusan a követelmények rögzítése és a részletes tervek elkészíttetése és betartatása. Ezek mögött végsősoron minden esetben a bizonytalanságtól való félelem áll.

Néhány szomorú tény a tervezhetőségről...

A Standish Group rendszeresen közzéteszi "Chaos report" nevű jelentését, amiben a szoftverfejlesztési projektek eredményeit vizsgálja. Ezek alapján az derül ki, hogy a szoftverfejlesztési projektek mindössze 31%-a fejeződik be határidőre és költségkereten belül. További rossz hír, hogy a fejlesztési projektek átlagos költsége az eredetileg becsült 189%-a. (Még rosszabb hír, hogy a projektkeretek túllépésének szórása igen nagy, tehát azt sem mondhatjuk, hogy valamilyen együtthatóval fel lehet szorozni az eredeti becslést annak érdekében, hogy a valós értékhez közelebb jussunk.) Ez jó példája annak, hogy a prediktív megközelítés elfogadhatatlanul nagy hibaszázalékkal dolgozik. Mi lehet ennek az oka?

• A formális becslési modellek (COCOMO I/II, Function Points stb.) alapja, hogy egy formális követelményspecifikáció alapján meghatározzuk a rendszer komplexitását, szkópját. Ezekből az információkból méretezési alapadatokat képzünk, melyekhez a korábbi tapasztalataink valamilyen ráfordítási mérőszámot rendelünk. Ezekeket a méretezési értékeket valamilyen mágikus képletbe helyezzük, ami megadja a projekt várható ráfordítási adatait. Mivel a különböző fejlesztő cégek eltérő tapasztalati alapokkal rendelkeznek, kicsi az esélye annak, hogy hasonló eredményre jutnak. (Nem beszélve arról, hogy a követelményspecifikációk értelmezése is meglehetősen különböző lesz.) A lényeg tehát az, hogy bármilyen mágikus formulát is alkalmazunk, a kiinduló értékek feltételezéseken és eltérő tapasztalatokon alapulnak. A képletek alkalmazása annyiban rontja a helyzetet, hogy abban az illúzióban ringat, hogy "tudományos" alapokon nyugszik a becslésünk.
• Egy megdöbbentő tanulmány (Chris Kemerer: "An Empirical Validation of Software Cost Estimation Models" ) mutatott rá arra, hogy a fejlesztő csapat számára új üzleti domain esetén a "tudományos" becslési módszerek hibaszázaléka 85% és 772% (!!) között mozog, amelyek közül sok a 600% körüli tartományban van. (Az, hogy a projektek nagy része nem szenved ekkora költség-túllépést, sokszor a kezdeti követelmények projekt közbeni elhagyásával, vagy megváltoztatásával magyarázható.)
• Ambler W. Scott számos további tanulmányra hivatkozik, melyek mind alátámasztják, hogy a "tudományos" becslési módszerek alapja továbbra is az egyszerű szakértői becslés, melynek pontosságát az alkalmazott képletek és módszerek nem befolyásolják.
• Nem mindenki egyenlő. Barry Boehm /Software Cost Estimation with Cocomo II (Addison-Wesley 2000)/ szerint a legjobb és a leggyengébb fejlesztő közötti különbség a produktivitás terén 1-10 arányú. Ebből az következik, hogy ha nem tudjuk pontosan, hogy milyen fejlesztőkből áll a megvalósító csapat, akkor a megalapozott, tapasztalati becslési modellek sem vezethetnek közel megbízható eredményre sem.

A tervezhetetlenség következményeiről a következő bejegyzésben írok majd...