Povraćaj uloženog (ROI) na projektima za razvoj softverskih proizvoda kojima se upravlja u skladu sa SCRUM agilnom metodologijom

Postojeća literatura koja se bavi agilnim metodologijama u većini slučajeva uticaj metodologije na uspešnost projekta predstavlja koz idealizirane primere koji su veoma retki u praksi. Ovaj rad kroz konkretne primere iz prakse a na osnovu podele razvojnih timova prema načinu na koji se pokreću projekti razvoja softverskih proizvoda ima cilj da proveri da li na povraćaj uloženog ROI odlučujući uticaj ima izbor agilnih metodologija za upravljanje projektima.

Na osnovu teksta koji sledi napisan je rad:

Povraćaj uloženog (ROI) u SCRUM metodologiji

U literaturi koja se bavi agilnim metodologijama često se kao prednost u odnosu na tradicionalne metodologije navodi brži povraćaj uloženih sredstava (ROI). Kao potvrda takvog stava se navodi da povraćaj uloženog postaje veći od nule odmah posle prvih sprinteva (Dean Leffingwell, 2011). Idealan povraćaj sredstava bi bio da već posle prvog SCRUM sprinta proizvod koji je isporučen ima zaokružene funkcionalnosti koje mogu da vraćaju uloženo. Ipak, proizvod koji je rezultat prvog sprinta veoma teško može da ima dovoljan skup funcionalnosti da bi klijent odmah mogao da ima povraćaj uloženog. Naprimer, teško da bi neka banka imala povraćaj uloženog posle prvog sprint-a u kome je realizovana funkcionalnost unosa podataka o klijentima ali nije realizovana funkcionalnost koja omogućava davanje potrošačkih  kredita klijentima. Zbog toga je ključno pitanje kako odrediti kritičnu masu funkcionalnosti (Angelina Njeguš et al., 2011) kojom se određuje skup zahtevanih funkcionalnosti čijom realizacijom klijentu počinje da se vraća uloženo?

Kritičnu masu funkcionalnosti može da definiše samo klijent tj. samo naručioc softverskog rešenja, koji definiše zahtevane funkcionalnosti, osobine i kvalitet konkretnog softverskog proizvoda i može da da procenu koji minimalni skup funkcionalnosti i osobina softverskog rešenja u kom trenutku na tržištu može da dovede do početka povraćaja uloženih sredstava.
Ovakva postavka je realna kod sistema:

  • koje je moguće uvoditi fazno,
  • kod kojih se planirano na tržište izlazi sa određenim skupom funkcionalnosti da bi se zadržalo interesovanje tržišta za konkretan proizvod ili skup servisa.

S druge strane mnogi sistemi se što zbog svojih funkcionalnih zahteva, što zbog strategije nastupa na tržištu ne mogu se fazno uvoditi već pre postavljanja na produkciju moraju biti kompletno implementirani.

Kad je SCRUM teorija u pitanju obično se povraćaj uloženog (ROI) izračunava prema formuli (Pete Deemer et al., 2010):

ROI = Business value / Effort

gde se “Business value” i “Effort” izražavaju u poenima koji se daju stavkama Product backlog-a. SCRUM rola Product Owner je zadužena ne samo za praćenje povraćajem uloženog već i za upravljanje njime tako što je Product Owner zadužen za priotitizaciju stavki Product backlog-a. Izračunavanjem ROI-ja za stavke Product backlog-a može se uraditi prioritizacija stavki Product backlog-a i doći do toga da se ROI maksimizira odmah u prvim sprintevima. Ipak to je veliko pojednostavljenje i moguće samo u  idealnom slučaju tj. u teoriji.

Ovakvo izračunavanje ROI-ja je bitno SCRUM timu, ali ne mora da bude uvek bitno naručiocu posla pogotovu njegovom menadžment-u. Menadžmentu će uvek biti potrebno izračunavanje ROI-ja kao odnosa povraćaja i uloženog novca.

Na ROI ne utiče samo metodologija već i zahtevane funkcionalnosti, tehnologije koje su korišćene u razvoju, platforma na kojoj se izvršavaju front-end aplikacije, marketing, način ugovaranja posla itd.

