Cos’è il Diagramma di Ishikawa?

Il Diagramma di Ishikawa è uno strumento visuale di problem solving utilizzato per organizzare e analizzare le possibili cause di un problema. La sua struttura ricorda lo scheletro di un pesce: nella testa inseriamo il problema che vogliamo investigare e lungo le lische distribuiamo diversi gruppi di possibili cause.

Proprio per questa forma viene spesso chiamato diagramma a lisca di pesce. Un altro nome molto comune è diagramma causa-effetto, perché lo scopo è collegare un effetto osservato — il problema — alle diverse cause che potrebbero contribuire a generarlo.

Uno dei suoi vantaggi principali, secondo me, è che ci obbliga ad analizzare il problema da una prospettiva più sistemica. Invece di scegliere immediatamente una spiegazione conveniente, apriamo diverse linee di indagine e iniziamo a chiederci quali processi, persone, strumenti, informazioni, metodi o condizioni possano contribuire al risultato che stiamo osservando.

Questo è particolarmente utile nei progetti, perché un problema importante raramente ha una sola causa isolata. Un ritardo può essere collegato a stime imprecise, poca esperienza nel team, dipendenze esterne, task scritte male, troppo lavoro contemporaneamente in corso, mancanza di automazione oppure a una combinazione di tutti questi elementi.

A cosa serve il Diagramma di Ishikawa?

Il Diagramma di Ishikawa può essere utilizzato praticamente ogni volta che abbiamo bisogno di capire perché un determinato risultato si sta verificando. Nei progetti può aiutarci a investigare ritardi, aumento dei costi, problemi di qualità, rilavorazioni, bug ricorrenti, bassa produttività, conflitti tra aree, errori di processo o qualsiasi altro risultato diverso da ciò che avevamo pianificato.

Per quanto possiamo pianificare bene un progetto, prima o poi qualcosa che non avevamo previsto emergerà. Quando questi problemi non vengono compresi correttamente, possono trasformarsi in ritardi nelle consegne, problemi con gli stakeholder, pressione sui team, aumento dei costi e, nei casi più gravi, decisioni che coinvolgono direttamente persone e budget.

Il punto è che correggere l’effetto non significa necessariamente correggere la causa. Se le task sono in ritardo perché il team non riesce a stimarle correttamente, esercitare più pressione sugli sviluppatori non risolve il problema. Se la causa è una dipendenza gestita male, aggiungere un’altra persona al team potrebbe non cambiare nulla. Il Diagramma di Ishikawa serve proprio ad aprire queste possibilità prima di scegliere una soluzione.

Diagramma di Ishikawa, diagramma causa-effetto o diagramma a lisca di pesce?

Questi nomi indicano normalmente lo stesso strumento. Diagramma di Ishikawa è il nome associato alla tecnica, diagramma causa-effetto descrive la relazione che vogliamo analizzare e diagramma a lisca di pesce descrive semplicemente la sua forma.

Qualunque nome utilizziamo, la logica rimane la stessa: partiamo da un effetto che vogliamo comprendere e organizziamo le possibili cause in categorie. In questo modo smettiamo di vedere il problema come un unico blocco e iniziamo a trattarlo come un sistema composto da diversi fattori che possono essere collegati tra loro.

Quali sono le 6M del Diagramma di Ishikawa?

Uno dei modi più conosciuti per organizzare le cause all’interno del Diagramma di Ishikawa consiste nell’utilizzare le cosiddette 6M. Sono categorie che ci aiutano a esplorare il problema da prospettive differenti e a evitare di concentrare tutta l’analisi su una sola area.

• Macchina: strumenti, sistemi, infrastruttura, attrezzature e tecnologie utilizzate.
• Metodo: processi, procedure, regole, pratiche e modalità con cui viene svolto il lavoro.
• Materiale: componenti, documentazione, informazioni, requisiti e altri input necessari.
• Madre Natura / Ambiente: ambiente fisico, organizzativo, culturale o condizioni esterne che influenzano il lavoro.
• Misurazione: metriche, controlli, indicatori, monitoraggio e modalità utilizzate per valutare i risultati.
• Manodopera: persone, esperienza, competenze, capacità, formazione e disponibilità.

Le 6M nascono in un contesto fortemente legato alla qualità e alla produzione, ma la loro logica può essere adattata molto bene anche ai progetti tecnologici. “Macchina”, per esempio, può significare pipeline, ambienti, strumenti o infrastruttura. “Materiale” può rappresentare requisiti, documentazione, API o componenti software.

Non è nemmeno necessario compilare tutte le categorie. Se non troviamo alcuna possibile causa collegata alla Misurazione, non dobbiamo inventarne una solo per completare il diagramma. Lo scopo è migliorare l’analisi, non riempire un template.

Come fare un Diagramma di Ishikawa passo dopo passo

Il primo passo consiste nel definire con chiarezza il problema che vogliamo investigare. Può sembrare ovvio, ma molte analisi della causa radice iniziano male proprio perché il problema è stato definito in maniera troppo vaga.

“Il progetto sta andando male” non è una definizione sufficientemente precisa. “Le user story del Team X hanno un tasso di ritardo di circa il 20%” ci offre invece una base molto migliore su cui lavorare.

Dopo aver definito il problema, lo inseriamo nella testa del pesce. Successivamente creiamo le categorie che useremo nell’analisi — le 6M oppure un’altra classificazione più adatta al nostro contesto — e iniziamo a inserire le possibili cause.

In questa fase cerco di non saltare immediatamente alla soluzione. Prima voglio ampliare l’indagine. Posso parlare con il team, analizzare dati storici, osservare processi, verificare dipendenze e formulare ipotesi. Solo successivamente iniziamo a eliminare ciò che non trova supporto nei fatti e ad approfondire le cause più probabili.

Esempio di Diagramma di Ishikawa applicato a un progetto

Immaginiamo un problema molto comune: “Tutte le nostre task sono in ritardo.” Se dico immediatamente che la causa è la bassa produttività del team, sto già saltando dal problema alla conclusione. Il Diagramma di Ishikawa mi obbliga invece ad aprire l’analisi.

Utilizzando le 6M potremmo iniziare con alcune ipotesi. In Macchina potrebbe mancare l’automazione DevOps per i deploy in staging e produzione. In Metodo, i refinement potrebbero non tenere conto dell’esperienza reale degli sviluppatori. In Materiale, i componenti utilizzati potrebbero non essere riutilizzabili. In Manodopera, potremmo avere troppi sviluppatori junior oppure potrebbe mancare un professionista DevOps.

Nota che non dobbiamo necessariamente trovare una causa per ogni M. Inoltre, la stessa causa può comparire in più categorie. La mancanza di esperienza del team può essere collegata alla Manodopera, ma può influenzare anche il Metodo. L’assenza di un professionista DevOps può comparire sia nella Manodopera sia nella Macchina, perché influenza anche l’automazione e l’infrastruttura.

Quando una causa compare ripetutamente in diverse parti dell’analisi, tendo a prestarvi particolare attenzione. Non significa automaticamente che abbiamo trovato la causa radice, ma è sicuramente un buon motivo per approfondire quella direzione.

Come trovare la causa radice di un problema

Il Diagramma di Ishikawa ci aiuta a organizzare le possibili cause, ma una vera analisi della causa radice non dovrebbe terminare nel momento in cui il diagramma è completo. Il passaggio successivo consiste nel verificare quali ipotesi spiegano realmente il problema.

Se pensiamo che le task siano in ritardo per la poca esperienza del team, dobbiamo cercare evidenze. I professionisti junior impiegano realmente più tempo? Quali tipi di task mostrano la maggiore differenza tra durata stimata e durata effettiva? I ritardi sono concentrati in una determinata area? Esiste una relazione con bug, rilavorazioni o attività descritte male?

Se invece pensiamo che il problema sia la qualità dei refinement, possiamo verificare quante attività iniziano senza stima, quante vengono ristimate dopo essere iniziate, quante hanno descrizioni insufficienti e quanto rework compare durante l’esecuzione.

È in questo momento che smettiamo di avere soltanto un’opinione e iniziamo a costruire un’analisi basata sui fatti.

Come usare i 5 Perché per trovare la causa radice

La tecnica dei 5 Perché, conosciuta anche come 5 Whys, è uno dei metodi più semplici per approfondire una causa individuata con il Diagramma di Ishikawa. Il concetto consiste nel continuare a chiedere “perché?” finché non arriviamo a una spiegazione più fondamentale di ciò che sta accadendo.

Nonostante il nome, non esiste alcuna regola che ci obblighi a formulare esattamente cinque domande. Possiamo trovare la causa alla terza domanda oppure aver bisogno della settima. L’obiettivo non è raggiungere il numero cinque, ma continuare finché le risposte smettono di descrivere soltanto sintomi o conseguenze.

Immaginiamo questo esempio:

