De mennyibe fog kerülni a fejlesztés?

“Jó, de mennyibe fog kerülni a teljes fejlesztés? Nem értem, hogy miért nem tudjátok megmondani, hiszen Ti vagytok a fejlesztő cég. Itt van, hogy mit szeretnék, le is írtam 15 oldalban, ott van minden feketén-fehéren…
Mennyi idő lesz, és milyen költségekkel fog járni?”

Hogyan lehet feloldani a helyzetet, mikor a megrendelő szeretné tudni, mennyit is fog fizetni a szoftverért? Illetve a másik oldalról pedig egy komplex rendszer fejlesztése előtt áll a fejlesztő cég, és pontos összeget (időt) nem tud mondani, csak tartományt.

Hogyan kezeljük a kialakult helyzetet? Nézzük meg pár pontban, milyen kapaszkodóink vannak.

• Tartsunk az ügyfélnek egy fejlesztési módszertani workshopot, ahol bemutatjuk az iterációs alapokon történő fejlesztési módszertant, összevetve a vízesés jellegű fejlesztési szemlélettel.
• Amennyiben a projekt kivitelezése (vagy a Megrendelő) a vízesést követeli meg, fektessünk erőforrást részletes specifikációba. Ebben az esetben viszont szigorú szabályokat állítsunk a CR, nem CR kérdéskör kapcsán. Ebben az esetben fontos, hogy az ügyfél is tisztában legyen azzal, hogy a tervezési folyamat is költséggel fog járni, ami egy markánsabb rendszer esetében egészen fájó is lehet.
• Amennyiben agilis szemlélettel megyünk tovább, abban az esetben tisztázzuk, hogy a fejlesztés egészére kevésbé, a kisebb iterációkra viszont lehet időbecsléseket alapozni. A teljes scope dinamikusan változhat, külső/belső/üzleti tényezők változásával.
• Mutassuk be a microservice vs. monolit rendszerek előnyeit, hátrányait rövid- és hosszútávon szakmailag, pénzügyileg. Miért lehet előnyös az agilis szemlélet és a microservice architektúra, hogyan egészítik ki egymást?
• Legyen egy erős input. A projektek kudarca többször köszönhető a rossz inputnak, mint magának a fejlesztésnek. A megrendelő sokszor nem tudja, valójában mit szeretne, vagy legalábbis nem tudja jól átadni. Ezért szükségünk lesz egy remek üzleti logikával rendelkező, IT- szemléletű Product Ownerre és Architectre is, akik már a sales/tervezési fázisban segítenek a projekt felmérésében és valódi méretének meghatározásában.
• A becslés esetében két utat választhatunk.
  Amennyiben vízesés szemlélet mellett döntünk, minden részletet a lehető legaprólékosabban kell definiálnunk, így egy kész, mindkét fél számára elfogadott specifikációval felvértezve kezdhetjük meg a munkát. (Amely feltételezhetően módosulni fog.)
  Agilis személettel haladva nagyságrendi becslésekkel, eposzokkal, és ahol érdemes, már storykkal látunk hozzá a feladatokhoz. Ez esetben érdemes használni a hárompontos becslés rendszerét, ahol pesszimista, realista és optimista szempontból a feltételezéseket és a kockázatokat is kalkuláljuk.
• Kérdezzük meg a Megrendelőt, hogy valójában számára miért fontos, hogy egzakt összegeket, elkészülési időt kapjon. (Triviálisnak tűnik, de sok felesleges kört meg lehet spórolni azzal, hogy megértjük a hátteret.)
• Érdemes tisztázni, hogy mi az a minimum funkcionalitás, ami már elégséges az induláshoz. Az MVP fogalma nem újdonság, ne felejtsük ki az eszköztárunkból.
• Előfordulhat, hogy bármennyire is kecsegtető az üzleti lehetőség, és megvan a kémia is a két fél között, a megrendelő fix költségeket szeretne egy olyan rendszerre, amire öngyilkosság lenne fixet mondani. Ebben az esetben tudni kell nemet is mondani.
  A fejlesztő belemehet abba a játékba, hogy fix összeget (időt) mond a kivitelezésre. Ebben az esetben legtöbbször vagy megrendelői, vagy fejlesztői, vagy mindkét oldalon valaki sérülni fog a projekt során. (Feltéve, ha nincs nagyon túlárazva a rendszer.)

Mi az, ami szerintünk a legjobb mindkét félnek? 

• Tapasztalataink alapján az agilis fejlesztéssel a legkönnyebb a végterméket adott költségkereten belül tartani a legtöbb funkció kivitelezésével. Lássuk be, a vízesés modell során mindkét fél rengeteg időt és energiát fordít arra, hogy minden a végletekig le legyen specifikálva, és ezzel “bevédjék” magukat. Az agilis fejlesztés során ez az energia- és munkamennyiség a projektre fordítódik.
• Mindemellett maga a vízesés folyamat ellentéteket szül. Ezt egyszerű belátni, hiszen a megrendelő érdeke, hogy az adott fix árért minél több minden benne legyen a szoftverben, a kivitelezőé pedig, hogy minél kevesebb munka befektetésével érje el azt, ami specifikálva lett. Ezzel szemben az agilis fejlesztés során a Product Owner – lehetőség szerint a megrendelő oldaláról biztosított személy, aki a projekt érdekeit tartja szem előtt – a csapattal megvitatva dönti el, hogy egy adott funkció mennyi munkabefektetést ér. Szinte minden feladatra van több megoldás, nem mindig egyértelmű, hogy a megrendelő fejével gondolkodva melyiket válasszuk, mi a legfontosabb a hosszútávú tervek figyelembe vételével – melyekről sok esetben nem is biztos, hogy tudomása van a kivitelezőnek.
• És még nem is említettük az egyik legfontosabb kérdést: vajon mindenre gondoltunk az elején? A válaszon nem érdemes sokat gondolkodni, hogy az agilitás a legjobb választás. A feladatok folyamatosan, a projekt előrehaladásával kerülnek pontosításra, ha van olyan funkció, ami az alapvázat ismerve nem olyan fontos, akkor simán kihagyhatjuk, és helyette kivitelezhetünk valamit, ami útközben jutott eszünkbe. A kapcsolattartás folyamatos, megrendelő folyamatában látja a termékét kialakulni, így a visszajelzésre is folyamatosan lehetősége van. Ha nagyon nem jó az irány, nem tud a két fél együttműködni, akkor még idejében le lehet állítani a projektet. A vízesés módszertan során egy dokumentum alapján 2-3 hónap múlva kap valamit a megrendelő, ami aztán vagy olyan , mint amilyennek elképzelte, vagy nem. Jó eséllyel nem – ennek számos oka lehet, a leggyakoribb az “erre nem gondoltunk” – és még jó pár módosítási körre szükség van ahhoz, hogy használni is tudja a rendszert.
• “Jó, értem, tényleg sokkal jobbnak hangzik az agilis módszertan, de félek, hogy a napi- vagy óradíjban számlázással nagyon el fog csúszni a költség” – szokták mondani a megrendelők. Az első lépés az legyen, hogy olyan kivitelezőt keresel, akiben megbízol. Egy funkciólista alapján egész pontosan meg lehet becsülni egy projektet, ha a kivitelező tapasztalt, és már számos hasonló szoftver elkészítésén túl van. Onnantól a Product Owner feladata, hogy a költségkereten belül maradjon, és igen sok múlik egy jó PO-n. Statisztikáink alapján az agilis projektek többször készülnek el költségkereten belül maradva, lényegesen nagyobb ügyfél-elégedettséggel.