Il blog Lessons Learned offre un’altro articolo interessantissimo per chi sviluppa applicazioni o software per Internet o IT in generale. Spiega il metodo della ricerca della causa all’origine del problema (root cause analysis) con il metodo delle 5 perché?
Quali sono gli spunti più importanti che si possono estrarre dall’articolo?
- 5 perché significa tenere una riunione immediatamente dopo avere implementato la soluzione ad un problema che l’organizzazione sta affrontando. Ogni volta quando succede qualcosa di inatteso, si può fare l’analisi delle cause
- il primo passo è l’identificazione dei seguenti: quale problema si sta tentando di risolvere? chi è responsabile per la riunione (una persona esperta che conosce la materia…)? chi è direttamente influenzato dal problema (se necessario/possibile, far partecipare anche i clienti…)?. La riunione deve essere fatta al manifestarsi di primi sintomi del problema e non sulle supposizioni astratte. Le persone devono comunque essere ruotate nei vari problemi aumentando in questo modo la loro competenza globale…
- la cosa più importante nella riunione è quella che lo scopo della stessa è di imparare e non di fare accuse alle persone… Tolleranza ZERO per chi fa le accuse altrimenti la riunione diventa quella del 5 chi?…
- per ogni problema esaminato dobbiamo chiederci: “perché è successo?” e “perché i nostri processi attuali non lo hanno fermato in tempo?” e questo si fa iterativamente fino ad avere una profondità di indagine e analisi di almeno 4-5 livelli (o anche più se necessario…)
- bisogna tentare di restare sempre concentrati su una specifica linea di indagine: il metodo delle 5 perché non deve fare una analisi esaustiva di tutti i problemi possibili, ma di identificare la causa all’origine per il problema che si sta esaminando. Lo scopo non è di trovare la soluzione ideale ma di fare il metodo delle 5 perché il più frequentemente possibile, così che i problemi maggiori saltino fuori nuovamente se non risolti a tutti i livelli… (qui mi trovo un pò in disaccordo, ma probabilmente nello sviluppo di software ci possono essere varie cause non molto evidenti e questo metodo può funzionare…)
- una volta definiti i livelli appropriati del problema, bisogna procedere con le soluzioni: non fare né troppo né troppo poco… una giusta via di mezzo per mettere in chiaro il problema e trovare una soluzione adatta…
- è importante che il responsabile della riunione alla fine scelga una soluzione per ogni problema che poi assegna a qualcuno di effettuarla…
- l’ultimo elemento dell’analisi è la condivisione dei risultati a tutta l’organizzazione che ne può essere influenzata, con uno scopo duplice: diffondere la conoscenza e fa vedere all’organizzazione che i problemi vengono affrontati seriamente.
- il metodo dei 5 perché permette alle squadre di reagire più velocemente e poi adattarsi costantemente alle condizioni in cambiamento…
Un bell’esempio di lean thinking applicato allo sviluppo di software… Nella vostra organizzazione, se vi occupate anche dello sviluppo delle applicazioni software, vengono seguite pratiche simili? Se no, perché no?