Prima si configura il sistema, si definiscono i processi, si completano gli interventi e si eseguono i test. Soltanto quando tutto sembra pronto, si presenta il risultato alle persone che dovranno utilizzarlo. È una sequenza apparentemente logica, ma contiene un rischio: scoprire troppo tardi che alcune decisioni sono state prese senza osservare abbastanza da vicino il lavoro reale.

Una sessione formativa non serve soltanto a spiegare come funziona uno strumento. Può far emergere possibilità già disponibili, responsabilità da chiarire e passaggi operativi che devono ancora essere verificati.

01

Spiegare una funzione significa verificarne il significato

Durante l’analisi e la configurazione, l’attenzione si concentra soprattutto sul funzionamento tecnico. Si controlla che una procedura sia disponibile, che le informazioni vengano registrate correttamente e che i diversi passaggi conducano al risultato previsto. Quando quella procedura deve essere spiegata a un utilizzatore, emergono domande differenti: in quale momento deve essere usata, chi deve eseguirla, quali informazioni deve conoscere e che cosa succede prima e dopo.

Spiegare una funzione significa inserirla all’interno di un’attività concreta. Se è difficile chiarire quando e perché debba essere utilizzata, può darsi che il processo che dovrebbe sostenerla non sia stato ancora definito completamente.

02

Le domande degli utenti mostrano ciò che l’analisi non vede

Chi utilizza quotidianamente uno strumento osserva il progetto da una prospettiva diversa rispetto a chi lo configura. Non ragiona soltanto in termini di funzioni disponibili: pensa alle eccezioni, ai tempi operativi e alle informazioni necessarie per completare il proprio lavoro. Durante una sessione possono così emergere dubbi sui ruoli, sulle autorizzazioni, sulle situazioni particolari o sui passaggi tra attività differenti.

Non sono necessariamente carenze del progetto. Spesso rendono visibili aspetti rimasti impliciti o conosciuti soltanto da alcune persone. Se la formazione avviene quando ogni decisione è già definitiva, vengono percepiti come richieste tardive. Se avviene mentre il progetto può ancora accoglierli, diventano informazioni utili per completarlo.

03

La formazione può far scoprire ciò che esiste già

Non tutte le esigenze emerse durante una sessione richiedono un nuovo sviluppo. Un software può contenere funzioni, collegamenti e configurazioni che l’organizzazione non utilizza ancora o di cui gli interlocutori non conoscono l’esistenza. Parlando del processo reale possono emergere opportunità per semplificare pagamenti, aggiornare automaticamente alcune informazioni, offrire viste dedicate ai diversi ruoli o collegare attività oggi separate.

Il punto non è attivare tutto ciò che risulta disponibile. È riconoscere ciò che può generare un beneficio, valutarne l’utilità e distinguere ciò che può essere configurato da ciò che richiede un intervento più articolato. A volte l’evoluzione più efficace non consiste nello sviluppare qualcosa di nuovo, ma nell’utilizzare correttamente ciò che esiste già.

04

Formare significa chiarire ruoli e responsabilità

Molte difficoltà attribuite al software nascono in realtà da responsabilità non ancora definite. Una funzione può essere disponibile, ma chi deve utilizzarla? Chi può modificarne le configurazioni? Quali informazioni devono essere visibili ai diversi profili? Chi interviene quando il processo non viene completato correttamente?

Durante la formazione queste domande emergono naturalmente, perché ogni spiegazione deve essere associata a una persona e a un momento operativo. La sessione consente di verificare che ciascun ruolo disponga delle possibilità necessarie, senza assegnare autorizzazioni eccessive e senza affidare attività ordinarie a profili amministrativi generali.

05

Replicare una configurazione non basta

Quando uno strumento viene esteso a un nuovo gruppo di lavoro, a una sede o a un diverso contesto operativo, può sembrare sufficiente replicare quanto esiste già. In realtà possono cambiare responsabilità, documenti, percorsi autorizzativi, informazioni consultabili e modalità di controllo. Una sessione formativa permette di simulare il percorso completo: dall’accesso dell’operatore fino agli effetti prodotti dalle sue attività.

Seguendo il flusso si possono individuare opzioni non necessarie, passaggi che richiedono una regola più precisa o differenze tra il processo ipotizzato e quello che verrà realmente adottato. In questo caso la formazione non avviene dopo la configurazione: procede insieme alla sua verifica.

06

Il momento più utile è quando le decisioni sono ancora modificabili

Anticipare la formazione non significa presentare uno strumento privo delle sue funzioni fondamentali. Se la soluzione è troppo incompleta, gli utenti non riescono a collegare le spiegazioni al proprio lavoro. Il momento più utile arriva quando esiste una base sufficientemente concreta da poter essere provata, ma c’è ancora spazio per correggere una configurazione, chiarire un ruolo o approfondire un’esigenza.

Una prima sessione può condividere il modello operativo e verificare i flussi principali. Gli incontri successivi possono approfondire le attività dei diversi ruoli, provare gli aggiornamenti e preparare gli utenti al go live.

07

Il manuale deve accompagnare il lavoro, non descrivere i menu

Anche la documentazione acquista maggiore valore quando nasce dal confronto con gli utilizzatori. Un manuale costruito soltanto sulla struttura tecnica tende a descrivere schermate, pulsanti e percorsi. Un manuale costruito dopo aver osservato domande e attività può invece spiegare quale operazione deve essere svolta, da quale ruolo, con quali attenzioni e quale risultato debba essere controllato.

Nel primo caso il documento descrive lo strumento. Nel secondo accompagna il lavoro. Le sessioni permettono inoltre di individuare le terminologie da semplificare, i passaggi che richiedono esempi e le procedure che devono essere documentate con maggiore precisione.

08

Dalla sessione deve nascere un piano operativo

Una formazione efficace non dovrebbe terminare con un generico elenco di osservazioni. Ciò che emerge deve essere classificato e trasformato in attività verificabili. Alcuni punti richiedono soltanto una spiegazione aggiuntiva, altri una configurazione o un test. Le esigenze che introducono un risultato nuovo devono invece essere analizzate separatamente.

Per ogni elemento è utile stabilire che cosa sia emerso, quale risultato si voglia ottenere, quale attività sia necessaria, chi debba occuparsene e come verrà verificata. In questo modo la formazione alimenta il piano di lavoro e rende visibile lo stato delle decisioni.

09

Formazione e collaudo devono incontrarsi

Formare e collaudare sono attività differenti, ma possono rafforzarsi reciprocamente. Durante la formazione l’utente comprende il funzionamento previsto. Durante il collaudo verifica che quel funzionamento produca davvero il risultato necessario. Le domande emerse nelle sessioni possono quindi diventare casi di test: un passaggio tra ruoli, una situazione particolare, un diverso livello di accesso o l’effetto prodotto da una configurazione.

Non è sufficiente controllare che la funzione sia presente. Occorre verificare come si inserisca nel processo complessivo. Questo collegamento riduce la distanza tra ciò che viene spiegato, ciò che viene configurato e ciò che le persone faranno realmente.

010

La formazione non consegna soltanto competenze

Considerare la formazione come l’ultima voce di un progetto significa utilizzarne soltanto una parte del valore. Naturalmente serve a rendere autonome le persone. Ma può anche verificare la solidità dei processi, far emergere configurazioni utili, chiarire le responsabilità e trasformare le domande operative in casi di test.

Per riuscirci deve essere collocata quando lo strumento è abbastanza concreto da essere compreso, ma il progetto è ancora abbastanza aperto da poter migliorare. Formare troppo tardi significa spiegare decisioni già prese. Formare nel momento giusto significa coinvolgere gli utilizzatori nella verifica di quelle decisioni.

IN SINTESI

Un progetto software non è pronto soltanto quando le funzioni sono state configurate. È pronto quando le persone comprendono come utilizzarle, il processo sostiene il loro lavoro e le domande più importanti hanno trovato risposta prima del go live.