Ko smo že omenili, naj bi na odločitev o uporabi tradicionalnega ali agilnega pristopa najbolj vplivala jasnost opredelitve končnih ciljev na začetku projekta in s tem povezana (ne)rutinska izvedba projekta, dodaten pomemben dejavnik pa je možnost koriščenja vmesnih rezultatov in s tem povezane dodane vrednosti, ki jo prinaša projekt. Ta naj bi pri agilnem pristopu rasla ves čas trajanja projekta, pri tradicionalnem pa dodano vrednost prinese šele povsem zaključen projekt.
Ker našteti dejavniki vplivajo na možnost jasne ocene (opredelitve) časa in stroškov izvedbe, ki skupaj z obsegom (ki naj bi bil pri agilnih projektih manj natančno opredeljen) predstavljajo ključne postavke pogodbe med naročnikom in izvajalcem, potem je jasno, da se tradicionalne pogodbe zelo težko uporabljajo za agilne projekte. Razlika v »jeklenih projektnih trikotnikih« (obseg, čas, stroški) je lepo prikazana na prvi sliki, pri čemer bi opozoril na trditev avtorjev, da agilni pristop temelji na viziji projekta, kar bi pomenilo, da sledi predvsem dodani vrednosti, ki jo prinaša projekt.
Ena od oblike pogodb, ki poudarja usmerjenost v ustvarjanje koristi, je, da se pogodba ne podpiše za celoten projekt, ampak za vsako fazo posebej, cene pa se opredelijo na osnovi dodane vrednosti rezultatov faz. Faze načeloma niso cikli (sprinti), ampak več teh skupaj (pri IT projektih je npr. cilj faze izdaja (ang. release) nove verzije programske opreme z dodatnimi funkcijami). Ta tip pogodbe je lahko del obsežnejše več-nivojske pogodbe, kjer se pogodbeni odnos doreče z več dokumenti – v glavnem so dorečene zadeve, ki se ne spreminjajo (npr. garancije, arbitraža); zadeve, ki se lahko spreminjajo (npr. cene storitev, opisi izdelkov) se opredelijo v terminskem planu storitev, dinamične postavke, kot so obseg, časovni razpored in proračun, pa se formalizirajo v izjavi o delu. Ključna težava faznih pogodb pa je v tem, da težko primerjamo ponudbe različnih izvajalcev, ko izbiramo najustreznejšega.
Dodatna težava pogodb, ki slonijo na dodani vrednosti, pa je tudi merjenje slednje, kar je lahko velik izziv. Eno je merjenje neposrednih in posrednih koristi. Če razvijamo programsko opremo za podporo procesu reklamacij, so neposredni učinki manjše število reklamacij, hitri odzivni čas, manj ur dela ljudi, ne moremo pa pomeriti dviga ugleda firme, posledično več naročil, ipd. Seveda je težava lahko tudi v tem, da izvajalec ne sme videti določenih poslovnih kazalnikov (poslovne skrivnosti). Taka pogodba torej zahteva veliko stopnjo zaupanja med naročnikom in izvajalcem. Je pa res, da ima običajno v takem pogodbenem (partnerskem) odnosu izvajalec obsežnejšo nalogo – če je pri tradicionalnem razvoju programske opreme le »razvijalec«, je pri agilnem tudi »ustvarjalec« (sodeluje pri razvoju »poslovne« rešitve, ne le programske opreme). Če je govora o dolgoročnem sodelovanju (brez časovne omejitve), kjer izvajalec pomaga naročniku že pri analizi delovanja in iskanju smotrnih sprememb, ki jih potem skupaj razvijejo in uveljavijo, govorimo o pogodbi »Razširjena ekipa«.
Naslednji tip pogodbe je »Fiksna cena +«. Obseg projekta se razdeli na mikro-rezultate (npr. uporabniške zgodbe) s fiksnimi cenami. Naročniku omogoča večjo kontrolo porabe denarja, izvajalcu pa zniža finančno tveganje prekomernega dela na raven posamezne funkcije. Veliko težavo pa vidimo v tem, da se uporabniške zgodbe jasno opredelijo šele na začetku posameznih ciklov. Kako naj torej izvajalec lahko realno oceni strošek razvoja uporabniških zgodb, če te še niso opredeljene?
Pogodba »Fiksiran rok in proračun« je oblika, ki popolnoma sledi temu, kar smo jo prikazali na prvi sliki. Prilagodljiv obseg projekta pomeni, da lahko naročnik – v okviru dogovorjenega časa in proračuna – v projekt vključi nove zahteve (funkcije, opravila), ki prvotno niso bile načrtovane, pri čemer naj bi te zamenjale nekatere prvotno planirane. Ta način sloni na pristopu, da lastnik izdelka na začetku vsakega cikla izbere v tistem trenutku najbolj pomembne funkcije … do porabe vseh sredstev in/ali do dogovorjenega roka, najmanj pomembne funkcije pa se ne razvijejo. Zasledili smo tudi poimenovanje Pogodba z dinamičnim obsegom, poznana pa je tudi pod nazivom »Money for nothing, change for free.«. Nekateri avtorji pa priporočajo tudi, da proračun, poleg planiranih stroškov, vsebuje tudi rezervni sklad za primer dodatnih ur dela. Dodatna možnost je deljenje finančnega tveganja, po pogodbi »Dosežen čas in proračun«. Izvajalca je mogoče nagraditi z višjo urno postavko v primeru dobave pred dogovorjenim rokom oz. dobi manjše plačilo v primeru zamude izvedbe.
Na predpostavki, da lahko želeno dodano vrednost projekta dosežemo v manj funkcijami, kot smo jih opredelili na začetku, sloni pogodba »Možnost predčasne odpovedi«. Če izvajalec pred rokom (tudi na polovici projekta) zadovolji potrebe naročnika, slednjemu ni potrebno plačati preostalega pogodbenega zneska (v pogodbi se določi nadomestilo za prekinitev pogodbe). Naročnik zniža stroške projekta, izvajalec pa dobi plačilo za storitve, ki jih ni potrebno izvesti. Smiselnost predčasnega zaključka projekta je prikazana na drugi sliki, ki izpostavlja tudi pomembno značilnost projekta, ki vpliva na odločitev, ali se projekta lotiti tradicionalno ali agilno – stalno rast dodane vrednosti. Uporaba agilnega pristopa je zelo priporočljiva, če je možno koristiti vmesne rezultate! To je možno pri razvoju programske opreme, novozgrajenega objekta pa ne moremo (ne smemo) uporabljati, če vsa dela niso zaključena! Na pol razvitega avta pa tudi ne moremo začeti tržiti.
Vrste pogodb smo povzeli po priročniku Agile practice guide (PMI, 2017).
Leave a Reply