Poche affinità e tante divergenze tra le società IT e noi tecnici, ovvero come rendere la giungla un po’ più vivibile e a portata d’uomo. Riflessione sui generis sul rapporto tra tecnico e azienda.

Tecnocrazia

La Tecnocrazia, parola la cui etimologia deriva dalle parole greche τὴχνη tecne (arte o tecnica) e κράτος cratos (potere), come forma di governo, significa letteralmente governo dei tecnici.

La definizione, presa direttamente dalla wikipedia italiana, non ha bisogno di ulteriori approfondimenti. Perché ci interessa? Perché l’informatica è certamente tecnocratica.

Apple, fondata da Steve Wozniak, un hacker, e Steve Jobs, un appassionato di computer in grado di vedere un business in ciò che allora era poco più di un hobby. Microsoft, nata dalla passione di Bill Gates, un giovane studente di Harvard, è partita dall’implementazione di un interprete BASIC fino a detenere il 90% di un mercato come quello dei sistemi operativi. Yahoo, nata dal progetto personale di due studenti di Stanford, Jerry Yang e David Filo, capaci di vedere un business nel creare gerarchie di siti web dividendoli per categoria. Google, fondata pochi anni più tardi da altri due studenti di Stanford, Sergey Brin e Larry Page, in grado di creare un impero da una idea semplice come organizzare il web relazionando i siti in base ai link da un sito all’altro. Gli esempi sono infiniti, da Red Hat a Oracle la tecnologia è in mano ai tecnici, che hanno creato nuovi mercati e compagnie in grado di sfruttarli.

Noi tecnici, senza accorgercene, sperimentiamo la tecnocrazia quotidianamente svolgendo il nostro lavoro, individuando i colleghi più preparati e assorbendone le conoscenze, ricambiandoli con rispetto e, inavvertitamente, sottomettendoci ai loro consigli e giudizi. Un buon designer deve essere un folle per non seguire con estremo interesse un consiglio di Jeffrey Zeldman o Jason Fried, un programmatore non può ignorare Paul Graham.

In Italia, purtroppo, la situazione è ben diversa. Il tecnico non è che un mezzo per raggiungere uno scopo, un operaio, la sua libertà decisionale è limitata all’ambito implementativo quando chi sta sopra di lui non ha i mezzi per decidere o non vuole tale responsabilità. Potrebbe sembrare un lieve vantaggio ma non lo è – se la featureset di un prodotto è errata (o, spesso, semplicemente stupida), l’implementazione può essere perfetta senza spostare di una virgola il valore intrinseco del prodotto. Sarebbe bello poter dare la colpa alle aziende, ma non è così. Il tecnico italiano è spesso il primo a sentirsi un operaio, a estranearsi da un progetto diventando un semplice “timbra- cartellino”, investendo pochissimo nella propria formazione o nel proprio miglioramento e compiendo scelte tecnologicamente molto discutibili, basate più che altro su ciò che le aziende più comunemente richiedono, senza farsi sfiorare dal dubbio che una tecnologia molto richiesta può trasformarsi nel giro di pochi mesi in una tecnologia eccessivamente richiesta. Il risultato è un mercato sovraffollato di curriculum fotocopia, che rende la selezione del personale estremamente difficoltosa per le aziende, abbassando il valore di queste figure e infine creando un divario gigantesco tra tecnico senior e tecnico junior. La cosa che pero’ lascia più perplessi, è il fatto che il gusto personale non rientri nell’equazione, ma anzi sia, nel migliore dei casi, relegato all’hobby, alla cultura personale, o più comunemente a qualcosa di superfluo che che placidamente non si fa – ci sono da pagare le bollette qui, non c’è tempo per giocare. Da una figura così, è difficile aspettarsi rivoluzioni. Infatti non ce ne sono.

A quanto pare la situazione è paragonabile ad un cane che si morde la coda: abbiamo professionalità su cui spesso non vale la pena di investire, per aziende che in ogni caso non ne hanno la benché minima intenzione.

Rivolta

Il primo problema da trattare è puramente tecnologico: le aziende non sanno trattare con la tecnologia, e i tecnici si piegano troppo facilmente. Una qualsiasi nuova tecnologia incontra un numero incredibile di resistenze all’interno di qualsiasi azienda, dalla più piccola alla più grande, e più l’azienda è estesa più è difficile introdurre qualcosa di nuovo, anche nel momento in cui è conscia che potrebbe trarne grandissimo beneficio. Tali aziende, al giorno d’oggi, pretendono di trovare personale già formato e velocemente inseribile nel loro staff tecnico, al più basso costo possibile (il che è comprensibile), semplicemente per delegargli “parti” di progetto che internamente non sarebbero in grado di sviluppare. Una volta usato, il tecnico se ne va per passare ad altro, nel vortice di insicurezze economiche e contrattuali che è il nostro paese al giorno d’oggi. Chiaramente un tale approccio non può funzionare in ambito tecnologico, per l’evidente motivo che una tecnologia nuova (e per “nuova” intendo una tecnologia come RubyOnRails, la cui versione 1.0 risale al Dicembre 2005) non ha ancora abbastanza sviluppatori per reggere tale carico. In realtà nemmeno una tecnologia come Python possiede questa caratteristica, nonostante la user base gigantesca e le innegabili qualità tecniche (Google e YouTube hanno certamente qualcosa da dire a riguardo).