Povraćaj uloženog (ROI) u praksi

Projekti za razvoj softverskih proizvoda se po mnogo čemu razlikuju i to ne samo po funkcionalnostima koje proizvod treba da ima, po upotrebljenim tehnologijama za razvoj, metodologijama za upravljanje projektima već i po načinu iniciranja i dobijanja razvojnih projekata, modelu finansiranja takvih projekata, strategiji nastupa na tržištu, marketingu itd… U središtu bilo kog projekta za razvoj softverskih proizvoda su razvojni timovi pa je zbog toga ispitivanje ključnih uticaja na konkretnim primerima u praksi na povraćaj uloženog (ROI), kao jednog od ključnih pokazatelja uspešnosti projekata razvoja softverskih rešenja, u ovom radu rađeno prema podeli razvojnih timova po tome kako oni dolaze do posla tj. do konkretnih projekata.

Većina timova koji razvijaju softverska rešenja se, prema tome kako se je došlo do konkretnog projekta, mogu podeliti na:

  • timovi koji razvijaju proizvod za nastup, firme u kojoj rade, na tržištu,
  • timovi koji razvijaju na osnovu zahteva neke druge firme (ugovori),
  • timovi koji razvijaju proizvod za interno korišćenje u firmi u kojoj rade (in house).

Timovi koji razvijaju proizvod za sopstveni nastup na tržištu

Timovi koji razvijaju za široko tržište, razvijaju softverske proizvode na osnovu vizije menadžmenta firme, na osnovu ideje nekog od zaposlenih koju je prihvatio menadžment firme ili na osnovu ispitivanja tržišta. Takvi timovi obično razvijaju veće softverske sisteme kao što su: veliki poslovni paketi (ERP, CRM…), BI sistemi, sistemi koji se razvijaju za specifične potrebe pojedinih grana delatnosti ali takođe i srednje i manje sisteme različite namene (Web sajtovi, servisi, itd…). Ovakvi projekti traju duže, pošto se obično radi o obimnijim projektima. Sva ulaganja u razvoj proizvoda su na strani firme koja radi razvoj. Poslovna odluka o razvoju proizvoda bi trebala da se donosi na osnovu ispitivanja tržišta i projekcije tržišnih kretanja. Proizvod će, posle pojavljivanja na tržištu, možda vratiti uloženo i doneti profit. Zbog promena uslova na tržištu ili zbog finansijskih razloga, u nekoj od faza projekta, menadžment firme možda odluči da je projekat neisplativ i da prekine projekat.

Na slici 1 je prikazan sumarni iznos ulaganja i sumarni povraćaj po mesecima na projektu razvoja web baziranog softverskog sistema koji uključuje web aplikaciju za mobilnog klijenta i web administrativnu aplikaciju koja služi za naplatu određenih usluga. Za upravljanje projektom je korišćen SCRUM. Svi sprintevi su završeni u predviđenom roku i na kraju svakog sprinta je isporučen skup predviđenih funkcionalnosti. Firma koja je razvijala softver je donela poslovnu odluku da investira u razvoj pomenutog softverskog sistema i ponudi ga na korišćenje, preko web-a, raznim poslovnim sistemima. Firma koja je razvijala softver je i hostovala rešenje tj. obezbedila je sopstvenim investicijama neophodan serverski hardver, serverske licence, linkove, podršku i održavanje. U petom mesecu od počekta projekta je nabavljen serverski hardver, serverske licence i urađen je zakup i postavljanje neophodnih linkova prema Internetu. U šestom mesecu od početka projekta je urađeno postavljanje na produkciju prve verzije i potpisan je prvi ugovor sa eksternom firmom korisnikom sistema.

Slika 1

Slika 1. Sumarni iznos uloženog i sumarni povraćaj po mesecima

Na slici 2 je dat procenat povraćaja uloženog po mesecima. Može se videti da se je prvi povraćaj sredstava desio u šestom mesecu od početka projekta a da je za totalni povraćaj investiranog od 100% bilo potrebno 17 meseci.

Slika 2

