consulenza aziendale - 07/11/08

Un articolo su un esempio di formazione in azienda, condotto su una equipe di programmazione informatica.

Contenuti dell'articolo:

1.	Introduzione
2.	Definizione del problema
2.1	Aspetti strategici
2.2	Aspetti tecnici
2.3	Chi è il programmatore
2.4	Profilo psicologico del programmatore
3	Analisi dei bisogni formativi
3.1	L'assunzione del committente
3.2	Il coinvolgimento dell'utenza
3.3	Interpretazione delle aree problematiche rilevate
3.4.	La formulazione dell'ipotesi di intervento
4.	Progettazione dell'intervento
4.1	Definizione degli obiettivi formativi
4.2	Scelta delle metodologie e del personale docente
4.3	Organizzazione dei corsi
4.3.1	Articolazione e durata
4.3.2	Sede di svolgimento del programma
4.3.3	Composizione dei gruppi
4.3.4	Mezzi audiovisivi e altro materiale didattico
4.4	Documentazione
4.4.1	Documentazione didattica
4.4.2	Reporting per la committenza
5.	Verifica e valutazione dell'intervento

1. Introduzione

Questo articolo presenta l'esempio reale di un intervento formativo e aggiornamento professionale in un settore specifico: quello dei programmatori informatici.



Sono riportate tutte le fasi classiche di un intervento di formazione, riprendendone la traccia dal compendio sulla formazione pubblicato altrove su questo sito, dai colloqui iniziali alla realizzazione, alla valutazione dei risultati. Si tratta quindi di un esempio pratico di come la formazione possa essere attuata. L'intervento è stato condotto da me alcuni anni fa, in un'azienda di media grandezza.

2. Definizione del problema

2.1 Aspetti strategici

Come certo saprai, i sistemi programmabili hanno raggiunto una capillare diffusione nella nostra vita: non solo personal computer, ma videocamere, televisori, telefoni cellulari, impianti hi-fi, aerei, automobili, lavatrici sono ormai tutti controllati da microprocessori. Persino il monitor del personal computer su cui stai visualizzando questo articolo, se sei davanti a un perconal computer, contiene al suo interno un altro computer, che controlla la qualità dell'immagine sullo schermo affinché resti in ogni momento la migliore possibile.

Tutti questi microcontrollori e microprocessori hanno una cosa in comune: devono essere programmati.

E produrre software di buona qualità è costoso.

Se possiedi un'aziende produttrice di tecnologie informatiche, disporre di un team di programmatori adeguatamente preparati e motivati è essenziale, per conservare il vantaggio strategico sulla concorrenza. Questo obiettivo è perseguito in modo diverso da aziende diverse, a seconda della cultura aziendale, dei mezzi disponibili e degli obiettivi prestabiliti dall'azienda.

Resta però un fatto: la velocità con cui le tecnologie informatiche si sviluppano obbliga di continuo a rivedere verso l'alto gli standard produttivi e qualitativi di qualunque azienda coinvolta nell'information technology e, di conseguenza, a rivedere e riaffilare le proprie armi anche in termini di know-how.

In altre parole, se il successo della tua azienda dipende dai programmatori, sarà bene che tu investa risorse affinché questi siano tecnicamente pronti e motivati a rispondere alle sfide del mercato.

2.2 Aspetti tecnici

Il software moderno è caratterizzato da una tendenza verso la modularità: un componente software progettato oggi per svolgere una certa funzione, se la progettazione è fatta correttamente, può essere riutilizzato in futuri progetti che necessiteranno della stessa funzione.

Parti consistenti di un software o persino un intero progetto possono essere trattati come un componente. Qualsiasi pezzo di programma, dalla funzione di una sola riga di codice all'intero applicativo è trattabile, entro i limiti che gli sono propri, come un componente e come tale può essere riutilizzato.

Della possibilità di riutilizzazione del software beneficiano sia la comunità degli utenti finali, sia la comunità degli stessi informatici, che usa strumenti software per creare altri software. L'innovazione tecnologica in questo campo ha aumentato non solo la quantità dei nuovi prodotti, ma anche la velocità con cui  questi vengono creati.

Tutto ciò non fa che confermare l'importanza strategica, per l'azienda, di aggiornare il patrimonio di conoscenze dei programmatori abbastanza spesso.

2.3 Chi è il programmatore

Nel valutare l'opportunità e le modalità di esecuzione dell'intervento descritto qui, è stato fondamentale considerare le abilità relazionali dei programmatori.

Le valutazioni che seguono sono tratte in parte dalla mia esperienza professionale di più di 30 anni nel campo della programmazione, sia come dipendente che come consulente esterno per conto di aziende di vario tipo e dimensione.

