Post-progetto Incontrare uno spreco di tempo?

Nel mio posto di lavoro, abbiamo avuto alcuni gravi problemi di crescita. Siamo passati da un team di sviluppo da 3 a 10 e la società stessa è cresciuta del 30% nell'ultimo anno. Con la maggior parte delle misurazioni, stiamo andando bene. Sfortunatamente, la qualità del nostro software ha sofferto.

Oggi, in un incontro con il direttore della mia divisione, ho proposto un incontro del team di progetto un giorno o due dopo il lancio del prodotto. Potremmo discutere di problemi di budget, portata, cosa è andato storto e cosa è andato bene. Idealmente, imparando dai nostri errori. Costruiamo siti / app per altre persone, quindi il nostro tempo è fatturabile o non fatturabile. Un incontro come questo rientrerebbe in quest'ultimo.

Il mio manager ha eliminato quasi immediatamente: "Quel tempo non è fatturabile. Ci farà tornare indietro su un altro progetto perché perdiamo tempo alla fine di quello che ne parliamo." Ero così preso alla sprovvista da questa logica che non mi sono nemmeno preoccupato di combatterlo.

Quindi la mia domanda: vedo che il valore sono le riunioni post-progetto, ma non lo fa. Esistono prove documentate delle riunioni post-progetto che aiutano a risparmiare tempo e denaro nel lungo (o nel breve) periodo? Intuitivamente penso che lo farà / lo farebbe, ma chiaramente è più preoccupato per una piccola quantità di tempo non fatturabile da parte delle 5 persone che dovrebbero essere presenti.

Guardando indietro, guardando avanti sarebbe vicino alla prova documentata sull'idea. Il progetto Post-Mortem: uno strumento prezioso per il miglioramento continuo sarebbe un post sul blog al riguardo.

The Art Of The Post-Mortem ha questo punto sull'idea:

Le origini del Post-Mortem sono con i militari, che usano abitualmente questo tipo di processo per interrogare le persone in prima linea. Ma la sua applicazione di gestione è essenziale per qualsiasi organizzazione di apprendimento ad alte prestazioni.

Il tuo manager non capisce il concetto di debito tecnico .

Le riunioni post-progetto sono un investimento, non un costo. È così che devi venderli. Lo scopo di ogni incontro è scambiare idee su come risparmiare denaro e realizzare gli obiettivi dell'azienda a lungo termine.

Il tuo manager è un manager perché si occupa di questi obiettivi a lungo termine. Quindi, a mio avviso, ci sono due possibili verità: il tuo manager vuole tutto il controllo per se stesso o il tuo manager non sta facendo il suo lavoro. Se la società ha una storia e una filosofia di fare le cose "nel modo giusto" e di investire nel proprio successo, considera di prendere la questione al di sopra del tuo manager.

Questa è essenzialmente una revisione dopo l'azione , che è particolarmente utile in molti contesti diversi, non solo militari.

Il mio ciclo di sviluppo prevede l'analisi sia di ciò che dovrebbe essere fatto nella prossima iterazione o progetto sia di ciò che potrebbe essere fatto meglio nel progetto precedente. Anche se un progetto viene archiviato per un po ', avere un elenco di cose su cui lavorare aiuta quando esce dallo scaffale (o backburner ...) ed è di nuovo un progetto attivo. La prossima volta che lo tocco, non devo passare troppo tempo a rivedere ciò che devo fare.

Inoltre, rivedendo un progetto e trovando i trucchi accurati che io o altri abbiamo implementato, questi vengono divulgati e il prossimo progetto o la prossima iterazione è molto meglio. (Potrebbe non sorprendere il fatto che penso spesso in termini di iterazioni.)

Il valore di questo è una logica semplice e intrinsecamente ovvia. Come puoi migliorare su progetti futuri se non impari mai dai tuoi errori sui tuoi progetti precedenti?

Sebbene non sia specificamente documentazione, la revisione del processo (durante o dopo il completamento) è un componente importante di quasi tutti i sistemi di controllo di qualità basati su standard che conosco, CMMI e Lean 6 Sigma in particolare.

Forse potresti proporlo come non un obbligo, qualcosa che viene fatto volontariamente durante una riunione di pranzo o qualcosa del genere? È probabile che un bel po 'del tuo team di sviluppo sarà ansioso di venire e provare nuove cose ... quindi se riesci a far oscillare almeno il primo, i risultati parleranno da soli.

È possibile che il tuo manager sia sotto pressione del budget. Questa deve essere una grande preoccupazione quando si espandono da 3 a 10 sviluppatori in breve tempo. In tal caso, probabilmente è una buona idea saltare le riunioni post mortem per ora e suggerirle di nuovo tra qualche mese, quando si spera che le questioni immediate relative al budget non siano così urgenti.

Uno dei motivi per cui la qualità può essere la sofferenza è che la comunicazione tra 10 persone è un problema molto più grande della comunicazione tra 3 persone: 3! << 10 !. Anche se probabilmente puoi confonderti per un po ', alla fine dovrai apportare alcune modifiche per favorire una migliore comunicazione tra gli sviluppatori e per assicurarti che i principi stabiliti dai 3 sviluppatori originali vengano divulgati ai persone più recenti e aggiornate per funzionare bene nel tuo nuovo gruppo più ampio. Le riunioni post mortem del progetto sono un modo per farlo; le revisioni periodiche del codice sono un'altra. Non farebbe male sottolineare che gli incontri post mortem sono una parte fondamentale del miglioramento della qualità nelle industrie dalla medicina alla produzione.

È difficile immaginare che il tuo manager crede di poter espandere il suo team di sviluppo semplicemente assumendo altre persone. Devono esserci assolutamente degli investimenti in formazione e team building; senza quello, la tua organizzazione crollerà sotto il suo stesso peso. Se aspetti un po 'di tempo, la tua organizzazione potrebbe iniziare a riscontrare alcuni problemi concreti che sono direttamente attribuibili a una scarsa comunicazione. A quel punto, probabilmente il tuo manager dirà: "Dobbiamo mettere tutti sulla stessa pagina! Pianifica un incontro con tutti gli sviluppatori!" E se sembra aiutare, probabilmente dirà: "Dovremmo farlo dopo ogni progetto!" ;-)

Quindi, sii paziente, ma sii persistente.

Sarò in controtendenza: sono d'accordo con il manager.

Ho trovato recensioni post-progetto in gran parte inutili perché è troppo tardi per fare molto per correggere i problemi rivelati.

Quello che consiglio vivamente sono le retrospettive periodiche fatte durante il progetto. Una o due volte al mese il team parla di cosa è andato bene, cosa no; cosa fare di più, cosa fare di meno. Fallo durante il progetto in modo da poter applicare immediatamente i suggerimenti e vedere come funzionano.

Guarda a fomalizzare l'incontro. Molte riunioni post-progetto sono talk-fiest e il tuo manager ha assolutamente ragione a non supportarle.

Invita a partecipare alla riunione (chiedigli di presiedere / moderare), far circolare un ordine del giorno e ottenere risultati specifici. Come manager, può quindi vedere il valore nella riunione.

Usiamo e raccomando il processo di revisione "6 Thinking Hats" di de Bono ( consultare Wikipidia ). Il risultato sono alcuni (2 o 3) punti d'azione che l'incontro identifica come il motivo più importante appreso. Le prime volte abbiamo difficoltà a uscire dai blocchi di partenza, ma una volta che ci siamo abituati, non torneremo indietro.

Non eseguire una revisione post-progetto ti condanna a fare gli stessi errori che hai fatto nel progetto precedente.