- Perché non abbiamo accesso alle macchine di produzione?
- Perché l’area di sicurezza non ci ha fornito l’accesso.
- Perché l’area di sicurezza non ci ha fornito l’accesso?
- Perché soltanto il team di sicurezza può accedere alla produzione.
- Perché soltanto il team di sicurezza può accedere alla produzione?

E qui forse arriviamo alla risposta che tutti conoscono ma che nessuno vuole dire:

Perché il CTO lo ha richiesto.

Questo esempio mostra anche uno dei limiti di qualsiasi tecnica di analisi della causa radice: abbiamo bisogno di trasparenza. Se le persone evitano determinate risposte perché il problema coinvolge politica, gerarchia o paura, possiamo costruire un Diagramma di Ishikawa perfetto e arrivare comunque alla conclusione sbagliata.

Come fare l’esercizio dei 5 Perché

Una pratica che considero molto utile consiste nel costruire sempre la domanda successiva partendo dalla risposta precedente. Questo crea tracciabilità e riduce il rischio di saltare continuamente da un’ipotesi all’altra senza seguire una linea logica.

Potremmo iniziare chiedendo: “Perché le task sono in ritardo?”. La risposta potrebbe essere: “Perché gli sviluppatori le stanno stimando in modo errato”. La domanda successiva dovrebbe quindi essere: “Perché gli sviluppatori stanno stimando le task in modo errato?”.

Potremmo scoprire una mancanza di esperienza, refinement insufficienti, requisiti incompleti oppure una tecnica di stima inadeguata. Ogni risposta crea la domanda successiva fino ad arrivare a un punto in cui possiamo identificare un’azione concreta capace di affrontare l’origine del problema.

Il Diagramma di Ishikawa e i 5 Perché funzionano molto bene insieme. Ishikawa amplia l’indagine e organizza le possibilità; i 5 Perché permettono di approfondire una di quelle possibilità.

Diagramma di Ishikawa o 5 Perché: quando usare ciascuno?

Non considero queste due tecniche concorrenti. Risolvono momenti diversi della stessa indagine. Quando non sappiamo ancora da dove possa arrivare il problema, il Diagramma di Ishikawa è particolarmente utile perché amplia il nostro campo visivo e organizza famiglie differenti di cause.

Quando invece abbiamo già individuato una causa candidata e vogliamo capire cosa esiste dietro di essa, i 5 Perché possono essere più efficienti. Spesso parto proprio da Ishikawa e applico successivamente i 5 Perché alle cause che sembrano più rilevanti.

Nel nostro esempio delle task in ritardo, potremmo identificare “stime errate” nel Diagramma di Ishikawa e poi utilizzare i 5 Perché per capire perché le stime sono sbagliate. Potremmo fare lo stesso con “mancanza di automazione”, “poca esperienza del team” o qualsiasi altra causa candidata.

La formulazione delle ipotesi fa parte della root cause analysis

Prima di confermare una causa stiamo normalmente lavorando con delle ipotesi. Per formulare buone ipotesi dobbiamo comprendere il problema, il suo contesto, le persone coinvolte, i processi collegati e la differenza tra il risultato atteso e ciò che è realmente accaduto.

Un’ipotesi utile deve poter essere verificata. Dire che “il team non è motivato” è troppo astratto. Dire invece che “l’aumento del numero di attività svolte contemporaneamente sta aumentando il tempo medio di consegna” crea qualcosa che possiamo misurare e investigare.

Possiamo anche utilizzare un’analisi degli scenari per capire come determinate cause potrebbero evolvere. Immagina che un tech leader sia sovraccarico e chieda un aumento di stipendio. Il problema potrebbe essere soltanto economico, ma potrebbero esistere anche un eccesso di responsabilità, una forte concentrazione di conoscenza o l’assenza di altre persone capaci di assumere le sue attività.

Se questa persona lascia l’azienda, potremmo perdere conoscenza, dover redistribuire improvvisamente il lavoro, creare insoddisfazione nel resto del team e generare nuovi ritardi. Costruire questi scenari ci aiuta non soltanto a comprendere il problema, ma anche a valutare il rischio di non intervenire.

Quando questa analisi coinvolge persone con molto potere o impatto sul progetto, può essere utile anche una corretta analisi degli stakeholder. Ne parlo nell’articolo: Stakeholder: cosa sono e come mapparli, analizzarli e gestirli in un progetto .

Definisci bene il problema prima di cercarne la causa

Esiste un errore capace di compromettere tutta l’analisi: cercare la causa radice di un problema che non è mai stato definito correttamente. Se la nostra definizione iniziale è sbagliata, possiamo passare ore a investigare le cause di qualcosa che non rappresenta nemmeno il vero problema.

