Problem Solving: An Incremental Approach
Grey problem – problema con causa tecnologica non individuabile o non individuabili immediatamente.
Alcuni casi più specifici di grey problem:
- errori a intermittenza errori con stesso
- valori inattesi
- problemi di performance
Case study: sistema di code su 50 server
Il sistema in questione è distribuito sul territorio nazionale, 50 e passa macchine in totale, e svolge il compito di tenere in sync su tutti server alcune informazioni.
Problema: pur essendo la configurazione apparentemente omogenea, solo su alcuni server si manifesta un rallentamento significativo nel consumo dei messaggi, a intermittenza.
Primo passo – Ammettere di avere il problema
Non basta accorgersi delle conseguenze di un malfunzionamento, bisogna esplicitamente constatare il fatto che il problema esiste. Solo cosi possiamo approcciare la risoluzione del problema nel modo olistico.
Houston, we have a problem
Due aspetti: tecnologico e sociale
Aspetti tecnologici da tenere in considerazione sono:
- Strumenti di analisi a disposizione
- Bagaglio di competenze personale
- Accesso alla documentazione e al know-how
Mentre quelli sociali e organizzativi:
- Decidere chi si assume la responsabilità per la risoluzione
- Il vostro network, sul quale potete fare leva
- Autorizzazione (o consenso) a risolvere il problema in questione
Secondo passo – nominare un responsabile
Nel caso reale che stiamo analizzando è stato l’ostacolo più grosso. Essendo grey problem, con più fornitori in gioco, è stato difficile individuare una figura responsabile.
Terzo passo – Raccolta di informazioni
Bisogna assolutamente fare leva su tecnologia, e raccogliere più dati possibile. Se mancano le informazioni vanno assolutamente trovate o sviluppate soluzioni di introspezione, che abilitano all’analisi su più livelli, nel nostro caso sia lato applicativo, che lato sistemistico, necesstivano di strumenti ad-hoc.
Ogni informazione comunicata da qulsiasi fornitore deve essere verificata con dati alla mano, altrimenti si rischia la situazione dove “sulla carta” è tutto regolare, ma le cose non funzionano comunque. In generale il consiglio è non fidarsi di nessuno, e fare opportune verifiche e cross-check.
Quarto passo – Analisi con gli strumenti giusti
Come strumenti concettuali e organizzative possiamo avvalerci di vari strumenti:
- 5 W-s Rule
- Checklist
- Data visualization
- Framework di risoluzione problemi (e.g FMEA)
Oltre a questo può essere utile coinvolgere consulenti esterni anche solo per avere un parere diverso dal proprio. Una cosa che aiuta tanto è anche l’esclusione di scenari ottimistici in combinazione con “context diff” (e.g “prima vs dopo”, “server a vs server b”, etc)
Quinto passo – ventaglio soluzioni ed esecuzione
Una volta conclusa la fase di analisi, bisogna ipotizzare una o più possibili soluzioni e andare a implementare i fix. Raccogliere feedback a ogni iterazione, e ripartire dal terzo passo se necessario.
In alcuni casi ci possiamo permettere di applicare la tecnica “trial and error”, ma non sempre è possibile, quindi non può mancare la componente di brainstorming.
L’approccio può essere modellato su ogni caso specifico, tenendo conto di due aspetti:
- Il mental frame di chi risolve il problema, ma anche delle persone coinvolte, è fondamentale.
- A volte può essere utile applicare lateral thinking, quindi provare diverse “angolazioni” e prospettive specialmente nella fase di analisi