Et estimat er IKKE en forpligtelse

Projektleder: ”Hvornår kan I være færdige med komponeten til ERP-integration?”
Udvikler: ”Tja, vi har estimeret den til 5 dage, og da vi ikke er kommet i gang med opgaven endnu, så er det stadig bedste bud.”
Projektleder: ”Er det 5 arbejdsdage?”
Udvikler: ”Øh, ja, vi regner med det tager 5 dage, hvis alt gå godt...”
Projektleder: ” Det er fint, 5 arbejdsdage, og det er mandag i dag...dvs. at den er klar på fredag .”
Udvikler: ”Fredag? Det tror jeg ikke du skal regne med, men spørg mig igen i morgen eftermiddag, så kan jeg sige det mere præcist.”
Projektleder: ” Mere præcist? Har du ikke lige sagt komponenten er færdig om 5 dage? Og hvis du arbejder på den hver dag i denne uge, og så måske giver den en skalle en aften, så er den vel færdig på fredag, hvis ellers jeg kan regne...”
Udvikler: ” Måske er den færdig på fredag, men jeg kan ikke sige det mere præcist nu.
Projektleder: ”Ok, jeg siger til kunden at vi er færdige med komponeten på fredag som vi har lovet!”

Kan du nikke genkendende til ovenstående dialog mellem en projektleder og en udvikler? Eller er det et fuldkomment urealistisk & tænkt eksempel, som ikke har gang på denne jord ...?

Jeg tror de fleste udviklere har prøvet at stå i en situation, hvor deres estimater bliver opfattet som en forpligtelse til at levere på et bestemt tidspunkt. Og det er en kilde til mange alvorlige problemer i et it-projekt!

Det er egentlig utroligt, når man tænker på, at dygtige mennesker har skrevet stolpe op & stolpe ned om estimering inden for softwareudvikling. Man fristes til at mene, at der må gå en masse sindssyge mennesker rundt i vores branche, hvis sindssyge kan defineres ved, at man foretager de samme handlinger om og om igen, men alligevel forventer forskellige resultater hver gang!

For ikke at blive beskyldt for at være useriøs har jeg slået ordene estimat og forpligtelse  op i værker, som må betegnes som værende rimelige troværdige kilder:

Estimat: ”Statistisk udregnet skøn over den faktiske værdi af en talstørrelse ud fra et sæt måleresultater”
Kilde: Gyldendals encyklopædi – (statistik og matematik)

Forpligtelse: ”Det forhold, at man forpligter sig  til noget; skyldighed; pligt; ogs. mere konkr.: betingelse, som man forpligter sig til at opfylde
Kilde: Ordbog over det danske sprog

Det burde være indelysende for enhver, at man ikke kan forpligte sig til at aflevere noget, som er baseret på et skøn, selvom det i bedste fald er underbygget af noget erfaring eller empiriske data.

En særlig variant af begrebet estimat er det i udviklerkredse nok så bekendte ”guesstimat”.  Det er det man ofte bruger, når de empiriske data ikke er tilstede  og erfaringen også er sparsom, f.eks. når man har intet eller kun lidt kendskab til den opgave man skal i gang med, men alligevel skal komme med et bud på hvor lang tid det tager.

Det giver ikke mening at komme med et længere blog indlæg om hvordan man skal estimere, og ikke mindst, at komme med værktøjer og gode argumenter – der findes en masse god litteratur om emnet, og jeg kan klart anbefale at læse Mike Cohns bog ”Agile estimating and planning”.  Den findes også min liste over gode  bøger her på bloggen.

Ligeledes har Giovanni Asproni skevet en glimrende artikel om emnet ” Fingers in the air: a Gentle Introduction to Software Estimation”, som enhver softwareudvikler og ikke mindst projektleder, burde læse igennem.

Og lad mig så lige til sidst slå fast med syvtommersøm:

Et estimat er IKKE en forpligtelse og det er IKKE til forhandling.

Hvor svært kan det være?