Qui entrano in gioco le cosiddette Body Rental o, termine preferibile per concisione e chiarezza, gli Head Hunters. Una azienda preferisce spendere una cifra sensibilmente più alta a causa della strabordante stupidità di questa situazione, cifra che poi verrà ripartita tra tecnico e intermediario in solo Dio sa che percentuali. Una Body Rental, appunto, dispone di un range di figure professionali ben più ampio, range che le aziende clienti pagano profumatamente e con gli interessi, a scapito di chi poi il lavoro lo fa e con tutta probabilità preferirebbe di gran lunga essere dipendente dell’azienda, senza intermediari di sorta, ma che non può visto che … beh, le aziende usano le BR. La mentalità deve cambiare, nessun ingenuo può credere che l’arretratezza e la mediocrità tecnica, per fattori puramente logistico/organizzativi, possa far fiorire una industria come quella dell’IT tipicamente e ovviamente basata sul progresso.

Rivoltiamoci.

Smettiamo di piegarci alle scelte tecnologiche fatte da chi non è in grado di farle, e smettiamo di chinare la testa di fronte alla pretesa di avere sempre un ricambio facile per la nostra posizione, ma piuttosto rendiamolo possibile convincendo le aziende che l’unica via alla riuscita di un progetto non è lo sviluppatore senior “usa e getta”, ma un vero e proprio lead developer in grado di usare le sue competenze tecniche per formare il personale e guidare pienamente lo sviluppo tecnico del prodotto, dandogli le giuste responsabilità. Pretendiamo la carriera tecnica, il concetto per cui un ottimo sviluppatore diventerà un giorno un ottimo PM non è e non deve essere nostro, sono due figure differenti e che resteranno differenti, accumunate in modo piuttosto bizzarro da chi ha poca visibilità sui compiti e sulle competenze dell’una e dell’altra. Soprattutto investiamo in noi stessi, non attraverso “certificazioni” dalla dubbia utilità, ma attraverso una crescita costante e appassionata delle nostre competenze e dei nostri interessi, evitando il più possibile di accettare cifre ridicole e soprattutto contratti ridicoli (e quasi sempre illegali: quanti co.co.pro. non hanno l’obbligo di frequenza ?). Ma investiamo tout court, investiamo anche sulle nostre idee, cerchiamo finanziatori, i costi di startup in questo periodo non sono incredibili, ed esistono un numero infinito di modi per raggiungere finalmente l’indipendenza ed il successo (abbiamo addirittura un clone europeo di Y-Combinator), portando grossi benefici a noi stessi e al nostro mercato in perenne crisi di identità e in costante bisogno di esempi forti da seguire (o per meglio dire, copiare). E’ vero, può andare male, ma il gioco vale la candela, oltre all’inconfutabile ed evidente osservazione che in effetti ci va già male.

E’ chiaro che la mentalità aziendale italiana non si piega a piacimento in 2 settimane, ma dovessimo cambiare anche gradualmente il nostro atteggiamento nei confronti del lavoro, lasceremmo veramente poca scelta – una azienda che non si adatta al proprio ambito e mercato è destinata a fallire molto velocemente.

Rivoluzione

La rivoluzione (dal tardo latino revolutio, -onis, rivolgimento, cfr. re-volvere, rivolgere) è un mutamento improvviso e profondo che comporta la rottura di un modello precedente e il sorgere di un nuovo modello.

Ancora una volta Wikipedia ci viene in aiuto. Una rivoluzione è non solo auspicabile, ma direi necessaria onde non trovarsi in pochi anni ad essere un ulteriore paese di solo outsourcing, facendo fruttare le idee di chi le sa far fruttare ma senza ricavarne alcunché, e soprattutto con una moneta e una società forte che ci farebbe avere tutti i difetti di tale sistema, ma nessuno dei pregi.

Una rivolta dovrebbe portare le aziende a comprendere i benefici portati dal progresso tecnologico (no, non sto parlando di marketing), in grado di farci rivaleggiare con i paesi più sviluppati, convincerle che il personale tecnico non è ne poco importante per le loro infrastrutture e per il loro business ne sostituibile con uno schiocco di dita, ma una parte fondamentale da far crescere e sviluppare in seno all’azienda. Dovrebbe convincerle ad investire nelle idee dei tecnici e a sviluppare senso critico per capire dove investire e come farlo, e questo non solo per il nostro bene, ma per il loro. Certo, io sono un utopico (sono uno sviluppatore dopotutto), ma non trovo così impossibile arrivare inizialmente ad un compromesso, soprattutto per coloro che non hanno famiglie a carico e un costo di vita esagerato – ovvero dove il compromesso è perfettamente accettabile. Alla prossima analisi progettuale tecnicamente abbozzata ma straripante di termini “enterprisey”, avanziamo una proposta – un tecnico preparato ha per forza di cose argomenti per giustificare una scelta tecnica in cui crede – e soprattutto buttiamo sul tavolo motivazioni che possono attirare l’attenzione del management: maggiore produttività, minore richiesta di personale, formazione interna che faccia crescere il valore intrinseco del tecnico, maggiori motivazioni per il team, maggiore manutenibilità del software.

Vale la pena prendersi un minimo di responsabilità.

Un passo alla volta, ma un passo deciso.