jag kommer att ta upp frågan ur programvaruteknikens perspektiv, även om många av lärdomarna också gäller andra projekt. Att producera exakta projektberäkningar är en av de svåraste uppgifterna att göra inom mjukvaruutveckling och en ofta förbisedd färdighet som de flesta ingenjörer (inklusive mig själv) inte vet hur man gör bra. Det är också så att personer som inte har behövt uppskatta slutförandetider för projekt tidigare tenderar att underskatta svårigheten och ofta får sina uppskattningar Felaktiga med minst en faktor två. Som alla färdigheter blir man bara bättre med övning.
mitt mest levande minne av projektberäkningar som gått fel hände några månader efter att ha gått med som ingenjör på Ooyala, en start som gav en end-to-end online videoplattform. I augusti 2008, bara drygt ett år efter att företaget grundades, började ingenjörsteamet arbeta med en omskrivning av produktens flashbaserade videospelare. Våra mål var att göra spelaren mer modulär och mer performant och att också ha en renare och bättre testad kodbas. Ett första team på 3 personer designade och skrev en del kärninfrastruktur innan jag tog in mig själv och resten av ~10-personers ingenjörsteam. De uppskattade 4 månader för projektet att slutföra, och CTO och product manager producerade Gantt-diagram som sammanfattar arbetsfördelning och beroenden. Den nya spelaren slutade helt lansera 9 månader senare i maj 2009 .
vi missade målet inte för brist på hårt arbete eller begåvade ingenjörer; Det fanns en serie månader där de flesta i laget drog 70-80 timmars veckor (rekommenderas inte). Halvvägs genom projektet gick vi till och med noggrant igenom några dagars övningar där vi tilldelade timuppskattningar till ganska granulära uppgifter. De största förseningarna berodde nästan alltid på faktorer, många externa, som vi inte beaktade i de ursprungliga uppskattningarna:
- högprioriterade kundavtal undertecknades som krävde att ingenjörer skulle byta till anpassat arbete,
- buggar i Adobes flash player-kod som gjorde det svårt att exakt bestämma när videon faktiskt pausades, buffrade och spelade,
- svåra att reproducera videokorruptionsfel som skulle krascha spelaren när man söker till vissa videoramar i IE,
- produktutveckling som behöver återuppta 4 månader in i projektet för att hålla den nuvarande kundbasen nöjd,
- skalbarhetsproblem som behövde åtgärdas som mängden analysdata växte,
- en tidig ingenjör som lämnade teamet mitt i projektet, vilket krävde en stor mängd kunskapsöverföring av större delar av kodbasen,
- etc.
medan spelarens omskrivning var definitivt nödvändig för företaget, tog det oförutsedda sättet på vilket släpade ut en stor vägtull på den tidiga starten. Andra projekt som jag har arbetat med, sett begagnade eller pratat med andra ingenjörer om har följt liknande mönster där den faktiska färdigställandetiden ofta fördubblar de ursprungliga uppskattningarna.
här är några av mina takeaway-lektioner så långt från dessa erfarenheter:
så mycket som möjligt, har de personer som producerar uppskattningarna för en uppgift de faktiska människorna som kommer att arbeta med det. Detta liknar Ian McAllisters punkt att använda B-spelarens uppskattning-det är redan oerhört svårt för en person att exakt förutsäga hur lång tid en lista med uppgifter skulle ta sig att göra, även om uppgifterna är ganska granulära; det är ännu svårare att förutsäga hur lång tid det skulle ta någon annan med en annan grad av förtrogenhet och en annan grad av skicklighet. Det blev uppenbart under Ooyalas omskrivning av spelare att många av de ursprungliga uppskattningarna var extremt aggressiva och ignorerade en ingenjörs rampuptid på delar av kodbasen som han var mindre bekant med.
akta dig för andra systemeffekten. I den mytiska Manmånaden beskriver Frederick Brooks från sina projektupplevelser hos IBM hur en mänsklig tendens att överdesignera det andra systemet leder till väsentligt ökad komplexitet, vilket orsakar tidtabeller för redesignprojekt att glida :
en arkitekts första arbete är lämpligt att vara reserv och ren. Han vet att han inte vet vad han gör, så han gör det noggrant och med stor återhållsamhet.
när han designar det första verket, uppstår frill efter frill och utsmyckning efter utsmyckning för honom. Dessa lagras bort för att användas ” nästa gång.”förr eller senare är det första systemet färdigt, och arkitekten, med fast förtroende och en demonstrerad behärskning av den klassen av system, är redo att bygga ett andra system.
denna andra är det farligaste systemet en man någonsin designar… Den allmänna tendensen är att över utforma det andra systemet, med hjälp av alla ideer och krusiduller som var försiktigt sidospår på den första.
speciellt för ett projekt som innebär omskrivning av befintlig programvara är det frestande att bunta en massa nya funktioner i vad som annars kan ha varit en enkel port, med argumentet att laget lika bra kan göra det om de kommer att skriva om kodbasen ändå. Den ökade komplexiteten kan leda till att varken omskrivningen eller de nya funktionerna lanseras förrän betydligt senare.
var försiktig med att sammanföra hur mycket tid ett projekts uppgifter tar med hur snart ett projekt kommer att slutföras. Ju längre ett projekt tar, desto högre är sannolikheten för att externa miljövariabler spelar in och förlänger projektets övergripande tidslinje. Det återkommande draget som Ian nämner bidrar till ett projekts tidslinje, men det gör också oväntade händelser. För projekt som jag har arbetat med tidigare i år på Quora tog ett antal av dem längre tid att starta än väntat på grund av de kumulativa tidskostnaderna för:
- svara på och återhämta sig från ett oväntat, flerdagars AWS-avbrott,
- hantera perioidiska personsökningsvarningar för att hålla webbplatsen uppe,
- schemalagda semestrar som en gång verkade långt borta från ett projekt men som slutade överlappa med det,
- förbereda och delta i rekryteringshändelser,
- kontextväxling mellan flera projekt som visade sig vara svårare än förväntat.
för alla projekt kan man förmodligen lista ett antal händelser och distraktioner som individuellt kan vara osannolika eller okostliga, men som kollektivt är bundna att hända och lägga upp under en tillräckligt lång tidsram. Ju längre projektet är, desto mer distraktioner kommer det att finnas, och det är viktigt att budgetera bufferttid för externa, okända faktorer.
Budget tillräcklig tid för alla integrationsrelaterade uppgifter. Speciellt för projekt med många sammanhängande komponenter tenderar många ingenjörer att 1) skjuta upp integrationsuppgifter från slut till slut och 2) underskatta avsevärt den tid som krävs för att integrera alla bitar i ett arbetssystem. Eftersom integration tenderar att vara så långt borta och eftersom riskerna vanligtvis är okända-antagandet av integrationstiden är att alla komponenter framgångsrikt fungerar isolerat-underskattar integrationstiden tenderar att vara ganska vanligt. Projekt tilldelas ofta bara en liten del av den totala projekttiden för end-to-end-testning, även om det vanligtvis är en av de mer riskfyllda aspekterna av ett projekt och, i jämförelse med tidigare milstolpar, kräver väsentligt mer kommunikationskostnader mellan teammedlemmar.
följden av detta är att starta end-to-end-testning så tidigt som möjligt för att identifiera integrationsrisker och problem tidigare så att det finns tillräckligt med tid att ta itu med dem.
uppskattning baserat på hur lång tid uppgifterna faktiskt tar, inte baserat på hur lång tid du eller någon annan vill att de ska ta. Det kommer alltid att finnas tryck för att slutföra projekt snabbare, antingen från dig själv, från dina teammedlemmar, från ledningen eller från kunder, och ofta förankrar det emotionella svaret på det trycket oss till externt efterfrågade tidslinjer och leder oss till att systematiskt underskatta uppgifter. Psykologiskt vill ingen släppa andra människor, och det är lätt att berätta för dig själv att om du bara arbetar lite hårdare eller mer effektivt kan du möta en viss tidsfrist. Speciellt för långa projekt är dock denna typ av önsketänkande i slutändan ohållbart.
regelbundet se över och revidera projekt uppskattningar som projektet fortskrider. Precis som hur de flesta bra program byggs och förbättras stegvis, så är också projektuppskattningar. Att se över projektberäkningar och jämföra uppskattningar för uppgifter under den senaste veckan med faktisk tid hjälper till att ytbehandla uppskattningsfel och att revidera scheman baserat på tidigare oförutsedda risker.
projektberäkningar tenderar nästan alltid att vara underskattningar snarare än överskattningar; man hör sällan av långa projekt som slutar före schemat. Att vara medveten om att projektuppskattning är svårt och att reflektera över varför uppskattningar gick fel på ett visst projekt leder dig till mindre uppskattningsfel på efterföljande projekt.
det finns mycket mer att utföra på ett projekt än att bara producera exakta uppskattningar. Om du är ingenjör och vill behärska tekniker som används av de bästa mjukvaruingenjörerna för att göra sina projekt till framgångar, ladda ner ett gratis provkapitel i min bok, The Effective Engineer. Den är fylld med hundratals berättelser, insikter och handlingsbara strategier från ledare över hela Silicon Valley.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html