Il programmatore svolge un lavoro nel quale sono richieste buone abilità di concentrazione, astrazione, memoria, prontezza di apprendimento e flessibilità di ragionamento. Queste abilità si esprimono nell'universo ristretto che comprende il programmatore e il suo programma. Si tratta, in sostanza, di un intenso lavoro mentale.

Se si considera che il programmatore svolge il proprio lavoro attraverso un linguaggio (di programmazione), è come se a tutti gli effetti parlasse da solo. Ma si trova anche, spesso suo malgrado, a dover fare i conti con altre persone, ad esempio altri programmatori che stanno lavorando a parti diverse dello stesso progetto.

Ma non sono rari i programmi sviluppati da una singola persona in pochi mesi, in quasi completo isolamento. A volte, anzi, i programmi migliori sono proprio questi, se il programmatore ha talento.

In breve: il programmatore tipico è una persona caratterizzata da un tratto notevole di introversione.

Prendiamo ora in considerazione i rapporti che il programmatore ha con altri settori dell'azienda. Ad esempio, rispetto ai settori commerciale e direzionale, un tecnico può essere meno dotato di abilità comunicative. Queste gli tornerebbero certo utili, per fronteggiare il gioco di dinamiche interpersonali che sono il pane quotidiano dei commerciali.

Ma il progettista è di base un risolutore di problemi: c'è qualcosa da sistemare? Allora troviamo il modo migliore o più veloce di farlo. Nella sfera comunicativa invece può avere qualche difficoltà. O perché gliene manca la capacità oppure perché, molto semplicemente, è un'area che gli interessa poco.

Tuttavia, si ricorda che dovrebbe interessargli quando deve chiedere un aumento.

La conseguenza è che il programmatore ha difficoltà a vendere il proprio lavoro. Questo vale sia per il dipendente che per il consulente free-lance. Per quanto possa sembrarti strano, in Italia non sono moltissimi i programmatori che lavorano da autonomi. E anche quando sono in grado di valutare con obiettività il proprio lavoro, soffrono dello stesso appiattimento remunerativo che affligge il mondo del lavoro nel nostro paese.

Il programmatore, come del resto l'ingegnere, si sente relegato al ruolo di operaio specializzato del terzo millennio, dove niente funziona più senza il frutto del suo lavoro, che tuttavia è sottopagato e riconosciuto ancor meno. Ad accentuare questo diffuso sentimento di svalutazione contribuisce la consapevolezza che in altri paesi la sua figura professionale è trattata economicamente molto meglio.

Non solo negli Stati Uniti, dove lo stipendio lordo annuo non di un programmatore, ma di un'infermiera, ammontava nel 2006 a circa 50.000 euro, ma anche più vicino a noi, negli altri paesi dell'Unione Europea. Addirittura in paesi in via di sviluppo come il Brasile, un bravo programmatore può permettersi un tenore di vita relativamente elevato rispetto al collega italiano.

Come se non bastasse, la richiesta di programmatori è fortissima, ma nemmeno questo riesce a conferire maggior potere contrattuale alla categoria.

Riassumendo, per i motivi fin qui esposti, l'atteggiamento tipico del programmatore nei confronti della sua stessa professione è ambivalente: da un lato ne è appassionato, prova ne sia che si è sacrificato per lunghi anni nello studio di materie e argomenti complessi; d'altro lato, l'importanza attribuita a parole al programmatore nel nostro paese; da un altro ancora, l'avere una percezione di scarso riconoscimento nei fatti, economico e personale.

Sì, perché un commento tipico sul software da parte di molte aziende è: "Tanto basta scriverlo".

2.4 Profilo psicologico del programmatore

Riassumendo, ecco un profilo psicologico del programmatore tipico, almeno in Italia:

Tratti di personalità rilevanti:

	Introversione.
	Orientamento agli aspetti pratici del lavoro.
	Tenacia nel perseguimento dell'obiettivo.
	Cura dei dettagli, una certa ossessività.
	Abilità generali di comunicazione interpersonali non eccellenti.

Abilità cognitive:

	Abilità di concentrazione.
	Abilità di ragionamento astratto.
	Abilità di apprendimento.
	Ottima memoria.

E sul piano sociale:

	Consapevolezza di appartenere a una categoria professionale ritenuta importante.
	Moderata competitività nei confronti dei colleghi.
	Atteggiamento ambivalente verso la propria professione: idealmente positivo e motivato, ma sminuito nei fatti dai mancati riconoscimenti.

3. Analisi dei bisogni formativi

Di seguito la presentazione del caso reale, che articola l'analisi dei bisogni formativi in quattro fasi:

3.1	L'assunzione del committente
3.2	Il coinvolgimento dell'utenza
3.3	Interpretazione delle aree problematiche rilevate
3.4.	La formulazione dell'ipotesi di intervento

