Teknik

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

Vi reder ut varför det är så svårt att få utvecklare att svara på hur lång tid det kommer ta att utveckla en ny funktion.

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:

tidestimering

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 tidestimera.

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 bevara 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 avsknaden 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. En 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 mjukvaruutveckling

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ättningarna 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.

Twitter hashtag och artiklar på ämnet tidsestimering

No estimate hashtag på twitter

Estimering av mjukvaruutveckling

Tabell för översättning av estimat till riktig tid