Varför är det så svårt för utvecklare att tidsestimera projekt?
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:
- 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.
Fler inlägg
Singles day - Har du koll?
Black Friday närmar sig med stormsteg men visste du att köpfesten som startade år 1869 i USA på senare år har fått en överman både vad gäller omsättning och antal köp?
Så väljer du rätt e-handelsplattform till ditt affärssystem
Teknik och åter teknik. I denna artikel skriver Johan Carlmark om hur du bör tänka när du ska välja affärssystem till din e-handelsplattform.
Negativa sökord i Google ads - Används alltid!
I denna artikel tänkte vi gå igenom hur man genom att jobba med negativa sökord kan optimera adwordskampanjer för att få in lite mer relevant trafik.