Il formatore dispone di vari strumenti per l'ottenimento delle informazioni necessarie. In determinate situazioni possono essere più utili alcuni strumenti rispetto ad altri. Nel complesso, gli strumenti sono gli stessi utilizzati in ogni tipo di ricerca psicosociale:

	L'osservazione diretta.
	Il colloquio.
	L'intervista individuale o di gruppo.
	Il questionario.

Gli strumenti che ho effettivamente utilizzato sono indicati.

3.1 L'assunzione del committente

Questa fase costituisce il punto iniziale dell'intervento.

Dopo il primo contatto con i rappresentanti dell'azienda, e dopo aver concordato che poteva rendersi opportuno un intervento, furono fissati ulteriori incontri allo scopo di definire e approfondire il problema.

Il committente era rappresentato dal capo progetto responsabile di una squadra di nove programmatori.

Nei contatti iniziali con il committente lo strumento di raccolta dati più appropriato è senz'altro il colloquio. Esso ti permette di ottenere un risultato importante: far sì che il committente si senta ascoltato come persona, portatore di un problema che richiede una soluzione individualizzata.

In questa fase è necessario ascoltare con attenzione ciò che il cliente ha da dirti. La sua diagnosi è importante per lui, perché lo aiuta a formarsi un quadro coerente del problema. Il tuo compito come consulente consiste nell'accettare questa diagnosi e poi nell'ampliarla, arricchendola con altri aspetti accessibili tramite le tue competenze.

Nello specifico, la diagnosi del cliente fu la seguente.

Di recente l'azienda aveva rilevato un certo calo nella produttività di alcuni programmatori. Il dato era trasversale e interessava persone a vari livelli di abilità. Il capo progetto aveva avuto l'impressione che dietro ci fossero ragioni riguardanti la sfera personale o interpersonale. Ad ogni modo era evidente il rallentamento del procedere del lavoro.

Inoltre, era preoccupato perché la sua divisione stava per varare una nuova famiglia di prodotti, che prevedeva l'impiego di tecnologie recenti. Questo avrebbe richiesto una quota notevole di aggiornamento tecnico da parte del personale, in parte risolvibile tramite autodidattica, ma che necessitava in ogni caso di investimenti per l'acquisto di nuovi materiali, frequenza di corsi e così via.

La preoccupazione dell'azienda era quindi duplice: da un lato il desiderio di recuperare una produttività ottimale in un reparto strategicamente importante; dall'altro la stesura di un piano di aggiornamento professionale in vista dei nuovi obiettivi (la nuova linea di prodotti).

Dopo averne parlato con i programmatori e le altre persone interessate in azienda, e dopo aver cercato invano di capire le cause del problema, il capo progetto, che già mi conosceva, decise di rivolgersi a me. Dopo qualche resistenza iniziale la richiesta di rivolgersi a consulenti esterni fu avallata anche dalla direzione.

La scelta cadde su di me perché è molto raro trovare uno psicologo che abbia anche esperienza tecnica specifica in quel settore. Ciò fu confermato durante i colloqui con i programmatori, che preferivano di gran lunga avere a che fare con qualcuno in grado, all'occorrenza, di parlare la loro stessa lingua.

La diagnosi fatta dal committente mi fornì diversi elementi d'informazione. Innanzitutto mi rese chiaro che, dal punto di vista economico, il trattamento ricevuto dal personale poteva essere considerato di tutto rispetto. L'azienda promuove una cultura di tipo meritocratico e cerca di mantenere vivo lo spirito di squadra. La produttività è incentivata con premi-produzione annuali in denaro e altri benefici, come la possibilità periodica di uso delle auto della ditta a scopo personale, cene aziendali pagate, organizzazione di eventi sportivi, biglietti per spettacoli teatrali e altri benefit.

Malgrado ciò, il responsabile mi confidò che alcune persone, a suo modo di vedere, "proprio non riescono a fare spirito di squadra". Durante le pause pranzo preferivano consumare in fretta il proprio pasto e poi tornare in laboratorio per restarsene in disparte, un po' immusoniti, giocando a qualche videogame e aspettando lo squillare della campanella, riprendendo a lavorare fino alla campanella successiva, quella delle 17:00, con una produttività inferiore a quella di un tempo.

"Ma io ti domando" mi disse il capo "se secondo te è possibile che dei ragazzi così pieni di talento preferiscano starsene da soli a trastullarsi nell'orario di pausa, quando potrebbero scambiare due chiacchiere con le altre persone?"

A questo punto avevo già deciso di accettare l'incarico e proposi al committente di aggiornarci con i programmatori per parlarne anche con loro.

