Prioretizacija korisničkih zahtjeva za agilne projekte sa fiksnom cijenom
- Detalji
- Klikova: 11786
Projekat razvoja softverskog proizvoda ima četiri dimenzije: novac, vrijeme, funkcionalnosti i kvalitet. Ako su novac i vrijeme fiksirani, a kvalitet proizvoda ne želimo dovesti u pitanje, onda se moramo dogovarati oko - funkcionalnosti. U nastavku prezentiram jedan takav pristup.
Mnogi klijenti žele IT proizvode sa fiksnim budžetom i unaprijed utvrđenim krajnjim rokom za realizaciju. U idealnom slučaju, dosljedna primjena agilnog pristupa razvoju softvera bi optimizirala radni proces i učinila transparentnom vrijednost koju klijent dobija za uloženi novac; pa tačno poznavanje budžeta i vremenskog okvira unaprijed ne bi bilo nužno da se i klijent i softverska kompanija osjećaju sigurno. Međutim, takav poslovni aranžman sa otvorenim budžetom i vremenskim okvirom često nije ostvariv: nekada nedostaju znanja i vještine agilnog upravljanja projektima i agilnog pristupa razvoju softvera na strani klijenta ili softverske kompanije ili na obje strane; vrlo često klijent želi da zna cijenu softverskog proizvoda unaprijed jer ne prepoznaje razliku između kupovine usluge razvoja informacionog sistema i kupovine neke robe (npr. računara); a neki klijenti poput organa uprave, javnih preduzeća i javnih ustanova primjenjuju zakonske propise iz oblasti javnih nabavki gdje najniža cijena tehnički zadovoljavajuće ponude odnosno cijena kao podkriterij ekonomski najpovoljnije ponude mora biti fiksna. Ako se u toku razvoja proizvoda otkrije potreba za novim funkcionalnostima, pa time i povećanjem cijene, ovi propisi ne dozvoljavaju pravljenje aneksa (dodataka) osnovnog ugovora već se mora provesti novi postupak nabavke. Privatne korporacije i međunarodne organizacije imaju vlastite propise o nabavkama u kojima je na sličan način riješeno pitanje cijene ugovora.
Dakle, u velikom broju slučajeva, fiksni budžet za razvoj softverskog sistema je datost. To ipak ne znači da u ovom slučaju ne možemo prakticirati agilni pristup razvoju softverskih proizvoda.
Prioretizacija korisničkih zahtjeva
Jedan od mehanizama koji nam može pomoći da realizujemo agilni razvoj softverskog proizvoda u kontekstu ugovora sa fiksnim budžetom jeste prioretizacija korisničkih zahtjeva. U tradicionalnom pristupu specifikacije zahtjeva sistema ne postoji koncept odnosno praksa utvrđivanja važnosti korisničkog zahtjeva. Ustaljena praksa je da imamo obrazac za definisanje korisničkog zahtjeva, svi korisnički zahtjevi pišu se sa istim nivoom detaljnosti a u pripremi SRS (software requirements specification) dokumenta nastojimo pobrojati sve moguće funkcionalnosti sistema kako ne bi došli u poziciju da smo zaboravili nešto što nam treba.
Prisustvovao sam mnogim ovakvim sastancima pripreme SRS dokumenta:
A: „A šta mislite o X?“, B: „Nisam siguran da li nam to uopšte treba?“, A: „Može se desiti Y pa će nam trebati X.“, B: „Ali u zadnjih 10 godina nam se Y desio samo jednom, šta mislite da X radimo van sistema?“....nakon trominutne diskusije... A,B: „Hajde da ipak stavimo i X, za svaki slučaj, nije viška.“
Na ovaj način, vrlo vjerovatno potpuno nebitna funkcionalnost X završi u SRS dokumentu. Čak i nije toliki problem što je ta funkcionalnost spomenuta u SRS dokumentu, koliko je problem što nije naveden prioritet razvoja ove funkcionalnosti. Kada razvojna kompanija uzme tendersku dokumentaciju da uradi procjenu opsega posla ili kasnije implementira ugovoreni posao, programeri, koji se vrlo vjerovatno po prvi put susreću sa tom poslovnom domenom, neće znati razlikovati funkcionalnost X od bilo koje druge funkcionalnosti koja je stvarno bitna za sistem i bez koje možda sistem nema smisla.
Agilni pristup specifikaciji korisničkih zahtjeva uvažava realnost razvoja softvera: da ne možemo poznavati baš sve poslovne zahtjeve unaprijed, da ono što znamo ne znamo na istom nivou detaljnosti i da su funkcionalnosti očekivanog softverskog rješenja različitog stepena važnosti odnosno da su neke funkcionalnosti prioritetnije od drugih. Softverski proizvod nije moguće u potpunosti definisati unaprijed jer će znanje koje steknemo u samom procesu razvoja tog proizvoda sigurno uticati na njegovo oblikovanje u konačni proizvod. Prioretizacija nam u slučaju agilnog razvoja sa fiksnim budžetom pomaže, jer nam omogućava da možemo odustati od manje bitnih stvari kako bi programerski napor preusmjerili na otkrivene bitnije stvari.
MoSCoW tehnika
Vrlo efektna tehnika prioretizacije korisničkih zahtjeva koju koristim je tkzv. MoSCoW tehnika. MoSCoW je akronim za Must Have, Should Have, Could Have i Won't Have. Svaki korisnički zahtjev, bez obzira na formu kojom je on opisan, može se svrstati u jednu od ove četiri kategorije prioriteta.
Ako unutar tima klijenta (kojeg zovem Product Owner Tim), odnosno tima sastavljenog od poslovnih ljudi, korisnika pa i predstavnika razvojne kompanije (ako smo već u fazi razvoja), postavite pitanje: „Šta će biti ako ne napravimo ovu funkcionalnost?“ i dobijete odgovor „Softver nema smisla bez ove funkcionalnosti, možemo odmah odustati od projekta.“, onda je riječ o Must Have funkcionalnosti. Ako sistem ima smisla bez te funkcionalnosti, ali bi mu vrijednost bila znatno veća da je ima, onda govorimo o Should Have ili Could Have funkcionalnosti. Što je poslovna vrijednost veća to je funkcionalnost potrebnija odnosno važnija.
U stalnim razgovorima i promišljanjima funkcionalnosti softvera vrlo vjerovatno ćemo spomenuti i funkcionalnosti za koje ćemo se složiti da nam ne trebaju (Won't Have), ali svjesni neizvjesnosti koje donosi sutrašnjica, zapisaćemo i te funkcionalnosti, jer ako nam one nisu potrebne sada, to ne znači da nam jednog dana te funkcionalnosti neće postati Should Have ili čak Must Have.
MoSCoW tehnika zavređuje poseban tekst koji bi objasnio kako definisati značenje svake pojedinačne kategorije prioriteta unutar Product Owner Tima odnosno Scrum tima, kako pristupiti određivanju prioriteta pojedinačnim korisničkim zahtjevima, kako balansirati sa brojem dodijeljenih prioriteta iz svake kategorije u odnosu na ukupni opseg posla i kako upotrebljavati prioretiziranje u hijerarhijsko organizovanim korisničkim zahtjevima. U ovom tekstu sam dao samo kratki uvod u ovu tehniku.
Šta klijent, koji ima obavezu sklapanja ugovora o razvoju softvera sa fiksnim budžetom, dobija sa prioretizacijom korisničkih zahtjeva u tenderskoj dokumentaciji?
Sigurnost.
Klijent očekuje da će mu se, u idealnom i vrlo nerealnom slučaju, isporučiti sve Must Have, Should Have i Could Have funkcionalnosti. To će softverska kompanija i naplatiti. Međutim, u stvarnom životu, Product Owner koji zastupa najbolje interese klijenta će u toku razvoja softverskog proizvoda sigurno otkriti neke nove detalje. Ovi detalji se mogu odnositi na ranije definisane funkcionalnosti ili je riječ o potpuno novim funkcionalnostima kojih se klijentska strana nije mogla sjetiti u fazi nabavke usluge razvoja tog softverskog proizvoda. U zavisnosti od inteziteta promjena, odnosno novog posla koji uvodimo u projekat, klijent može odustati od Could Have funkcionalnosti kako bi dodatno razradio ili uveo nove Must Have i Should Have funkcionalnosti. Dakle, idealni slučaj je da će klijent dobiti sve Must Have, Should Have i Could Have funkcionalnosti koje je ugovorio, ali su njegova stvarna očekivanja: garantovana isporuka svih inicijalno specificiranih i u razvoju otkrivenih Must Have funkcionalnosti i dosta visoka pouzdanost isporuke većine inicijalno specificiranih i u razvoju otkrivenih Should Have funkcionalnosti.
Ovim pristupom i razvojni tim dobije jasniju sliku očekivane poslovne vrijednosti budućeg proizvoda ali i jednu vrstu sigurnosti da u projektima sa fiksnim budžetom, klijent u tenderskoj dokumentaciji neće posezati za frazama tipa „...i tako dalje“, „...i sve što je za to potrebno“, koje bi to onda u implementaciji tumačio kao specifikaciju nekakvih zahtjeva.
Šta vi mislite?
Šta ovdje nedostaje ili je pogrešno ili dobro? Ako ste član razvojnog tima odnosno predstavnik softverske kompanije koja razvija softverski proizvod po ugovoru sa fiksnom cijenom, kako vi upravljate promjenama očekivanja klijenta? Ako ste u ulozi voditelja projekta na klijentskoj strani, kako vi prakticirate agilni odnosno Scrum razvoj sa ugovorenim vanjskim razvojnim timom u kontekstu projekta sa fiksnim budžetom?
Molim podijelite svoja razmišljanja i komentare na pripadajućem LinkedIn blog post-u ili ovdje.
