WHITE PAPERS
HOME
 
Il problem solving è una delle attività più comuni in ambito informatico ed investe tutti i campi del sapere. Ho elaborato negli anni la metodologia oggetto di questo documento, partendo dal lavoro di Thomas Gordon, a cui ho aggiunto la mia personale esperienza in ambito IT.

 

 

IT Problem Solving

Giampaolo Spaggiari
Febbraio 2007

Introduzione

Considerata la più complessa di tutte le funzioni intellettuali, il problem solving è stato definito come "un processo cognitivo di alto livello che richiede la modulazione e il controllo di più variabili e di abilità fondamentali" (Goldstein & Levin, 1987). Karl Popper scrisse un famoso libro intitolato "Tutta la vita è risolvere problemi" e nessuno meglio degli informatici sa quanto avesse ragione. IT Manager, System Administrator, Help Desk Specialist, sono solo alcune delle figure che in ogni momento della giornata lavorativa devono affrontare e risolvere i problemi che si presentano.

Ognuno di noi è abituato ad affrontare i problemi in un modo particolare. Nella mia esperienza mi sono spesso avvalso di una metodologia di analisi e risoluzione dei problemi presentata per la prima volta da Thomas Gordon, psicologo clinico stretto collaboratore di Carl Rogers e presidente della California State Psycological Association, che ha fondato e diretto l'Effectives Training Associates, un istituto i cui programmi di training per genitori, insegnanti ed educatori sono realizzati in tutto il mondo. Una volta acquisita, la metodologia diventa un modo di pensare e di risolvere i problemi che viene automaticamente applicato nelle più svariate situazioni, nell'arco di pochi minuti e a mente, oppure in una riunione con l'ausilio di lavagne e computer. L'utilizzo di un metodo strutturato diventa utile quando chi deve risolvere i problemi e prendere delle decisioni è sotto pressione, stressato e con poco tempo a disposizione, condizioni che si verificano facilmente per un informatico alle prese con situazioni critiche quali sistemi bloccati, programmi in errore, ecc. L'uso di un metodo impedisce all'emotività di prendere il sopravvento e consente di rimanere agganciati alla logica di processo, evitando di attuare soluzioni che a prima vista sembrano le più probabili e che portano invece, in caso di fallimento, a scoraggiamento e perdita di tempo.

Metodologia

Il metodo di problem solving qui proposto si basa su 7 fasi sequenziali.

1) Identificare e definire il problema.

Una buona soluzione dipende da una accurata identificazione del problema. Davanti al problema, le domande più importanti che ci dobbiamo porre sono:

  • cosa sta succedendo "veramente"?
  • quanto mi è stato presentato è realmente vero?
  • da quando si verifica il problema?
  • ci sono state delle azioni insolite prima che si verificasse il problema (aggiornamenti, installazioni, ecc.)
  • il problema si è già verificato in passato e quando? come è stato risolto?

E' importante raccogliere quanti più dati possibile e verificare di persona la situazione, senza fidarsi troppo di quanto è stato rilevato da chi ci presenta il problema. Ricordarsi che il tempo impiegato in questa fase, anche se tanto, ne risparmierà moltissimo dopo in quanto se si intraprende una strada sbagliata occorrererà tornare indietro e rifare tutto. Spesso chi ci riporta il problema non si limita a descrivercelo ma ci suggerisce la soluzione, quasi senza neanche considerare la nostra capacità di analisi. In questi casi occorre focalizzarsi sulle cause del problema e non su quanto ci suggerisce l'utente. Una volta compreso a fondo il problema, proviamo a confrontarci con chi ha richiesto il nostro intervento per verificare che quanto abbiamo analizzato corrisponda a quanto percepito. Se il problema è complesso, occorre dare delle priorità di soluzione alle varie componenti del problema e valutare qual'è il nostro ruolo: siamo noi che dobbiamo soluzionare il problema o la competenza è di qualcun'altro?

In sintesi:

  • verificare di persona;
  • dedicare tempo;
  • raccogliere tutte le informazioni;
  • focalizzarsi sulle cause del problema;
  • confrontarci con l'utente;
  • capire il nostro ruolo.

2) Generare soluzioni

Una volta che ci siamo fatti un quadro esatto del problema, è possibile iniziare a risolverlo, considerando alcune ipotesi e partendo da quelle che riteniamo più probabili. Quindi ci porremo le domande:

  • Come potremmo fare diversamente?
  • Quali sarebbero le conseguenze in caso di questa soluzione?
  • Abbiamo pensato a tutto?

In questa fase, teniamo conto del Rasoio di Occam, un principio metodologico espresso nel XIV secolo dal filosofo e frate francescano inglese William of Ockham (noto in italiano come Guglielmo di Ockham), secondo il quale è inutile formulare più assunzioni di quelle strettamente necessarie per spiegare un dato fenomeno. Tra le varie spiegazioni possibili di un evento, è quella più semplice che ha maggiori possibilità di essere vera, anche in base a un altro principio, elementare, di economia di pensiero: se si può spiegare un dato fenomeno senza supporre l'esistenza di qualche ente, è corretto il farlo, in quanto è ragionevole scegliere, tra varie soluzioni, la più semplice e plausibile.

3) Valutare le soluzioni proposte

Ogni soluzione proposta viene valutata, considerando:

  • vantaggi e svantaggi;
  • grado di copertura del problema, se parziale o totale;
  • capacità della soluzione di funzionare nel lungo periodo;
  • attuabilità della soluzione in termini di tempo, costi e risorse disponibili .

4) Scegliere una soluzione

La soluzione più appropriata viene scelta per essere implementata.

5) Implementare la soluzione

La soluzione scelta viene implementata. In questa fase occorre, nei casi più complessi, scrivere un piano per l'implementazione, dettagliando i passi richiesti per la realizzazione del piano, con relative risorse coinvolte e tempi di scadenza delle azioni richieste.

6) Valutare il risultato

Si valuta il risultato. Il problema è stato definitivamente risolto? Questa fase, insieme alla Fase 1, in cui si identifica il problema, è a mio avviso la più importante di tutto il procedimento. Spesso si tende a sottovalutare la verifica del risultato, che deve essere approfondita e riportata all'utente. Non sempre quanto abbiamo progettato sulla carta si attua nei modi in cui lo avevamo pensato.

7) Archiviare e imparare

L'ultima fase, non presente nella toria classica di Gordon e aggiunta da me, è relativa all'archiviazione del caso tramite la scrittura di un breve memo riportante gli estremi del problema e di come è stato risolto. Si creerà così una documentazione di domande e risposte, meglio se consultabile sulla intranet aziendale, che aiuterà gli utenti a risolvere in proprio i problemi, evitando così le chiamate di aiuto relative a situazioni già risolte in passato. Infine, è' importante che chi ha risolto il problema apprenda da questa esperienza e ne faccia tesoro per il futuro, aggiornando il proprio know-how personale.


Copyright Giampaolo Spaggiari, 2007, IT CONSULTANT | Modena (IT) | www.giampaolospaggiari.it