Per lo sviluppo di software di ingegneria, problemi persistenti che si ripetono tra sprint, distribuzioni, o anche versioni di prodotto possono erodere il morale del team, gonfiare il debito tecnico e aumentare i costi operativi. Le squadre spesso si trovano ad applicare le correzioni di livello superficiale che affrontano i sintomi piuttosto che le cause di root, portando a un ciclo di guasti di ingegneria ripetuti.

Qual è la tecnica 5 Perché?

Il 5 Whys è un metodo di analisi causa radice sviluppato da Sakichi Toyoda, il fondatore di Toyota Industries. Toyoda ha introdotto la pratica come parte del sistema di produzione Toyota, che in seguito è diventato la base per la produzione di magra e sviluppo software magra. La premessa è semplice: quando si verifica un problema, chiedere "Perché?" ripetutamente, tipicamente cinque volte, per seguire la catena di causa ed effetto dal sintomo visibile alla causa principale.

Per esempio, se una linea di produzione si ferma, il primo "Perché?" potrebbe rivelare un fusibile soffiato. Chiedendo perché il fusibile soffiato potrebbe puntare a un circuito sovraccaricato. Rivolgendosi al perché il circuito è stato sovraccaricato potrebbe rivelare un cuscinetto che sequestrava.

In ingegneria del software, l'analogia è diretta. Un crash, una domanda lenta, o un dispiegamento fallito spesso ha una catena di fattori di contributo. I 5 Perché aiuta le squadre a resistere alla tentazione di fermarsi alla prima spiegazione plausibile e invece continuare a chiedere fino a quando non raggiungono una causa sistemica che, quando affrontata, impedisce al problema di ricorrenti.

La psicologia dietro i 5 Perché: Perché funziona

La tecnica 5 Whys è efficace perché contrasta diversi pregiudizi cognitivi che affliggono i problemi di risoluzione in team di ingegneria. Il primo è il [anchoring bias[], dove le squadre si attaccano alla prima spiegazione che sembra ragionevole e smettere di indagare.

Il secondo è l'errore di attribuzione fondamentale[], dove le persone attribuiscono problemi agli errori individuali piuttosto che ai guasti sistemici. Quando uno sviluppatore introduce un bug, la reazione naturale potrebbe essere "così-e-così ha scritto un codice cattivo." Ma chiedendo "Perché lo sviluppatore scrive quel codice?" potrebbe rivelare requisiti non chiari, infrastrutture di prova insufficienti, o pressione temporale da processi incoltori incolti indefiniti.

In terzo luogo, la tecnica sfrutta ]un'indagine guidata dalla curiosità[]. Chiedendo "Perché?" ripetutamente impegna il desiderio naturale del team di capire, facendo sentire l'analisi meno come un esercizio burocratico e più come un'indagine collaborativa. Questo impegno psicologico porta a risposte più approfondite e un maggiore buy-in per le azioni correttive che emergono.

Applicare i 5 Perché nello sviluppo del software di ingegneria

Nel contesto del software di ingegneria, i 5 Perché possono essere applicati attraverso più fasi del ciclo di vita di sviluppo. Durante il debugging], aiuta gli sviluppatori a passare oltre il messaggio di errore immediato per capire le scelte di configurazione, ambientale o di progettazione che hanno permesso l'inserzione di esistere.

Esempio dei 5 Perché in Azione

Considerare uno scenario comune in molti team di ingegneria: un'applicazione si schianta durante il login. Ecco come i 5 Perché potrebbero svolgersi in un'analisi sistematica:

  • Problem:[] L'applicazione si schianta durante il login.
  • Perché?] Perché la funzione di login getta un'eccezione non gestita.
  • Perché?] Poiché i dati dell'utente non vengono recuperati correttamente dal database.
  • Perché?] Perché la query del database sta restituendo valori nulli invece che record utente.
  • Perché?] Poiché la stringa di connessione del database è errata, causando la query di colpire un'istanza di database non esistente o non configurata.
  • Perché?] Poiché il file di configurazione è stato aggiornato durante una recente distribuzione con una stringa di connessione errata, e la modifica non è stata catturata da una validazione automatizzata.

