The Relationship between Customer Collaboration and Software Project Overruns (SLO)

Univerza v Ljubljani

Fakulteta za racunalnistvo in informatiko

Vpliv sodelovanja med narocnikom in

razvojno skupino na presezek

projekta

SEMINARSKA NALOGA

Mentor: prof. dr. Viljan Mahnic

Ljubljana 2015

Kazalo

1 Uvod 1

2 Metoda meritve 5

3 Podatki pridobljeni z raziskavo 7

3.1 Mozni moteci dejavniki . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Pogostost sestajanja s stranko . . . . . . . . . . . . . . . . . . 8

3.3 Tip pogodbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Vescina narocanja . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Zakljucek 13

KAZALO

Poglavje 1

Uvod

Studij glede vpliva sodelovanja med stranko in izvajalcem, pred studijo, ka-

tere rezultati bodo opisani kasneje, se ni bilo. Kar vemo iz dosedanjih studij

je, da se projekti, pri katerih se uporablja fleksibilne razvojne procese izva-

jajo bolj uspesno, kot pa projekti, pri katerih se uporablja zaporedne razvojne

procese. Priblizno 1 odstotek je presezkov pri prvo omenjenih metodah, med

tem, ko pri drugo omenjenih presezki sezejo do 60 odstotkov. In ne samo

to, pri fleksibilnih razvojnih procesih je sodelovanje z narocnikom pogostejse

oziroma boljse.[1] Pri omenjeni studiji je zaslediti, da je sodelovanje s stranko

pomembno, ni pa se dotaknila tudi tega dela raziskave.

Omenimo tri najpogostejse razloge (na katere neposredno vpliva narocnik)

za napacno oceno dela na projektu:

1. spremenjene ali dodane zahteve/zelje: najpogostejsi razlog za presezke

2. slabo definirane zahteve/zelje

3. slaba sposobnost odlocanja narocnika

Nemogoce je izmeriti kakovost sodelovanja objektivno, zato so se raziskale

kljucne lastnosti, po katerih lahko ocenimo kakovost sodelovanja med stranko

in razvijalcem. Pogostost sestajanja najboljse oceni kvaliteto sodelovanja.

Vprasanja po katerih se sprasujeta avtorja raziskave, so

1

2 POGLAVJE 1. UVOD

1. Ali sestankovanje na dnevni bazi ugodno vpliva na zblizevanje

ocene dela in dejanskega dela na projektu

Fiksna cena projekta in pogodba o ceni zavezuje tako narocnika, kot

tudi razvijalca in velikokrat se interesi obeh ’sprejo’. Zdi se, da agilne

metode ne vkljucujejo vloge narocnika in vpliv samega narocanja na

razvoj in uspesnost projekta.

2. Ali pogodbe za delitev tveganja ugodno vplivajo na zblizevanje

ocene dela in dejanskega dela na projektu

Primeri pogodb, ki jih lahko skleneta narocnik in izvajalec so pogodba,

ki doloca ure dela (by the hour), pogodba, ki oba zavezuje k ceni pro-

jekta (fixed price) in pa pogodba, ki deli tveganje na oba sodelujoca

(target price oziroma risk sharing). Pri prvo omenjeni pogodbi se delo

oziroma vlozen trud doloci v predvidenih urah dela. Druga pogodba

doloca, da se v primeru profita pri razvoju le-ta razdeli med narocnika

in izvajalca, prav tako velja podobno v primeru izgube pri razvoju.

Na primer: pri snovanju projekta sta narocnik in vodja razvojnega pro-

jekta predvidela 1000 ur dela. Razvojno podjetje racuna eno uro dela po

120 evrov. Ce je bilo dejansko potrebnih le 800 ur dela, potem stranka

placa 800 ur po ceni 120 evrov, preostalih 200 pa krijeta oba. Stroske

si torej delita, na primer na polovico, torej preostalih 200 ur stranka

placa le po 60 evrov. Nasprotno, v kolikor je bilo potrebnih na primer

1100 ur dela, teh 100 nadur stranka placa po polovicni ceni, torej ra-

zvojno podjetje prevzame polovico odgovornosti za zaostanek z delom in

presezek delovnih ur.

3. Ali narocnikove vescine in izkusnje z narocanjem projekta

ugodno vplivajo na zblizevanje ocene dela in dejanskega dela

na projektu