Slika 2. Procenat povraćaja uloženog po mesecima

Faktori koji su uticali na povraćaj uloženog su sledeći:

  • Proizvod je morao da ima sve zahtevane funkcionalnosti da bi mogao da se postavi na produkciono okruženje tj. da bi mogao da počne da se koristi. Samim tim proizvod nije mogao da bude postavljen na produkciju pre završetka poslednjeg sprinta,
  • Prodaja je zavisila od skupa funkcionalnosti koji bi mogao da bude prezentovan potencijalnim kupcima. Zbog toga je proizvod morao, pre prezentovanja potencijalnim kupcima, da ima završen veliki deo zahtevanih funkcionalnosti (oko 80%),
  • Prodaja je zavisila od referenci koje konkretan proizvod ima u korišćenju pošto su na tržištu već postojali slični proizvodi. Zbog toga je bilo vrlo bitno da proizvod ponudi nove funkcionalnosti i da pokaže odlične rezultate kod prvih korisnika,
  • Prodaja nije previše zavisila od ulaganja u klasične marketinške aktivnosti pošto je proizvod specijalizovan za konkretnu granu delatnosti i nije namenjen širokoj upotrebi. Samim tim troškovi marketinga nisu dodatno opteretili projekat i povraćaj uloženog nije zavisio od klasičnih marketinških aktivnosti.

Projekat je bio uspešan i ispunio je očekivanja menadžmenta na konkretnom tržištu. Izbor SCRUM-a kao metodologije za upravljanje pomenutim razvojnim projektom nije presudno uticao na povraćaj uloženog (ROI) i uspeh projekta.

Timovi koji razvijaju proizvod na osnovu ugovora sa eksternom firmom

Veliki broj ugovora, za razvoj softverskih proizvoda se sklapa posle tendera na kojima naručioc posla (klijent) definiše kakav proizvod želi da dobije. Na osnovu dokumentacije, koju je klijent kreirao i koja je u većini slučajeva nedovoljno jasna, potencijalni isporučioc željenog softvera daje ponudu kojom definiše vreme isporuke i cenu. Tek iza dobijanja posla i potpisivanja ugovora, kreće se u detaljnu analizu, dokumentovanje onoga što se želi da se uradi (korisniči scenariji) i sam razvoj. Karakteristično za sve takve razvoje je da je inicijalna analiza vrlo kratka i radi se na osnovu nedovoljniih informacija. Takođe, o vremenu razvoja i ceni odlučuju prodavci koji se trude da svojom, za klijenta što boljom ponudom, dobiju posao, dobiju proviziju i zaposle svoj razvojni tim. U mnogim ovakvim slučajevima, cena razvoja itekako premašuje ugovorenu cenu. Razlozi za  to mogu da budu sledeći:

  • Klijent stalno proširuje svoje zahteve za funkcionalnostima jer tenderska dokumentacija nije bila kvalitetna,
  • Poddimenzionisaoni su potrebni resursi i vreme razvoja zbon nepotpunih informacija,
  • Prodavac je dao najnižu cenu samo da bi dobio ugovor i procenat od
    prodaje a krivica za neuspeh projekta se prebacuje na razvojni tim,
  • U ponudi nisu bili predviđeni troškovi održavanja i nisu potpisani ugovori o održavanju a u većini slučajeva, ovakvi razvojni timovi održavaju konkretna rešenja i daju podršku korisnicima.

