Estimat på softwareudvikling: sådan får du et tal du kan budgettere efter

Et estimat på softwareudvikling er et kvalificeret bud på hvor mange timer det tager at bygge en løsning, og et brugbart estimat er altid et interval med antagelser, ikke ét tal. Vil du kunne budgettere efter det, skal du give udvikleren et ordentligt grundlag, bede om intervallet opdelt i dele og lægge dit budget efter den øvre ende. Jo mere der er afklaret, før estimatet bliver givet, jo smallere bliver intervallet, og derfor er et forprojekt den mest effektive vej til et tal du kan stole på.

Den korte version: hvor præcist kan et estimat være?

Præcisionen afhænger mest af hvor meget der er afklaret, når estimatet bliver givet. Tabellen viser mine tommelfingerregler for spændet mellem den nedre og den øvre ende.

Tallene er mine egne skøn, men mønstret er velkendt. Barry Boehm tog modellen ind i softwareudvikling, og forskningen bag den peger på at et estimat, der bliver givet før kravene er afklaret, kan ligge op til fire gange for højt eller for lavt. Usikkerheden falder, efterhånden som der bliver truffet beslutninger. Modellen kaldes på engelsk the cone of uncertainty, og dens vigtigste pointe er let at overse: tragten bliver kun smallere, når nogen aktivt fjerner usikkerheden.

Hvad typiske projekter koster i kroner, står i prisguiden til softwareudvikling. Her handler det om at få et pålideligt tal for dit eget projekt.

Estimat, tilbud, fast pris og budget er fire forskellige ting

Meget af frustrationen omkring estimater opstår, fordi ordene bliver blandet sammen.

Den klassiske fejl er at bruge den nedre ende af et estimat som budget. Så har du behandlet et gæt som et løfte. En fast pris flytter risikoen over på udvikleren, men så betaler du for bufferen. Hvornår det er en god handel, gennemgår jeg i sammenligningen af timepris og fastpris.

Den anden fejl er at blande estimatet sammen med en frist. Et estimat siger hvor lang tid noget tager, en frist siger hvornår du har brug for det. Passer de ikke sammen, er løsningen at skære i omfanget, ikke at bede udvikleren om at gætte lavere.

Hvorfor estimater på software skrider

Software er svært at estimere, fordi hver opgave er lidt ny. Var den ikke det, kunne du som regel købe løsningen færdig. Når estimater skrider, er det typisk af disse grunde:

• Ukendte integrationer. Den anden parts system opfører sig sjældent præcis som dokumentationen lover, og testadgang kan tage uger at få.
• Beslutninger der ikke er truffet. "Det finder vi ud af senere" er en af de dyreste sætninger i et projekt, fordi senere ofte betyder ombygning.
• Nye ønsker undervejs. De er normale og ofte gode, men de skal erstatte noget andet eller have deres egen pris.
• Arbejde der ikke var med. Test, opsætning af servere, møder, fejlretning og overdragelse bliver let glemt, når der kun er estimeret på funktioner.
• Optimisme. Daniel Kahneman og Amos Tversky beskrev i 1979 planlægningsfejlen: vi undervurderer systematisk hvor lang tid en opgave tager, også når vi ved at lignende opgaver tog længere tid end planlagt.

Derfor skrider estimater sjældent lige meget begge veje. En opgave kan højst blive lidt hurtigere færdig end forventet, men den kan blive mange gange dyrere. Den danske forsker Bent Flyvbjerg og hans medforfatter Alexander Budzier gennemgik 1.471 it-projekter og fandt en gennemsnitlig budgetoverskridelse på 27 %, men hvert sjette projekt overskred budgettet med i gennemsnit 200 % og tidsplanen med næsten 70 %.

Undersøgelsen handler om store it-projekter, så tallene kan ikke overføres direkte til en mindre webapp. Pointen holder alligevel: de store tab ligger i halen, og det skal et godt estimat tage højde for.

Sådan læser du et estimat

Et godt estimat viser hvor usikkerheden ligger, så du kan gøre noget ved den. Her er et tænkt eksempel på en mindre bookingløsning, regnet i timer:

Regnet med 1.000 kr. i timen ekskl. moms, som er et rundt regnetal og ikke min pris, giver det 195.000-325.000 kr. Det spænd er for bredt til at skrive under på, men estimatet viser præcis hvorfor: bookingreglerne og integrationen står for over halvdelen af usikkerheden. Det er dem der skal afklares, før tallet kan blive smallere.

Nogle udviklere giver tre tal for hver del: et optimistisk, et sandsynligt og et pessimistisk. Det er mere ærligt end ét tal, fordi du ser både det bedste og det værste udfald.

Kig efter tre ting, når du læser et estimat:

• Er det delt op? Et samlet tal på 250 timer kan du hverken vurdere eller skære i.
• Står antagelserne der? "Økonomisystemet har et brugbart API" er en antagelse. Holder den ikke, holder estimatet heller ikke.
• Hvad er ikke med? Design, tekster, flytning af gamle data, hosting og drift er de typiske huller. Har du flere estimater, så brug guiden til at sammenligne tilbud fra udviklere til at stille dem op på samme grundlag.

Sådan får du et estimat du kan budgettere efter

Du kan ikke få et præcist estimat på en uafklaret idé, men du kan få det mest præcise tal projektet tillader:

1. Beskriv problemet før løsningen: hvem skal bruge systemet, hvad gør de i dag, og hvad skal blive bedre? Så er der plads til at udvikleren kan foreslå en enklere vej end din funktionsliste.
2. Fortæl hvad din budgetramme er. Uden en ramme bliver der estimeret på den dyreste udgave af din idé. Med en ramme kan I forme løsningen efter den.
3. Bed om et interval opdelt i dele, som i eksemplet ovenfor, så du kan se hvad der er dyrt, og hvad der er usikkert.
4. Få antagelser og udeladelser skrevet ned. Det er dit vigtigste værktøj, hvis noget ændrer sig undervejs.
5. Spørg til de tre største risici, og hvad de kan koste. En udvikler der ikke kan svare, har ikke tænkt projektet igennem.
6. Fjern den største usikkerhed, før du binder dig. Det kan være et forprojekt eller en lille, afgrænset afprøvning af den mest usikre del, fx et par timer hvor udvikleren tester en integration i praksis.
7. Budgettér efter den øvre ende plus en reserve. Min tommelfingerregel er 10-20 % oven i den øvre ende til de ændringer du selv kommer til at ønske, når du ser systemet i brug. Hvordan du stiller det op, kan du se i skabelonen til budget for et softwareprojekt.
8. Aftal hvordan estimatet bliver fulgt op. Bed om at se forbrugte timer mod estimatet efter hver fase og om at få besked, så snart en del ser ud til at skride.

Hvorfor et forprojekt gør estimatet så meget mere præcist

Et forprojekt er et kort, betalt forløb før udviklingen, hvor løsningen bliver afklaret og estimeret. Jeg sælger selv forprojekter til fast pris, så læs afsnittet med det forbehold. Det næste afsnit handler derfor også om hvornår præcision ikke er pengene værd.

Et forprojekt gør estimatet mere præcist af fire grunde, og ingen af dem handler om at udvikleren gætter bedre:

• De ukendte dele bliver kendte. Integrationer bliver undersøgt med rigtig dokumentation og testadgang, og gamle data bliver set igennem. Det er netop de dele der har det bredeste spænd i eksemplet ovenfor.
• Beslutningerne bliver truffet. Hvem må se hvad? Hvad sker der, når en betaling fejler? Hvilke funktioner kan vente? Hver beslutning fjerner en kilde til usikkerhed.
• Opgaverne bliver små. Det er langt lettere at estimere en opgave på en dag end en på en måned. Et forprojekt bryder løsningen ned i dele der er små nok til at blive vurderet hver for sig.
• Omfanget bliver prioriteret. Med en liste sorteret i "skal med", "bør med" og "senere" kan du skære til, så det smalle interval også passer til dit budget.

