Pizza estimering

Det har krævet en del overdådige måltider, en overordentlig mængde mozzarella, oregano og pepperoni, men efter mange års hård og opslidende research er jeg nu kommet frem til følgende:

9 ud af 10 pizzamænd vil afgive enslydende svar på følgende spørgsmål: "Hvornår kan jeg hente mine pizzaer?"

og svaret vil lyde: "15 minutter"

Uanset om jeg bestiller en king size meatlover med ekstra spicy tilbehør, en flad margherita eller den helt store veggielover med alt fra asparges over jalepeños til skorzonerødder...

15 min it is - every bloody time...

Gæt et tal Estimering er øvelsen hvor man forsøger at finde et tal, der passer til en opgave af en given kompleksitet. Tallet findes ud fra hvor produktiv man vurderer sig selv til at være, gerne tillagt en usikkerhed ved uforudsete udfordringer. Det er en udbredt holdning blandt udviklere, at Pi er den rette usikkerhedsfaktor at gange med, men det er vist ikke videnskabeligt bevist ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Sjovt er det som udvikler når man lige har fyldt et helt Excel regneark ud med estimater og så får at vide af sin projektleder, at man nu skal afgive nogle nye tal på samme opgave. Tallene skal denne gang afspejle at opgaven løses af en (endnu ikke navngiven) udvikler med mindre erfaring end en selv. Første gang jeg stødte på denne udfordring gik jeg tilbage i mit regneark og tilføjede én ny aktivitet med titlen "ramp-up time" til X timer.

Done - send til projektleder.

Selvom jeg nok kan sætte mig ind i de udfordringer en mindre erfaren udvikler måtte gå igennem, så har jeg ingen ide om hvordan vedkommende performer, og kan kun gætte på hvad tallene så skal være....

Udfordringer med estimaterne

En anden spøjs udfordring ved estimater er andres holdning til dine estimater.

Den nemme: Hvis du bruger mere tid end estimeret, skal du som regel blot redegøre for hvorfor opgaven tager længere tid. Her er PC problemer, netværksproblemer og forstyrrende kolleger der skal have support altid nogle velpassende undskyldninger at slynge ud ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Hvis du bliver færdig før tid er dine udviklerkolleger nok ret imponerede - men din projektleder er skeptisk: Hvad har du mon glemt ? Og er du virkelig SÅ dårlig til at estimere.

Når du dine ting præcis på estimatet, så har du VIRKELIG dummet dig. Projektlederen bliver mistænksom: Var du mon færdig før tid og har du blot siddet idle indtil tiden var forbrugt ? Dine udviklerkolleger er heller ikke begejstrede. De ved jo at estimering ikke er en nøjagtig disciplin ligesom udvikling heller ikke er det, så hvordan kan de to overhovedet ramme samme timetal ?

Gyldne regler Hvis du vil bruge estimering til noget fornuftigt - uanset om du gør det på din egen måde, poker måden eller russisk roulette måden, så følg for din egen skyld op på tallene og lær af dem. Hvorfor brugte du for meget ' Hvad gik galt ' Eller hvad gik bedre end forventet ?

På et tidspunkt gjorde jeg det til en vane at notere alle de aktiviteter der sneg sig ind oveni i den opgave jeg estimerede. Ups, jeg brugte for lang tid på fejlretning, eller test tog for lang tid - eller jeg undervurderede hvor svært det kan være at skrive en specifik stump kode. Eller - den klassiske - kravene til opgaven ændrede sig. Op til flere gange !!

Hvad problemet end er, så klæder det dig bedre på til at forstå dit input til estimaterne næste gang.

Og tilbage i pizzaland..

Skulle vi teste om pizzafolk kan afgive 15-minutters estimater de rent faktisk kunne holde, så burde vi jo nok ringe tilbage 5 min. efter bestilling og ændre et par ingredienser. Og så ringe igen 5 minutter senere og ændre bunden fra classic style til american deep pan...

Så kan de lære hvor hårdt det er at lave IT, ja de kan ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Tommy Dejbjerg Pedersens billede

Kommentarer (12)

Jens Fallesen

Sjovt at du skriver 15 minutter, for jeg har fra utallige pizzamænd fået netop 10 minutter som svar hver gang.

Der var dog lige en lejlighed, hvor vi bestilte i omegnen af 20 pizzaer til et eller andet nørdarrangement. Der blev igen sagt »10 minutter«, hvilket vi dristede os til at tvivle lidt på, når der nu var så mange pizzaer. Et sekunds tænkepause … »11 minutter«. :-)

Men du har ret i, at estimering er en besværlig disciplin. Og den bliver ikke nemmere af, at man i sin beregning også skal medtage, hvem der beder om estimatet.

Hvis en sælger beder mig komme med et bud på, hvor hurtigt jeg kan sætte en MPLS-core op, kan jeg være sikker på, at han regner det om til en pris, som kunden vil holde os op på. Tilmed skal jeg kende kunden, for netop hos kunde X tager projekter altid 20 % længere tid, fordi den ansvarlige tekniker kan tale en vis herre et øre af.

Når projektlederen spørger mig, skal jeg helst ramme præcist, for hun står med et puslespil af opgaver og ressourcer, der skal passe sammen. Som du selv er inde på, er det her en hårfin balance – for lidt tid afsat får planen til at skride, for meget tid ses som spild.