3.2 Il coinvolgimento dell'utenza

La seconda fase prevede il coinvolgimento non più del committente, ma dell'utenza. Ascoltai così l'altra campana, la versione del problema raccontata dai programmatori. Negli interventi di questo tipo non solo cliente e utente spesso non coincidono, anche quando lavorano per la stessa azienda, ma portano versioni e visioni molto differenti riguardo agli stessi fatti.

Avrei saputo di essere riuscito a raggiungere il primo obiettivo trasformando gli utenti in committenti, ossia persuadendo i programmatori a desiderare essi stessi un aiuto, piuttosto che riceverlo come un'imposizione dall'alto.

Per la raccolta delle informazioni in questa fase è opportuno alternare incontri e colloqui individuali con incontri di gruppo. Il colloquio individuale offre i vantaggi descritti in precedenza, mentre l'uso di tecniche di gruppo come il contraddittorio può far emergere le idee rilevanti e le modalità comportamentali dei singoli, all'interno del gruppo. Tuttavia, per ovvi motivi il contraddittorio potrebbe non essere la scelta migliore quando nel gruppo sono presenti persone a differenti livelli gerarchici.

Alcuni esempi di ciò che emerse.

I programmatori affermavano di amare il loro lavoro, eppure di sentirsi poco valorizzati dall'azienda. Alla richiesta di specificare meglio che cosa intendessero con "poco valorizzati", dato che i loro stipendi sembravano già essere al di sopra della media, alcuni espressero un desiderio di maggior partecipazione. Avrebbero voluto che i progetti ai quali lavoravano potessero esser sentiti in qualche misura anche come propri, non solo dell'azienda.

Feci notare allora che dalle informazioni in mio possesso risultava che una delle preoccupazioni dell'azienda, specie nelle fasi di avvio di nuovi progetti, era proprio il cercare di coinvolgere i singoli, invitandoli a esporre le proprie idee e opinioni. Ma il punto era proprio questo: i progettisti potevano esporre le loro idee solo in forma consultiva, "però poi le decisioni importanti le prende sempre qualcun altro".

Indagando ancora qualcuno si sfogò, ridacchiando con amarezza, che dopotutto il merito della riuscita dei progetti se lo prendevano sempre i soliti, "quelli del commerciale", perché sono quelli "in prima linea con i clienti" e perché "ci dicono sempre che nessun'azienda esiste senza il commerciale. Già, perché "tanto il software basta scriverlo". Allora perché non lo scrivono i commerciali, se sono così bravi?"

Molti di loro aspiravano a qualcosa in più oltre allo starsene davanti a un monitor dalla mattina alla sera. Avrebbero gradito essere più responsabilizzati. Avrebbero voluto poter rispondere di persona sia degli esiti positivi che di quelli più critici delle loro idee. E avere meno filtri gerarchici con la direzione, avere più voce in capitolo e non sentirsi trattati solo come dei mezzi.

Un paio di loro, più estroversi e comunicativi, rammentarono come nelle leggendarie software house d'oltreoceano esistano sempre dei piani di partecipazione, tramite l'offerta ai dipendenti di azioni o quote dell'azienda. A ciò gli altri risposero laconicamente: "Sì, ma qui non siamo in America, te lo sei scordato?"

Riassumendo: per la direzione e per i quadri intermedi, buone retribuzioni, vantaggi, premi e un clima benevolo e accogliente nei confronti del personale sarebbero dovuti bastare per ottenere un clima relazionale favorevole. I programmatori, dal canto loro, si sentivano relegati al ruolo di meri macchinari produttivi e svuotati di una reale partecipazione alle scelte dell'azienda nello stabilire il destino delle loro creazioni.

3.3 Interpretazione delle aree problematiche rilevate

La fase di interpretazione è svolta dal consulente da solo, senza alcun contatto con il committente né con gli utenti. Questa fase ha una duplice funzione: da un lato permette al consulente di chiarire a sé stesso quanto emerso dai colloqui. Dall'altro gli rende possibile prepararsi alla fase successiva, ovvero la formulazione dell'ipotesi di intervento da presentare a committente e utenti.

L'interpretazione del problema va distinta da ciò che invece costituirà la proposta di soluzione. Diagnosi e terapia sono momenti vicini, ma diversi. Fra l'altro non tutti gli aspetti che emergono dall'analisi devono essere spiegati e resi pubblici, sia perché analisi e proposta appartengono a piani concettuali diversi, sia perché il cliente è interessato non tanto al perché, ma piuttosto al come. Senza contare che l'addentrarsi in discussioni sulle cause profonde rischierebbe di essere controproducente, rispetto al fondamentale bisogno difensivo presente in ognuno.

