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...