Na slici 3 je prikazan sumarni iznos ulaganja i sumarni povraćaj po mesecima na projektu, koji je dobijen na tenderu, za razvoj sistema koji se sastoji od aplikacije za tablet PC u vozilima koja preko web-a komunicira sa centralom, aplikaciju za Pocket PC za agente na terenu i aplikaciju za GPS praćenje vozila firme naručioca sistema. Prva rata ukupnog iznosa je uplaćena firmi koja radi razvoj odmah po potpisivanju ugovora i pokretanja projekta. Za upravljanje projektom je korišćen SCRUM. Svi sprintevi su završeni u predviđenom roku i na kraju svakog sprinta je isporučen skup predviđenih funkcionalnosti. Pre svakog sprinta je bilo izmena zahteva i dodatnih zahteva od strane komisije koju je formirao naručioc posla od svojih zaposlenih i eksternog nadzornog tela. Oko svake izmene i dodatnih zahteva je bilo potrebno pregovarati zbog toga što zahtevi nisu bili jasno i detaljno definisani u tenderskoj dokumentaciji pa su samim tim novi zahtevi poskupljivali projekat. Firma realizator projekta je pet meseci kasnije ipak isporučila verziju 1 i naplatila je drugu, ugovorenu ratu od naručioca. Onda su neki viši menadžeri naručioca proizvoda, koji su tek tad prvi put videli proizvod počeli da definišu dodatne zahteve tvrdeći da je sve to već podrazumevano tenderskom dokumentacijom. Umesto da mesec dana nakon postavljanja prve verzije na produkciju isplate zadnju ratu, kao što je bilo ugovoreno, izgovarajući se da još uvek nije isporučen kompletan proizvod i stalno tražeći nove izmene i dorade na sistemu, isplatili su zadnju dogovorenu ratu tek u 14-tom mesecu od početka projekta. U Agilnom Manifestu (K. Beck et al., 2001) njegovi autori kažu da više vrednuju “Saradnju sa klijentima od ugovornih aranžmana”. Poenta je ipak u tome da firma koja razvija i prodaje softverska rešenja mora da adekvatno naplati svoj rad da bi konkretan projekat ne samo vratio uloženo već i doneo profit.

Slika 3

Slika 3. Sumarni iznos uloženog i sumarni povraćaj po mesecima

Na slici 4, na kojoj je dat procenat povraćaja uloženog, se može videti da povraćaj ni posle zadnje naplaćene rate po ugovoru nije dostigao 100%. Firma koja je radila razvoj ne samo da nije zaradila već je bila i na gubitku. U mnogim slučajevima, u praksi, na projektima razvoja softvera do kojih se dolazi na tenderima, ROI ne prelazi 80%.

Slika 4

Slika 4. Procenat povraćaja uloženog po mesecima

Faktori koji su uticali na povraćaj uloženog su sledeći:

  • Proizvod je morao da ima sve zahtevane funkcionalnosti da bi mogao da se postavi na produkciono okruženje tj. da bi mogao da počne da se koristi. Samim tim proizvod nije mogao da bude postavljen na produkciju pre završetka poslednjeg sprinta,
  • Dobijanje ugovora na tenderu je najviše zavisilo od što niže cene proizvoda koju je ponuđač definisao,
  • Prodaja nije zavisila od ulaganja u klasične marketinške aktivnosti.

Projekat nije bio uspešan i nije ispunio očekivanja realizatora projekta. S druge strane naručioc posla je dobio kvalitetan proizvod po izuzetno niskoj ceni. Planirano vreme realizacije projekta od strane naručioca posla nije bilo probijeno tj. s tačke gledišta naručioca posla projekat je bio uspešan. Izbor SCRUM-a kao metodologije za upravljanje pomenutim razvojnim projektom nije presudno uticao na povraćaj uloženog (ROI) i uspeh projekta.

Do ugovora na osnovu kojih se razvijaju softverski proizvodi ne dolazi se samo na tenderima već i na osnovu direktnog dogovaranja sa naručiocem posla. Takvi razvojni projekti su ipak povoljniji za firmu realizatora softverskog rešenja.

ROI nema svoj smisao samo za firme koje razvijaju softverske proizvode već je takođe od značaja i za firme koje naručuju razvoj softverskog proizvoda bilo za sopstvenu upotrebu u svom poslovnom procesu bilo za nastup na tržištu preko Interneta.

Na slici 5 je prikazan sumarni iznos ulaganja i sumarni povraćaj po mesecima na projektu nabavke i implementacije ERP sistema od strane jedne industrijske firme. Projekat je pored kupovine licenci ERP sistema predviđao određenu kastomizaciju (prilagođavanje) sistema, migraciju postojećih podataka i obuku korisnika i administratora. Posle sedam meseci od pokretanja projekta je dokupljen neophodan hardver i serverske licence. Posle osam meseci je urađeno postavljanje sistema (deployment) a posle devet meseci od pokretanja projekta je isplaćena zadnja ugovorena rata. Upotrebom sistem vraća mesečno neki procenjeni iznos.