Sposobnosti narocnika razdelimo na sposobnosti sodelovanja pri pro-

jektu, racunalniskega in programerskega znanja, odlocitvene lastnosti

3

ter jasnost zastavljenega cilja. Na tem mestu je dobro omeniti pojem

”Product owner”, ki ga velikokrat srecamo. Navezuje se na narocnika

in oznacuje tistega, ki naroci uslugo oziroma profesionalen razvoj pro-

gramske opreme.

4 POGLAVJE 1. UVOD

Poglavje 2

Metoda meritve

Studija je bila izvedena leta 2006 v Norveskem podjetju, s priblizno 300

zaposlenimi razvijalci. Programersko podjetje narocnikom nudi celostne pro-

gramske resitve.

Slika 2.1: Podatki o podjetju, ki so pomembni v raziskavi

Dejstva pomembna pri raziskavi: anketirani so bili vodje projektov, vsi

podatki so bili shranjeni in vedno na voljo in vsak projekt je bil zahteval vsaj

100 ur dela.

Pozitivno pri raziskavi je, da vprasalniki niso bili vnaprej doloceni in so

tako dopuscali dodatne komentarje izprasanih vodij projektov in pa to da so

bili vodje osebno vpleteni, izprasani in so raziskavo vzeli bolj resno. Slaba

stran raziskave pa je, da je casovno potratna in tako v raziskavo vkljucenih

le nekaj projektov.

5

6 POGLAVJE 2. METODA MERITVE

Vsak intervju je trajal od 20 do 80 minut, anketirani so bili obvesceni o

tem, da je intervju anonimen in da nanj ne bodo dobili povratnih informacij

njihovi nadrejeni ali kdo, ki v raziskavi ne sodeluje profesionalno.

Pri raziskavi je bilo potrebo izolirati nekaj dejavnikov, ki lahko vplivajo

na rezultate, to so na primer obseznost in kompleksnost projekta ter tehnicno

znanje in sposobnosti razvijalcev.

Za pridobitev tovrstne ocene je poznanih vec metod ocenjevanja. Cilj v

tem primeru je primerjati oceno dela, ki ga bo potrebno vloziti v razvoj pro-

jekta in delo, ki je bilo za razvoj dejansko potrebno. V ta namen uporabimo

oceno BREbias, ki izmeri presezke oziroma razliko med napovedjo dela in

dejanskim delom.

Primerjava dejanskega vlozenega dela in predvidenega Izracunamo ga po

enacbi:

BREbias =x− y

min(x, y)(2.1)

X=dejanska vrednost, Y=ocenjena vrednost, BRE=Balanced Relative

Error

Poglavje 3

Podatki pridobljeni z raziskavo

V raziskavo je bilo vkljuceno 18 projektov. Projekti so bili analizirani glede na

naslednje dejavnike: pogostost sestajanja s stranko, tip pogodbe, strankina

vescina narocanja, mozni moteci dejavniki.

Predno se posvetimo dejavnikom, ki jih zelijo preucevati vprasanja raz-

iskave se ustavimo ob moznih motecih dejavnikih. Ob ugotavljanju vpliva

sodelovanja med stranko in razvijalcem, moramo upostevati tudi obstranske

dejavnike.

3.1 Mozni moteci dejavniki

Ti dejavniki so lastnosti projekta, kot so obseznost, kompleksnost in pozna-

vanje tehnologije.

BREbias glede na velikost projekta

Slika 3.1: BREbias glede na velikost projekta

Tipicni primer je podoben ne glede na velikost projekta medtem, ko pov-

precje prikazuje kako pri vecjem projektu veckrat manj natancno ocenimo

7

8 POGLAVJE 3. PODATKI PRIDOBLJENI Z RAZISKAVO

delo na projektu.

BREbias glede na komplekstnost projekta

Slika 3.2: BREbias glede na komplekstnost projekta

Kompleksnost projekta se je ocenjevala z ocenami visoka, srednja ter

nizka kompleksonst. Ni bilo projekta za katerega bi ocenili, da je njegova

kompleksnost nizka. BREbias se kaze, kot malo odvisen od kompleksnosti

projekta.

BREbias glede na tehnicno znanje

Slika 3.3: BREbias glede na tehnicno znanje

Anketiranci so ocenjevali svoje znanje z ocenami slabo, vredu in dobro.

Tehnicno znanje se je ocenjevalo z upostevanjem zahtevnosti razvoja pro-

