Non c’è come fuggire, se facciamo tutte le pianificazioni possibili per una buona esecuzione del progetto, appariranno problemi che non sono stati mappati precedentemente e, la non risoluzione di questi problemi porteranno conseguenze come:

• Ritardo delle consegne
• Dimora per lanciare nuovi prodotti nel mercato
• Problemi con gli stakeholder
• Equipe se sentindo pressionada
• Dimissioni

Consiglio la lettura della cronaca: “Come misurare la produttività del tuo team e come migliorarla” per gestire il tuo team e la cronaca: “Gli stakeholder – migliorando il tuo potere e impatto” per una migliore gestione degli stakeholder coinvolti nel progetto.

Ritornando al centro della nostra cronaca, quando troviamoci di fronte a un problema, possiamo utilizzare tecniche per il suo approfondimento e la ricerca di soluzioni che risolvano il problema nella sua genesi. Andiamo alla prima tecnica:

Il metodo sperimentale

Per una buona formulazione d’ipotesi, ci vuole capire il problema dato in reazione alle sue caratteristiche, contesto, i suoi attori, le relazioni fra di loro, quali procedure ci sono dentro del problema e quali sono i risultati attesi VS ottenuti. Usando un diagramma di flusso dei dati, abbiamo un buon inizio della comprensione, concentrandoci sui processi e risultati. Lascio qui un esempio con sua spiegazione:

Diagramma di flusso dei dati

• Rettangoli rappresentano quantità accumulate lungo il tempo, come popolazione
• Frecce rappresentano il flusso: natalità, mortalità
• Circoli rappresentano variabili ausiliari come densità della popolazione
• Segni di più e meno rappresentano se il flusso aumenta o diminuisce

Analisi degli stakeholder

L’analisi degli stakeholder è fatta per capire chi sono gli attori, le sue relazioni e molte volte, in quale contesto si inseriscono. Ripeto qui mia cronaca per fare questa analisi: “Gli stakeholder – migliorando il tuo potere e impatto.”

Analisi di scenario

Questo punto sulla formulazione d’ipotesi è esplorare possibili scenari alternativi sull’evoluzione del problema e come possiamo risolverli. Ci basiamo su diverse premesse, variabili e in incertezze. Valutiamo le implicazioni e i rischi di ogni scenario per la prese di decisione. Qui metto come lo faccio e l’esempio:

1. Identificare il problema
2. Definire cosa lo influenza
3. Stabilire come si può evolvere nel futuro
4. Costruire diversi scenari
5. Fare una comparazione sugli scenari, considerando i vantaggi e svantaggi, opportunità e rischi, oltre le implicazioni

Esempio:

• Problema: Mio tech leader ha richiesto un aumento
• Influenza: Sovraccarico di lavoro, eccesso di responsabilità
• Evoluzione: dimissione, ritardo delle consegne
• Scenari
  • Tech leader si è dimesso e non c’è documentazione del progetto
  • Tech leader ha cominciato a passare le sue responsabilità per un altro, senza la documentazione necessaria
  • Altri membri del team non sono soddisfatti dalle richieste inaspettate
  • Tech leader si è dimesso e il manager non ha sviluppatori senior

Discaimer: fai attenzione a formulare le ipotesi con procedure non chiare e stakeholder che hanno una grande influenza, però non sono stati ancora mappati correttamente. La mancanza di chiarezza può portarci a gravi errori quando andiamo a creare le nostre ipotesi.

5 perché

Penso che la tecnica dei 5 perché sia una delle migliori e più facili per scoprire la root cause di un problema. Però, funziona soltanto se usata di una forma trasparente, principalmente quando si tratta di problemi politici dentro di un’azienda. Può esistere quella paura di parlare lo che è esplicito a tutti. Allora la tecnica per sé non risolverà molto. Es:

- Perché non abbiamo accessi ai computer di produzione?

- Perché l’area di sicurezza non ci ha dato accesso

- Perché l’area di sicurezza non ci ha dato accesso?

- Perché ci hanno detto che gli accessi ai computer di produzione può essere fatti soltanto dalla squadra di sicurezza

- Perché soltanto la squadra di sicurezza può avere accessi ai computer di produzione?

Tutti pensano:

- Perché il CTO ha mandato che fosse così

Comunque, stesso se la risposta è ovvia, l’esercizio di domandarsi sino alla root cause è, per sé, rivelatore.

Quali sono i vantaggi dei 5 perché?

Identifico qui vantaggi come:

• Identificare fallimenti nei processi
• Analisi di basso rendimento
• Investigare conflitti
• Comprendere tendenze
• Capire il successo di un prodotto
• Capire il fallimento di un prodotto

Come fare l’esercizio del 5 perché?

Nonostante il nome, non è bisogno fermarsi alla quinta domanda né è bisogno arrivarci. Il numero cinque è stato scelto perché è una buona misura da trovare la root cause. Il concetto qui è domandarsi fino a trovare il motivo. Nell’esempio sopra, avrei potuto anche continuare: “perché il CTO ha mandato che soltanto la squadra di sicurezza avesse accesso alla produzione?” Un altro punto a essere usato è: Sempre cominci la prossima domanda usando la risposta anteriore. Così abbiamo una tracciabilità del nostro problema. Es:

