Non fate quella faccia, perché non si tratta di rapporti di obitorio o di epitaffi ma, più banalmente, di rapporti finali redatti alla consegna (o comunque al termine) di un progetto.
Cos’è un postmortem
Un postmortem è un documento di riassunto del progetto appena terminato. Contiene qualche dettaglio tecnico, una breve storia di come il progetto è progredito, e note e considerazioni su cosa è andato bene e cosa è andato male.
Il postmortem viene redatto solitamente dal project manager, a volte (ma non necessariamente) in seguito ad una riunione finale. Una volta redatto, il postmortem viene reso disponibile a tutto il team, per non dire tutta l’azienda.
A cosa serve
Il contenuto fondamentale di un postmortem è la lista di cosa è andato bene e cosa è andato male. Senza queste considerazioni il documento conta poco. O perlomeno non è un postmortem.
L’utilità di analizzare questi punti permette a un team, a un’organizzazione, a un progetto di crescere passo dopo passo, consegna dopo consegna. Equivale ad analizzare, in maniera critica, le proprie azioni e valutarle per poterle migliorare successivamente. Un team che non valuta il proprio operato e si limita a passare velocissimamente da un progetto ad un altro, da una consegna a un’altra, probabilmente è destinato a compiere ripetutamente gli stessi errori.
Come afferma Mike Gunderloy, citato anche da Jeff Atwood:
The difference between average programmers and excellent developers is not a matter of knowing the latest language or buzzword-laden technique. Rather, it can boil down to something as simple as not making the same mistakes over and over againIl postmortem è autoanalisi.
Uno strumento potente. E pericoloso.
Pericoloso ? Perché ?
Il postmortem, messo in mani sbagliate, diventa uno strumento pericoloso come possono esserlo tutte le best practice adottate ciecamente e senza buon senso.
Un postmortem redatto male può fare male a un team in tanti modi:
- Può rappresentare un solo punto di vista – se l’unica persona che lo compila non ‘lascia parlare il team’, il documento diventa il punto di vista di un’unica persona, quindi estremamente limitato.
- Può essere uno strumento per attaccare i singoli – se il postmortem punta solamente a dare la colpa dei problemi ai singoli, diventa uno strumento utile solo allo ‘scaricabarile’, non certo al miglioramento progressivo.
- Può essere demotivante – il postmortem deve evidenziare cosa non ha funzionato ma anche cosa ha funzionato. Focalizzarlo solamente sugli errori risulta demotivante per tutto il team e a lungo termine viene solo associati a considerazioni negative.
Che bello, anch’io voglio un postmortem !
Scrivere un postmortem è facile. Continuando a citare Jeff Atwood:
I don't think it matters how you conduct the postmortem, as long as you do it.L’importante è scriverlo e, aggiungo io, focalizzarsi su ‘cosa è andato bene + cosa è andato male’.
Prendere esempio da altri postmortem, leggerne di già compilati può essere utile e, in molti casi, piacevole. Infatti molti postmortem, se scritti bene, sono delle letture veramente interessanti.
In più ‘famosi’ e diffusi sono quelli che seguono il rilascio dei videogiochi. Un sito che ne raccoglie parecchi è Gamasutra. Alcuni sono anche raccolti in un libro che spero un giorno di poter leggere (è in wishlist, è quasi Natale, se qualcuno volesse fare 2+2 …)
Ma deve avere un nome così macabro ?
Per niente.
Personalmente io lo vedo come un documento dal tono positivo, che completa una fase, quella dello sviluppo, che è solo il preludio della nascita di qualcosa di bello. La consegna di un software è solo l’inizio, no ?
E’ per questo che io lo chiamo post-parto. Non è positivissimo e può essere associato a una patologia, ma nel mio immaginario è più bello associare questa analisi a una nascita, non certo a una morte.
Che ne dite ?
Quando ho letto il post ho pensato al post-mortem di un disco o di un sistema compromesso. Poi ho letto bene e ho capito a cosa ti riferivi. :)
RispondiEliminaSì, è importantissimo imparare dall'esperienza che si accumula: senza un debita analisi non solo non si può evitare di ripetere errori già incontrati, ma non si individuano i punti in cui si può migliorare. O capire cosa si può recuperare e riciclare di quanto già fatto.
Sfortunatamente la frenesia del fare e la fissazione tipica dei programmatore di "rifare, perfezionare sempre le cose" significa saltare a piè pari qualunque cosa che venga dopo un deployment.
Con tutto ciò che ne consegue. Sigh.
Ciau & gran bel post! ^^
JP
No, non è il postmortem di un disco :)
RispondiEliminaSì, la frenesia del post deployment fa saltare tutta una serie di considerazioni che sarebbero utili. Una accurata analisi magari potrebbe anche evitare problemi tipici della second system syndrome a cui avevi accennato in un tuo precedente post..
Bell post :) e mi trovi completamente d'accordo... anche se non sempre si ha la possibilità (i.e., il tempo) per poterlo fare :(
RispondiElimina@contezero74 grazie per la visita. Sì, una delle ragioni per non compilare un rapporto di questo tipo è, come sempre, la mancanza di tempo. Certo che con un meeting in meno, magari di quelli inutili ..
RispondiElimina