| home | |
| note bio | |
| intervento | |
| in azienda | |
| risultati | |
| contatti | |
| articoli | |
| glossario | |
| bibliografia | |
| link | |
| mappa | |
| corsi | |
| novità & commenti | |
| guida al sito | |
| termini d'uso |
Formazione e aggiornamento professionale di programmatori informatici
(leggi anche gli altri articoli)
 |
Introduzione |
Basandomi sulla traccia utilizzata nell'articolo La formazione in azienda, ho riportato tutte le fasi dell'intervento, dai colloqui iniziali alla realizzazione, alla valutazione dei risultati. Quest'articolo è quindi un esempio pratico di come la formazione possa essere attuata. L'intervento ha avuto effettivamente luogo alcuni anni fa in un'azienda di media grandezza.
L'esposizione è inframezzata da alcune mie riflessioni e commenti personali.
|
Definizione del problema |
Come chiunque può facilmente constatare, 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, lettori MP3 sono tutti regolati da microchip che ne governano le funzioni. Persino lo stesso monitor del personal computer usato per comporre questo documento contiene al suo interno un altro computer, che controlla continuamente la qualità dell'immagine sullo schermo affinché questa resti in ogni momento la migliore possibile.
Tutti questi microcontrollori e microprocessori hanno una cosa in comune: devono essere programmati. E produrre del software di buona qualità è costoso.
Per le aziende produttrici di tecnologie informatiche, disporre di un team di programmatori adeguatamente preparato e motivato è cruciale ai fini della conservazione del vantaggio strategico sulla concorrenza. Quest'obiettivo è perseguito in modo diverso a seconda della loro cultura aziendale, dei mezzi disponibili e degli obiettivi prestabiliti dall'azienda.
Resta però costante un fatto: la velocità con cui le tecnologie informatiche si sviluppano obbliga continuamente 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 altri termini, se un'azienda dipende dai programmatori sarà bene che essa investa risorse affinché questi siano tecnicamente pronti e motivati a rispondere alle sfide del mercato.
Aspetti tecnici
Il software moderno è caratterizzato da una crescente modularità: un componente software progettato e costruito oggi per svolgere una determinata funzione può, se la progettazione è fatta correttamente, essere reimpiegato in futuri progetti che necessiteranno di quella stessa funzione.
Anche una parte consistente di un intero software o persino l'intero progetto possono oggi essere trattati come un componente. Qualsiasi pezzo concepibile di programma, dalla funzione composta da 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.
Dalla modularità e dalla riutilizzabilità del software hanno tratto e continuano a trarre beneficio sia la comunità degli utenti finali, sia la stessa comunità di persone che crea il software, che usa dei software per creare altri software. Ciò implica che l'innovazione tecnologica in questo campo è simile a una reazione geometrica a catena: ciò che aumenta non è solo la quantità dei nuovi prodotti, ma la velocità con cui essi vengono creati.
Tutto ciò non fa che confermare l'importanza strategica da parte dei programmatori di aggiornarsi spesso.
Chi è il programmatore
Nel valutare l'opportunità e le modalità del nostro intervento è stato fondamentale considerare le abilità relazionali dei programmatori.
Le valutazioni che seguono sono tratte dalla mia esperienza professionale più che ventennale 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 esplicano nel ristretto universo che comprende il programmatore ed il suo programma che è, essenzialmente, un prodotto della sua mente.
Se si considera che egli si esprime attraverso un linguaggio - di programmazione - è come se a tutti gli effetti il programmatore nel suo lavoro parlasse da solo (spesso avviene davvero). Solo incidentalmente si trova poi a dover fare i conti con le altre persone, ad esempio altri programmatori che stanno lavorando a parti diverse del progetto e che s'interfacciano con la sua.
Ma non sono infrequenti programmi sviluppati da una singola persona in qualche mese, in quasi completo isolamento. A volte, anzi, i programmi migliori sono proprio questi, se il programmatore ha veramente talento.
In altre parole dovrebbe esser chiaro che il tipico programmatore è una persona in cui il tratto dell'introversione è notevole.
Prendiamo ora in considerazione i rapporti che i programmatori hanno con altri settori dell'azienda. Ad esempio, nei rapporti con i settori commerciale e direzionale troviamo che il tecnico è spesso un po' carente di abilità comunicativa. Essa tornerebbe loro utile per esprimersi in quel sottile gioco di interessi e dinamiche interpersonali che sono il pane quotidiano dei suoi interlocutori commerciali.
Ma il progettista è sostanzialmente un risolutore di problemi: c'è qualcosa da fare? Allora troviamo il modo migliore per farlo in base ai criteri forniti. Nella sfera comunicativa invece ha qualche difficoltà o perché non ne è capace oppure perché, molto semplicemente, non gli interessa.
Tuttavia, si ricorda che dovrebbe interessargli quando deve chiedere un aumento.
Una conseguenza di ciò è 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 apparire strano, in Italia non sono moltissimi i programmatori che lavorano da autonomi. Inoltre, anche se essi sono in grado di valutare obiettivamente il proprio lavoro, soffrono di quell'inesorabile appiattimento remunerativo che affligge da decenni il mondo del lavoro nel nostro paese.
Il programmatore, come del resto l'ingegnere, si vede relegato al ruolo di operaio specializzato del terzo millennio, dove niente funziona più senza il frutto del suo lavoro ma che, tutto sommato, è pagato poco e riconosciuto ancor meno. Ad accentuare questo sentimento di svalutazione contribuisce la consapevolezza che in altri paesi una figura come la sua è trattata economicamente molto meglio.
Non solo negli States, dove lo stipendio lordo annuo non di un programmatore, ma di un'infermiera ammonta oggi (2006) a circa cinquantamila 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 nostro.
Per aggiungere la beffa al danno, la richiesta di programmatori è fortissima ma, per incredibile che possa sembrare, nemmeno questo riesce a conferire maggior potere contrattuale alla categoria. Parte della causa di ciò è da attribuire ai diretti interessati, però, per i motivi suddetti.
Riassumendo, per i motivi fin qui esposti l'atteggiamento del programmatore e delle categorie professionali affini nei confronti della loro stessa professione è ambiguo: da un lato essi hanno una passione che li ha spinti a studiare a lungo materie e argomenti complessi e difficili; per altro verso la rilevanza attribuita loro dalla nostra società ipertecnologica; e per un altro ancora la loro percezione di scarso riconoscimento nei fatti, sia economico che personale.
Profilo psicologico del programmatore
Riassumendo, delineiamo un possibile profilo psicologico del programmatore tipico:
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; | |
| |
buona memoria. | |
Sul piano sociale:
| |
consapevolezza di appartenere ad una categoria professionale ritenuta importante; | |
| |
moderata competitività nei confronti dei colleghi; | |
| |
atteggiamento verso la propria professionalità/professione ambiguo: in origine positivo e appassionato ma sminuito nei fatti dai mancati riconoscimenti. | |
|
Analisi dei bisogni formativi |
| |
L'assunzione del committente | |
| |
Il coinvolgimento dell'utenza | |
| |
L'interpretazione delle aree problematiche rilevate | |
| |
La formulazione e la presentazione della proposta di intervento | |
Il formatore dispone di vari strumenti per l'ottenimento delle informazioni necessarie. In ciascun momento possono essere più utili alcuni strumenti rispetto ad altri. Nel complesso, gli strumenti disponibili sono sostanzialmente gli stessi utilizzati in ogni tipo di ricerca psicosociale:
| |
l'osservazione diretta; | |
| |
il colloquio; | |
| |
l'intervista individuale o di gruppo; | |
| |
il questionario. | |
Gli strumenti utilizzati sono indicati ove necessario.
L'assunzione del committente
Questa fase costituisce il punto iniziale dell'intervento.
Dopo il primo contatto con i rappresentanti dell'azienda cliente, stabilito che potrebbe rendersi opportuno un intervento, sono programmati ulteriori incontri allo scopo di approfondire il problema.
Nel nostro caso, la figura del committente era rappresentata dal capo progetto responsabile di una squadra composta da nove programmatori.
Nei contatti iniziali con il committente lo strumento di raccolta dei dati più appropriato è senz'altro il colloquio. Com'è facilmente comprensibile questo strumento consente 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 attentamente ciò che il cliente ha da dirci. La sua diagnosi è importante per lui, perché lo aiuta a organizzare le proprie percezioni e perché è il mezzo con cui riesce a governare il suo senso di bisogno. Il nostro compito consiste nell'accettare la sua diagnosi e poi ampliarla, arricchendola degli aspetti a noi accessibili attraverso le nostre competenze.
Nello specifico, la diagnosi del cliente fu la seguente. Ultimamente l'azienda aveva rilevato un certo calo nella produttività di alcuni programmatori. Il dato era trasversale e interessava persone situate a vari livelli di abilità. Il capo progetto ebbe l'impressione che dietro vi fossero ragioni attinenti alla 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. Ciò avrebbe richiesto una quota notevole di aggiornamento tecnico da parte del personale, che si sarebbe tradotto in parte in autoistruzione, ma anche in investimenti per l'acquisto di nuovi materiali, frequenza di corsi e così via.
La preoccupazione dell'azienda era quindi duplice: da un lato rivolta al recupero di 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).
Il capo progetto, dopo aver parlato sia con i programmatori interessati che con le persone in azienda che avevano rapporti con loro, e quindi dopo aver cercato invano di capire le cause del problema, decise di rivolgersi al sottoscritto. Dopo qualche resistenza iniziale la richiesta di rivolgersi a consulenti esterni fu avallata anche dalla direzione.
La scelta dell'autore rispetto ad altri consulenti fu giustificata dal possedere esperienza tecnica specifica oltre che formativa. Quest'intuizione fu poi confermata 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.
L'esposizione della versione del cliente ci fornisce elementi di informazione. Ci fa notare che dal punto di vista economico il trattamento ricevuto dal suo personale può essere considerato del tutto ragguardevole. 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 altre cose.
Malgrado tutto ciò il responsabile mi confidò che vi erano persone che a suo modo di vedere "proprio non riescono a entrare a far parte della squadra". Durante le pause pranzo questi individui preferivano consumare in fretta il proprio pasto e poi rimanersene in disparte (magari proprio in laboratorio!), un po' immusoniti, magari giocando a qualche videogame, aspettando lo squillare della campanella per riprendere a lavorare con una produttività inferiore a quella di un tempo.
"Ma io le domando - mi dice ancora il capo - secondo lei è 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.
Il coinvolgimento dell'utenza
La seconda fase prevedeva il coinvolgimento dell'utenza ed ascoltai "l'altra campana", ossia la versione del problema riferita dai programmatori. Si dovrebbe notare che negli interventi di questo tipo cliente e utente spesso non coincidono, anche quando lavorano entrambi per la stessa azienda.
Avrei saputo di aver raggiunto il primo obiettivo quando fossi riuscito a trasformare gli utenti in committenti, ossia quando gli utenti si sarebbero persuasi a desiderare essi stessi un aiuto piuttosto che riceverlo come un'imposizione.
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 fa emergere le idee rilevanti e le modalità comportamentali dei singoli all'interno del gruppo. Tuttavia, tecniche di gruppo come questa non sono indicate nei contatti con il personale direttivo, per motivi facilmente intuibili.
Alcuni esempi di ciò che emerse furono i seguenti.
I programmatori affermavano di amare il loro lavoro ma di non sentirsi valorizzati a sufficienza dall'azienda. Alla richiesta di specificare meglio che cosa intendessero con "sentirsi valorizzati", dato che i loro stipendi sembravano già essere un po' al di sopra della media, alcuni espressero un desiderio di maggior partecipazione. Desideravano 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 cercare di coinvolgere i singoli, invitandoli a esporre le loro idee e opinioni. Ma il punto era proprio questo: i progettisti potevano esporre solo consultivamente le loro idee, ma poi "tanto, le decisioni importanti le prende sempre qualcun altro".
Indagando ulteriormente qualcuno ammise ridacchiando amaramente che dopotutto il merito della riuscita dei progetti se lo prendevano sempre i soliti, "quelli del commerciale", perché sono quelli "sempre in prima linea", perché "ci dicono sempre che nessun'azienda esiste senza il commerciale" e via dicendo.
Molti di loro aspiravano anche a qualcosa di più che starsene davanti a un monitor dalla mattina alla sera. Avrebbero gradito essere maggiormente responsabilizzati. Avrebbero gradito poter rispondere di persona sia degli esiti positivi che di quelli problematici delle loro idee, avere meno filtri gerarchici nei rapporti con la direzione, avere "maggior voce in capitolo" e non sentirsi trattati solo come mezzi.
Un paio di loro, più estroversi e comunicativi, rammentarono come nelle software house leggendarie d'oltreoceano esistano sempre dei piani di partecipazione agli utili, tramite l'offerta ai dipendenti di azioni o quote dell'azienda. A queste affermazioni altri risposero con ironia e disillusione "sì, ma qui non siamo in America, te lo sei scordato?"
Riassumedo, la direzione e i quadri intermedi vedevano buone retribuzioni, vantaggi, premi e un clima sostanzialmente benevolo e accogliente nei confronti del personale. I programmatori, dal canto loro, si sentivano relegati al ruolo di strumenti produttivi e privi di una reale partecipazione alle scelte dell'azienda che riguardavano le loro creazioni.
È importante notare come tutte queste valutazioni rappresentino solo diversi punti di vista, non verità assoluta. Molto probabilmente se avessi ascoltato anche i commerciali avrei ricevuto ancora altri resoconti. Ma ciò non sposta il problema, poiché l'oggetto di tutta la psicologia è la realtà percepita, non la "realtà reale".
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 formatore 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 che dovrà essere presentata a committenti ed utenti.
Questa duplicità suggerisce la necessità di distinguere l'interpretazione del problema da ciò che invece costituirà la proposta di soluzione. Ciò significa che non tutti gli aspetti che emergeranno dall'analisi saranno necessariamente 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 che potrebbero essere all'origine dei problemi rischierebbe di essere controproducente rispetto al fondamentale bisogno difensivo presente in ognuno.
In sostanza, e questo è un dato di fatto dell'esperienza professionale di ogni consulente, i clienti sono in genere ben disposti a porre rimedio ai loro errori, purché si stia ben attenti a non cercare di far loro ammettere di averli commessi.
Un primo aspetto potenzialmente problematico poteva risiedere nella già menzionata diversità di impostazione del personale direttivo/quadri intermedi rispetto a quello tecnico. Abbiamo visto nel profilo psicologico del programmatore come questi sia una persona facilmente introversa, più portata verso la riflessione che la comunicazione. Il commerciale tipico si situa di solito all'opposto, mostrando un tratto di personalità estroverso, ben disposto ai rapporti con gli altri e relativamente meno alla riflessione sistematica.
Rispetto alle altre figure professionali presenti in azienda accade che i tecnici si rapportino più di frequente con i rispettivi capi reparto, spesso di estrazione tecnica, ma che finiscano per attribuir loro una scarsa capacità di risolvere i propri problemi. Ciò deriva in parte dal minor potere decisionale posseduto da un quadro rispetto a un dirigente. L'insoddisfazione aumenta così nei singoli, sino a che individualmente o in gruppo questi non decidono di scavalcare il proprio capo e andare a parlare con la direzione.
E qui possono facilmente scatenarsi conflitti e incomprensioni.
Il capo progetto nel mio caso partiva dal presupposto scontato che ognuno dovesse desiderare "far parte della squadra" e non riusciva, se non con difficoltà o riluttanza, a prendere in considerazione la possibilità che uno dei modi per coinvolgere una persona introversa è al contrario conferirgli maggior autonomia.
Ad esempio, assegnandole 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 (traducibile approssimativamente come "cantinari"), descritto da Peters (1982) e adottato da sempre in aziende come IBM, 3M, Digital, HP con livelli ineguagliati di soddisfazione del personale e conseguente successo presso il pubblico dei loro prodotti.
Queste aziende lasciano liberi i dipendenti di organizzarsi come meglio credono, di lavorare con chi vogliono e di servirsi di tutti i mezzi che riescono a trovare in azienda, anche non convenzionali, allo scopo di svolgere efficacemente e comodamente il proprio 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 che è necessario esercitare si riducono pure al minimo: le persone lavorano alacremente senza che nessuno nemmeno glielo chieda.
Aziende come Microsoft non obbligano i dipendenti non solo a timbrare il cartellino, ma neppure a recarsi in azienda. A patto che essi riescano a consegnare il lavoro nei tempi e nelle modalità prestabilite, e su questo l'azienda resta rigida, il personale è libero di fare ciò che preferisce: andare in azienda, restare a casa oppure andarsene in ferie.
Naturalmente tutto ciò ha un rovescio della medaglia, che si chiama selezione: queste aziende non assumono chiunque.
Un altro elemento che caratterizza il personale tecnico appassionato al proprio lavoro è la gelosia per gli strumenti della sua attività: ha una cura ossessiva per i suoi computer, gli apparati, gli strumenti di misura e guai a toccarglieli senza permesso. Anche queste sono piccole cose che un accorto organizzatore dovrebbe saper osservare e rispettare. A volte l'acquisto di un nuovo strumento o di un nuovo e più potente computer è in grado di inorgoglire un tecnico e innalzarne il livello di motivazione per un lungo periodo di tempo, tutto sommato con una spesa modesta.
Alcuni parlano dell'importanza della cosiddetta politica della "porta aperta". Bill Gates, ormai ex presidente della solita Microsoft, è noto per aver sempre avuto un ufficio addirittura senza porte. Qualunque lavoratore dell'impresa, dal dirigente alla persona incaricata delle pulizie, poteva recarsi da lui per fare le sue rimostranze. Lui era sempre lì, e consumava i suoi 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 sarà un motivo. Certo, c'è stata dietro un'idea vincente e un periodo storico estremamente favorevole. Ma le migliori idee non vanno avanti e non possono realizzarsi se non ci sono anche formidabili intuizioni sul modo di far coesistere armoniosamente così tante persone.
La figura del quadro intermedio, il capo progetto del mio caso, era designata al ruolo di cerniera fra le diverse realtà presenti in azienda. Ciò richiedeva tuttavia adeguate abilità comunicative, che possono senz'altro essere apprese, ma della cui importanza è necessario prima di tutto essere consapevoli.
La formulazione dell'ipotesi di intervento
La formulazione dell'ipotesi è consistita in un'offerta di massima. I dettagli sono stati approfonditi in sede di progettazione, dopo l'approvazione della mia proposta. È importante sottolineare come quest'approvazione debba essere sottoscritta dall'utenza, poiché in caso contrario ci troveremmo a lottare, paradossalmente, proprio con la parte che dovrebbe ricevere il nostro aiuto.
In questo caso scelsi di effettuare la discussione separatamente per committente ed utente. Pur trattandosi della stessa proposta, adattai il linguaggio e lo schema di presentazione al differente tipo di aspettative di entrambi i tipi di rappresentanti. 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 della motivazione e della produttività del personale, articolai la mia proposta come segue.
Dopo averne parlato al committente e ottenuta la sua approvazione, 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 di partecipare, ma non obbligati a farlo.
Nel caso in cui qualcuno di loro avesse ritenuto di non averne bisogno, avrebbe potuto chiedere di esserne esonerato. Naturalmente, in questa evenienza si sarebbe dato per scontato che il livello delle sue conoscenze tecniche fosse già in grado di far fronte ai nuovi incarichi. Nel caso in cui questo non fosse stato vero, l'interessato avrebbe dovuto provvedere per conto proprio alla necessaria autoformazione, pena l'esclusione dalla partecipazione ai nuovi progetti in arrivo. In via confidenziale tuttavia, spiegai che la presenza di ognuno era raccomandata poiché, oltre ad 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 ciascuno.
Il corso sarebbe stato articolato su due livelli: nel primo livello sarebbero stati trattati gli argomenti tecnici di base e nel secondo quelli più avanzati. Dissi che dato il differente livello di conoscenza esistente fra i componenti del team, non era indispensabile che tutti partecipassero a entrambi i livelli, anche se 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 invece avesse scelto di frequentarli entrambi.
Procedendo in questo modo lasciai agli interessati un grande margine di autonomia, andando incontro al bisogno di maggior senso di responsabilità sull'iniziativa.
La mia proposta venne accettata subito di buon grado e senza alcuna obiezione da parte degli utenti, segno che avevo toccato gli argomenti giusti. L'approvazione contribuì a rafforzare anche nella committenza l'idea che l'inizio stesse avendo luogo nel modo desiderato.
Oltre a delle normali aule di istruzione specialistica organizzate a lezioni, le giornate avrebbero quindi 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.
|
Progettazione dell'intervento |
Rammento ancora una volta che gli obiettivi da raggiungere erano due:
| |
sviluppo delle conoscenze tecniche negli ambiti di interesse; | |
| |
sviluppo nel personale di un atteggiamento più funzionale agli obiettivi aziendali. | |
A questi possiamo aggiungerne un terzo meno evidente ma che, pur non essendo ancora stato menzionato, riveste pari importanza: favorire nel nostro committente lo sviluppo dell'abilità di comunicare con i propri collaboratori, sviluppando al contempo atteggiamenti che tenessero maggiormente conto del loro punto di vista.
L'abilità di comunicazione interpersonale torna sempre utile e consiste appunto nell'incontrare le persone su un terreno a loro familiare.
Non a caso, si tratta di una cosiddetta abilità trasversale.
Scelsi d'inserire nella proposta formale presentata all'azienda la partecipazione degli stessi committenti a seminari di comunicazione aziendale per quadri e dirigenti. A tali giornate avrebbero presenziato persone provenienti da aziende diverse. Quadri e manager sono in genere ben disposti a partecipare a iniziative dove possono incontrarsi con dei "pari grado" di altre realtà, per confrontarsi sulle rispettive esperienze.
I nostri committenti, ossia il capo progetto e il dirigente di divisione cui il laboratorio faceva parte, decisero di accettare e concordammo così anche sulla realizzazione di un corso di comunicazione per loro della durata di tre giorni.
Scelta delle metodologie e del personale docente
Al nostro interno decidemmo di suddividere il carico di lavoro in due. L'istruzione del personale tecnico venne curata dall'autore, mentre il corso di comunicazione per quadri e dirigenti venne seguito da un collega.
In entrambi i casi 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. | |
Organizzazione dei corsi
Articolazione e durataI 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 4 ore, con una pausa di alcuni minuti ogni ora. Le lezioni su argomenti tecnici furono alternate con riflessioni di gruppo sulla vita in azienda, secondo 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 fu 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 PC tramite l'uso di un programma apposito, che simulava le funzioni del registratore.
Alla fine della realizzazione, il software era programmato su una memoria E2PROM residente a bordo del registratore. L'innovazione consisteva nella programmabilità del registratore, che poteva adattarsi alle diverse funzioni richieste da un bar, un ristorante, un self-service o una cassa di supermercato.
Il corso di comunicazione per quadri e dirigenti durò anch'esso tre giorni e fu contraddistinto dalla seguente scaletta di argomenti:
| |
introduzione; | |
| |
l'abilità comunicativa; | |
| |
obiettivi del seminario; | |
| |
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. | |
Sede di svolgimento del programma
La sede di svolgimento dei corsi per i programmatori fu come già detto l'azienda. La sede in cui si svolse il corso per quadri e dirigenti fu invece un hotel situato appena fuori città.
Composizione dei gruppi
I programmatori decisero tutti autonomamente di partecipare ad ambedue i corsi. All'ultimo momento vi fu una sola defezione al corso base, dovuta a un imprevisto da parte di uno dei partecipanti. I due gruppi furono così di otto e nove persone.
Il gruppo del corso di comunicazione fu di quattordici persone.
Mezzi audiovisivi e altro materiale didattico
Il materiale impiegato:
| |
lavagne a fogli mobili; | |
| |
un computer dotato della possibilità di uscita su schermo gigante; | |
| |
un secondo computer di back-up nel caso si fossero verificati problemi nel primo; | |
| |
blocchi notes, penne biro; | |
| |
badge personali con pinzetta; | |
| |
radiomicrofoni ed impianto di amplificazione; | |
| |
libretti e fogli di risposta per i test da somministrare (vedi più avanti alla sez. verifica e valutazione); | |
| |
documentazione tecnico-didattica distribuita prima dell'inizio delle lezioni (vedi sotto). | |
Documentazione
Documentazione didatticaÈ noto che la documentazione per gli utenti in formazione ha normalmente scarse probabilità di essere letta. Tuttavia, trattandosi in questo caso di documentazione tecnica, essa fu al contrario 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 basandosi su tecnologie esistenti.
Nel corso di comunicazione venne fornito invece un sintetico manualetto redatto su misura, che riportava sommariamente gli argomenti trattati. Per gli approfondimenti si rimandò alla bibliografia consigliata.
Reporting per la committenza
La relazione finale per il cliente è invece indispensabile e 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, feddback sull'adeguatezza dello staff di docenza, gli aspetti organizzativi, la sequenza dei tempi, l'impatto del programma nel suo complesso, l'utilità di ulteriori periodi di approfondimento, verifica e follow-up.
Fu esclusa volutamente qualsiasi valutazione personale sui singoli partecipanti.
|
Verifica e valutazione dell'intervento |
Oltre a tutti i colloqui che avemmo con il personale e che sfruttammo il più possibile per ottenere le conoscenze di cui sopra, 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 ciò che era importante, 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, ossia il capo progetto e il dirigente.
Decidemmo di lasciar correre due 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'organizzazione aziendale fu il BFO (Big Five Observer), composto da 40 item e somministrabile in circa 5 minuti. Una utile particolarità di questo test è che può essere utilizzato sia per l'autovalutazione che per l'eterovalutazione.
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 di soddisfazione, dando un'idea globale del costrutto "importanza del lavoro" che la persona possiede.
Ciascuna somministrazione consistette quindi in una batteria composta da tre test.
Sebbene sotto il profilo teorico della standardizzazione, dell'attendibilità e della validità tutti i test che misurano atteggiamenti e valori siano criticabili, in quanto basati su punteggi ipsativi, essi possono rivelarsi utili nella pratica. Infatti Cronbach (1984) sostiene che "se a una persona un lavoro piace, non è importante se quel lavoro piace anche al 50% o al 90% delle altre persone".
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, nell'effettuare una valutazione più accurata del lavoro che svolgemmo.
Il confronto fra le due somministrazioni mostrò un miglioramento significativo in tutte e tre le aree sondate: le conoscenze tecniche, gli atteggiamenti verso l'organizzazione e i valori aziendali. I resoconti verbali di tutti i programmatori che parteciparono ai gruppi furono in generale positivi, riportando soddisfazione sia sugli apprendimenti tecnici che nella qualità dei rapporti con l'azienda.
Il capo progetto e il dirigente si dichiararono soddisfatti dell'esperienza all'interno del gruppo sulla comunicazione, sia nell'area dei contenuti che in quella del confronto con i partecipanti di altre aziende. In particolare, com'è tipico di chi frequenti per la prima volta un seminario sulla comunicazione, essi diventarono coscienti delle implicazioni legate al loro personale modo di esprimersi.
Durante questo corso venne impiegata anche la videocamera, per restituire ai partecipanti l'impressione suscitata dalla loro comunicazione, con effetti drammatici. Entrambi dichiararono che avrebbero proseguito lo studio della comunicazione sia leggendo dei libri che 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, soddisfacendo le richieste che le pervennero dai suoi clienti.
(leggi anche gli altri articoli)
| scrivimi |
| segnala a un amico |
| login |
| registrazione |
| "Controllare la complessità è l'essenza della programmazione" -B. Kernighan |
| "È l'unico lavoro in cui posso essere allo stesso tempo un progettista e un artista. Ha un aspetto incredibilmente rigoroso e tecnico, che mi piace perché ti costringe a essere estremamente preciso. D'altra parte, ha anche un lato smisuratamente creativo dove i soli limiti sono quelli imposti dall'immaginazione" -A. Hertzfeld |
| "Per sviluppare del software straordinario è necessaria una devozione fanatica alla bellezza. Se guardi dentro a dell'ottimo software troverai delle parti bellissime ma che nessuno vedrà mai. Non sto affermando che io scrivo software straordinario ma so che quando si tratta di programmare mi comporto in un modo che mi costringerebbe a curarmi se affrontassi allo stesso modo la vita di tutti i giorni. Mi fa impazzire vedere del codice indentato male oppure dei brutti nomi di variabile" -P. Graham |
| "È facile gridare 'Bug!' quando la verità è che hai un sistema complesso che può richiedere un po' di tempo per far sì che tutti i suoi componenti coesistano armoniosamente" -D. Vargas |
| "Programmatore: organismo che trasforma caffè in software" -Anonimo |
01/12/09
info@incom.fi.it cell. 329 4073565 tel. 055 8734699
firenze, signa