- Perché le attività sono in ritardo?

- Perché gli sviluppatori stimano di forma sbagliata

- Perché gli sviluppatori stimano di forma sbagliata??

Alla fine, dopo arrivarci alla root cause, è partire alla soluzione. Lascio qui una cronaca che scriverò: “Come trovare le soluzioni giuste per i problemi del tuo progetto”

Diagramma di Ishikawa

Il diagramma di Ishikawa è una tecnica usata per la comprensione di un problema dal punto di vista sistemico, cioè, dal punto di vista generale. Sarebbe come fare un passo indietro e vedere il quadro generale di una situazione.

Per questo, usiamo un modello come la immagine sotto, che spiegherò punto per punto.

Testa del pesce – problema iniziale

Qui mettiamo il nostro problema iniziale che bisogna trovare sua root cause. Es: tutte le nostre attività sono in ritardo

Spina del pesce e 6M

Nelle nostre spine, mettiamo i problemi correlati al principale, facendo una verifica se si trova in uno degli M, che sono:

• Macchina: attrezzature, utensili e macchine che vengono utilizzati
• Metodo: procedure norme o istruzioni adottati
• Materiale: materie prime, input o componenti usati
• Medio ambiente: condizione del luogo o dell’azienda
• Misura: sistemi di misura, controllo
• Manodopera: Persone coinvolte

Andiamo al nostro esempio per la creazione del diagramma e, per questo, inizieremo dal nostro problema principale: “Tutte le nostre attività sono in ritardo”. Da questo problema, metteremo sulle spine le questioni coinvolte a questo problema principale. Es:

• Macchina: mancanza di un DevOps per automatizzare il processo di upload in staging e produzione.
• Metodo: il raffino delle attività non stanno tenendo conto la esperienza degli sviluppatori
• Materiale: i nostri componenti del sistema non sono riutilizzabili
• Medio ambiente: -
• Misura: -
• Manodopera: molti sviluppatori junior nel team, manca un DevOps

Così sarebbe il nostro diagramma:

Nota due punti nel nostro esempio:

1. Non tutti gli M sono stati riempiti. Soltanto quelli che fanno relazione al problema
2. Una questione può essere dentro di due o più M, come è il caso dell’esperienza del team, che si trova su metodo e manodopera, oltre il DevOps che c’è su macchina e manodopera.

Disclaimer: Nella mia comprensione, quando la stessa questione appare in due o più luoghi, è grande candidata a essere la root cause del problema. Per questo sempre do la priorità nella mia to do list.

Disclaimer 2: Il diagramma di Ishikawa può essere usato con i 5 perché. Facendo questo, su ogni M ci sarà uno studio di root cause, portando a sotto questioni per risolvere il problema per bene.

Problem Statement

Alla fine, dopo tutte le tecniche che abbiamo usato per scoprire la root cause, arriviamo al problem statement. Ma cos’è questo?

Problem statement è una dichiarazione chiara si cos’è il problema che risolveremo. È quasi come una dichiarazione di guerra al problema. In questa dichiarazione, specifichiamo lo scopo, quanto è importante, oltre i nostri obiettivi. Non possiamo lasciare indietro quali saranno i criteri di accettazione e le sue restrizioni. Spiego ora come costruire questo documento e uno esempio.

Costruzione del problem statement

Per questa costruzione, dobbiamo:

• Definire il problem statement con chiarezza – descrivere che succede, dove, quando e perché.
• Identificare gli stakeholder – chi è influenzato dal tuo problema, le sue aspettative, comportamenti e posizione su.
• Criteri per valutare la soluzione – qui sono i criteri di accettazione e gli obiettivi che intendiamo al risolvere questo problema. Esempi sono il miglioramento dei costi, tempo, qualità sicurezza, ecc.
• Quantificare il problema – se possibile, sapere quanto il problema disturba. Es: ritardo de 1 mese nel progetto, costi di US$ 100.000 in più, per ogni semestre
• Spiegare l root cause – qui si può metter i risultati che abbiamo trovato dalle tecniche usate anteriormente

Disclaimer: Ricordati che il problem statement dev’essere SMART, cioè:

• Specifico (S)
• Misurabile (M)
• Raggiungibile (A)
• Realistico (R)
• Temporizzabile (T)

Andiamo qui al nostro esempio:

“Il tasso di ritardo delle consegne dalle User Stories del team X è di 20%, che porta a un ritardo di 1 mese a ogni semestre, generando costi aggiuntivi di US$ 100.000 per semestre. Genera anche insoddisfazione per il cliente finale, CTO, CEO e l’area finanziaria. Le principali cause del ritardo è la mancanza si esperienza del team ed estimative sbagliate. Come possiamo diminuire il ritardo per 5% in 3 mesi?”

Bene, adesso è andare alla risoluzione. A presto scriverò una cronaca su: “Come trovare le soluzioni giuste per i problemi del tuo progetto.”

Arrivo alla fine di questa cronaca. Qui hai imparato le 4 tecniche per trovare le root cause di un problema.

Cosa ne pensi? Ti piacerebbe aggiungere qualche istrumento che pensi essere importante?

Metti un like sulla cronaca, commenti sul LinkedIn o condividi sulle tue reti sociali.

A presto!

Erik Scaranello