Ad ogni fase, il team avrebbe potuto fermarsi presto, avrebbero potuto fissare il gestore delle eccezioni, aggiungere un controllo nullo, o aggiornare la stringa di connessione, e il crash si sarebbe fermato temporaneamente. Ma solo raggiungendo l'ultimo "Perché?" hanno scoperto che il processo di distribuzione non ha eseguito controlli di validazione per le modifiche di configurazione.

Guida passo per passo per condurre un'analisi di 5 Perché

Per ottenere il massimo dai 5 Perché, i team di ingegneria dovrebbero seguire un processo ripetibile.

Passo 1: Definire il problema chiaramente

Scrivere il problema come appare, con la maggior parte delle specificità possibile. Evitare descrizioni vaghe come "il sistema è lento." Invece, afferma: "Il tempo di risposta API per l'autenticazione dell'utente ha superato 5 secondi durante il carico di picco il 15 marzo." Un problema ben definito assicura che il team sta indagando lo stesso fenomeno.

Fase 2: Assemblare i partecipanti giusti

Includere le persone che hanno una conoscenza diretta del sistema interessato, così come le parti interessate da aree adiacenti come operazioni, QA e gestione dei prodotti.

Passo 3: Chiedi il primo "Perché"

Non accettare "perché abbiamo bug" o "perché qualcuno ha commesso un errore". Spingere per una risposta specifica e fattiva come "perché il pool di connessione del database ha esaurito le connessioni disponibili".

Passo 4: Chiedi "Perché" di nuovo per ogni risposta

Per ogni risposta, chiedere "Perché?" di nuovo. Continuare questo processo, tipicamente cinque volte, ma non trattare il numero cinque come rigido. Alcuni problemi possono richiedere tre giri per raggiungere la causa principale; altri possono avere bisogno di sette. L'obiettivo è quello di raggiungere un punto in cui la risposta indica un processo, una politica, o un sistema che può essere cambiato, piuttosto che un evento di una tantum o un'azione individuale.

Passo 5: Identificare le azioni correttive

Ogni azione correttiva dovrebbe essere specifica, assegnata a una persona o a un team, e data una scadenza. Evitare azioni generiche come "migliori test". Invece, specificare "add copertura di test di integrazione automatizzata per il flusso di login attraverso tutte le versioni del database supportate entro la fine del prossimo sprint".

Fase 6: Documento e condivisione

Scrivi la catena completa di domande e risposte, la causa principale e le azioni correttive. Condividi questo documento con il team più ampio e archivialo per riferimento futuro. Questa documentazione diventa una risorsa preziosa per l'imbarco, la formazione e la prevenzione di problemi simili in altre parti del sistema.

Studio di caso reale: Risolvere un'estrazione di sistema persistente

Per illustrare la tecnica in un contesto di ingegneria realistico, consideri un team che gestisce un CMS senza testa Directus per un'applicazione web senza contenuto. Il team ha notato che l'applicazione ha sperimentato interruzioni intermittenti ogni due o tre settimane, tipicamente durante periodi a bassa velocità.

La risposta iniziale era quella di riavviare il contenitore di applicazione e andare avanti, ma quando gli outage persistevano in diverse settimane, il team decise di condurre un'analisi di 5 Whys.

  • Problem:[] L'applicazione diventa irrisponsabile per 10-15 minuti ogni due o tre settimane.
  • Perché?] Perché il processo di applicazione smette di accettare connessioni.
  • Perché?] Perché il processo esce dalla memoria disponibile e il sistema operativo OOM-chills esso.
  • Perché?] Perché l'uso della memoria aumenta gradualmente nel tempo senza essere rilasciato.
  • Perché?] Perché un lavoro di sfondo che sincronizza i contenuti da un'API di terze parti contiene riferimenti a oggetti che impediscono la raccolta di rifiuti.
  • Perché?] Perché il lavoro utilizza un oggetto di lista statica che cresce senza limiti con ogni ciclo di sincronizzazione, senza mai sgomberare le vecchie voci.

La causa principale era una struttura dei dati non-bounded nel lavoro di sincronizzazione, che era una supervisione di codifica che non è stata catturata in recensione del codice perché il recensore si è concentrato sulla logica di sincronizzazione piuttosto che sulla gestione della memoria. Le azioni correttive incluso: fissare il codice per cancellare l'elenco statico dopo ogni ciclo di sincronizzazione, aggiungendo la profilazione della memoria al canale CI per rilevare la crescita non-bounded, e stabilire una lista di controllo di revisione del codice che include considerazioni di gestione della memoria per i lavori di sfondo.

Questo caso di studio dimostra come i 5 Perché possono risolvere problemi persistenti che inizialmente sembrano misteriosi: invece di trattare ogni outage come un evento isolato, il team ha scoperto un problema di codice strutturale che era stato presente per settimane.

Vantaggi dell'utilizzo dei 5 Perché in Contesti di Ingegneria

I team di ingegneria che adottano i 5 Perché come una pratica standard ottengono diversi vantaggi distinti:

  • Root Cause Identificazione:[ La tecnica indica il problema fondamentale piuttosto che solo affrontare i sintomi, impedendo ai team di sprecare tempo su correzioni superficiali che non durano.
  • Risoluzione Cost-Effective:[] Rivolgendosi alla vera causa principale, i team evitano ripetute spese di tempo e di sforzo sulla stessa classe di problemi. L'investimento in un'analisi approfondita si paga molte volte in risposta e rilavoro a incidenti ridotti.
  • Cultural Shift Toward Systemic Thinking:[ L'uso regolare dei 5 Perché incoraggia i team a pensare in termini di sistemi, processi e ambienti piuttosto che di colpa individuale. Questo spostamento porta ad una cultura ingegneristica più collaborativa e psicologicamente sicura.
  • Conoscere la cattura e l'apprendimento:[ Ogni analisi dei 5 Perché produce una catena documentata di ragionamento che funge da artefatto di apprendimento per l'intera organizzazione. I nuovi membri del team possono studiare le analisi passate per comprendere i modi comuni di fallimento e la logica dietro le attuali pratiche ingegneristiche.
  • Prevenzione della Ricorrenza:[ Poiché le azioni correttive mirano alla causa principale, lo stesso problema è improbabile che riapparire. Questo contrasta con le correzioni superficiali che limitano a trattare i sintomi e lasciare la vulnerabilità sottostante in atto.

Limitazioni e Come Mitigare Them

Mentre i 5 Whys sono uno strumento prezioso, non è senza limitazioni. I team di ingegneria dovrebbero essere consapevoli di questi fallimenti e prendere misure per mitigarli.

Sovrapposizione dei problemi complessi

Molti errori software del mondo reale hanno molteplici fattori di contributo che interagiscono in modi complessi. Il ripiegamento su una singola catena di interrogatori può portare il team a una conclusione incompleta o errata.

Mitigazione:[] Usare i 5 Perché in combinazione con altri metodi di analisi, come [ diagrammi di pesce[] (Ishikawa diagrams) o fault tree analysis]]. Questi strumenti aiutano a mappare più fattori causali e a garantire che il gruppo principale di gruppo di sviluppo di un gruppo di sviluppo.

Confermazione Bias

Se il team ha una nozione preconcetta di ciò che la causa principale potrebbe essere, possono inconsciamente guidare le domande verso quella conclusione, facendo domande leader "Perché?" che confermano il loro pregiudizio piuttosto che esplorare in modo autentico.

Mitigazione:[] Assicurare diverse prospettive sono coinvolte nell'analisi. Includere membri del team di diverse discipline, come QA, operazioni e gestione dei prodotti. Assegna un facilitatore che non è direttamente coinvolto nel sistema interessato per mantenere la domanda neutrale e aperta.

Stoccando troppo presto

Le squadre a volte si fermano a una "Perché?" che produce una risposta plausibile senza verificare che sia veramente la causa principale. Ad esempio, potrebbero fermarsi a "perché lo sviluppatore non ha scritto un test" senza chiedere perché il test non è stato scritto, che potrebbe rivelare problemi con la cultura di prova, l'attributo, o vincoli di tempo.

Mitigazione:[] Stabilire una regola che l'analisi non è completa fino a quando la risposta non indica un processo, una politica o un sistema che può essere modificato. Se la risposta è circa l'azione di un individuo, chiedere "Perché?" di nuovo per scoprire i fattori sistemici che hanno permesso tale azione.

Mancanza di risultati azionabili

Circa 5 Perché le analisi producono interessanti intuizioni ma non portano a cambiamenti concreti. Senza seguire, lo sforzo viene sprecato.

Mitigazione:[ Per ogni causa radice identificata, definire almeno un'azione correttiva specifica e misurabile con un proprietario e una scadenza.

Integrare i 5 Perché con altri metodi di problem-solving

I 5 Whys sono più potenti quando vengono utilizzati come parte di un più ampio kit di strumenti per la risoluzione dei problemi, e i team di ingegneri possono combinarlo con diversi metodi complementari per ottenere analisi più robuste.

Diagrammi di pesce

Come accennato, i diagrammi della colonna vertebrale aiutano a identificare più categorie di potenziali cause, come persone, processi, tecnologia e ambiente. Il team può generare il diagramma in collaborazione, quindi applicare i 5 Perché ad ogni ramo principale che sembra rilevante.

Analisi delle cause della radice (RCA)

Nelle strutture RCA formali, i 5 Perché sono spesso utilizzati come tecnica di intervista del core. Le squadre possono documentare i risultati in un modello RCA standard che include descrizione dei problemi, timeline, catena causale, causa radice, azioni correttive e lezioni apprese.

Post-Mortems senza spalmi

Nel campo dell'ingegneria dell'affidabilità del sito, i post-mortems incolpati sono una pratica standard. I 5 Perché si adattano naturalmente a questo quadro perché si concentra sulle cause sistemiche piuttosto che sugli errori individuali. Le squadre possono condurre un'analisi 5 Perché durante l'incontro post-mortem e pubblicare i risultati accanto al rapporto incidente. Questa integrazione rafforza una cultura dell'apprendimento e del miglioramento continuo.

Miglioramento continuo (Kaizen)

I 5 Whys sono una pietra angolare di Kaizen, la pratica del miglioramento incrementale continuo. I team di ingegneria possono incorporare la tecnica nelle loro retròspettive di sprint regolari. Quando un team identifica un punto di dolore ricorrente, come tempi di dispiegamento lento o frequenti conflitti di fusione, un'analisi rapida di 5 Perchés può rivelare i problemi di processo sottostanti e generare elementi di miglioramento per la prossima sprint.

Migliori Pratiche per le Squadre di Ingegneria

Per massimizzare l'efficacia dei 5 Perché nello sviluppo del software di ingegneria, i team dovrebbero adottare le seguenti best practice:

  • Dedicare il tempo per un'analisi approfondita:[ Non correre il processo. Pianifica una sessione focalizzata con i partecipanti pertinenti e allocare il tempo sufficiente per porre domande profonde.
  • Riscrivete ogni risposta:[ Documenta la catena di domande e risposte in tempo reale, creando un record chiaro e impedisce alla squadra di perdere la traccia della logica.
  • Verificare la causa principale con i dati:[ Prima di implementare azioni correttive, verificare se la causa radice identificata produce effettivamente il problema osservato. Ciò potrebbe comportare la riproduzione del problema in un ambiente di staging o l'analisi di log e metriche per confermare il collegamento causale.
  • Tenere sotto controllo l'analisi:[ Ogni causa principale dovrebbe portare ad almeno un cambiamento concreto di codice, configurazione, processo o infrastruttura.
  • Risulta ampiamente:[] Inviare l'analisi in una base di conoscenza condivisa, wiki interna o blog di ingegneria. Incoraggia altre squadre a rivederla e applicare ragionamenti simili ai propri sistemi.
  • Iterate sulla tecnica stessa: Dopo alcune analisi, tenete una retrospettiva sul processo 5 Whys stesso.

Conclusioni

I problemi persistenti nello sviluppo del software di ingegneria sono raramente causati da un singolo errore o da una semplice supervisione. Sono quasi sempre il risultato di una catena di fattori che, lasciati inesaminati, continuano a produrre fallimenti. La tecnica 5 Perché fornisce un quadro diretto per rompere quella catena, guidando i team di problemi di superficie al processo sottostante, sistema, o politica che deve cambiare.