jeg vil behandle spørgsmålet fra perspektivet af programmel teknik, selv om mange af de erfaringer også gælder for andre projekter samt. At producere nøjagtige projektestimater er en af de sværeste opgaver at udføre inden for programmelteknik og en ofte overset færdighed, som de fleste ingeniører (inklusive mig selv) ikke ved, hvordan de skal klare sig godt. Det er også tilfældet, at folk, der ikke har brug for at estimere færdiggørelsestider for projekter før, har tendens til at undervurdere vanskeligheden og ofte får deres estimater forkert med mindst en faktor på to. Som enhver færdighed bliver man kun bedre med praksis.
min mest levende hukommelse af projektestimater, der er gået galt, skete et par måneder efter at være blevet ingeniør hos Ooyala, en opstart, der gav en ende-til-ende online videoplatform. I August 2008, kun lidt mere end et år efter, at virksomheden blev grundlagt, begyndte ingeniørteamet at arbejde på en omskrivning af produktets flashbaserede videoafspiller. Vores mål var at gøre spilleren mere modulær og mere performant og også have en renere og bedre testet kodebase. Et indledende team på 3 personer designet og skrev nogle kerneinfrastrukturer, før de trak mig selv og resten af ~10-personers ingeniørhold. De anslog 4 måneder for projektet at gennemføre, og CTO og product manager producerede Gantt-diagrammer, der opsummerede arbejdsopdelingen og afhængighederne. Den nye spiller endte med at lancere 9 måneder senere i maj 2009 .
vi savnede målet ikke på grund af manglende hårdt arbejde eller talentfulde ingeniører; der var en række måneder, hvor de fleste på holdet trak 70-80 timers uger (anbefales ikke). Halvvejs gennem projektet gik vi endda omhyggeligt igennem et par dages øvelser, hvor vi tildelte timestimater til ret granulære opgaver. De største forsinkelser skyldes næsten altid faktorer, mange eksterne, som vi ikke overvejede i de oprindelige estimater:
- kundeaftaler med høj prioritet, der blev underskrevet, der krævede, at ingeniører skiftede kontekst til brugerdefineret arbejde,
- fejl i Adobes flash player-kode, der gjorde det vanskeligt nøjagtigt at bestemme, hvornår videoen faktisk blev sat på pause, bufferet og afspillet,
- svære at gengive videokorruptionsfejl, der ville gå ned i afspilleren, når de søgte til bestemte videobilleder i IE,
- produktudvikling, der skulle genoptages 4 for at holde den nuværende kundebase glad,
- skalerbarhedsproblemer, der skulle løses som mængden af analytics-data voksede,
- en tidlig ingeniør, der forlod teamet midt i projektet, hvilket nødvendiggjorde en stor mængde videnoverførsel af store dele af kodebasen,
- etc.
mens spilleren omskrivning var absolut nødvendigt for virksomheden, den uforudsete måde, hvorpå trukket ud tog en stor vejafgift på den tidlige opstart. Andre projekter, jeg har arbejdet på, Set brugt eller talt med andre ingeniører om, har fulgt lignende mønstre, hvor den faktiske færdiggørelsestid ofte fordobler de oprindelige estimater.
her er nogle af mine afhentningstimer så langt fra disse oplevelser:
så meget som muligt, lad de mennesker, der producerer estimaterne for en opgave, være de faktiske mennesker, der vil arbejde på det. Det er allerede utroligt svært for en person at præcist forudsige, hvor lang tid en liste over opgaver ville tage sig selv at gøre, selvom opgaverne er ret granulære; det er endnu sværere at forudsige, hvor lang tid det ville tage en anden med en anden grad af fortrolighed og en anden grad af færdighed. Det blev tydeligt under ooyalas spiller omskrivning, at mange af de oprindelige skøn var ekstremt aggressive og ignorerede en ingeniørs rampup-tid på dele af kodebasen, som han var mindre fortrolig med.
pas på den anden systemeffekt. I den mytiske Mandmåned beskriver Frederick Brooks fra sine projektoplevelser hos IBM, hvordan en menneskelig tendens til at overdesigne det andet system fører til væsentligt øget kompleksitet, hvilket får tidsplaner for redesignprojekter til at glide :
en arkitekts første arbejde er egnet til at være ekstra og ren. Han ved, at han ikke ved, hvad han laver, så han gør det omhyggeligt og med stor tilbageholdenhed.
da han designer det første værk, opstår frill efter frill og udsmykning efter udsmykning for ham. Disse bliver gemt væk for at blive brugt “næste gang.”før eller senere er det første system færdigt, og arkitekten er med fast tillid og en demonstreret beherskelse af den klasse af systemer klar til at bygge et andet system.
dette sekund er det farligste system, en mand nogensinde designer… Den generelle tendens er at overdesigne det andet system ved hjælp af alle de ideer og dikkedarer, der forsigtigt blev sidesporet på den første.
især for et projekt, der involverer omskrivning af eksisterende programmer, er det fristende at samle en masse nye funktioner i, hvad der ellers kunne have været en ligetil port, ved hjælp af argumentet om, at holdet lige så godt kan gøre det, hvis de alligevel vil omskrive kodebasen. Den øgede kompleksitet kan føre til, at hverken omskrivningen eller de nye funktioner lanceres før markant senere.
vær forsigtig med at samle, hvor lang tid et projekts opgaver vil tage, med hvor hurtigt før et projekt afsluttes. Jo længere et projekt tager, jo større er sandsynligheden for, at eksterne miljøvariabler kommer i spil og udvider den samlede projekttidslinje. Det tilbagevendende træk, som Ian nævner, bidrager til et projekts tidslinje, men det gør også uventede begivenheder. For projekter, som jeg har arbejdet på tidligere i år på kvora, tog en række af dem længere tid at lancere end forventet på grund af de kumulative tidsomkostninger for:
- at reagere på og komme sig efter en uventet, flerdags-strømafbrydelse,
- håndtering af perioidiske personsøgervarsler for at holde stedet op,
- planlagte ferier, der engang syntes langt væk fra et projekt, men som endte med at overlappe med det,
- forberedelse til og deltagelse i rekrutteringsbegivenheder,
- kontekstskift mellem flere projekter det viste sig at være vanskeligere end oprindeligt forventet.
for ethvert projekt kunne man sandsynligvis liste et hvilket som helst antal begivenheder og distraktioner, der individuelt kan være usandsynlige eller uhyrlige, men som kollektivt er bundet til at ske og tilføje op over en tilstrækkelig lang tidsramme. Jo længere projektet er, jo flere distraktioner vil der være, og det er vigtigt at budgettere buffertid for eksterne, ukendte faktorer.
Budget tilstrækkelig tid til eventuelle integrationsrelaterede opgaver. Især for projekter med mange indbyrdes forbundne komponenter har mange ingeniører en tendens til at 1) udsætte end-to-end integrationsopgaver helt til slutningen, og 2) undervurderer den tid, der kræves for at integrere alle brikkerne sammen i et arbejdssystem. Fordi integration har tendens til at være så langt væk, og fordi risiciene typisk er ukendte-antagelsen ved integrationstid er, at alle komponenter med succes fungerer isoleret-undervurderer integrationstiden en tendens til at være ret almindelig. Projekter tildeles ofte kun en lille brøkdel af den samlede projekttid til ende-til-ende-test, selvom det typisk er et af de mere risikable aspekter af et projekt og i sammenligning med tidligere milepæle kræver væsentligt mere kommunikationsomkostninger mellem teammedlemmer.
konsekvensen af dette er at starte end-to-end test så tidligt som muligt for at identificere integrationsrisici og problemer hurtigere, så der er tid nok til at løse dem.
skøn baseret på, hvor lang tid opgaver rent faktisk vil tage, ikke baseret på hvor lang tid du eller en anden vil have dem til at tage. Der vil altid være pres for at gennemføre projekter hurtigere, enten fra dig selv, fra dine teammedlemmer, fra ledelsen eller fra kunder, og ofte forankrer den følelsesmæssige reaktion på dette pres os til eksternt krævede tidslinjer og fører os til systematisk at undervurdere opgaver. Psykologisk ønsker ingen at svigte andre mennesker, og det er let at fortælle dig selv, at hvis du bare arbejder lidt hårdere eller mere effektivt, kan du overholde en bestemt frist. Især for lange projekter er denne type ønsketænkning imidlertid i sidste ende uholdbar.
regelmæssigt gennemgå og revidere projektestimater, når projektet fortsætter. Ligesom hvordan de fleste gode programmer er bygget og forbedret trinvist, så er også projektoverslag. Revision af projektestimater og sammenligning af estimater for opgaver i den forløbne uge med det faktiske tidsforbrug hjælper med at overfladestimeringsfejl og revidere tidsplaner baseret på tidligere uforudsete risici.
projektestimater har næsten altid tendens til at være undervurderer snarere end overvurderer; man hører sjældent om lange projekter, der afsluttes forud for tidsplanen. At være opmærksom på, at projektestimering er svært og reflektere over, hvorfor estimater gik galt på et bestemt projekt, vil guide dig til mod mindre estimeringsfejl på efterfølgende projekter.
der er meget mere at udføre på et projekt end blot at producere nøjagtige estimater. Hvis du er ingeniør, og du vil mestre teknikker, der bruges af topingeniører til at gøre deres projekter til succeser, skal du hente et gratis, prøvekapitel i min bog, Den effektive ingeniør. Det er fyldt med hundredvis af historier, indsigter og handlingsstrategier fra ledere over hele Silicon Valley.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html