jekta. Kot pricakovano se bolje odrezejo projekti pri katerih imajo razvijalci

dobro tehnicno znanje glede na zahtevnost projekta.

3.2 Pogostost sestajanja s stranko

18 vkljucenih projektov je bilo razdeljeno na 11 projektov, pri katerih so se

razvijalci dnevno sestajali z narocnikom in 7 projketov, kjer sestanki niso bili

tako pogosti.

Iz tabele razberemo, da redno sestajanje s stranko ugodno vpliva na ustre-

znost ocene dela in dejanske izvedbe. Razberemo lahko tudi, da je razlika v

presezku projekta ob rednem in nerednem sestajanju velika.

3.2. POGOSTOST SESTAJANJA S STRANKO 9

Slika 3.4:

A preden lahko diskusijo zakljucimo, moramo preiskati tudi ostale de-

javnike, ki bi bilo lahko vplivali na dobljene rezultate. V naslednji tabeli je

prikazan

Slika 3.5: BREbias v odvisnosti od pogostosti sestajanja

V raziskavi se je izkazalo pogosto sestajanje s stranko, kot ugoden vpliv

na presezek projekta. In ne le to, pri dnevnem sodelovanju je presezek ne

le obcutno, temvec veliko vecji kot pri nestalnem sestankovanju. A vendar,

moramo upostevati mozne motece dejavnike.

Dejavnika, ki ju moramo umeniti sta obseznost projekta in tehnicno zna-

nje razvojne ekipe, med tem ko je vpliv kompleksnosti projekta zanemarljiv.

Slika 3.6: Dejanski obseg projekta pri razlicnih pogostostih sestajanja

Opazimo, da je pri projektih, kjer so sestanki bili vsakodnevna rutina, kar

enkrat vecji kot pa tisti, kjer sestanki niso biti nujni vsak dan. Kar dodatno

potrdi, da je vsakodnevno sestajanje pomembno pri doseganju optimalnega

presezka. Ko se prej omenjeno je pri obseznejsih projektih tezje oceniti obseg

dela in cas potreben za razvoj.

Pa vendar ostaja se dejavnik tehnicnega znanja.

Tokrat so opazanja nasprotna. Pri projektih, pri katerih so se razvijalci

vsakodnevno sestajali s stranko, je bilo tehnicno znanje razvojne skupine

10 POGLAVJE 3. PODATKI PRIDOBLJENI Z RAZISKAVO

Slika 3.7: Tehnicno znanje pri razli?nih pogostostih sestajanja

boljse, kot pa pri konkurencnih projektih. Torej uspeha ne moremo pripisati

zgolj vsakodnevnemu sestajanju, a vendar upostevamo dva obstranska dejav-

nika, kar nas pripelje do ugotovitve, da doticni dejavnik ima pozitiven vpliv

na projekt, ne moremo pa ga definirati, kot razlog za optimalen presezek

pri projektu. Spet drugo opazanje in razmisljanje bi nas lahko pripeljalo do

ugotavljanja ali se ob obseznejsih projektih stranke odlocijo za pogostejse

sodelovanje. Narocnik lahko tako sproti opazuje napredek in vpeljane funk-

cionalnosti. Ze med samim razvojem lahko razvijalce opozori na nepotrebne

funkcionalnosti ali na nove zelje oziroma zahteve.

3.3 Tip pogodbe

Slika 3.8: BREbias v odvisnosti od tipa pogodbe

Ni presenetljivo, da je najvecji presezek opazen pri pogodbi, kjer je placilo

po uri. Taksna pogodba je ugodna za razvijalca, saj ga ’opere’ tveganja. A

se vec. Razvijalec lahko projekt zavlece in si tako njemu v prid pridobi ure

dela in s tem vecje placilo, zato presezek ni presenetljiv. Najmanjsi presezek

je viden pri pogodbi, kjer se tveganje deli, kar zopet je pricakovano. Pri

tovrstnih pogodbah je tveganje na obeh straneh in v interesu obeh sodelujocih

je, da se ure cim bolj priblizajo predpostavki.

3.4. VESCINA NAROCANJA 11

Poglejmo se stranske dejavnike.

Slika 3.9: Dejanski obseg projekta pri razlicnih pogodbah

Tabela izkazuje, da je obseg projekta izrazito vecji pri pogodbi z vnaprej

doloceno ceno projekta.

