La paralisi da innovazione e la sindrome del Not Invented Here

Nel mondo IT esiste un paradosso tragicomico: organizzazioni che considerano sperimentale una tecnologia con dieci anni di servizio attivo, usata da milioni di sviluppatori, mentre fanno girare in produzione software improvvisato scritto senza standard riconosciuti. La paura di essere early adopter colpisce selettivamente, creando una paralisi decisionale che porta ad adottare le tecnologie sbagliate al momento sbagliato.

Questa cautela patologica si manifesta quando si suggerisce di usare tecnologie consolidate. “Ma è sicura? È testata? Chi altro la usa?” Praticamente ogni altra azienda tech sul pianeta, ma potrebbe essere solo una moda passeggera secondo chi teme l’innovazione.

La paranoia selettiva

La paranoia dell’early adoption colpisce in modo curioso. Lo stesso manager che considera sperimentale un framework usato da milioni non ha problemi a far girare sistemi costruiti senza standard. La definizione di tecnologia consolidata diventa soggettiva: qualsiasi cosa familiare è sicura, qualsiasi cosa nuova è pericolosa.

“Ma chi ci garantisce che tra cinque anni esisterà ancora?” Ignorando che le tecnologie standard esistono da vent’anni, mentre soluzioni proprietarie interne spariscono continuamente.

Database NoSQL usati da metà di Internet sono “troppo nuovi”, mentre database proprietari con documentazione inesistente sono “affidabili”. Linguaggi con milioni di sviluppatori sono “rischiosi”, mentre linguaggi esoterici interni sono “strategici”.

Il paradosso degli early adopter sbagliati

Questa cautela patologica porta spesso a essere davvero early adopter, ma delle tecnologie sbagliate. Mentre il resto del mondo passa alla versione successiva, alcune organizzazioni celebrano l’adozione della versione precedente come grande innovazione. Si diventa pionieri dell’obsoleto.

Si arriva tardi alle feste tecnologiche. Quando finalmente si decide di adottare una tecnologia, il mercato sta già migrando al suo successore. Si investe in formazione su tecnologie al tramonto. Si costruiscono competenze che il mercato sta già dismettendo. Si creano dipendenze da stack tecnologici che perderanno supporto a breve.

Il timore delle competenze mancanti

“Non abbiamo le skill!” è l’obiezione classica. Mentre si dipende da consulenti per mantenere sistemi talmente vecchi che i loro creatori sono in pensione.

Acquisire competenze su tecnologie moderne è visto come rischio. Ma mantenere competenze su sistemi obsoleti è considerato prudente. La logica è invertita: ciò che è difficile imparare oggi sarà impossibile mantenere domani. Trovare esperti di tecnologie moderne è facile ed economico. Trovare esperti di legacy è difficile e costoso.

Late regretters invece di early adopters

Essere troppo cauti può essere più pericoloso che essere troppo audaci. La cautela eccessiva porta a diventare late regretters: quelli che si pentono di essere arrivati tardi quando tutti sono già andati via.

“Meglio tardi che mai” è il mantra. Peccato che nel mondo della tecnologia, tardi significa troppo tardi. Ogni anno di ritardo accumula gap che diventano sempre più costosi da colmare.

La scusa per evitare il cambiamento

Questa paranoia è spesso solo una scusa per non uscire dalla zona di comfort. È più facile continuare con tecnologie familiari, anche se obsolete, che affrontare il cambiamento. La paura si traveste da prudenza.

Ogni proposta viene accolta con scetticismo rituale. “Non è matura.” “È rischiosa.” Le obiezioni non nascono da analisi razionale, ma da resistenza emotiva. Il risultato sono organizzazioni congelate, incapaci di evolversi.

La sindrome del Not Invented Here

A questa paranoia si aggiunge la sindrome del Not Invented Here (NIH): la convinzione che qualsiasi soluzione non sviluppata internamente sia inferiore.

I sintomi: reinventare ruote quadrate quando esistono librerie perfettamente rotonde, convinzione che “i nostri requisiti sono unici” anche per problemi banali. Team spendono mesi a sviluppare framework proprietari mentre quelli open source maturi vengono ignorati.

NIH nei contesti critici

La sindrome NIH è particolarmente assurda in contesti critici. Progetti in ritardo dove si decide “costruiamo il nostro framework di test, quelli esistenti non sono abbastanza buoni”.

È come decidere, mentre la casa brucia, che i camion dei pompieri non sono del colore giusto e costruirne uno da zero. Ogni settimana spesa a reinventare soluzioni standard è sottratta al valore di business.

Le cause profonde

Le cause della sindrome NIH sono molteplici. Ego di architetti che vogliono lasciare il loro marchio. Paura di dipendenze esterne. Attrazione verso problemi tecnicamente interessanti invece di quelli necessari per il business.

Usare tecnologie standard è visto come privo di creatività. Costruire soluzioni proprietarie come dimostrazione di eccellenza. Questa distorsione porta a sprecare talento in reinvenzioni inutili che richiedono manutenzione continua, mentre le alternative standard evolvono gratuitamente.

La terapia necessaria

La terapia è dolorosa ma necessaria. Serve un inventario onesto delle competenze core, seguito dalla domanda: “Siamo davvero i migliori al mondo in questo?”

Probabilmente no. Riconoscere questo non è ammettere debolezza, è dimostrare saggezza. Serve distinguere tra ciò che è differenziante per il business e ciò che è commodity tecnologica. Ma questa distinzione raramente viene fatta con onestà.

Verso un equilibrio possibile

L’equilibrio sta nel riconoscere quando una tecnologia è veramente matura, indipendentemente dalla familiarità personale. Significa accettare che le competenze si possono acquisire, che le dipendenze esterne gestite bene sono meno rischiose di quelle interne gestite male.

Significa avere il coraggio di adottare standard quando hanno senso, e la disciplina di non reinventare soluzioni a problemi già risolti. Significa distinguere tra prudenza razionale e paralisi da paura. Ma questo richiede leadership che valorizzi il pragmatismo sopra l’ego, che misuri il successo sui risultati piuttosto che sul codice proprietario prodotto.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT