Varför är det så svårt för utvecklare att tidsestimera projekt?

Varför är det så svårt att få utvecklare att svara på hur lång tid någonting tar att utveckla?

Även om det finns en bra kravspecifikation är den allmänna uppfattningen att man minst måste dubbla tidsestimatet man får av sina tekniska leverantörer.

Utvecklare i sin tur verkar vara allergiska mot att tidsestimera projekt och gör det oftast motvilligt efter påtryckningar.

Varför är det då så här?

Vi börjar med att illustrera tidsestimering ur en utvecklares perspektiv.

Tänk att du deltar i det klassiska TV-programmet fångarna på fortet. Du står på borggården med ditt lag och ni har tre nycklar. Du väljs ut för att gå upp i tornet och hämta in den fjärde.

Väl i tornet träffar du Fader Fouras. Han ställer följande gåta:

- Om en kartong ägg kostar 14 kronor, vad kostar då en kyckling?

Men han ber dig bara estimera hur lång tid du tror att det kommer ta att svara på gåtan.

Det här är utmaningen som utvecklare ställs inför varje gång det skall tidsestimeras.

Om man kan svaret på gåtan och har löst den flertalet gånger innan är det enkelt att kalkylera hur lång tid det kommer att ta. Men om man inte löst gåtan tidigare hur ska man då kunna besvara hur lång tid det tar att lösa den?

• Ska man utgå ifrån en generell tid som det tar att svara på en gåta?

• Räkna ut genomsnittstiden på hur lång tid andra besökare under säsongen har tagit på sig?

• Ta den bästa eller den sämsta tiden i säsongen och ge dessa som estimat?

Den stora utmaningen med tidestimering är att man aldrig kan veta hur lång tid det tar innan man löst gåtan.

Ändå tvingas utvecklare ofta att ge ett estimat för att få ett okej från beställaren att börja. Det är här som avsaknaden av samsyn mellan beställare och utvecklare är som störst.

Den tidsuppskattning som utvecklaren gav tas emot av beställaren och förvandlas från den gissning som det var till att bli fakta. Fakta som sedan kommuniceras ut till alla iblandade i projektet. Blir den initiala gissningen inte spot-on får utvecklaren stå till svars för att tiden inte hålls.

Det här är en stor bidragande faktor till att utvecklare starkt ogillar att tidsestimera.

Så fungerar mjukvarutveckling

Mjukvara är föränderlig och det är skillnaden mot mycket annat som skapas. Mjukvaran måste vara föränderlig för att vara värdefull. Ju mer värdefull den är desto mer kommer användaren att vilja förändra den (tänk tillexempel på ditt operativsystem).

Vad är lösningen?

Kommunikation är som alltid den viktigaste faktorn för att skapa bra förutsättningar för ett lyckat projekt. Att tidigt i processen berätta om dina förväntningar på resultatet gör att ni tillsammans kan skapa en gemensam förväntansbild på vad projektet skall leverera och på hur lång tid.

Att som beställare vara ödmjuk och ha en förståelse för den utmaning som utvecklaren står inför är två andra enkla sätt att skapa en positiv arbetsgång under projektet.