ITÉlet

Csak informatikus lehet az, aki szerint egy 90%-os megoldás megfelelő J

Holden blogján olvastam Határ és határidő cikket. Az egyik megjegyzés különösen érdekes volt:

Matyi Tamás, 2011. 09. 02. 22:30

"...hiába van meg a 95%-a."

Kicsit kötekszem:
Minek a 95%-a? A részletes projektspecifikációnak, ami a szerződés előtt lett hosszasan kőbe (szerződésbe) vésve?

És ha időközben - az elkészült részteljesítések tapasztatai alapján - kiderül, hogy nem is pont arra/úgy van szükség?
Mi a jobb? Egy 100%-os teljesítés, de nem túl jól használható eredmény, vagy egy 90%-os teljesítésű, de az igényeknek leginkább megfelelő megoldás?

Természetesen sokszor igaz, hogy egzakt módon lehet és kell mérni, hogy valami kész van-e, vagy nem.
Azonban - pl. fejlesztési projektek kapcsán - érdemes meggondolni, mit is akarunk a végére elérni ill. mit és hogyan definiálunk, mérünk, követelünk meg hozzá... (lásd pl. iteratív szoftverfejlesztés)

A megjegyzés klasszikus IT szemléletet tükröz, akárki írhatta volna. Az kétségkívül igaz, hogy egy 90%-os, de az igényeknek megfelelő megoldás jobb, mint egy 100%-os de nem használható. Ez olyannyira igaz, hogy még fejlesztési módszertant is építettek rá: Rapid Application Development (RAD).

A RAD előnye a gyorsaság. Minél hamarabb van valami (prototípus, működő szoftver), annál hamarabb tudnak a felhasználók visszajelzést adni. A visszajelzés alapján pedig jobb szoftvert lehet késziteni.

A RAD fontos kiindulási pontja, hogy egy fejlesztési projektben a funkciók nagy részét gyorsan el lehet készteni. Viszonylag hamar lesz működő szoftverünk, viszonylag hamar elérjük az 50%-os teljesítési szintet, illetve innen gyorsan eljutunk a 70% és 90%-ig. A sok munka és idő az utolsó 10%-zal szokott lenni, ez az a rész, amikor a fejlesztők vért izzadnak és hétvégéznek (lásd 90-90 rule). A RAD-ban az az okosság, hogy felgyorsítjuk a 90% elérését, azaz minimálisra csökkentjük az előzetes tervezést és kihagyjuk az utolsó 10%-ot. Elvégre ez egy iteratív folyamat, megcsináljuk a 90%-ot, és a maradék 10%-et majd a következő iterációra hagyjuk. A felhasználók addig úgyis meggondolják magukat, új igények merülnek fel, szóval ne is törjük magunkat – feleslegesen – a 100% megvalósításával.

Jól hangzik, de akkor miért nem mindenki így fejleszt?

Mert két komoly baj is van:

1) A szoftver valójában sosem lesz kész – mindig csak 90%-ot érünk el, hogy utána a következő iterációban szintén csak 90% legyen a cél

2) A gyenge tervezés miatt egyre több architektúrális és minőségi problémánk lesz

Az 1. ponttal szeretnék foglalkozni bővebben.

A mondás úgy tartja, hogy jobb ma egy veréb, mint holnap egy túzok. Azaz jobb ma egy 90%-osan kész, működő szoftver, mint holnap egy 100%-os. A felhasználók örülnek, mindenki boldog… aztán a felhasználók megkérdezik, hogy a maradék funkció mikor lesz kész.

Ugyanis nekik minden funkció kell. Ahogyan Holden írta, a teljesítésnek csak két állapota van: készen van, vagy nincs. Ha 10% hiányzik, az nincs kész.

A valóság az, hogy egy 90%-osan kész szoftverrel a felhasználók nem tudnak sokat kezdeni. Az üzleti célok adottak, és azokat egyszer valamikor 100%-ban el kell érni. Például tegyük fel, hogy a projekt célja egy új autó modell bevezetése, illetve az ehhez szükség változtatások végrehajtása az informatikai rendszereken. Amíg ezek nincsenek készen, addig az új modellt nem tudjuk értékesíteni. Ha a változtatások 90%-ban készen vannak, az azt jelenti, hogy 10% még hiányzik, vagyis az új modell még mindig nem értékesíthető. Ilyen értelemben mindegy, hogy a készültség mértéke 50%, 70% vagy 90%.

