Problem Solving: An Incremental Approach

Mikhail ci spiega come da un esperienza reale ha formalizzato un approccio, definito iterativo, per la risoluzione di problemi tecnici le cui cause sono difficili da trovare e come questo può far risparmiare una grande quantità di tempo.

Problem solving

Problem solving è una skill indispensabile a giorno d’oggi, e risolvere i problemi è il pane quotidiano di tutti professionisti del mondo informatico. In questo talk faremo una panoramica di cinque passi che io uso spesso e che potete seguire anche voi per risolvere i problemi di diverso tipo. L’approccio è un po’ unconventional, quindi per dare l’idea più chiara e pratica tratteremo anche un case study reale.

 

Che cosa è un problema?

Uno ostacolo che rende difficile il raggiungimento di qualche obiettivo, e che dobbiamo risolvere in qualche modo
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.

Conseguenza: cliente non proprio contentissimo, customer care inondato di segnalazioni di utenti finali, reputazione del fornitore messa in discussione.

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.
Oltre a individuare la figura (o prendersi la responsabilità), bisogna anche stabilire il risultato atteso.

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

Crafted Software

Crafted Software é un’Associazione Culturale senza scopo di lucro.

Da Maggio 2019 è lo strumento per supportare nuove idee e iniziative.

Ci piacerebbe condividere questa avventura con tutti voi!

Se volete farne parte potete inviare la vostra adesione scrivendo a [email protected], dove risponderemo a tutte le vostre domande!