Därför slår tidsuppskattningar i mjukvaruutveckling alltid fel, och hur du får en du kan planera efter

Samtalet brukar gå till så här. Chefen vill ha en ändring i orderbilden: ett nytt fält, en ny regel för rabatter, en liten rapport. Utvecklaren tänker efter en stund och säger: ”Ungefär två veckor.” Två månader senare är det fortfarande inte klart, och chefen undrar om utvecklaren ljög, var lat eller helt enkelt inte kan sitt jobb.

Oftast är det inget av de tre. Uppskattningen var förmodligen ärlig för arbetet så som det beskrevs dag ett. Problemet är att arbetet dag ett och arbetet som faktiskt levererades inte var samma arbete, och att de två veckorna förutsatte två veckor av ostörd tid som aldrig fanns.

Den här artikeln är för dig som äger företaget, är vd eller leder verksamheten och måste planera kring mjukvara men gång på gång blir överraskad. Den handlar om varför tidsuppskattningar missar, vad som egentligen händer med tiden och hur du ber om en uppskattning som du faktiskt kan planera efter.

Uppskattningar börjar breda, och det är normalt

Steve McConnell, som skrivit standardverket om tidsuppskattning i mjukvaruutveckling, beskriver osäkerhetskonen (cone of uncertainty). Allra först, när arbetet bara är en idé, kan en uppskattning slå fel med en faktor fyra åt båda hållen. Två veckor kan i själva verket vara en halv vecka, eller åtta veckor. När arbetet definieras, designas och kommer i gång blir spannet smalare.

Skede	Realistiskt spann för ”två veckor”
Idé, beskriven i en mening	0,5 till 8 veckor
Överens om vad det ska göra	1 till 4 veckor
Krav nedskrivna och kontrollerade	1,3 till 3 veckor
Design klar, arbetet påbörjat	1,6 till 2,5 veckor

McConnell kallar detta det bästa fallet. Konen smalnar bara av när någon faktiskt fattar de beslut som tar bort osäkerheten. Att tiden går gör det inte av sig självt.

Där har du den första orsaken till överraskningen: en enda siffra som ges dag ett, för en förfrågan på en mening, är den minst pålitliga uppskattning som någonsin kommer att finnas. Och de flesta ”två veckor” ges precis i det läget.

Vart tiden faktiskt tar vägen

Även när uppskattningen för själva kodandet stämmer är koden bara en del av arbetet. Så här kan en realistisk fördelning se ut för en ändring på ”två veckor” i ett etablerat affärssystem:

Arbete	Brukar det ingå i uppskattningen?	Typisk andel
Skriva den nya koden	Ja	40 %
Förstå den befintliga koden som berörs	Delvis	15 %
Tester, och att rätta det testerna hittar	Ofta inte	15 %
Kodgranskning och ändringar efter granskning	Sällan	10 %
Release, konfiguration, migrering av data	Sällan	10 %
Frågor, förtydliganden, väntan på svar	Aldrig	10 %

Andelarna är illustrativa, inte uppmätta, men alla som har levererat mjukvara känner igen dem. Om utvecklaren bara uppskattade första raden låg den ärliga summan närmare fyra eller fem veckor redan innan något gick snett. I äldre system blir andra raden mycket större, vilket vi förklarar i artikeln om teknisk skuld och långsam utveckling.

Hur två veckor blir två månader

Den största orsaken är sällan själva uppskattningen. Det är det som händer efteråt. Ett exempel, påhittat men typiskt:

1. Vecka 1Arbetet börjar som överenskommet
2. Vecka 2”Kan det hantera returer också?”
3. Vecka 3Akut fel i produktion, tre dagar förlorade
4. Vecka 4Ett annat projekt blir högsta prioritet
5. Vecka 6Tillbaka på det, hälften måste läras in igen
6. Vecka 7Rabattregeln ändras efter en demo
7. Vecka 9Äntligen levererat

Ingen gjorde något dramatiskt fel. Varje enskild förfrågan var rimlig. Tillsammans gjorde de ett jobb på två veckor till ett på nio. Så här mycket kostade var och en egentligen:

Vad som efterfrågades	Hur det låter	Vad det egentligen kostar
”Kan det hantera returer också?”	Ett fall till	Nya regler, nya tester, ofta en omdesign av det som redan byggts
Ett akut fel i produktion	Tre dagar	Tre dagar, plus tiden det tar att komma in i arbetet igen
”Lägg det här på is, det andra projektet är viktigare”	En paus	Att lära in arbetet igen senare, och risken att koden under har ändrats
En ändring efter en demo	En liten korrigering	Att riva upp och göra om en del av det som är klart
”Bara en snabb fråga” flera gånger om dagen	Ingenting	Bruten koncentration, varje gång

Kontextbytena förtjänar en siffra. Författaren Gerald Weinberg föreslog en tumregel: varje ytterligare projekt som en person arbetar med parallellt kostar ungefär 20 % av tiden bara i byten. En utvecklare som delas mellan två projekt ger inte vart och ett halva veckan, utan närmare 40 %, och de resterande 20 % försvinner någonstans mittemellan.

Därför hjälper inte press

När deadlines glider är den naturliga reaktionen press: ett fast datum, ett dagligt statusmöte, en påminnelse om att kunden väntar. Oftast blir det värre.

• Under press blir uppskattningar kortare, inte bättre. Folk säger den siffra som avslutar mötet, inte den de tror på.
• Tester och granskning är det första som stryks. Deadlinen hålls, buggarna kommer en vecka senare, och att rätta dem kostar mer än tiden som sparades.
• Statusmöten är också avbrott. En daglig avstämning om en försenad uppgift tar tid från uppgiften.
• Bra utvecklare märker det. Ständig deadlinepress ovanpå ständigt ändrade prioriteringar är ett av skälen till att seniora utvecklare slutar.

Så ber du om en uppskattning du kan planera efter

Du kan inte göra tidsuppskattning i mjukvaruutveckling exakt. Men du kan göra den användbar.

1. Be om ett spann, inte en siffra. ”Mellan två och fyra veckor” säger mer än ”tre veckor”. Är spannet väldigt brett är det också användbar information: arbetet är ännu inte förstått.
2. Fråga vad som skulle göra det längre. ”Vad kan göra det här till sex veckor?” Svaret visar dig riskerna, och ofta ett beslut du kan fatta redan nu för att ta bort en av dem.
3. Dela upp arbetet. Ett stort arbete som uppskattas i sin helhet är en gissning. Samma arbete uppdelat i bitar på några dagar, där varje bit levereras och visas för sig, är en plan. En tydlig kravspecifikation hjälper mycket här.
4. Låt uppskattningen omfatta allt. Fråga uttryckligen: ingår tester, granskning, release och datamigrering? Om inte, lägg till dem.
5. Uppskatta om när något ändras. Ett nytt krav är en ny uppskattning, inte en fotnot till den gamla.

Vad du kan göra som chef

Det mesta av den förlorade tiden i exemplet ovan låg inte i utvecklarens händer. Det här ligger i dina:

• En kanal för nya önskemål. Idéer, buggar och ändringar går till ett ställe, inte direkt till den utvecklare som sitter närmast.
• Prioriteringar som håller i minst två veckor. Ändra dem när du måste, men inte med några dagars mellanrum. En plan som håller i två veckor är värd mer än en perfekt plan som håller i två dagar.
• Nya idéer går in i nästa omgång. ”Kan det hantera returer också?” är en bra fråga, och svaret är: ja, i nästa arbetsbit, med en egen uppskattning.
• Skydda tiden för fokus. Färre möten, färre snabba frågor och en person som tar hand om akuta produktionsfel, så att inte alla blir avbrutna.
• Titta på trenden, inte på en enskild miss. Om ett team konsekvent ligger 50 % över, planera med 1,5 gånger deras uppskattningar och arbeta med orsakerna. Det är ärligare än att låtsas att nästa gång blir annorlunda.

När arbetet går till en extern partner gäller samma logik för avtalet. I vår artikel om fast pris eller löpande räkning förklarar vi varför ett fast pris inte tar bort den här osäkerheten, det flyttar den bara in i priset.

Frågor vi ofta får

Varför kan inte en utvecklare bara ge en exakt deadline?

För att ingen i början vet exakt vad arbetet kommer att innebära, inte ens den som beställer det. Detaljerna dyker upp medan arbetet görs. Ett exakt datum i början är ett löfte, inte en uppskattning, och löften som ges under osäkerhet brukar brytas.

Ska vi lägga till en buffert på varje uppskattning?

En dold buffert som alla känner till brukar ändå gå åt. Det fungerar bättre att be om ett spann, planera efter den övre halvan av det för sådant som verkligen spelar roll, och hålla skälen till spannet synliga.

Vårt team är alltid sent. Är de bara långsamma?

Kanske, men kontrollera först de andra orsakerna: hur ofta prioriteringarna ändras, hur många projekt varje person arbetar med, hur många avbrott det blir och hur gammal och snårig koden är. Enligt vår erfarenhet förklarar de det mesta av förseningen.

Hjälper uppskattningstekniker som story points?

De kan hjälpa ett team att uppskatta konsekvent och se sina egna mönster. De hjälper inte när arbetet hela tiden ändras under uppskattningen. Rätta till arbetsflödet först, tekniken sedan.

Så arbetar vi

ProCoding är en .NET-studio i Split, Kroatien. Vi bygger och förvaltar affärssystem, och en stor del av att göra det bra handlar om hur arbetet planeras: små bitar som kan visas varannan vecka eller oftare, uppskattningar som spann där riskerna är namngivna, och ändringar som går in i nästa omgång i stället för att störa den pågående. I ditt eget projekt, tillsammans med ditt team eller med en .NET-konsult i ditt team. Boka ett kostnadsfritt samtal på 30 minuter.

Källor

• The Cone of Uncertainty, Steve McConnell, Construx
• The Multi-Tasking Myth, Jeff Atwood, om Gerald Weinbergs tumregel för byten mellan projekt