Der er en femte fordel, som er let at overse: estimatet kommer fra den der skal bygge løsningen og bagefter leve op til tallet. Sådan arbejder jeg selv før større projekter, og når forprojektet er færdigt, er det realistisk at give en fast pris eller et snævert interval på første fase, fordi gætteriet er taget ud. Hvad et forprojekt koster, og hvad du skal have med hjem, står i indlægget om prisen på en discovery-fase.

Hvornår et præcist estimat ikke er umagen værd

Præcision koster tid, og nogle gange er den ikke pengene værd:

• Små opgaver. En ændring eller en integration på under ca. 100 timer kan som regel estimeres godt nok ud fra en samtale og et skriftligt oplæg. Et forprojekt ville blive en for stor del af regningen.
• Produkter hvor du skal lære undervejs. Bygger du en første version for at finde ud af hvad kunderne vil have, er et detaljeret estimat på det hele spild. Sæt hellere et fast beløb pr. periode og lad indholdet være fleksibelt. Det er tankegangen bag agil udvikling frem for vandfald.
• Når du kun skal vide om idéen er realistisk. Skal du beslutte om projektet overhovedet er umagen værd, er et groft interval nok. Det præcise tal kan vente, til du har besluttet dig.

Og så er der situationer hvor jeg ikke er det rigtige valg. Har du brug for en bindende fast pris på et stort, uafklaret projekt efter et enkelt møde, vil jeg sige nej. Nogle leverandører giver dig gerne det tal, men de er nødt til at lægge en stor buffer ind for at gøre det, og den betaler du, uanset om risikoen bliver til noget.

Næste skridt: gør dig klar til at få et estimat

Jo bedre grundlag du giver, jo smallere bliver intervallet allerede fra første samtale. Gå listen igennem, før du beder mig eller en anden udvikler om et estimat.

Vil du se hvordan jeg selv prissætter forprojekter og udvikling, og hvordan et estimat bliver til en fast pris bagefter, så står det på siden med mine priser. Du taler direkte med mig, der også skriver koden, og du får svar inden for én hverdag.

Ofte stillede spørgsmål

Hvor lang tid tager det at få et estimat på et softwareprojekt?+

Et groft interval kan du ofte få efter en enkelt samtale og et skriftligt oplæg, typisk inden for få dage. Et estimat du kan budgettere efter, kræver mere arbejde, og ved større projekter betyder det typisk et forprojekt på 1-3 uger i kalendertid. Det er sjældent udviklerens tid der styrer tempoet, men hvor hurtigt spørgsmålene om omfang, data og integrationer bliver besvaret.

Er et gratis estimat noget værd?+

Et gratis estimat er fint som pejlemærke, men sjældent noget du bør budgettere efter. Det er typisk lavet på kort tid, uden at integrationer og data er undersøgt, så usikkerheden er stor, også selvom tallet ser præcist ud. Brug det til at vurdere om projektet er realistisk, og betal for en ordentlig afklaring, når beløbet er stort nok til at det betyder noget for dig.

Hvad gør jeg, hvis projektet er ved at løbe over estimatet?+

Stop op og find årsagen, før du sætter flere timer af. Er omfanget vokset, så skær noget andet fra eller flyt det til en senere fase. Var en del simpelthen undervurderet, så bed om et nyt estimat på resten, så du kan beslutte på et opdateret grundlag. Det dyreste du kan gøre, er at fortsætte i håbet om at det retter sig selv.

Kan jeg bruge et estimat fra én udvikler til at få tilbud fra andre?+

Ja, hvis du har ret til materialet, og det skal helst stå i aftalen. Et estimat opdelt i dele og med antagelser er et godt grundlag at sende videre, fordi andre så prissætter den samme løsning. Selve tallene er mindre nyttige end beskrivelsen bag dem. Spørg derfor, før du betaler for et forprojekt, om du må dele resultatet med andre leverandører.

Hvorfor estimerer nogle udviklere i story points i stedet for timer?+

Story points er en relativ størrelse som mange agile teams bruger til at sammenligne opgaver indbyrdes, fx at én opgave er dobbelt så stor som en anden. Det hjælper teamet med at planlægge sine sprints, men du kan ikke budgettere direkte efter point. Som kunde bør du altid kunne få estimatet oversat til timer eller kroner, også selvom teamet planlægger internt i point.