In sostanza - e questo è un dato di fatto dell'esperienza di ogni consulente - i clienti sono in genere ben disposti a porre rimedio ai propri errori, purché tu stia ben attento a non cercare di far loro ammettere di averli commessi.

Un primo aspetto critico poteva risiedere nella diversità d'impostazione mentale del personale direttivo/quadri intermedi, rispetto a quello tecnico, come detto sopra. Abbiamo visto nel profilo psicologico del programmatore che si tratta di una persona introversa, più portata alla riflessione che alla comunicazione. Il commerciale si situa di solito all'opposto, mostrando un marcato tratto di estroversione, ben disposto ai rapporti con gli altri e meno alla riflessione sistematica.

Rispetto ad altre figure professionali, accade che i tecnici si rapportano più di frequente con i rispettivi capi reparto, anche loro spesso di estrazione tecnica, finendo però per attribuire loro una scarsa capacità di risolvere i problemi. Ciò deriva in parte dal minor potere decisionale posseduto da un quadro rispetto a un dirigente. L'insoddisfazione così aumenta, finché il collaboratore non decide di scavalcare il proprio capo diretto e andare a parlare con la direzione. E qui possono scatenarsi ulteriori conflitti e incomprensioni.

Il nostro capo progetto partiva dal presupposto che ognuno dovesse desiderare far parte della squadra, senza riuscire a prendere in considerazione la possibilità che uno dei modi per coinvolgere una persona introversa consiste nel dargli più autonomia.

Oltretutto, puoi notare come ogni aspettativa che qualcuno "debba desiderare" qualcosa è viziata in partenza: il desiderio può solo essere spontaneo, mai forzato o necessario.

Un modo per dare più autonomia è assegnare il collaboratore a un incarico del quale possa sentirsi in qualche modo titolare. Oppure favorendo la creazione spontanea di piccoli gruppi di lavoro dettata dal reciproco, naturale affiatamento.

Uno dei modelli più efficaci di organizzazione del lavoro nei laboratori è ancora quello degli skunk works ("cantinari"), descritto da Peters (1982) e adottato da sempre nelle aziende hi-tech più lungimiranti, ottenendo livelli ineguagliati di soddisfazione del personale e successo presso il pubblico dei loro prodotti.

Queste aziende ti lasciano libero, come dipendente, di organizzarti come meglio credi, di lavorare con chi vuoi e di servirti di tutti i mezzi che riesci a trovare in azienda, anche non convenzionali, per svolgere con efficacia il tuo lavoro. I livelli gerarchici sono ridotti al minimo e di fatto, dato l'enorme entusiasmo che questo modo di lavorare riesce a generare, i controlli da esercitare si riducono al minimo: le persone lavorano con enorme soddisfazione e più del necessario, senza che nessuno nemmeno glielo chieda.

Le aziende di questo tipo non ti richiedono l'obbligo di timbrare il cartellino, e talvolta neppure di lavorare in azienda. A patto che riesca a consegnare il lavoro nei tempi e nelle modalità prestabilite - e questa regola è poco flessibile - sei libero di fare ciò che preferisci: andare in azienda, restare a casa o andartene in ferie.

Naturalmente tutto ciò ha un rovescio della medaglia, che consiste nella selezione: queste aziende non assumono chiunque, solo i migliori.

Un altro elemento che caratterizza il personale tecnico appassionato al proprio lavoro è la gelosia per gli strumenti dell'attività: ha una cura ossessiva per i suoi computer, gli apparati, gli strumenti di misura e guai a toccarglieli senza permesso. Anche questi sono piccoli confini che un organizzatore attento dovrebbe imparare a rispettare. A volte l'acquisto di un nuovo strumento o di un computer più potente riesce a inorgoglire un tecnico e innalzarne il livello di motivazione.

Alcuni sostengono l'importanza della cosiddetta politica della "porta aperta". Bill Gates, ormai ex presidente Microsoft, è noto per aver sempre avuto un ufficio addirittura senza porte. Qualunque lavoratore dell'impresa, dal dirigente all'inserviente delle pulizie, poteva andare da lui e parlargli. Lui era sempre lì. Consumava persino i pasti, in ufficio, in una grossa scodella di metallo.

Se un'azienda può crescere in pochi anni fino a contare decine di migliaia di dipendenti, ci saranno dei motivi. Certo, ci vuole l'idea vincente in un periodo storico favorevole. Ma le migliori idee non vanno avanti e non possono realizzarsi se non sono supportate da formidabili intuizioni sul modo di far collaborare in armonia e con profitto così tante persone.

Il capo progetto del nostro caso, come quadro intermedio, aveva il ruolo di cerniera fra diverse realtà presenti in azienda. Ciò richiedeva adeguate abilità comunicative, che possono essere apprese, ma della cui importanza è necessario prima di tutto essere consapevoli. Come vedremo è stato necessario agire anche in questo senso.

3.4 La formulazione dell'ipotesi di intervento

La formulazione dell'ipotesi consistette inizialmente in un'offerta di massima. I dettagli furono approfonditi in sede di progettazione, dopo l'approvazione della proposta.

L'ipotesi d'intervento deve essere sottoscritta anche dall'utenza, in caso contrario ci troveremmo a lottare, paradossalmente, proprio con la parte che dovrebbe ricevere il nostro aiuto.

Decisi di effettuare la discussione in sedi separate per committente e utenti. Pur trattandosi della stessa proposta, adattai il linguaggio e la presentazione al differente tipo di visioni e aspettative. Ritenni che ciò fosse preferibile a un confronto diretto, almeno in questa fase. Successivamente, a richiesta, realizzai incontri collettivi per discutere lo stato di avanzamento del progetto.

Ricordando che l'intervento prevedeva da un lato la realizzazione di un percorso di aggiornamento professionale e dall'altro il recupero di un'adeguata motivazione e della produttività del personale, articolai la mia proposta come segue.

Dopo aver parlato con il committente e ottenuto il suo benestare, spiegai al team di programmatori che sarebbero stati organizzati in azienda dei corsi di aggiornamento sugli argomenti richiesti dagli imminenti nuovi progetti, al quale tutti loro sarebbero stati liberi, ma non obbligati, di partecipare.

Nel caso in cui alcuni di loro avessero ritenuto di non averne bisogno, avrebbero potuto chiedere di esserne esonerati. Naturalmente, in questa evenienza sarebbe stato dato per scontato che il livello delle loro conoscenze tecniche fosse già sufficiente per far fronte ai nuovi incarichi. Nel caso in cui ciò non si fosse rivelato vero, l'interessato avrebbe dovuto provvedere per conto proprio alla necessaria autoformazione, pena l'esclusione dalla partecipazione ai nuovi progetti in arrivo. Spiegai tuttavia in via confidenziale che la presenza era raccomandata poiché, oltre a essere il corso interamente pagato dall'azienda, il momento sarebbe stato utilizzato anche per offrire degli interessanti spunti di riflessione sull'esperienza di vita in azienda di ognuno.

Il corso si sarebbe articolato su due livelli: nel primo, sarebbero stati trattati gli argomenti tecnici di base e nel secondo quelli più avanzati. Dato il differente livello di conoscenza esistente fra i componenti del team, spiegai, non era indispensabile che tutti partecipassero a entrambi i livelli, però potevano decidere di farlo. Potevano organizzarsi fra loro come meglio credevano e decidere autonomamente chi avrebbe partecipato e chi no, chi ad uno solo dei due e chi a entrambi.

Procedendo in questo modo, lasciai ai programmatori un grande margine di autonomia, andando incontro al bisogno di maggior senso di responsabilità sull'iniziativa.

La mia proposta venne accettata subito e senza obiezioni, segno che erano stati toccati gli argomenti giusti. L'approvazione contribuì a rafforzare anche nella committenza l'idea che l'inizio stesse avendo luogo nel modo desiderato, che stavamo iniziando con il piede giusto.

Oltre a delle normali aule di istruzione specialistica, organizzate sotto forma di lezioni, le giornate avrebbero previsto spazi dedicati alla riflessione sull'esperienza in azienda. Con la collaborazione di un altro docente appositamente preparato cercammo di favorire lo sviluppo di un clima disteso e informale, per fare emergere gradualmente le aspirazioni di ognuno e riflettervi in gruppo.

4. Progettazione dell'intervento

4.1 Definizione degli obiettivi formativi

Ricordiamo che gli obiettivi erano due:

	Sviluppo delle conoscenze tecniche negli ambiti di interesse
	Sviluppo nel personale di un atteggiamento più funzionale agli obiettivi aziendali.

A questi potremmo aggiungerne un terzo, meno evidente, che pur non essendo stato fin qui menzionato, è altrettanto importante: favorire nel committente lo sviluppo dell'abilità di comunicare con i collaboratori e imparare a tenere più conto del loro punto di vista.

L'abilità della comunicazione interpersonale può sempre tornare utile, e consiste in sintesi nell'essere capaci d'incontrare le persone su un terreno a loro familiare.

Non a caso è considerata un'abilità trasversale.

Scelsi d'inserire nella proposta la partecipazione dei committenti a seminari di comunicazione aziendale per quadri e dirigenti. A tali giornate avrebbero partecipato persone provenienti da aziende diverse. Quadri e manager sono in genere ben disposti a incontrarsi con dei "pari grado" di altre realtà, per confrontarsi sulle rispettive esperienze.

