Gli ultimi 5 anni hanno segnato una contrazione delle attività di consulenza. In Italia, in parte a torto e in parte a ragione, la figura del consulente è stata bollata come una spesa accessoria e spesso inutile. Eppure in altri settori, come la programmazione informatica, le risorse ambiscono ad una crescita che è orientata proprio alla consulenza e la project management. Cerchiamo di capire perché e quali siano le conseguenze più comuni.
Come ormai è noto, il consulente è colui che consiglia il cliente nell’ambito delle sue competenze. Il consulente informatico, figura piuttosto fumosa per certi aspetti, affianca un cliente non esperto in informatica, nella realizzazione di sistemi e architetture di varia complessità. L’area consulenziale, tuttavia, è diventata anche un pozzo per far sparire soldi in modo, spesso, illecito a danno di una professione tanto importante quanto affascinante.
Al contrario il ramo programmazione, nel corso degli anni, è rimasto molto più stabile. Questo in buona parte era prevedibile: i programmatori servono sempre, e il rapporto qualità/prezzo è un elemento di valutazione intramontabile, con la quale effettuare assunzioni e valutazione del personale. Tuttavia, sempre più frequentemente, i programmatori sembrano ambire ad ampliare le loro conoscenze uscendo dalla mera programmazione, per orientarsi ad un rapporto più aperto, esteso, e strategico con il cliente. Questo accade, generalmente, dopo i primi 5-6 anni di programmazione.
Gli analisti programmatori tra i 35 e i 40 anni sono quelli che, durante colloqui e interviste, hanno mostrato maggiore interesse per le dinamiche di business analysis, ossia per un ruolo decisionale orientato alla scelta delle tecnologie e delle strategie da adottare all’interno dei progetti. Quando viene chiesto il motivo del cambio di orientamento professionale, si ottiene una risposta importante. La maggior parte adduce motivi legati alla ripetitività del lavoro, con poca possibilità di spaziare in relazione a tematiche e clienti ma c’è anche dell’altro.
La prima cosa che si avverte è la mancanza di un vero e proprio controllo sul proprio lavoro. Molti programmatori dichiarano di sviluppare parti di codice richiesto da altri, e controllato da altri ancora. L’effetto da “catena di montaggio” però li fa sentire “ciechi”, con possibilità di crescita limitata e la loro situazione lavorativa viene percepita come “precaria”. Questa sensazione, in molti casi, si manifesterà come una realtà. Ci sono aziende disposte ad accettare programmatori giorni a scapito di quelli senior, perché più costosi e meno inclini a scoprire nuovi linguaggi legati a tecnologie più moderne. Ma questi programmatori senior, come si presentano?
Tra loro ci sono persone con ottima preparazione tecnica ma scarsa capacità avere una visione “complessiva” e dinamica del progetto. Molti di loro non hanno mai portato avanti un incarico dall’inizio alla fine, con conseguenti incapacità a rapportarsi con tutta la filiera produttiva del software.
Di conseguenza, dopo anni di programmazione, la loro ambizione cambia e si orienta verso una crescita più “manageriale” a cui, però, devono ambire con un po’ di fatica per mancanza di conoscenze gestionali. Vivono una realtà a parte i programmatori di piccole imprese che, spesso, riescono a seguire progetti di media entità, dall’inizio alla fine e con una certa autonomia gestionale.
Forse, però, il problema maggiore è legato al fattore metodologico che spesso viene trascurato se non completamente ignorato. La metodologia di sviluppo è, per forza di cose, diversa dalla metodologia di conduzione del progetto. Di conseguenza, nella maggior parte dei casi, vi è un deficit metodologico da compensare che spesso si rivela nella documentazione redatta dal programmatore. Il più delle volte questa documentazione è squisitamente tecnica, poco comprensibile al cliente finale, e spesso incompleta (non sono descritte le metodologie di collaudo, i risultati, etc…). In altri casi, più rari a dir il vero, sono completamente mancanti i documenti base della programmazione.
La carenza della documentazione è legata ad un retaggio, assolutamente sbagliato, nel quale si sosteneva che la documentazione avesse una priorità inferiore rispetto al prodotto finito. Resta ben inteso che senza la documentazione è molto difficile che un utente riesca a prendere il controllo di tutti gli aspetti del software. Non è quindi strano trovarsi a colloquiare con analisti programmatori che, a conti fatti, riconoscono di aver partecipato a tanti progetti di cui nessuno portato avanti dall’inizio alla fine. Senza alcuna esperienza nella descrizione di documentazione come studi di fattibilità, documenti progettuali o similari e con una crescita molto limitata.
Un’alternativa di sviluppo professionale molto valida, e che viene presentata tanto nei CV quanto nei colloqui, sono le consulenze extra-lavorative. Vale a dire tutti quegli interventi che la singola risorsa esegue al di fuori del contesto lavorativo principale. In tal caso, agendo in autonomia, la persona è “obbligata” a mostrare caratteristiche più carismatiche e strategicamente più evolute rispetto ai suoi colleghi. In tal caso ci si imbatte in figure professionali più complete, con capacità di programmazione molto elevata ma anche con conoscenze e capacità di definizione di documenti progettuali complete e di dettaglio.