È qui che mi piace utilizzare un problem statement. Un problem statement è una dichiarazione chiara del problema che vogliamo risolvere. Specifica cosa sta accadendo, chi ne è impattato, perché è importante, quanto è grande il problema e quale risultato vogliamo raggiungere.

Più riusciamo a quantificarlo, meglio è. Invece di scrivere “le nostre consegne sono spesso in ritardo”, potremmo arrivare a qualcosa come:

“Il tasso di ritardo nelle consegne delle user story del Team X è di circa il 20%, generando approssimativamente un mese di ritardo ogni semestre, US$ 100.000 di costi aggiuntivi per semestre e insoddisfazione da parte del cliente finale, CTO, CEO e area finanziaria. Le principali cause identificate sono la poca esperienza del team e stime imprecise. Come possiamo ridurre questi ritardi al 5% entro tre mesi?”

Ora abbiamo un problema molto più concreto. Possiamo misurare se stiamo migliorando, sappiamo chi viene impattato e possiamo collegare la soluzione alle cause identificate durante l’analisi.

Come usare i dati del progetto per validare la causa radice

Esiste una grande differenza tra una causa possibile e una causa supportata da evidenze. Nei progetti tecnologici produciamo una quantità enorme di dati durante l’esecuzione del lavoro. Jira, Azure DevOps, Asana, Monday.com e ClickUp registrano già attività, stime, responsabili, stati, sprint, date, tipi di lavoro e molte altre informazioni che possono supportare un’analisi della causa radice.

È proprio qui che Saint Jude Project Intelligence può aiutare. Invece di dipendere soltanto dalla percezione del manager, possiamo analizzare pattern di ritardo, stime errate, performance del team, costi, qualità delle attività, bug, deviazioni degli sprint e rischi.

Tornando al nostro esempio — “tutte le task sono in ritardo” — possiamo separare l’analisi per area, seniority, ruolo, tipo di task, tag, costo, ore pianificate, ore consumate o performance degli sprint. Potremmo scoprire che il problema non riguarda il team nel suo complesso, ma soltanto un determinato tipo di attività. Oppure che i ritardi sono concentrati sulle task senza stima o su un determinato livello di seniority.

Questo non sostituisce il Diagramma di Ishikawa, i 5 Perché o il lavoro del manager. Al contrario: i dati rendono questi strumenti più efficaci perché ci aiutano a confermare o scartare le nostre ipotesi.

La stessa logica vale per la produttività. Se l’analisi suggerisce che il problema possa essere collegato alla capacità o alla performance del team, consiglio anche: Indicatori di produttività: KPI e metriche per misurare e migliorare le performance del team .

Se invece i ritardi sembrano collegati a dipendenze e all’impatto di determinate attività sulla data finale del progetto, può essere utile leggere anche: Metodo del percorso critico: come prevedere i ritardi .

Trovare la causa radice è soltanto l’inizio

Il Diagramma di Ishikawa ci aiuta a organizzare le possibili cause. Le 6M ci offrono una struttura per analizzare il problema da prospettive differenti. I 5 Perché ci permettono di approfondire una linea di indagine. La formulazione delle ipotesi e l’analisi degli scenari ampliano la nostra comprensione, mentre un buon problem statement trasforma ciò che abbiamo scoperto in un problema chiaro e misurabile.

Ma nessuno di questi strumenti dovrebbe servire soltanto a produrre un bel diagramma o a completare un foglio. L’obiettivo è uscire da una discussione basata sui sintomi e arrivare a una spiegazione sufficientemente solida da permetterci di prendere una decisione.

Se le mie task sono in ritardo, non voglio sapere soltanto quante sono in ritardo. Voglio capire perché lo sono. Se i costi stanno aumentando, non voglio soltanto ridurre le spese; voglio capire cosa sta consumando più denaro del previsto. Se la produttività diminuisce, voglio sapere cosa è cambiato nel sistema prima di concludere semplicemente che le persone stanno lavorando meno.

Dopo aver trovato la causa radice possiamo finalmente iniziare a discutere delle soluzioni. Parlo proprio di questa fase nell’articolo: Come trovare le soluzioni giuste per i problemi del tuo prodotto .

Alla fine, forse questo è il contributo più importante del Diagramma di Ishikawa: ci costringe a smettere di chiederci soltanto “come risolviamo questo problema?” e a partire da una domanda ancora più importante:

“Perché sta succedendo?”

A presto!

Erik Scaranello