Il capo progetto e il dirigente della divisione di cui il laboratorio faceva parte accettarono e concordammo quindi sulla realizzazione di un corso di comunicazione per loro, della durata di tre giorni.

4.2 Scelta delle metodologie e del personale docente

Decidemmo di suddividere in due il carico di lavoro. L'istruzione del personale tecnico venne curata da me, mentre il corso di comunicazione per quadri e dirigenti venne seguito da un collega.

Per entrambi le tecniche di apprendimento adoperate sono state:

	Lezioni per la trasmissione del materiale tecnico.
	Impiego di analogie e linguaggio evocativo.
	Tecniche di comunicazione suggestiva.
	Studio di casi ed esempi presi dai partecipanti.
	Esercitazioni pratiche a piccoli gruppi.
	Tecniche cognitive e linguistiche di ristrutturazione.
	Impiego dell'umorismo.
	Impiego della videocamera.

4.3 Organizzazione dei corsi

4.3.1 Articolazione e durata

I corsi per i programmatori durarono tre giorni ciascuno, sia per il livello base che per quello avanzato. Ogni giornata prevedeva una sessione mattutina e una pomeridiana per lo svolgimento delle lezioni. Ciascuna sessione aveva una durata di quattro ore, con una pausa di alcuni minuti ogni ora. Le lezioni sugli argomenti tecnici furono alternate con riflessioni di gruppo sulla vita in azienda, seguendo una struttura flessibile.

L'ultima ora dell'ultimo giorno di ogni corso fu dedicata allo svolgimento del test finale per la verifica degli apprendimenti. Un test iniziale era stato somministrato prima dell'avvio dei corsi.

Le lezioni tecniche verterono, in sintesi, sull'impiego di alcuni strumenti informatici per lo sviluppo di software applicativi specializzati, che caratterizzavano il funzionamento di un innovativo registratore di cassa programmabile. Lo sviluppo degli applicativi avveniva su dei comuni personal computer tramite l'uso di un programma apposito, che simulava le funzioni del registratore.

Alla fine della realizzazione il software era scritto su una memoria E2PROM residente a bordo del registratore. L'innovazione consisteva nella programmabilità del registratore, che poteva in tal modo adattarsi alle diverse funzioni richieste da un bar, un ristorante, un self-service o una cassa di supermercato.

Anche il seminario di comunicazione per quadri e dirigenti durò tre giorni, con la seguente scaletta di argomenti:

	Obiettivi del seminario.
	L'abilità comunicativa.
	Le quattro fasi dell'apprendimento.
	Definizioni di base: messaggio, codice, canali.
	Aspetti informativi e performativi della comunicazione.
	Comunicazione, persuasione, manipolazione, coercizione.
	L'etica del comunicare.
	Comunicazione verbale e non verbale.
	Canali sensoriali.
	Ridondanza.
	Congruenza.
	Paralinguistica.
	Cinesica.
	Prossemica.
	Acutezza sensoriale.
	Calibrazione.
	Piani di contenuto e relazione.
	Tipi di relazione: simmetrica e complementare.
	Sviluppo e miglioramento della voce.
	Sviluppo e miglioramento dell'espressività facciale.
	Sviluppo e miglioramento della gestualità.
	Chunk-up e chunk-down: specificare dettagli o generalizzare.
	Bibliografia consigliata.

4.3.2 Sede di svolgimento del programma

I corsi per i programmatori si tennero in azienda. La sede in cui si svolse il corso per quadri e dirigenti fu invece un hotel situato appena fuori città.

4.3.3 Composizione dei gruppi

I programmatori decisero tutti di partecipare a entrambi i corsi. All'ultimo momento vi fu una sola defezione al corso base, dovuta a un imprevisto personale. I due gruppi furono perciò di otto e nove persone.

Il gruppo del corso di comunicazione fu di 14 persone.

4.3.4 Mezzi audiovisivi e altro materiale didattico

Materiale impiegato:

	Lavagne a fogli mobili.
	Computer con possibilità di uscita su schermo gigante.
	Computer di back-up nel caso si fossero verificati problemi nel primo.
	Blocchi notes, penne biro.
	Badge personali con pinzetta.
	Radiomicrofoni e impianto di amplificazione.
	Libretti e fogli di risposta per i test da somministrare (vedi più avanti sez. verifica e valutazione).
	Documentazione tecnico-didattica distribuita prima delle lezioni (vedi qui sotto).

4.4 Documentazione

4.4.1 Documentazione didattica

È noto che la documentazione per gli utenti della formazione ha scarse probabilità di essere letta, così come i manuali d'uso delle apparecchiature. Tuttavia, trattandosi in questo caso di documentazione tecnica, essa fu consultata piuttosto di frequente nel periodo successivo ai corsi, almeno fino a che gli apprendimenti non furono adeguatamente assimilati.

