jeg tar opp spørsmålet fra perspektivet til software engineering, selv om mange av erfaringene også gjelder for andre prosjekter også. Å produsere nøyaktige prosjektestimater er en av de vanskeligste oppgavene å gjøre i programvareutvikling og en ofte oversett ferdighet som de fleste ingeniører (inkludert meg selv) ikke vet hvordan de skal gjøre det bra. Det er også slik at folk som ikke har behov for å estimere ferdigstillingstider for prosjekter før, har en tendens til å undervurdere vanskeligheten og ofte får sine estimater feil med minst en faktor på to. Som enhver ferdighet blir man bare bedre med praksis.
mitt mest levende minne om prosjektestimater gått galt skjedde noen måneder etter at han begynte som ingeniør Ved Ooyala, en oppstart som ga en ende-til-ende online videoplattform. I August 2008, bare litt mer enn et år etter at selskapet ble grunnlagt, begynte ingeniørteamet å jobbe med en omskrivning av produktets Flash-baserte videospiller. Våre mål var å gjøre spilleren mer modulær og mer effektiv, og å ha en renere og bedre testet kodebase. Et innledende team på 3 personer designet og skrev noen kjerneinfrastruktur før de trakk inn meg selv og resten av ~10-personteknikkteamet. De estimerte 4 måneder for prosjektet å fullføre, og CTO og produktsjef produserte Gantt-diagrammer som oppsummerte arbeidsavbrudd og avhengigheter. Den nye spilleren endte opp med å lansere 9 måneder senere I Mai 2009 .
Vi savnet målet ikke for mangel på hardt arbeid eller talentfulle ingeniører; det var en serie måneder hvor de fleste på laget trakk 70-80 timers uker (ikke anbefalt). Delvis gjennom prosjektet, vi selv møysommelig gikk gjennom et par dager igjen av øvelser der vi tildelt time estimater til ganske granulære oppgaver. De største forsinkelsene skyldes nesten alltid faktorer, mange eksterne, som vi ikke klarte å vurdere i de første estimatene:
- høyt prioriterte kundeavtaler som ble signert som krevde at ingeniører skulle kontekstere bytte til tilpasset arbeid,
- feil I Adobes flash player-kode som gjorde det vanskelig å fastslå nøyaktig når videoen faktisk ble satt på pause, bufring og avspilling,
- feil som ville krasje spilleren når man søkte på bestemte videorammer I IE,
- produktutvikling som måtte gjenoppta 4 måneder inn i prosjektet for å holde den nåværende kundebasen fornøyd,
- skalerbarhetsproblemer som måtte tas opp som mengden analytics data vokste,
- en tidlig ingeniør forlater teamet midt i prosjektet, noe som krever en stor mengde kunnskapsoverføring av store deler av kodebasen,
- etc.
mens spilleren omskrive var definitivt nødvendig for selskapet, uforutsette måten dratt ut tok en stor toll på tidlig oppstart. Andre prosjekter jeg har jobbet med, sett brukt eller snakket med andre ingeniører om, har fulgt lignende mønstre der faktisk ferdigstillingstid ofte dobler de opprinnelige estimatene.
Her er noen av mine takeaway leksjoner så langt fra disse erfaringene:
så mye som mulig, har de som produserer estimatene for en oppgave, de faktiske menneskene som vil jobbe med den. Det er allerede utrolig vanskelig for en person å nøyaktig forutsi hvor lenge en liste over oppgaver ville ta seg å gjøre, selv om oppgavene er ganske granulære; det er enda vanskeligere å forutsi hvor lang tid det ville ta noen andre med en annen grad av kjennskap og en annen grad av ferdighet. Det ble tydelig Under ooyalas spiller omskrivning at mange av de første estimatene var ekstremt aggressive og ignorert en ingeniørs rampuptid på deler av kodebasen som han var mindre kjent med.
Pass på den andre systemeffekten. I Den Mytiske Man-Month beskriver Frederick Brooks fra sine prosjektopplevelser HOS IBM hvordan en menneskelig tendens til å over-designe det andre systemet fører til betydelig økt kompleksitet, noe som fører til at rutetider for redesignprosjekter glir :
en arkitekts første arbeid er egnet til å være ledig og ren. Han vet at han ikke vet hva han gjør, så han gjør det forsiktig og med stor selvbeherskelse.
når han designer det første arbeidet, oppstår frill etter frill og utsmykning etter utsmykning til ham. Disse blir lagret bort for å bli brukt «neste gang.»før eller senere er det første systemet ferdig, og arkitekten, med fast tillit og en demonstrert mestring av den klassen av systemer, er klar til å bygge et annet system.
dette andre er det farligste systemet en mann noensinne designer… Den generelle tendensen er å over-designe det andre systemet, ved hjelp av alle ideer og frills som var forsiktig sidetracked på den første.
Spesielt for et prosjekt som innebærer omskriving av eksisterende programvare, er det fristende å pakke en rekke nye funksjoner inn i det som ellers kunne ha vært en enkel port, ved å bruke argumentet om at laget også kan gjøre det hvis de skal omskrive kodebasen uansett. Den økte kompleksiteten kan føre til verken omskrivning eller de nye funksjonene lansering før betydelig senere.
Vær forsiktig med å sette sammen hvor mye tid et prosjekts aktiviteter vil ta med hvor snart et prosjekt vil fullføre. Jo lenger et prosjekt tar, desto større er sannsynligheten for at eksterne miljøvariabler spiller inn og utvider den samlede prosjekttidslinjen. Den gjentatte dra Som Ian nevner bidrar til et prosjekt tidslinje, men det gjør også uventede hendelser. For prosjekter som jeg har jobbet med tidligere i år På Quora, tok en rekke av dem lengre tid å starte enn forventet på grunn av kumulative tidskostnader for:
- svarer på og gjenoppretter fra en uventet, flerdagers AWS-strømbrudd,
- håndterer perioidiske personsøkervarsler for å holde nettstedet oppe,
- planlagte ferier som en gang virket langt borte fra et prosjekt, men som endte opp med å overlappe med det,
- forbereder og deltar på rekrutteringshendelser,
- kontekstveksling mellom flere prosjekter det viste seg å være vanskeligere enn først forventet.
for ethvert prosjekt kan man sannsynligvis liste opp et hvilket som helst antall hendelser og distraksjoner som individuelt kan være usannsynlig eller ukjent, men som kollektivt er bundet til å skje og legge opp over en tilstrekkelig lang tidsramme. Jo lengre prosjektet er, desto flere distraksjoner vil det være, og det er viktig å budsjettbuffertid for eksterne, ukjente faktorer.
Budsjett tilstrekkelig tid for integrasjonsrelaterte oppgaver. Spesielt for prosjekter med mange sammenhengende komponenter, har mange ingeniører en tendens til å 1) utsette ende-til-ende integrasjonsoppgaver helt til slutt, og 2) undervurderer betydelig tiden som kreves for å integrere alle delene sammen i et arbeidssystem. Fordi integrasjon har en tendens til å være så langt unna, og fordi risikoen vanligvis er ukjent-forutsetningen ved integrasjonstid er at alle komponentene vellykket fungerer isolert-undervurderer integrasjonstid en tendens til å være ganske vanlig. Prosjekter blir ofte tildelt bare en liten brøkdel av den totale prosjekttiden for ende-til-ende-testing, selv om det vanligvis er en av de risikofylte aspektene ved et prosjekt, og i forhold til tidligere milepæler krever det vesentlig mer kommunikasjon overhead mellom teammedlemmer.
konsekvensen av dette er å starte ende-til-ende-testing så tidlig som mulig for å identifisere integrasjonsrisiko og problemer før, slik at det er nok tid til å løse dem.
Estimat basert på hvor lenge oppgaver faktisk vil ta, ikke basert på hvor lenge du eller noen andre vil at de skal ta. Det vil alltid være press for å fullføre prosjekter raskere, enten fra deg selv, fra teammedlemmene dine, fra ledelsen eller fra kunder, og ofte er den følelsesmessige responsen på det presset forankrer oss til eksternt etterspurte tidslinjer og fører oss til systematisk undervurderer oppgaver. Psykologisk vil ingen la andre mennesker ned, og det er lett å fortelle deg selv at hvis du bare jobber litt hardere eller mer effektivt, kan du møte en bestemt frist. Spesielt for lange prosjekter er denne typen ønsketenkning i siste instans uholdbar.
periodisk revidere og revidere prosjektestimater som prosjektet fortsetter. Akkurat som hvordan de fleste god programvare er bygget og forbedret på trinnvis, så er også prosjektestimater. Revidere prosjektestimater og sammenligne estimater for aktiviteter i den siste uken med faktisk tid tatt hjelp til overflaten estimering feil og å revidere tidsplaner basert på tidligere uforutsette risikoer.
Prosjektestimater pleier nesten alltid å undervurdere i stedet for å overvurdere; man hører sjelden om lange prosjekter som er ferdig før planen. Å være oppmerksom på at prosjektestimering er vanskelig og reflektere over hvorfor estimater gikk galt på et bestemt prosjekt, vil lede deg til mot mindre estimeringsfeil på etterfølgende prosjekter.
det er mye mer å utføre på et prosjekt enn bare å produsere nøyaktige estimater. Hvis du er ingeniør og du vil mestre teknikker som brukes av topp programvareingeniører for å gjøre prosjektene til suksesser, last ned et gratis, prøvekapittel i boken Min, The Effective Engineer. Den er fullpakket med hundrevis av historier, innsikt 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