Lavoro IT/ Programmatori di uomini

Se l’Enterprise fosse un’azienda italiana qualsiasi, qualora il Capitano volesse strategicamente cambiare qualcosa nei sistemi tecnologici a supporto della missione, gli ufficiali di livello superiore risponderebbero prontamente… con una nutrita serie di riunioni.

A queste riunione, nel puro stile funzionale (o a silos, come lo chiamano gli americani), in cui ogni Responsabile nel proprio “silos” gode di piena ed assoluta autonomia, ogni convocato potrebbe prendere una delle seguenti decisioni: declinare l’invito, proporre nuove date o far intervenire chi vuole a titolo di “ascoltatore” (la decisione è sempre presa dal capo del “silos”).

Dopo una serie abbastanza lunga di riunioni ed un periodo molto più lungo di tempo gli ufficiali concorderebbero almeno su un aspetto: cosa proporre al Capitano per cambiare i sistemi secondo quello che ognuno di loro ha capito delle sue indicazioni. Nessuno degli ufficiali, infatti, inizierebe alcun tipo di lavoro, ma tutti insieme tornerebbero dal Capitano ed in un’ulteriore riunione tutti insieme gli mostrerebbero la proposta concordata. Se il Capitano nega il suo consenso si ricomincia ad organizzare riunioni, altrimenti si va avanti.

È chiaro che questa organizzazione è semplicemente pazzesca ed improponibile per ogni azienda che voglia fare profitto a causa delle sue drammatiche conseguenze (perdita di vantaggio competitivo, mancato profitto ed costi aumentati) eppure molte realtà italiane funzionano proprio cosi. Anzi, è molto probabile che neanche si rendano conto che lavorano cosi!

È molto probabile che alla fine del lungo giro di riunioni il cui unico fine è quello di aumentare il consenso e prendere una decisione plebiscitaria, così che non si possa effettivamente rintracciare un vero responsabile, la strategia aziendale sia cambiata e che quindi non serva più quanto richiesto dal Capitano, ma qualora si confermi il proposito di andare avanti occorre trovare chi è l’incaricato responsabile della modifica dei sistemi.

La scelta del responsabile del cambiamento dei sistemi probabilmente cadrà su un ICT, un project manager o, peggio, su una persona che non è un project manager, ma è chiamato con il titolo non meglio identificato di “coordinatore”, oppure è solo lo specialista della materia la cui unica colpa è quella di saperne qualcosa più degli altri sulla problematica in esame.
In ogni caso è una persona alla cui carica non corrisponde alcun potere reale a livello aziendale, meno che mai decisionale ed anzi, quasi sicuramente non è il capo gerarchico delle risorse che collaborano al progetto.
Forse il nostro ICT può arrivare a pensare che si tratti solo di un problema tecnico e che quindi lo tratti così. In realtà l’introduzione del nuovo sistema (o solo la modifica del vecchio) è un problemone e non da poco nello stagno (o palude) aziendale.

Tutto parte dalla considerazione che la nostra azienda italiana impiega persone, persone che hanno un livello di entusiasmo e pro-attività bassissimo a causa di anni di male gestione del personale. Lo studio globale di Towers Perrin, il Global Workforce Study , dice che solo il 21% dei lavoratori in Italia è motivato e che il 49% di essi è completamente demotivato.
Quel 49% è nell’area Distruttiva del Magico quadrante della motivazione (in basso a sinistra per intenderci): in pratica la mala gestione del personale ha ingenerato un tale malessere interno da portare gli stessi lavoratori ad essere completamente sfiduciati verso ogni tipo d’iniziativa. Questo significa che molti di loro cercheranno di opporre resistenza ad ogni cambiamento che non comporti anche ed immediatamente un miglioramento alla loro posizione.

E non voglio tralasciare il fatto che i vari responsabili, i padroni dei silos di prima, vedono il nostro ICT come un competitor o, peggio, qualcuno che può metterli in cattiva luce con il Capitano e quindi benché debbano mostrarsi collaborativi, in effetti non lo saranno affatto.
E con questo clima il nostro ICT si troverà ad affrontare uno di quei progetti che io chiamo: “destinati al fallimento”.

La tipica riunione di un progetto “Destinato al fallimento” si svolge cosi.

ICT: Vi ho convocato per illustrarvi il nuovo progetto richiesto dall’Alta Direzione etc etc etc.

Risposte ed impressioni raccolte dagli utenti/clienti che devranni usare il nuovo sistema o sono coinvolti nello sviluppo di esso: Io non lo sapevo.
Io non ho capito di cosa stiamo parlando.
Io non lo avevo capito così.
Io ho capito, ma vorrei avere un’analisi organizzativa dell’impatto sul mio dipartimento.
Io vorrei vedre prima i processi.
Io non penso di essere in grado, mi sembra troppo complesso e non siamo stati addestrati.
Io non ho tempo ne risorse.
Questo progetto non rientra nelle mie competenze.
È possibile avere infomazioni più di dettaglio?

La lista è molto lunga ma il senso ormai l’avete capito.
Se il nostro ICT cade nel tranello di considerare queste frasi come “piccoli sensati ostacoli, rimossi i quali il progetto andrà spedito”, è finita. Da programmatore di sistemi si traformerà in un programmatore di persone.

Più lui fornirà informazioni e si adopererà per prevedere anche l’impossibile e più la resistenza al cambiamento si farà più forte. Fino ad arrivare ad un’intensificazione del conflitto espressa in frasi come: ” nessuno mi ha detto cosa fare, se anche me lo avessero detto non ho avuto la formazione per farlo, se anche avessi avuto la formazione non l’ho capita, se anche l’avessi capita non ne ho compreso l’importanza, se anche ne avessi compreso l’importanza non avevo tempo per lavorarci, se anche avessi avuto il tempo etc etc etc “.

La lista dei task di progetto inizierà ad allungarsi come non mai. Ogni singola azione va divisa in N task: spiegazione degli obiettivi del task, formazione sul task, realizzazione del task, misurazione del risultato del task, riunione di condivisione sul risultato, etc.
Le ore di lavoro del nostro ICT aumenteranno, dalle solite 8-10 ore a 12-14, poi il Nostro inizierà a lavorare anche il sabato e la domenica.

È probabile che a questo punto o il progetto si cancellerà o il nostro ICT abbandonerà.

E siccome l’esperienza (ovvero il nome che noi diamo ai nostri errori) insegna a non commettere gli stessi errori in futuro, quello che normalmente si fa nelle aziende di questo tipo è assoldare per i nuovi progetti, quelli richiesti dal Capitano, un “costoso” ICT esterno a cui girare tutti i problemi (e le responsabilità).
Alla fine programmare un sistema per fargli eseguire dei compiti è cosa complessa e lunga, ma di sicuro successo: programmare le persone e far sì che siano la dorsale della Vostra impresa è cosa molto più difficile, ma anche molto più redditizia ed importante.

È forse un caso che Fortune abbia evidenziato come le aziende migliori sono quelle per cui le persone sono più curate?

Giuseppe Cubasia
Cubasia blog

I precedenti interventi di G.C. sono disponibili a questo indirizzo