Ét er dog sikkert: Alt for mange teknikere er slet ikke gode nok til at komme med den slags estimater (mig selv inklusiv fra tid til anden), så der er nok en grund til, at nogle af vores sælgere typisk lægger 50 % til et estimat, inden de laver et tilbud …

Død Profil

(Hvad med I hele sin karriere så?)

Måske det er lidt lettere at estimere hvis man gjorde :)

I forbindelse med outsourcede programmerm synes jeg ofte at være kommet ud for at skulle specificere ændringer, ned i en sådan detaljerings-grad ,at det ville være lettere selv at lave dem. Hvis man skærer alt projekt-gejlet udenom til at få ændringen igennem væk, så passer det estimat som er lavet på den velspecificerede opgave typisk ret præcist.

Som du så er inde på, så når kompleksiteten bliver større end man kan overskue, så bliver det til gætværk - og hvordan man end ganger op, så passer det altid med estimatet + den tid det reelt vil tage at lave ændringen :)

Mvh,
Søren

Jakob Veje Hansen

At producere en pizza er en driftsopgave og ikke en projektopgave. Opgaven er ikke unik, og den har heller ikke kompleksitet der gør det relevant at betragte den som et projekt.

Den konstante udmelding på 15 minutter kan jeg sagtens genkende. Det til trods, oplever jeg stor varians mellem de udmeldte 15 minutter, og det tidsrum der passerer jf. køkkenuret i huset. I min omgangskreds er den populære forklaring den, at tiden må bevæge sig relativt anderledes i et pizzaria end i den omkringliggende verden, således at der rent faktisk kun går 15 minutter i pizzariet, imens der ude omkring går 45 minutter. For netop på grund af opgavens driftslignende karakteristika, burde det da ikke være så svært at estimere den!?

Om den dybere årsag til hvorfor der skulle være en tidslomme? Måske stenovnene er så tunge, at de krummer selve rum/tiden omkring pizzariaet?

Jakob Veje Hansen

Eller skyde med elastikker hvis man selv har en bar numse :)

Det har du ret i. Set med produktionschefens briller, er det nu også hårde odds et pizzaria er oppe imod:

  1. Produktionskapaciteten er relativt lille, og dermed følsom overfor selv små udsving i bemandings-situationen og/eller værktøjer og råvarer.

  2. Ditto følsom i forhold til ekstra ordrer, der hurtigt kan fordoble eller måske endda 3-doble kravet om produktioner.

  3. Ordrer skal accepteres og produceres med det samme. Kapacitetsudjævning af ordrer accepteres ikke. Lead time er under 30 minutter - i mange tilfælde inkl. transport til kunden, der kan befinde sig et vilkårligt sted i området.

  4. Kundernes krav om lave priser medfører et produktionsmiljø, der kun liiige slår til i forhold til behovet.

Kristian Poulsen

Jeg har prøvet et par gange at ryge ind i en deadlock hvad angår estimering af opgaver (og dermed pris) når det handler om EU udbud.

I mange af de udbud jeg har haft i hænderne, står der at kunden ønsker at vi skal integreres til forskellige systemer, men uden at der er fastlagt nogen interfaces.

Det vil sige at man skal til at estimere noget som ikke er beskrevet, og hvor der typisk også er en anden leverandør i spil. Det bliver straks mere absurd, når man i et forsøg på at blive klogere (og måske også i strid med udbudsreglerne) kontakter kundens leverandør for at spørge om hvordan en løsning kunne skrues sammen, blot for at finde ud af at leverandøren intet kender til ønsker om integration.

Hvad gør man så ???

Såvidt jeg ser det vender opgaven nu 180 grader. Den skal godt nok estimeres efter bedste evne, men samtidig skal der opstilles en lang række CMA (cover-my-ass) betingelser og restriktioner. Det betyder at man bruger relativt meget tid på at finde ud af hvad det egentlig er kunden ønsker, men pga udbudsreglerne må man jo ikke lige snakke med kunden.
De spørgerunder der måtte være bliver pludselig et taktisk spil om ikke at sige mere end højest nødvendigt for ikke at give konkurrenterne gode ideer.

Kort sagt - jeg hader at estimere EU udbud, men det kan være at jeg skal få pizzamanden til det næste gang :-)

Morten Fordsmand

En gangda jeg skulle estimere en teknisk programmerins opgave, der skulle leveres som en del af et projet, sørgede jeg for at estimatet tog højde for en lang række risici, da man jo godt kan bruge et par dage med at komme uden om diverse udokumenterede features. Estimatet blev godkendt og dokumenteret som en unerleveranc.
Jeg gik i gang, men var faktisk ydderst heldig, for det gik lige ud af landevejen, og opgaven der var estimeret til at kunne tage 40 timer var løst på en dags tid.
Jeg afleverede resultatet og rappoterede opgaven færdig.
Men nu opstod problemet kunden ville gerne vide hvornår vi leverede de tilbageværende 30 timer, (som de ikke var faktureret for)

Mads N. Vestergaard

Det er da klart... Som Kunde vil jeg da også antage at noget er helt galt, hvis tingene kun tager 1/4 af tiden.

Godt nok er der mange parametre der kan snige sig ind når man skal estimere, men det der er da et stort skud ved siden af, specielt når der ikke er tale om mere tid end man kan se det inden for 1 uge eller 2.

Jeg ville som kunde også stille spørgsmålstegn ved det.

Log ind eller opret en konto for at skrive kommentarer