Non puoi negarlo: per quanto pianifichiamo un progetto, qualcosa che non era stato mappato in precedenza finirà per apparire. Questo è un fatto. E quando questi problemi non vengono compresi e risolti correttamente, possono generare conseguenze serie, come:

• Ritardi nelle consegne
• Ritardi nel lancio di prodotti o miglioramenti
• Problemi con gli stakeholder
• Team sotto pressione
• Licenziamenti

Consiglio anche di leggere il mio articolo “Come misurare la produttività del tuo team e come migliorarla” per comprendere meglio la performance del team, e l’articolo “Come usare la Stakeholder Matrix per aumentare la tua influenza e migliorare la comunicazione del progetto” per migliorare la gestione degli stakeholder coinvolti nel tuo progetto.

Tornando al nostro tema, quando affrontiamo un problema, possiamo usare tecniche specifiche per ottenere una comprensione più profonda di ciò che sta accadendo e cercare soluzioni che affrontino il problema alla sua origine. Negli ambienti di progetto, anche i dati possono supportare questa analisi. Una piattaforma come Saint Jude può aiutare i manager a identificare pattern nei ritardi, stime errate, performance del team, consumo dei costi, qualità delle task, deviazioni negli sprint e rischi. Questo non sostituisce la root cause analysis, ma offre ai manager evidenze migliori per capire da dove il problema può arrivare.

Passiamo alla nostra prima tecnica:

Formulazione delle ipotesi

Per formulare buone ipotesi, dobbiamo prima comprendere il problema, le sue caratteristiche, il suo contesto, le persone coinvolte, le relazioni tra loro, le procedure collegate al problema e i risultati attesi rispetto ai risultati effettivi.

Usare strumenti come un diagramma di sistema o un diagramma di rete può essere un buon punto di partenza per comprendere la situazione, soprattutto quando vogliamo concentrarci su processi, flussi e risultati. Ti darò un esempio e lo spiegherò qui sotto:

System Diagram - Network Diagram

• I rettangoli rappresentano qualcosa che si accumula nel tempo, come la popolazione
• Le frecce rappresentano i flussi, come i tassi di nascita e di morte
• I cerchi rappresentano variabili ausiliarie, come la densità della popolazione
• I segni più e meno rappresentano se il flusso sta aumentando o diminuendo

Analisi degli stakeholder

L’analisi degli stakeholder ci aiuta a capire chi sono gli attori, come si relazionano tra loro e, molte volte, il contesto in cui sono inseriti. Menziono di nuovo il mio articolo su questo tema: “Come usare la Stakeholder Matrix per aumentare la tua influenza e migliorare la comunicazione del progetto”.

Analisi degli scenari

Questa parte della formulazione delle ipotesi viene usata per esplorare scenari alternativi su come il problema può evolvere e su come possiamo risolverlo. Basiamo questa analisi su ipotesi, variabili e incertezze. Poi validiamo le implicazioni e i rischi di ogni scenario per supportare il processo decisionale. Ecco un processo passo dopo passo:

1. Identificare il problema
2. Definire cosa sta influenzando il problema
3. Stabilire come il problema può evolvere in futuro
4. Costruire scenari diversi
5. Confrontare gli scenari, considerando vantaggi, svantaggi, opportunità, rischi e implicazioni

Esempio:

• Problema: il mio tech leader ha chiesto un aumento di stipendio
• Influenza: sovraccarico di lavoro ed eccesso di responsabilità
• Possibile evoluzione: richiesta di dimissioni e ritardi nelle consegne
• Scenari:
  • Il tech leader si dimette e non esiste documentazione del progetto
  • Il tech leader inizia a trasferire responsabilità a qualcun altro, ma senza documentazione formale
  • Altri membri del team diventano insoddisfatti a causa di richieste inattese
  • Il tech leader si dimette e il manager non ha sviluppatori senior disponibili

Disclaimer: fai attenzione quando formuli ipotesi basate su processi poco chiari o su stakeholder ad alto impatto che non sono stati mappati correttamente. La mancanza di chiarezza può portarci a commettere errori seri nella creazione delle nostre ipotesi.

Qui Saint Jude può supportare l’analisi mostrando se il progetto presenta già segnali di sovraccarico, come task concentrate in una sola persona, ritardi per livello di seniority, bug ricorrenti, descrizioni delle task poco chiare o uno squilibrio tra allocazione pianificata e lavoro effettivo. Questi indicatori possono aiutare i manager a creare ipotesi migliori invece di basarsi solo sulla percezione.

5 Whys

Secondo me, la tecnica dei 5 Whys è uno dei modi migliori e più semplici per scoprire la causa radice di un problema. Tuttavia, funziona bene solo quando viene usata con trasparenza, anche quando stiamo affrontando questioni politiche all’interno di un’azienda. A volte le persone hanno paura di dire ciò che è ovvio per tutti. Quando questo accade, la tecnica perde parte della sua forza.

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é ci hanno detto che solo il team di sicurezza può accedere alla produzione.

- Perché solo il team di sicurezza può accedere alla produzione?

Tutti pensano:

- Perché il CTO lo ha richiesto.

Anche quando la risposta sembra ovvia, l’esercizio di continuare a chiedere “perché” fino ad arrivare alla causa radice può essere rivelatore. Aiuta a separare le supposizioni dai fatti e rende il vero problema più visibile a tutti gli attori coinvolti.

Quali sono i vantaggi dei 5 Whys?

Identifico vantaggi come:

• Identificare fallimenti di processo
• Analizzare una bassa performance
• Investigazioni sui conflitti
• Comprendere tendenze
• Comprendere il successo di un prodotto
• Comprendere il fallimento di un prodotto

Come fare l’esercizio dei 5 Whys?

Nonostante il nome, non è obbligatorio fermarsi alla quinta domanda o arrivare esattamente a cinque domande. Il numero cinque è stato scelto perché di solito è una buona misura per trovare la causa radice. Il concetto è continuare a chiedere fino a trovare la vera ragione dietro il problema. Nell’esempio sopra, avrei potuto continuare con: “Perché il CTO ha richiesto che solo il team di sicurezza accedesse alla produzione?”

Un’altra pratica utile è iniziare sempre la domanda successiva usando la risposta precedente. Questo crea tracciabilità e ci aiuta a seguire la logica del problema. Esempio:

- Perché le task sono in ritardo?

- Perché gli sviluppatori le stanno stimando in modo errato.

- Perché gli sviluppatori le stanno stimando in modo errato?

Alla fine, quando troviamo la causa radice, possiamo passare alla soluzione. Lascio qui un altro articolo che ho scritto: “Come trovare le soluzioni giuste per i problemi del tuo prodotto.”

In questo esempio, Saint Jude può aiutare a supportare l’investigazione confrontando durata stimata e durata effettiva delle task, identificando quali tipi di task sono solitamente in ritardo, quali professionisti o livelli di seniority sono più impattati e se i ritardi sono collegati a bug, user story, subtask, feature o tag specifici. Questo rende l’esercizio dei 5 Whys più basato sui fatti e meno dipendente da opinioni.

Diagramma di Ishikawa

Il diagramma di Ishikawa, spesso chiamato diagramma a lisca di pesce, è una tecnica usata per comprendere un problema da una prospettiva sistemica. In altre parole, ci aiuta a fare un passo indietro e vedere lo scenario generale invece di guardare solo sintomi isolati.

Per usarlo, possiamo iniziare con un modello come quello nell’immagine qui sotto, che spiegherò passo dopo passo.

Testa del pesce – problema iniziale

Qui inseriamo il problema iniziale per cui dobbiamo trovare la causa radice. Esempio: Tutte le nostre task sono in ritardo.

Lisca di pesce e 6M

Nella lisca di pesce organizziamo le possibili cause collegate al nostro problema principale, verificando se appartengono a una delle 6M:

• Machine: tutte le attrezzature, gli strumenti e le macchine utilizzate
• Method: processi e istruzioni adottate
• Material: materie prime, componenti e informazioni
• Mission / Mother Nature: ambiente aziendale, ambiente fisico e scopo dell’azienda
• Measurement: ispezioni, sistemi di monitoraggio e controlli
• Manpower: persone coinvolte