Slika 5

Slika 5. Sumarni iznos uloženog i sumarni povraćaj po mesecima

Na slici 6, na kojoj je dat procenat povraćaja uloženog, se može videti da je povraćaj uloženog u ovakvim slučajevima izuzetno spor.

Slika 6

Slika 6. Procenat povraćaja uloženog po mesecima

Faktori koji su uticali na povraćaj uloženog su sledeći:

  • Proizvod je morao da ima sve zahtevane funkcionalnosti da bi mogao da se postavi na produkciono okruženje tj. da bi mogao da počne da se koristi. Samim tim proizvod nije mogao da bude postavljen na produkciju pre završetka poslednjeg sprinta,
  • Naručioc posla sistem koristi u svom internom poslovanju.

Projekat je bio uspešan i za naručioca i za realizatora posla i ispunio je očekivanja i jednih i drugih. Realizator posla je u realizaciji projekta koristio svoju sopstvenu metodologiju, ali izbor metodologije nije presudno uticao na povraćaj uloženog (ROI) i uspeh projekta.

Za firme koje nabavljaju softver za nastup na tržištu preko Interneta, povraćaj sredstava zavisi od mnogih faktora kao što su: dobro urađena analiza tržišta, dobro osmišljena aplikacija i njeni sadržaji, dobro osmišljena strategija nastupa na tržištu, marketing itd. Na slici 7 je dat sumarni iznos ulaganja i sumarni povraćaj po mesecima na projektu realizacije sajta za prodaju robe preko Interneta, koju na tržištu nudi firma naručioc rešenja. Za upravljanje projektom je korišćena interna modifikacija Microsoft Solution Framework (MSF). Sve iteracije su završene u predviđenom roku i na kraju svake iteracije je isporučen skup predviđenih funkcionalnosti. Postavljanje na produkciju je urađeno osam meseci od pokretanja projekta. Sistem je morao da pre postavljanja na produkciju ima sve zahtevane funkcionalnosti tj. nije mogao da bude fazno postavljan zbog toga što se je strategija nastupa na tržištu i tržišno pozicioniranje oslanjalo na nekoliko funkcionalnosti koje konkurencija, koja je već imala sajtove za prodaju preko Interneta, nije smela da vidi pre vremena.

Slika 7

Slika 7. Sumarni iznos uloženog i sumarni povraćaj po mesecima

Kao što se može videti na slici 8 konkretna firma je tek posle osamnaest meseci imala povraćaj uloženog veći od 100% tj. počela je da zarađuje na konkretnom softverskom sistemu.

Slika 8

Slika 8. Procenat povraćaja uloženog po mesecima

Faktori koji su uticali na povraćaj uloženog su sledeći:

  • Proizvod je morao da ima sve zahtevane funkcionalnosti da bi mogao da se postavi na produkciono okruženje tj. da bi mogao da počne da se koristi. Samim tim proizvod nije mogao da bude postavljen na produkciju pre završetka poslednjeg sprinta,
  • Uspešnost projekta je zavisila od novih funkcionalnosti koje drugi sistemi iste namene na tržištu nemaju,
  • Uspešnost projekta je zavisila od analize tržišta kad je u pitanju prodaja asortimana robe koju na tržištu nudi naručioc posla,
  • Uspešnost projekta je zavisila od planirane strategije nastupa na tržištu,
  • Uspešnost projekta je zavisila od ulaganja u klasične marketinške aktivnosti.

Projekat je bio uspešan i ispunio je očekivanja menadžmenta i naručioca posla i realizatora. Izbor MSF-a kao metodologije za upravljanje pomenutim razvojnim projektom nije presudno uticao na povraćaj uloženog (ROI) i uspeh projekta.

Timovi koji razvijaju proizvod za korišćenje u firmi u kojoj rade (in house)

