Affronterò la questione dal punto di vista dell’ingegneria del software, anche se molte delle lezioni apprese si applicano anche ad altri progetti. Produrre stime accurate del progetto è uno dei compiti più difficili da fare nell’ingegneria del software e un’abilità spesso trascurata che la maggior parte degli ingegneri (me compreso) non sa come fare bene. È anche il caso che le persone che non hanno avuto bisogno di stimare i tempi di completamento per i progetti prima tendono a sottovalutare la difficoltà e spesso sbagliano le loro stime di almeno un fattore due. Come ogni abilità, si migliora solo con la pratica.
Il mio ricordo più vivido di stime di progetto andato storto è accaduto pochi mesi dopo l’adesione come ingegnere a Ooyala, una startup che ha fornito una piattaforma video online end-to-end. Nell’agosto 2008, solo poco più di un anno dopo la fondazione della società, il team di ingegneri ha iniziato a lavorare su una riscrittura del lettore video basato su Flash del prodotto. I nostri obiettivi erano di rendere il lettore più modulare e più performante e di avere anche una base di codice più pulita e meglio testata. Un team iniziale di persone 3 ha progettato e scritto alcune infrastrutture principali prima di coinvolgere me stesso e il resto del team di ingegneri ~10. Hanno stimato 4 mesi per il completamento del progetto e il CTO e il product manager hanno prodotto grafici di Gantt che riassumono la ripartizione del lavoro e le dipendenze. Il nuovo giocatore ha finito per lanciare completamente 9 mesi più tardi nel maggio 2009 .
Abbiamo mancato l’obiettivo non per mancanza di duro lavoro o ingegneri di talento; ci sono stati una serie di mesi in cui la maggior parte delle persone del team ha tirato 70-80 ore settimane (non raccomandato). Partway attraverso il progetto, abbiamo anche faticosamente passato attraverso un paio di giorni di esercizi in cui abbiamo assegnato stime orarie a compiti abbastanza granulari. I maggiori ritardi derivano quasi sempre da fattori, molti esterni, che non siamo riusciti a considerare nelle stime iniziali:
- alta priorità cliente si occupa della firma del contratto che ha richiesto ingegneri a commutazione di contesto di lavoro personalizzato,
- bug di Adobe flash player il codice che ha reso difficile determinare con precisione quando il video è stato effettivamente messo in pausa, buffer e la riproduzione,
- difficili da riprodurre video corruzione bug che avrebbe il lettore si blocca quando cerco di alcuni fotogrammi del video in IE,
- sviluppo prodotto la necessità di riprendere a 4 mesi nel progetto al fine di mantenere l’attuale base di clienti felici,
- scalabilità problemi che devono essere risolti, come la quantità di i dati analitici sono cresciuti,
- un ingegnere precoce che lascia il team a metà progetto, richiedendo una grande quantità di trasferimento di conoscenze delle parti principali della base di codice,
- ecc.
Mentre la riscrittura del giocatore era sicuramente necessaria per l’azienda, il modo imprevisto in cui è stato trascinato ha avuto un grande tributo all’avvio iniziale. Altri progetti su cui ho lavorato, visto di seconda mano o parlato con altri ingegneri, hanno seguito modelli simili in cui il tempo di completamento effettivo spesso raddoppia le stime originali.
Ecco alcune delle mie lezioni da asporto così lontane da queste esperienze:
Per quanto possibile, le persone che producono le stime per un compito sono le persone reali che lavoreranno su di esso. Questo è simile al punto di Ian McAllister di usare la stima del giocatore B – è già incredibilmente difficile per una persona prevedere con precisione quanto tempo una lista di compiti si impiegherebbe a fare, anche se i compiti sono abbastanza granulari; è ancora più difficile prevedere quanto tempo ci vorrebbe qualcun altro con un diverso grado di familiarità e un diverso grado di abilità. È diventato evidente durante la riscrittura del giocatore di Ooyala che molte delle stime iniziali erano estremamente aggressive e ignoravano il tempo di accelerazione di un ingegnere su parti della base di codice che aveva meno familiarità con.
Attenzione all’effetto del secondo sistema. Nel mitico Uomo-mese, Frederick Brooks descrive dalle sue esperienze di progetto presso IBM come una tendenza umana a over-design del secondo sistema porta ad un aumento sostanziale complessità, causando orari di progetti di riprogettazione a scivolare :
Il primo lavoro di un architetto è adatto per essere libero e pulito. Sa di non sapere quello che sta facendo, quindi lo fa con attenzione e con grande moderazione.
Mentre disegna il primo lavoro, frill dopo frill e abbellimento dopo abbellimento si verificano a lui. Questi vengono conservati per essere usati ” la prossima volta.”Prima o poi il primo sistema è finito, e l’architetto, con ferma fiducia e una padronanza dimostrata di quella classe di sistemi, è pronto a costruire un secondo sistema.
Questo secondo è il sistema più pericoloso che un uomo abbia mai progettato… La tendenza generale è quella di over-progettare il secondo sistema, utilizzando tutte le idee e fronzoli che sono stati cautamente sviato sul primo.
Soprattutto per un progetto che prevede la riscrittura del software esistente, si è tentati di raggruppare una serie di nuove funzionalità in quella che altrimenti avrebbe potuto essere una porta semplice, usando l’argomento che il team potrebbe anche farlo se riscriveranno comunque la base di codice. L’aumento della complessità può portare né la riscrittura né le nuove funzionalità di lancio fino a molto più tardi.
Fai attenzione a confondere quanto tempo impiegheranno le attività di un progetto con quanto tempo prima che un progetto finisca. Più tempo impiega un progetto, maggiore è la probabilità che le variabili ambientali esterne entrino in gioco ed estendano la cronologia complessiva del progetto. Il trascinamento ricorrente che Ian menziona contribuisce alla timeline di un progetto, ma anche agli eventi imprevisti. Per i progetti su cui ho lavorato all’inizio di quest’anno a Quora, alcuni di essi hanno richiesto più tempo del previsto a causa dei costi di tempo cumulativi di:
- la risposta e recupero da un imprevisto, multi-giorno AWS interruzione,
- gestione perioidic cercapersone dovere avvisi a mantenere il sito,
- programmato le vacanze che una volta sembrava lontano da un progetto, ma che ha finito per sovrapposizione con esso,
- preparazione e partecipazione agli eventi di reclutamento,
- cambio di contesto tra più progetti, che si è rivelato più complicato di quanto inizialmente previsto.
Per qualsiasi progetto, si potrebbe probabilmente elencare un numero qualsiasi di eventi e distrazioni che individualmente potrebbero essere improbabili o sconvenienti, ma che collettivamente sono destinati ad accadere e si sommano in un lasso di tempo sufficientemente lungo. Più lungo è il progetto, più distrazioni ci saranno, ed è importante budget buffer tempo per esterni, fattori sconosciuti.
Budget di tempo sufficiente per qualsiasi attività correlata all’integrazione. Soprattutto per i progetti con molti componenti correlati, molti ingegneri tendono a 1) posticipare le attività di integrazione end-to-end fino alla fine e 2) sottovalutare significativamente la quantità di tempo necessaria per integrare tutti i pezzi insieme in un sistema di lavoro. Poiché l’integrazione tende ad essere così lontana e poiché i rischi sono tipicamente sconosciuti-l’ipotesi per tempo di integrazione è che tutti i componenti funzionino con successo in isolamento-sottovalutare il tempo di integrazione tende ad essere abbastanza comune. I progetti spesso vengono assegnati solo una minuscola frazione del tempo totale del progetto per i test end-to-end, anche se in genere è uno degli aspetti più rischiosi di un progetto e, rispetto alle pietre miliari precedenti, richiede un sovraccarico di comunicazione sostanzialmente maggiore tra i membri del team.
Il corollario di questo è iniziare i test end-to-end il prima possibile per identificare i rischi e i problemi di integrazione prima in modo che ci sia abbastanza tempo per affrontarli.
Stima in base a quanto tempo le attività impiegheranno effettivamente, non in base a quanto tempo tu o qualcun altro volete che prendano. Ci sarà sempre una pressione per completare i progetti più velocemente, sia da te stesso, dai membri del tuo team, dal management o dai clienti, e spesso la risposta emotiva a tale pressione ci ancora a scadenze richieste dall’esterno e ci porta a sottovalutare sistematicamente le attività. Psicologicamente nessuno vuole deludere le altre persone, ed è facile dire a te stesso che se lavori un po ‘ più duramente o in modo più efficiente, puoi rispettare una certa scadenza. Soprattutto per i progetti lunghi, tuttavia, questo tipo di pio desiderio è in ultima analisi insostenibile.
Riesaminare e rivedere periodicamente le stime del progetto man mano che il progetto procede. Proprio come la maggior parte del buon software è costruita e migliorata in modo incrementale, così anche le stime del progetto. Rivedere le stime del progetto e confrontare le stime per le attività della scorsa settimana con il tempo effettivo impiegato aiuta a superare gli errori di stima e a rivedere i programmi in base a rischi precedentemente imprevisti.
Le stime dei progetti tendono quasi sempre a essere sottovalutate piuttosto che sovrastimate; raramente si sente parlare di progetti lunghi che terminano prima del previsto. Essere consapevoli che la stima del progetto è difficile e riflettere sul perché le stime sono andate male su un particolare progetto ti guiderà verso errori di stima più piccoli sui progetti successivi.
C’è molto di più da eseguire su un progetto che solo la produzione di stime accurate. Se sei un ingegnere e vuoi padroneggiare le tecniche utilizzate dai migliori ingegneri del software per trasformare i loro progetti in successi, scarica un capitolo di esempio gratuito del mio libro, The Effective Engineer. È ricco di centinaia di storie, approfondimenti e strategie attuabili dai leader di tutta la Silicon Valley.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html