Oggi, esamineremo un aspetto spesso esagerato del ciclo di vita dello sviluppo del software (SDL) noto come post Project review. Inizieremo definendo cosa, esattamente, è una revisione del progetto post e il passaggio a coprire gli elementi di una buona revisione del progetto.
Che cos’è una recensione post progetto?
Una delle caratteristiche di un progetto è che ha un inizio definito e una fine definita. A volte l’inizio e la fine potrebbero non essere definiti molto chiaramente (!) ma di solito si può avere un’idea approssimativa quando un progetto è iniziato e quando è finito. Qualcosa che non ha questo tipo di durata limitata non è davvero un progetto. Tuttavia, è possibile suddividere qualsiasi attività come la manutenzione e il supporto software in corso in una serie di progetti chiari, in genere terminando un progetto quando una versione software viene messa in produzione e avviando un nuovo progetto per la prossima versione o aggiornamento.
Una revisione del progetto post è un modo molto utile e potente per aggiungere un meccanismo di miglioramento continuo. La maggior parte delle attività può essere suddivisa in un insieme di progetti discreti come menzionato sopra. Questo meccanismo di miglioramento continuo contribuisce a rendere ogni progetto successivo più efficace (e spesso meno stressante per tutti i partecipanti). Le revisioni dei progetti post in genere coinvolgono il team di progetto e le principali parti interessate che si incontrano e riesaminano cosa è andato bene e cosa è andato male durante il progetto. Questo input può aiutare i partecipanti a prendere le decisioni e i piani giusti in modo che il prossimo progetto funzioni meglio. Può anche aiutare a chiarire incomprensioni e altre questioni.
Leggere: Che cosa è il software di gestione del progetto per gli sviluppatori?
Ad esempio, in una revisione del progetto post che ho condotto una volta, il team di Quality Assurance (QA) è rimasto sconvolto dal fatto che ritenevano che le modifiche ai requisiti fossero state approvate e fatte senza il loro contributo durante il progetto. Sulla base di questo feedback, questo è stato corretto nei progetti successivi assicurando che un rappresentante del team QA fosse sempre presente quando le discussioni sui requisiti dovevano essere fatte. Questo li ha messi in loop e ha dato loro l’opportunità di far emergere potenziali impatti sulle scadenze del QA. È importante assicurarsi che tutti i partecipanti alla revisione del progetto post capiscano che non è il momento di assegnare colpe o fare attacchi personali. L’idea è di lodarsi a vicenda su lavori ben fatti e trovare modi per fare le cose ancora meglio. Bisogna stare attenti che una recensione del progetto post non degeneri in un esercizio di punta del dito o in una partita urlante.
Gli elementi di una buona revisione del progetto Post
Come accennato in precedenza, lo scopo principale di una revisione del progetto post non è quello di attribuire la colpa, ma di identificare le aree per miglioramenti e modi per migliorarli. Prima di pianificare una revisione del progetto post identificare i vostri obiettivi primari e ciò che si vuole portare via.
- Identifica gli elementi che sono stati fatti bene: ad esempio, forse le stime di tempo erano molto buone, gli sviluppatori e i team di garanzia della qualità hanno lavorato bene insieme e così via.
- Identificare gli elementi che potrebbero migliorare: Forse la documentazione di sistema non era pronta in tempo; gli sviluppatori hanno avuto controversie con gli analisti, ecc Fondamentalmente questi sono elementi che hanno bisogno di qualche miglioramento che può essere realisticamente raggiunto con un certo grado di sforzo.
- Identificare gli elementi che sono rotti: Questi sono abbastanza gravi e possono richiedere un ripensamento completo su come sono fatti. Forse alcuni processi potrebbero dover essere eliminati o modificati. Forse i requisiti in continua evoluzione richiedono al team di passare a una metodologia di sviluppo più agile. Due persone che si danno sui nervi a vicenda potrebbero dover essere riassegnate in modo che non debbano lavorare insieme.
- Decidere piani d’azione: Ottenere input & accordo sui piani d’azione per migliorare gli elementi che hanno bisogno di miglioramento e modi per risolvere gli elementi che sono rotti. Ciò renderà molto più facile implementare cambiamenti a lungo termine e contribuirà a costruire un forte senso di impegno e spirito di squadra nel team.
Cerca di riunire il maggior numero di parti interessate e membri del team per l’incontro. Mentre può sembrare una ricetta per il caos (!), se pianificato bene può essere una grande esperienza per tutti. Assicurati che tutti comprendano il piano d’azione e gli obiettivi. È probabile che le parti interessate e i membri del team siano entusiasti se lo vedono come un’opportunità per lavorare per risolvere i problemi. Nella mia esperienza la prima volta che queste recensioni sono fatte di solito sono le più difficili dal momento che le persone non sono sicure di cosa è permesso e cosa no. Alcuni deputati possono anche prendere male le critiche. Può avere senso avere un’idea di problemi potenzialmente esplosivi e come disinnescarli prima di andare alla riunione. Incontro in privato con i partecipanti interessati prima della riunione per garantire regole di base sono compresi e ottenere l ” impegno che saranno seguiti può essere molto utile.
Una buona tecnica che ho trovato per aiutare a identificare i problemi principali è fare qualcosa come il voto. Ogni partecipante mette gli elementi che possono rientrare in una delle categorie ben fatto, alcune modifiche necessarie e deve essere risolto. Questo fa sentire a tutti che le sue opinioni vengono contati. Inoltre può aiutare a fornire una visione completa di molti problemi. Spesso si troverà un modello in molte questioni. Offri lodi su oggetti che le persone sentono ben fatti. Le questioni menzionate più frequentemente sono quelle che necessitano di attenzione. A questo punto può aiutare ad avere persone fornire idee su come migliorare gli elementi che hanno bisogno di miglioramento e come risolvere gli elementi che sono rotti. Si può anche avere un voto informale su quali idee sembrano le migliori.
Una volta terminata la riunione, raccogli tutte le informazioni e registrale. Assicurati di dettagliare cosa sta andando bene, cosa deve essere migliorato e cosa deve essere risolto. Identificare le tecniche che tutti concordavano avrebbero lavorato per migliorare e risolvere i problemi. È una buona idea presentarlo al senior management, specialmente se alcune correzioni necessitano di approvazione o risorse. Questi rapporti forniscono loro un modo per rivedere il team e costruiranno la loro fiducia che il team sta cercando di attaccare e risolvere i problemi da solo. È molto meglio trovare modi per risolvere i problemi da soli, piuttosto che avere alti dirigenti coinvolti nella ricerca delle correzioni. Le persone in genere si risentono degli ordini esecutivi, ma lavoreranno volentieri sui cambiamenti che loro stessi hanno proposto.
Leggi: I migliori strumenti di gestione dei progetti per gli sviluppatori.
Conclusione
Le revisioni dei progetti post sono un modo prezioso per i team di migliorare le proprie prestazioni e competenze. Offrono un meccanismo per aiutare il miglioramento continuo del carburante e migliorare il morale della squadra. È importante coinvolgere il maggior numero possibile di parti interessate nella revisione, poiché aiuta a rivedere tutte le parti del progetto e fornisce un meccanismo per chiarire incomprensioni e altre questioni. Una buona pianificazione e post meeting follow-up è fondamentale per rendere queste recensioni un successo.
