Döntéselmélet és szoftverfejlesztés

Egy szoftverfejlesztési projekt számtalan ponton képes elbukni, de ezek közül a legfontosabbnak a projekt céljainak hibás meghatározását tartom, ami végső soron a helytelen követelménykezelés következménye. Sok irodalmat olvastam fejlesztési módszertanokról és az ezekhez kapcsolódó követelményelemzési, specifikációs technikákról, de valahogy egyiknél sem volt az az érzésem, hogy a problémák gyökerénél járok. Néhány évvel ezelőtt hallgattam Dr. Baracskai Zoltán előadásait a döntéstanról egy MBA kurzuson. Nagyon erőteljesen hatottak rám a gondolatai, de nehezen találtam a kapcsolatukat a gyakorlattal. Később, amikor elkezdtem agilis fejlesztési módszertanokkal foglalkozni, valahogy kezdett kialakulni bennem egy kép a döntéstan és a szoftverfejlesztési projektek kapcsolatáról. Ma azt gondolom, hogy a döntéstan mindenképpen sokat segíthet a szoftverfejlesztési projektek követelménykezelési problematikájának megértésében és kezelésében. Miért gondolom így? Az alábbiakban a döntéselmélet néhány kérdését mutatom be Dr. Baracskai Zoltán és Velencei Jolán Üzleti döntések c. jegyzetére alapozva, remélve azt, hogy a felvezetés után a kérdésre kialakul a válasz az olvasóban is…
A döntési helyzetekben a legfontosabb feladat az elvárásaink kialakítása és definiálása. A döntési helyzet akkor nehéz, ha ezek nem pontosan ismertek. Az, hogy mennyire vagyunk nehéz döntési helyzetben, a problématerület strukturáltságán múlik. A döntési probléma lehet jólstrukturált vagy rosszul strukturált. A jólstruktkrált feladat jellemzője, hogy elvárásaink világosak és létezik ellenőrizhető, helyes megoldása. Ezek nem feltétlenül egyszerű feladatok, a lényeg, hogy számításokkal és kereséssel megoldhatók és ellenőrizhető a helyességük (pl. ügyfélfogadási rend kidolgozása). Az eredmény a jó megoldás.

Rosszul strukturált problémakörben inkább döntési dilemmáról, vagy problémamegoldásról lehet beszélni. A döntési dilemma esetén meglévő választási lehetőségek közül kell kiválasztanunk azt, ami ott és akkor a legjobbnak tűnik, azaz megfelel az elvárásainknak. (Ilyen pl. egy jelölt kiválasztása egy adott pozícióra.) Az eredmény az elfogadható megoldás, tehát nem tudjuk meg, hogy létezett-e jobb alternatíva, csak azt, hogy amit választottunk kielégíti-e az elvárásainkat. A probléma egy másik kategória. Itt nincsenek döntési alternatívák csak egy helyzet, amivel elégedetlenek vagyunk. A dolgunk ebben az esetben valami újnak a megalkotása, nem pedig döntés. A hagyományos „problémamegoldás” fogalom itt félrevezető lehet, a problémának nincs egy megoldása, én inkább elhárításnak, vagy elkerülésnek nevezném, melynek az eredménye egy elképzelés a dolgok újszerű, jobb működtetéséről. A szoftverfejlesztési projektben a technológiai döntésektől eltekintve túlnyomó részt problémákkal és döntési dilemmákkal találkozunk. Érdemes ezért tovább vizsgálódni, hogy mit mond ezekről a kérdésekről a döntéstan.

A követelmények kezelésének újfajta megközelítéséhez juthatunk a racionalitás kérdéskörének vizsgálatával. A menedzsmentben és általában az üzleti életben szeretjük azt gondolni, hogy racionális döntéseket hozunk, azaz jól ismerjük a céljainkat, lépéseink következményeit előre látjuk, az alternatívákat ismerjük, és ki tudjuk számítani a döntéseink eredményét. Ehhez általában modelleket építünk, melyek a valóság leegyszerűsítései és érvényesek rá a racionalitás követelményei (jól strukturált, megismerhető világ, érvényes szabályok, minden eleme mérhető stb.) és ebben a modellben keressük a megoldást. Máshogy mondva megpróbáljuk a problémákat és a dilemmákat megoldható (és ellenőrizhető) feladattá egyszerűsíteni. A kérdés az, hogy tudunk-e olyan modellt alkotni, melyben érvényesek a racionalitás szabályai és a modellben kialakított megoldások működőképesek maradnak a valós világban is? A korlátozott racionalitás elképzelése azon alapul, hogy a döntéseinkhez nem tudjuk megszerezni az összes szükséges információt és megismerni az összes szabályt, sőt még olyan használható, leegyszerűsített modellt sem tudunk alkotni, ahol a racionalitás követelményei teljesülnének, más szóval nem tudunk tökéletesen racionális döntéseket hozni. Ha ez így van, akkor talán nincs is értelme egy leegyszerűsített modellben keresni a tökéletes megoldást. Akkor viszont hogyan döntünk ilyen helyzetekben? A válasz az opportunista keresés. Az opportunista keresés során a döntési helyzeteknek valamilyen kezdeti elvárásokkal, igényekkel indulunk neki. Fogalmunk sincs róla, hogy az összes elvárásunkat ismerjük-e, és amiket megfogalmaztunk azok valójában a legfontosabbak-e. A megoldáskeresés során újabb és újabb megoldási ötletekkel találkozunk, melyeket mérlegelünk, és ezeket vetjük össze a kezdeti elvárásainkkal. E tevékenység során folyamatosan alakulnak az igényeink, mégpedig a megoldási alternatívák megismeréséből szerzett tapasztalatok hatására. A legtöbbször az elvárásainkat csak a folyamat végén tudjuk megfogalmazni, de a kifogásokat az alternatívákkal szemben sokkal hamarabb látjuk. A keresést akkor hagyjuk abba, amikor az éppen vizsgált megoldással szemben nincsenek már lényeges kifogásaink. Innentől nincs értelme tovább keresni, mert az eredmény maximum egy másik olyan megoldás lenne amivel szemben szintén nincsenek kifogásaink.

[Mindannyian így okoskodunk, legföljebb eddig nem tudtunk róla. Évekkel ezelőtt lakást kerestem, azt gondoltam egészen jó elképzeléseim vannak róla, hogy mit szeretnék. A kezdeti elképzeléseim jelentős részét persze feladtam, viszont három olyan szempontra is emlékszem, amikre nem gondoltam az elején, viszont a legfontosabb kritériumokká váltak a látogatásokon szerzett tapasztalatok alapján. Rájöttem például, hogy semmilyen esetre sem akarok lift melletti lakást, mert annak a zaja behallatszik. Ugyanezért nem akarok szemétledobó mellett lakni. Földszinti lakást sem akarok, mert a szemétledobó bűze a meleg nyári napokon beteríti az egész szintet.]

Meggyőződésem szerint az egyedi szoftverfejlesztési projektek túlnyomó része a rosszul strukturált problémakörök kategóriájába tartozik, ahol sem a megrendelő, sem a fejlesztők nem ismerik pontosan az elvárásokat. A vízesés modellek ezzel szemben azt feltételezik, hogy a racionalitás feltételei adottak egy fejlesztési projekt környezetében ezért a követelmények meghatározhatók a fejlesztés előtt. A valóságban ugyanakkor ennek ellenére működik az opportunista keresés jelensége, ezért a fejlesztés során kialakított alternatívák, ötletek hatnak az eredeti elképzelésekre és folyamatosan változtatják azokat. Ez így van rendjén. A kérdés ebben az esetben, hogy nem kidobott pénz-e alaposan specifikálni a tapasztalatok nélküli, hipotéziseken alapuló funkciókat a fejlesztést megelőzően? Nem lenne-e értelmesebb elfogadni azt, hogy az elvárásaink folyamatosan alakulnak a projekt során és ehhez a megváltoztathatatlan körülményhez igazítani az alkalmazott módszertant?