Posle inicijalnog razvoja, koji treba da obezbedi minimum funkcionalnosti, konkretnog softverskog proizvoda, koje pokrivaju zahtevani minimum poslovnih procesa, sve aktivnosti razvojnog tima se svode na dorade novih funkcionalnosti ili na izmenu postojećih funkcionalnosti. Inicijalni razvoj se ponekad zaobilazi kupovinom izvornog koda nekog već postojećeg softverskog rešenja od firme, koja se bavi proizvodnjom softverskih rešenja, koje svojom funkcionalnošću, manje ili više, pokrivaju konkretnu problematiku poslovanja. Većina zahteva za doradom funkcionalnosti ili zahteva koji za posledicu imaju izmenu postojećeg rešenja su mali zahtevi po zahtevanim resursima, po vremenu i ceni. U većini slučajeva, takvi razvojni timovi, pored razvoja rade i na održavanju konkretnih rešenja i daju podršku korisnicima.

Rad ovakvih timova je maltene nemoguće organizovati u skladu sa agilnim ili tradicionalnim metodologijama zbog velikog broja zahteva, male granulacije zaheva i vrlo dinamičnog razvoja. Na primer, u ovakvim timovima dnevni SCRUM sastanci nemaju smisla zbog toga što:

  • Timovi vrlo mali (najviše 2-3 developera). U većini slučajeva samo jedan developer radi na realizaciji jednog zahteva,
  • Na mnogim zahtevima koje treba realizova se troši po nekoliko čovek\sati a ne čovek\dana,
  • Nemoguće je zbog raznorodnosti više malih zahteva ukrupniti u velike da bi se mogao organizovati rad u timu.

Vrlo je nezahvalno ako ne i nemoguće pratiti povraćaj uloženog (ROI) kad je u pitanju rad timova na velikom broju zahteva za izmenama i doradama koji su mali po obimu. Pošto su ovakvi timovi zaposleni u poslovnim sistemima, oni se tretiraju kao servis osnovnoj delatnosti poslovnog sistema i njihove plate se tretiraju samo kao trošak, a ne razmatra se povraćaj uloženog pošto vrlo mala granulacija zahteva to onemogućava. S druge strane, kad je u pitanju veliki broj zahteva za izmenama i doradama, moguće je organizovati i outsource timove ali se u većini slučajeva i to tretira samo kao trošak i ne prati se povraćaj sredstava.

Zaključak

Ako razvojni tim, realizatora projekta, isporuči softverski proizvod zahtevanih funkcionalnosti u planirano vreme sa planiranim resursima tj. po planiranoj ceni onda se može reći da je konkretan projekat za razvojni tim bio uspešan. To ne znači da je konkretan projekat bio uspešan za firmu realizatora projekta a takođe ne znači da će i za naručioca posla konkretan projekat biti finansijski isplativ.

Kad je razvojni tim u pitanju, izbor neke agilne metodologije za upravljanje razvojnim projektima može donenti dodatnu optimizaciju rada razvojnog tima i smanjiti troškove razvoja (David F. Rico, 2008). S druge strane većina razvojnih timova koji zajedno rade više godina na raznim projektima i koriste neku iterativnu (tradicionalnu) metodologiju za upravljanje svojim projektima, već je optimizovalo svoj rad na projektima prilagođavanjem metodologije koju koriste. Samim tim izbor SCRUM-a ili bilo koje druge agilne metodologije teško da će doneti neke veće optimizacije u radu takvih timova sem finijih podešavanja. Zbog toga korišćenje agilnih metodologija kod već uspešnih timova ne može da bude odlučujući faktor kad je povraćaj uloženog (ROI) u pitanju.

Povraćaj sredstava u praksi zavisi od mnogih faktora kao što su kvalitet proizvoda, njegov izgled, servisi i sadržaji koje nudi, analize tržišta, projekcije tržišta, načina ugovaranja, dobre strategije nastupa na tržištu, marketinga itd… tako da pored optimizacije rada razvojnog tima na projektu, mnogo je odlučujućih faktora koje treba imati u vidu, planirati ih i pratiti ih u toku projekta da bi projekat bio uspešan za sve učesnike projekta.

Literatura:

Leave a Reply

%d bloggers like this: