Estimater i softwareudvikling holder sjældent, fordi udviklerne beskriver noget, de aldrig har bygget præcis sådan før. Det gælder også de dygtige. Ledelsen får brugbare svar ved at ændre spørgsmålet: bed om intervaller, skær opgaverne i små leverancer, og aftal, at forsinkelser skal varsles tidligt. Det egentlige faresignal er den forsinkelse, ingen sagde noget om.
Hvorfor det er svært
En ny funktion er sjældent en gentagelse af noget kendt. Var den det, kunne man bruge det, der allerede findes. Noget af arbejdet består i at finde ud af, hvad der skal gøres, og derfor er det svært at sige på forhånd, hvor længe det varer.
Hertil kommer nogle kendte grunde:
- Det sidste stykke tager lang tid. Når noget virker på udviklerens maskine, mangler der stadig test, fejlhåndtering, sikkerhed og udgivelse.
- Afhængigheder. Noget venter på en anden udvikler, en leverandør eller en kunde.
- Estimatet dækker tiden ved tastaturet, mens opgaven i praksis deler ugen med møder, support og fejl.
- Skjulte problemer i gammel kode dukker først op, når man går i gang, se ingen tør røre den del af koden.
- Kravene ændrer sig undervejs, eller de var aldrig helt afklarede.
Det sidste punkt er ofte det største. Mange forsinkelser opstår, fordi nogen undervejs fandt ud af, hvad de egentlig ville have.
Ledelsens egen andel
Ledelsen er tit medskyldig, uden at vide det. Et estimat bliver hurtigt til et løfte. Når en udvikler siger “måske tre uger” og hører direktøren sige “tre uger” til en kunde, lærer personen at sige seks næste gang, eller at sige det, ledelsen gerne vil høre.
Spørg jer selv, om det er trygt at give et dårligt svar hos jer. Har en udvikler tidligere sagt, at noget ville tage længere tid end ønsket, og hvad skete der så? Bliver et ærligt estimat presset ned på et møde, står I tilbage med et svar, som alle ved er forkert.
Datoen ligger også tit fast, før opgaven er forstået, fordi den er lovet i et salg, se artiklen om løfter fra salg.
Sådan får I brugbare svar
Bed om et interval. Spørg: hvad er det tidligste og det seneste, du tror, det kan blive? Et interval siger også noget om usikkerheden. Et stort spænd betyder, at teamet ikke ved nok endnu.
Skær opgaven i små bidder. Små opgaver kan estimeres langt bedre end store. Hvis en leverance tager mere end nogle uger, så del den, så der er noget at vise undervejs. En kørende version hver uge fortæller mere end noget estimat.
Giv en lille undersøgelse først. Er usikkerheden stor, så brug et par dage på at afklare det sværeste, før I giver et bud. Teamet får et bedre grundlag, og I får et bedre svar, for en lille og afgrænset udgift.
Lad dem, der skal gøre det, estimere. Et estimat, som lederen giver på teamets vegne, er et ønske.
Brug historikken. Se på, hvor lang tid lignende opgaver faktisk tog. Tal fra jeres egne afsluttede opgaver slår næsten altid et bud fra hukommelsen.
Vælg, hvad der er fast. Når datoen ligger fast, må omfanget kunne ændre sig. Når omfanget ligger fast, må datoen kunne flytte sig. Begge dele på én gang holder sjældent. Afgør på forhånd, hvad der er vigtigst, og hvad der kan skæres fra.
Tavse forsinkelser
Det mest alvorlige problem er forsinkelser, der ikke bliver sagt højt. En opgave er “næsten færdig” i tre uger. Status er grøn indtil dagen før levering. Så har I et problem med tillid eller kommunikation, og det løses ikke med bedre estimater.
Lav en fast aftale: så snart nogen ved, at en dato ikke holder, siger de det, helst samme dag. Vis, at det er velkomment. Tak for beskeden, og tag fat på, hvad I gør ved det. Afviger I selv fra aftalen og bliver irriteret, får I ikke flere varsler.
Stil spørgsmål, der er svære at svare “det går fint” på. Hvad er det sværeste, der mangler? Hvad ved I ikke endnu? Hvad ville få det her til at tage dobbelt så lang tid? Tilsvarende kan et udviklingshus vurderes på, om det varsler i tide, se er vores udviklere gode?.
Når I skal give kunden en dato
Kunder og salg har brug for en dato, og det er rimeligt. Brug intervallets seneste ende, eller angiv et kvartal frem for en bestemt dag, indtil usikkerheden er mindre. Hold det, I lover til kunden, adskilt fra det, teamet arbejder efter internt. Præcisér datoen, efterhånden som arbejdet skrider frem, og sig det, så snart I ved mere.
Det skal også passe sammen med køreplanen, se den tekniske køreplan. Er det en leverandør, der bygger for jer, så få datoer og leverancer skrevet ind i styringen af samarbejdet, se sådan styrer I en udviklingsleverandør.
Tænkt eksempel: en SaaS-virksomhed vil have en ny integration. Teamet siger mellem tre og otte uger. I stedet for at presse tallet bruger de tre dage på at prøve den sværeste del. Nu lyder intervallet fire til seks uger. Direktøren giver kunden en leverance i næste kvartal, og den holder.
Det skal I lade være med
- At lægge en buffer oveni i det skjulte · alle gør det, og usikkerheden forsvinder ud af samtalen.
- At forhandle estimatet ned · opgaven bliver ikke kortere af det, kun svaret.
- At straffe den, der kommer med dårligt nyt · så kommer nyheden senere næste gang.
Det skal I kræve af den eksterne
- ☐ En måde at estimere på, som teamet bruger og tror på.
- ☐ Intervaller og usikkerhed i det, ledelsen får at se.
- ☐ Sammenligning af estimater og faktisk tid, så teamet lærer af det.
- ☐ Tidlig besked, når en dato ikke holder.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Sådan følger I fremdriften · Hvornår er en leverance færdig?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
