Durante il nostro lavoro, cerchiamo di approcciare i problemi in maniera sistematica e oggettiva, prendendo ispirazione dal mondo dell’aeronautica e ingegneria. Qui sotto riportiamo la procedura PIOSEE, come la applichiamo noi. Si tratta di una procedura che ho sentito da un You-Tuber di nome Mentour Pilot per la prima volta, ma che si incastrava parecchio con il mio modo di approcciare i problemi. È stato molto utile poterla vedere sviscerata.

Fase 1 (P): Definizione del Problema

Un problema può originare da varie fonti. Indipendentemente dalla fonte del problema (che venga fatto presente dal cliente, o che venga messo alla luce da procedure interne), dobbiamo capire molto bene di cosa si tratta. Per questo interroghiamo la fonte, per capire esattamente quale obbiettivo si cerca di ottenere. A volte un problema sembra indicare una mancanza di un sistema, ma in verità si tratta solo di capire quale è la esigenza effettiva della persona o dello studio per poi scoprire che è sufficiente utilizzare una procedura diversa per eliminare l’apparente mancanza.

In questa fase, dopo aver identificato il problema, si crea un ticket, avente nella descrizione una chiara definizione misurabile della deliverable, ossia del nuovo stato. In altre parole, deve essere possibile leggendo la descrizione e conoscendo lo stato delle cose, definire, in maniera inequivocabile, quando il ticket è terminato.

Per esempio, un ticket intitolato “mettere a posto stampante” non ha un obiettivo chiaro, e sarà difficile sapere quando chiuderlo, specialmente se la stampante ha vari problemi. Un ticket con la descrizione “La stampante laser reception stampa caratteri geroglifici su fogli prevalentemente vuoti anziché quello che si vuole stampare quando si stampa da Pages.app sulla workstation amministrativa” diventa facile da chiudere: chiunque in grado di aprire Pages.app sulla workstation amministrativa e stampare, può verificare se la stampante in reception stampa ancora geroglifici. E se non lo fa, può chiudere il ticket, anche se la stampante presenta altri problemi.

Fase 2 (I): Raccolta Informazioni

Qua si raccolgono le informazioni che hanno a che vedere con il problema in questione.

La “deliverable” di questa fase sarà la presenza di informazioni aggiornate e attuali dello stato del backup/documentazione nella relativa pagina wiki del software in questione.

Fase 3 (O): Studio delle Opzioni

In questa fase, studiamo la differenza tra dove si vuole arrivare, e lo stato attuale, per produrre una lista di tutti i possibili/attualmente visibili piani di attacco.

La deliverable di questa fase potrebbe essere l’inserimento nel ticket di una bozza delle varie opzioni, senza opinioni. Una lista oggettiva.

Fase 4 (S): Seleziona una Opzione

In questa fase:

  • una delle opzioni della Fase O-pzioni viene selezionata, in base a certi criteri, come potrebbero essere priorità e importanza dei ticket, costi, ore di lavoro, ecc.
  • l’opzione selezionata viene espansa e sviluppata in un vero e proprio piano, fino al limite delle proprie conoscenze. Per esempio, è se faccio un mega piano di lavoro super-dettagliato per i prossimi 3 mesi, basato su speculazioni, magari ci metto delle ore. Ma poi verrà quasi sicuramente ri-formulato. Meglio dedicare 20-30m per fare un piano realistico, più dettagliato per i passi più prossimi e visibili, e meno per quelli venturi. E poi nel tempo raffinare il piano, aumentarne la risoluzione come si va avanti, come fanno i motori di rendering dei simulatori e videogiochi.

La “deliverable” di questa fase, potrebbe essere la creazione di vari ticket che rappresentano i vari passaggi dell’opzione selezionata, e la loro organizzazione corretta, temporale o prioritaria, per esempio, in una “board” che supporta il ranking. È importante che ogni ticket abbia una chiara meta misurabile (deliverable), in modo da sapere in maniere inequivocabile, quando questo ticket si possa considerare concluso.

Fase 5 (Ex): Esecuzione del piano

Qua è dove finalmente si esegue il lavoro.

La “deliverable” di questa fase sarà il piano definito qui sopra eseguito per intero. Ovvero tutti i ticket creati, conclusi.

Fase 6 (Ev): Valutazione del lavoro

Dipendendo dal lavoro che viene fatto, la fase Ex-ecuzione e la fase Ev-alutazione possono essere separate o distinte. Penso che nella maggior parte dei casi, le fasi I-O-S-Ex-Ev vengano loopate in corso d’opera.

Per esempio, dopo il lavoro preliminare di I-O-S-Ex, salta fuori una nuova informazione I, che prima non avevamo. Questo fa si di aggiungere o modificare la lista di O opzioni. Che ci permette di cambiare la selezione dell’opzione S, e quindi l’esecuzione.

Oppure, dopo l’esecuzione parziale in fase Ex, si nota che gli effetti non producono i risultati desiderati, e si decide di S-elezionare un’altra delle O-pzioni, pertanto iniziando una nuova fase Ex-ecutiva.

Ad ogni modo, questa fase serve per migliorare sia la procedura attuale, che quelle future. È pertanto indicato in questa fase di produrre come deliverable qualche forma di documentazione che possa essere ri-utilizzata in futuro per procedure simili. Come nuove regole, nuove procedure, aggiornamenti al wiki di procedure esistenti, registrazione del tempo che ci si è messo per completare la procedura, ecc. In una procedura andata storta, questa fase potrebbe produrre un IR (incident report).

Le deliverable di questa fase sono:

  • modifiche del piano esecutivo, correzione del tiro
  • registrazione di una analisi più o meno dettagliata da poter usare in futuro (ore di lavoro, incident report, …)