Még rosszabb a helyzet olyan fejlesztési projekteknél, ahol a fejlesztésen kívül egyéb üzleti feladatok is vannak, például oktatás vagy üzleti folyamat változás. Egy 90%-ban kész szoftvert nem lehet leoktatni, vagy le lehet, de utána az oktatást meg kell ismételni a 100%-osan kész szoftveren. Az üzleti folyamatok változtatása is kétállapotú: vagy a régit követjük, vagy az újat. Olyan nincs, hogy 90%-ban az újat követjük, de 10%-ban a régit.

(Arról nem is beszélve, hogy a 10%-ot az informatikusok választanák ki, nem az üzleti döntéshozók.)

Mondok egy analógiát: tegyük fel, hogy a közlekedésünket átállítanánk jobboldali közlekedésről baloldalira. Csak 100%-os átállás lehetséges, részleges átállás (90%-os) nem lehetséges. Nem mondhatjuk azt, hogy a személyautók és buszok átállnak és a bal oldalon haladnak, de a teherautókra még nem dolgoztuk ki a szabályokat ezért azok továbbra is a jobb oldalon közlekednek.

Mondok egy analógiát: tegyük fel, hogy álmaink házát építtetjük egy építésszel. Nagyon meglepő lenne, ha a ház 90%-ban elkészül, és az építész késznek minősíti a munkát. Bizonyára nem fogadnánk el késznek és nem költöznénk be. Bizonyára megoldható lenne, hogy a ház 90%-ban kész és beköltözhető – feltételezve, hogy mi választjuk ki a 90%-ot, és nem az építész. De ha be is költöznénk, a maradék 10%-ra is igényt tartanánk, mert hiszen egy teljesen kész házat szeretnénk a birtokunkban tudni.

A tévedés oka abban keresendő, hogy a programozók a készenlétet a specifikációhoz képest mérik, a felhasználók pedig az igényeikhez képest. A kettő nem ugyanaz, és ez jelenti a szoftverfejlesztés egyik, ha nem a legnagyobb kihívását. A felhasználó, a megrendelő fejében pontosan létezik egy kép az elvégzendő munkáról. Számára a munka akkor van kész, amikor a szoftver ennek a képnek 100%-ban megfelel. Nem hamarabb, és nem 90%-ban.

Azonban a kép a felhasználó fejében van, a programozók pedig nem tudnak gondolatot olvasni. Kell egy közbenső kommunikációs eszköz – a specifikáció (vagy nevezhetjük backlog-nak is, mindegy) – ami leírja ezt a képet, és a fejlesztők el tudják olvasni. Különben nem tudnának fejleszteni. A kommunikáció szükségszerűen veszteséggel jár, tehát a specifikáció nem lesz 100%-ban ugyanaz, mint ami a felhasználó fejében van. Arról nem is beszélve, hogy bizonyos részletek lehetnek homályosak, illetve az igények idővel megváltozhatnak.

Mindez úgy csapódhat le a programozóknál, hogy nem érdemes 100%-os készenlétre hajtani, hiszen a végén úgyse az eredeti specifikáció 100%-át kell megvalósítani. Egy igen jó közelítés az, ha megvalósítjuk a nagyját, aztán majd kezeljük a felmerülő igényeket és a különbségeket. Szóval lehet, hogy a végén csak a specifikáció 90%-át valósítjuk meg, de ettől még az üzleti igények 100%-a a cél.

A dolog azért fontos, mert egy adott ponton a programozók pénzt szeretnének látni a munkájukért. A megrendelő pedig általában olyan, hogy a beígért pénz 100%-át csak akkor szeretné kifizetni, ha az igényei 100%-át sikerült kielégíteni. Nem fog akarni fizetni egy 90%-os a teljesítésre.

Éppen ezért bármilyen fejlesztési módszertan, ami a 90%-os teljesítést célozza meg, nem az ügyfél érdekeinek és szándékának megfelelő. Hiába érzi azt az ügyfél a fejlesztés alatt, hogy jobban ki van szolgálva (hamarabb kap működő szoftvert), ha a végén nem készül el a teljes körű megoldás.

Természetesen kivételek vannak, és ezért az ilyen fejlesztéseknek is megvan a helyük.

Egy marketing célú céges web oldal esetén például fontosabb lehet a gyors megjelenés, mint a teljes funkcionalitás. Ha a design megvan és lehet a web oldalon keresztül rendelni, akkor nem baj, ha pár funkció még hiányzik (mondjuk a fórum még nem elérhető). Az ilyen projektekben kimondottan előny, pénzben mérhető üzleti előny, ha minél hamarabb elkészül egy részleges, de már működő megoldás.

Az informatikai projektek túlnyomó része nem ilyen.