Slika 3.10: Tehnicno znanje pri razlicnih pogodbah

Zdi se, da razvojno podjetje predlaga pogodbo z deljenim tveganjem, v

kolikor oceni, da so njihovi razvijalci dobro podkovani v tehnicnem znanju.

Obratno se stranka raje odloci za fiksno ceno projekta, ce je le ta obsezen in

s tem zmanjsa svoje tveganje.

3.4 Vescina narocanja

Sposobnost narocanja stranke so ocenjevali vodje projektov in sicer z ocenami

zelo dobro (1), povprecno (2) in zelo slabo (3).

Vescino narocanja so ocenjevali glede na stiri razlicne lastnosti: sodelova-

nje med stranko in izvajalcem, narocnikovo znanje informatike in racunalnistva,

odlocnost stranke in jasnost zastavljenih ciljev.

12 POGLAVJE 3. PODATKI PRIDOBLJENI Z RAZISKAVO

Slika 3.11: Ocene narocnikov, ki so jih podali vodje projektov

Slika 3.12: BREbias glede na sposobnost narocanja

Pri spodobnostih in vescinah stranke ni zaznan bistveni vpliv na presezek

pri projektu. Opazeno je lahko posledica tega, da so narocnike ocenjevali

vodje projektov, ocena je bila subjektiva, prav tako vodje niso bili uspo-

sobljeni za podajanje tovrstne ocene. Nekoliko se je subjektivnost iznicila

z predhodno deiniranimi vprasalniki. Lastnosti stranke na presezek ima le

majhen vpliv, torej ti faktorji v splosnem niso tako pomembni.

Poglavje 4

Zakljucek

Zakljucimo lahko s tremi odgovori na prej zastavljena vprasanja. Na prvo

vprasanje lahko odgovorimo pritrdilno. Pogostejse sestankovanje s stranko in

dobra komunikacija pripomoreta k boljsi oceni dela na projektu. Predhodnja

predvidenja lahko kljub obstranskim dejavnikom potrdimo. Drugo vprasanje

nas spodbudi k raziskavi o vplivu razlicnih pogodb med narocnikom in izva-

jalcem. Potrdimo lahko, da je najbolj ugodna pogodba vzajemnih sopodbud,

v nasem primeru pogodba, ki obvezuje obe strani projekta k odgovornosti

in tveganju. Najslabse se je v raziskavi odrezala pogodba, kjer je doloceno

placilo po uri. Posumimo lahko na izkoriscanje s strani razvijalca program-

ske opreme. Tretje vprasanje se je navezovalo na lastnosti stranke in po

raziskavi se zdi, da lastnosti stranke nimajo velikega vpliva na potek razvoja

in na koncni rezultat projekta, ce ne celo, zanamarljiv vpliv.

Vsekakor je na tem podrocju potrebna nadaljna raziskava in omenjeno

naj bo odskocna deska za nadaljne raziskave in ne dejstva. Pri nadaljnem

raziskovanju je prav tako potrebno nameniti pozornost tudi obstranskim de-

javnikom, ki imajo velik vpliv na taksno raziskavo. V kolikor motecih dejav-

nikov ne morem izlociti jih moramo upostevati pri dobljenih rezultatih.

13

14 POGLAVJE 4. ZAKLJUCEK

Literatura

[1] K. Molokken-Ostvold and M. Jorgensen, A Comparison of Software Pro-

ject Overruns Flexible vs. Sequential Development Models, IEEE Tran-

sactions on Software Engineering, vol. 31, pp. 754-766, 2005.

[2] Kjetil Molokken-Ostvold Kristian Marius Furulund, The Relationship

between Customer Collaboration and Software Project Overruns, Agile

Conference (AGILE), 2007, pp. 72 -83, 2007.

[3] K. Molokken-Ostvold and M. Jorgensen, A Review of Surveys on Soft-

ware Effort Estimation, in 2003 ACM-IEEE International Symposium

on Empirical Software Engineering (ISESE 2003), Frascati, Monte Por-

zio Catone (RM), ITALY, 2003, pp. 220-230.

[4] S. Grimstad, M. Jorgensen, and K. [18] Molokken-Ostvold, The Cli-

ents’ Impact on Effort Estimation Accuracy in Software Development

Projects, in 11th IEEE International Software Metrics Symposium (ME-

TRICS 2005), Como, Italy, September 19-22., 2005.

15