La documentazione completa fu fornita dalla casa produttrice del registratore, che non era il committente: quest'ultimo era una software house che sviluppava sistemi basandosi su tecnologie esistenti.

Nel corso di comunicazione venne fornito invece un sintetico manuale, redatto su misura, che riportava sommariamente gli argomenti trattati. Per gli approfondimenti si rimandò a una bibliografia consigliata.

4.4.2 Reporting per la committenza

La relazione finale per il cliente fu preparata al termine dei corsi. In essa vennero riportate informazioni sommarie sul clima, la motivazione e l'impegno dei gruppi, lo sviluppo del processo di apprendimento, feedback sull'adeguatezza dello staff di docenza, sugli aspetti organizzativi, sulla sequenza dei tempi, sull'impatto del programma di formazione nel complesso e sull'utilità di ulteriori periodi di approfondimento, verifica e follow-up.

Fu esclusa di proposito qualsiasi valutazione personale sui singoli partecipanti.

5. Verifica e valutazione dell'intervento

È necessario conoscere gli stati passati e futuri per effettuare una valutazione realistica del lavoro svolto. Ciò significa disporre di un approfondito livello di conoscenza professionale delle persone interessate prima dell'intervento, e poi di essere in grado di rilevare l'entità e la qualità delle differenze. Sta anche in questo la specificità della psicologia nella formazione.

Oltre a tutti i colloqui con il personale allo scopo di ottenere tali conoscenze, effettuammo anche due somministrazioni di test: dopo i colloqui iniziali con gli utenti e a qualche tempo di distanza dal termine della nostra azione formativa. Questi test misuravano solo l'essenziale, ossia le conoscenze tecniche, gli atteggiamenti verso l'organizzazione e i valori professionali delle persone coinvolte. Nessuna rilevazione venne condotta per i partecipanti al corso di comunicazione (capo progetto e dirigente).

Decidemmo di lasciar trascorrere 2 mesi fra la prima e la seconda somministrazione.

Per le conoscenze tecniche, preparammo un test a risposte multiple basato sul materiale fornito dall'azienda produttrice degli strumenti informatici.

Il test che utilizzammo per la misura degli atteggiamenti nell'azienda fu il BFO (Big Five Observer), composto da 40 item e somministrabile in cinque minuti. Un'utile particolarità di questo test è che può essere utilizzato sia autonomamente che somministrato da una persona esterna.

Un altro test che impiegammo fu la scala WIS/SVP per i valori professionali, composto da 63 item e somministrabile in 30 minuti. Oltre ai valori professionali, questa scala misura anche il livello di coinvolgimento e soddisfazione, dando un'idea globale del costrutto "importanza del lavoro" posseduto dalla persona.

Ciascuna somministrazione consistette quindi in una batteria composta da 3 test.

Le indicazioni che le persone ci fornirono attraverso i test, soprattutto dal confronto fra le due somministrazioni, costituirono un elemento in più, anche se non conclusivo, nella valutazione accurata del lavoro che svolgemmo. Il confronto mostrò un miglioramento significativo in tutte e tre le aree sondate: conoscenze tecniche, atteggiamenti verso l'organizzazione e valori aziendali. I resoconti verbali di tutti i programmatori che parteciparono ai gruppi furono positivi, riportando soddisfazione tanto sugli apprendimenti tecnici quanto nel miglioramento della qualità dei rapporti con l'azienda.

Il capo progetto e il dirigente si dichiararono soddisfatti dell'esperienza nel gruppo sulla comunicazione, sia per i contenuti che per l'opportunità di confrontarsi con partecipanti di altre aziende. In particolare, com'è tipico di chi frequenta per la prima volta un seminario sulla comunicazione, diventarono coscienti del loro personale modo di esprimersi e delle conseguenze che ciò poteva avere sugli altri. Durante questo corso venne impiegata la videocamera, per restituire ai partecipanti l'impressione suscitata dalla loro stessa comunicazione, con effetti notevoli. Entrambi dichiararono che avrebbero proseguito nello studio della comunicazione, leggendo libri e iscrivendosi a ulteriori corsi.

A distanza di sei mesi dalla seconda somministrazione, ossia otto mesi dopo il termine dei corsi, tutto il personale che partecipò all'intervento continuò a dichiararsi soddisfatto degli sviluppi che nel frattempo erano avvenuti.

L'azienda riuscì a impadronirsi dei nuovi strumenti informatici e a creare vari tipi di personalizzazioni per il registratore di cassa, soddisfacendo le richieste pervenute dai clienti.

_