Passiamo al nostro esempio. Inizieremo con il nostro problema principale: “Tutte le nostre task sono in ritardo.” A partire da questo problema, posizioneremo le possibili cause sulla lisca di pesce. Esempio:

• Machine: mancanza di automazione DevOps per i deploy in staging e produzione
• Method: i refinement non stanno considerando l’esperienza degli sviluppatori
• Material: i nostri componenti non sono riutilizzabili
• Mother Nature: -
• Measurement: -
• Manpower: troppi sviluppatori junior nel team e mancanza di un professionista DevOps

Il nostro diagramma:

Nota due punti importanti nel nostro esempio:

1. Non tutte le M sono state compilate, solo quelle collegate al problema principale
2. Una causa può comparire in due o più M, come l’esperienza del team, che appare in Method e Manpower, o DevOps, che appare in Machine e Manpower

Disclaimer: secondo la mia interpretazione, quando la stessa causa appare in due o più punti, è una forte candidata a essere la causa radice. Di solito la priorizzo nella mia lista di risoluzioni.

Disclaimer 2: il diagramma di Ishikawa può essere usato insieme alla tecnica dei 5 Whys. Facendo questo, possiamo identificare la causa radice per ogni M e definire sotto-problemi che devono essere risolti per eliminare il problema principale.

Questo è un altro punto in cui Saint Jude può aiutare. Se il problema è “tutte le task sono in ritardo”, la piattaforma può aiutare a separare l’analisi per area, seniority, ruolo, tipo di task, tag, costo, ore allocate, ore consumate e performance dello sprint. Questo aiuta i manager a capire se il problema è collegato alle persone, al processo, alla stima, alla qualità delle task, al carico di lavoro o al flusso di consegna.

Problem statement

Infine, dopo aver applicato le tecniche per scoprire la causa radice, dobbiamo definire il problem statement. Ma cos’è un problem statement?

Un problem statement è una dichiarazione chiara del problema che andremo a risolvere. È quasi come una dichiarazione di guerra contro il problema. In questa dichiarazione specifichiamo lo scope, perché il problema è importante e quali obiettivi vogliamo raggiungere risolvendolo. Dobbiamo anche includere criteri di accettazione e restrizioni. Qui sotto spiegherò come costruire questo documento e fornirò un esempio.

Come costruire un problem statement

Per costruirlo, dobbiamo:

• Definire chiaramente il problema – descrivere cosa sta accadendo, dove, quando e perché
• Identificare gli stakeholder – definire chi è impattato dal problema, le loro aspettative, comportamenti e posizione rispetto ad esso
• Definire criteri per valutare la soluzione – qui possiamo usare criteri di accettazione e obiettivi, come riduzione dei costi, riduzione dei tempi, miglioramento della qualità, miglioramento della sicurezza e altri
• Quantificare il problema – se possibile, quantificare quanto il problema sta danneggiando il progetto. Esempio: 1 mese di ritardo o US$ 100.000 per semestre in costi aggiuntivi
• Spiegare la causa radice – qui possiamo includere i risultati trovati attraverso le tecniche spiegate sopra

Disclaimer: ricorda che il problem statement deve essere SMART:

• Specific (S)
• Measurable (M)
• Achievable (A)
• Relevant (R)
• Time-bound (T)

Passiamo al nostro esempio:

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

Un problem statement forte dipende dai fatti. Saint Jude può supportare questo passaggio consolidando dati su schedule, costi, stime delle task, performance dei professionisti, bug, tipi di task, deviazioni degli sprint e indicatori di rischio. Con questa visibilità, i manager possono scrivere problem statement basati su evidenze invece che su supposizioni.

Da questo punto possiamo passare alla risoluzione. Qui condivido un altro articolo su questo tema: “Come trovare le soluzioni giuste per i problemi del tuo prodotto.”

Arrivo qui alla fine di questo articolo. Qui hai imparato le principali tecniche per trovare la causa radice di un problema: formulazione delle ipotesi, analisi degli scenari, 5 Whys, diagramma di Ishikawa e problem statement.

Cosa ne pensi di questo articolo? Ti piacerebbe aggiungere qualche strumento che consideri importante?

Metti like a questo articolo, commenta su LinkedIn o condividilo sui tuoi social media.

A presto!

Erik Scaranello