Hos Pandi Web er vi eksperter i software- og webudvikling. Derfor ved vi, at det er godt umuligt at give en 100% fastpris på et softwareprojekt. Der er altid så mange ubekendte faktorer når man giver sig i kast med udviklingen af et stykke software. Oftest ender man et andet sted end der man forestillede sig, fordi man er blevet klogere undervejs.

Derfor er der altid 2 scenarier, hvis man arbejder med fastpriser:

Scenarie 1: Udvikleren taber:

Arbejdet går i gang med en specifik funktion og der opstår noget uventet. Det betyder, at det vi regnede med tog 15 timer nu tager 20. Det betyder, at vi nu ikke får nok betalt for vores arbejde. Vores udvikler bliver nødt til at skynde sig for at holde sig så tæt på prisen som muligt og springer over hvor gærdet er lavest. Vi kan ikke tjekke arbejdet igennem inden det sendes til kunden fordi der ikke er råd til projektledertimer. Nu bliver kunden sur over at have modtaget noget med fejl fordi udvikleren har skyndt sig for at nå deadline. Kunden sender arbejdet tilbage irriteret over at arbejdet ikke var kvalitetssikret og leveret 1 dag for sent.

Udvikleren får projektet tilbage i hovedet og bruger yderligere 3 timer på at rette de fejl der var sendt tilbage og det bliver nu sendt tilbage til kunden. Vi har brugt 23 timer men kun fået betaling for 15 timer. Kunden har fået sit produkt, men har haft en dårlig oplevelse fordi forventningen var, at det ville tage 15 timer og var leveret i kvalitetssikret stand.

Scenarie 2: Du (kunden) taber:

Fordi de fleste udviklere godt ved ovenstående prøver man i branchen at kompensere for det ved at overestimere. Det virker for udviklerne, men snyder kunderne. I ovenstående eksempel ville funktionen måske være blevet estimeret til 15 timer, men det estimat ville en projektleder eller udvikleren selv havde ganget med 2.

I ovenstående eksempel ville udvikleren have brugt de ekstra 3 timer fordi han ville have rum til det og løsningen ville være lavet på 23 timer. Kunden modtager produktet som aftalt og glad, men uvidende om, at vedkommende har betalt 7 timer for meget.

Vores scenarie: Vi vinder sammen

Vi ved ovenstående og foretrækker transparens og gennemsigtighed. For at tage ovenstående eksempel ville fremgangsmetoden her være en smule anderledes.

Estimatet på 15 timer bliver sendt til kunden, men med det forbehold, at det kan ændre sig fordi udvikling er svært at forudsige eller der måske opstår ting undervejs, som vil være mere hensigtsmæssigt. Da der er gået 3 timer støder udvikleren ind i de første komplikationer. Vi kan her se, at vi ikke kan holde estimatet på de 15 timer. Kunden får straks besked om udviklingen og får at vide, at estimatet nu er tættere på 25 timer end de 15 der oprindeligt var estimeret. Da vi rammer 20 timer kan vi se, at vi kun mangler arbejde for 3 timer. Kunden bliver informeret om, at vi nu med stor sikkerhed kan sige vi holder os under 25 timer. Vi bliver færdig på 23 timer og kunden får leveret produktet. Glad for vi har holdt ham opdateret løbende og for at der har været gennemsigtighed i forløbet.

Det fungerer også den anden vej. En udvikler kan også komme til at overestimere opgaven. I de tilfælde betaler du som kunde her kun for de faktisk anvendte timer. Estimaterne er udelukkende til som rettesnor.

Vi ved dog godt, at du måske har et budget du skal holde dig til. Derfor vil vi meget gerne vide hvad det er, og hjælpe dig med at lave så meget som overhovedet muligt indenfor det.

Hvorfor er det så svært at give fast pris?

Vi forstår godt, at det kan være svært at forstå hvorfor man ikke bare kan give en fastpris. Hvis du gerne vil vide mere om, hvorfor det er kan du læse med i vores næste indlæg. Du kan også holde dig opdateret indenfor teknologi og udvikling ved at tilmelde dig vores nyhedsbrev til venstre.