Parliamo di Innovazione

Innovare, dal latino “novus”, significa introdurre delle innovazioni.
Può essere di due tipi:

  • Introduzione di novità non precedentemente presenti ed aventi carattere di originalità.
  • Imitazione di novità non presenti nel proprio mercato/settore.
    Nel primo caso si parla propriamente di invenzione, nel secondo  caso di adozione o di diffusione (a seconda del ruolo esercitato nel proprio mercato).Il ciclo di vita di un prodotto, ma anche di una idea o di un concetto, è caratterizzato dalla sua adozione in fasce temporali successive, da parte di utilizzatori progressivamente sempre meno “innovatori”, a seconda della propensione al rischio, intelligenza, adattabilità plastica a nuove idee:
  • inception: viene adottato da innovatori radicali, detti early-adopters
  • chasm between early adopters and mainstream. E’ la zona di “bonaccia” ed assenza di vendite in cui di solito naufragano o stentano le nuove idee ed i nuovi prodotti, dopo le prime avvisaglie di possibile successo (dovute agli early adopters).
  • mainstream: viene adottato dal grande pubblico di late adopters: utenti senza non amanti del rischio, che in buona sostanza segue delle mode e ripete quello che vede fare agli altri. Se si tratta di un prodotto o di un servizio, questo diventa una “cash cow” e genera grandi qualità di danaro. Chi lo ha introdotto sul mercato rischia il pericolo di diventare compiacente, e di ignorare minacce nascenti da parte di competitor maggiormente innovativi. Le aziende veramente innovative tendono a rendere obsoleti i propri prodotti prima che lo facciano altri, sostituendoli autonomamente.
  • obsolescence: il modello proposto viene alla fine adottato anche da laggards, utenti che resistono attivamente l’innovazione ed acquistano qualcosa solo dopo che lo hanno fatto proprio tutti, in genere sposano un modello quando è praticamente già obsoleto ed esistono alternative più valide che iniziano a diventare mainstream, oppure rimangono fedeli alla propria scelta iniziale, compiuta anni ed anni prima. Hanno ancora minore propensione al rischio del pubblico mainstream. Oggi un laggard è per esempio chi in azienda utilizza ancora versioni obsolete di Explorer, con cui chiede la compatibilità, oppure chi pensa di utilizzare Bootstrap per un sito web che vuole definire innovativo e dedicato al grande pubblico, perché così fan tutti, e quindi non si può sbagliare.A voler fare la chiosa sulle intenzioni, viene da interpretare maliziosamente frasi del tipo “l’innovazione non è invenzione” con il maldestro tentativo di un late adopter di spacciarsi per innovatore a tutti i costi.
    Altri esempi nella vita (informatica) di tutti i giorni:Scelta di Java all’interno di un sistema informatico sviluppato dal nuovo, e giustificazione sulla base del: “le risorse umane costano poco”, “non si può sbagliare” o simili…Gente che si definisce “innovatore”, ma la cui principale innovazione tecnica consiste nel passare da Java Swing (circa 2010) a Java EE. e nel 2017.Ho conosciuto persone che si vantano di essere stati “il primo programmatore in Italia di Java” e che ad oggi, in “startup innovative di cui sono direttori tecnici” che propongono Java e PHP. Java sembra essere diventato il nuovo Cobol.E’ anche vero che se tutto quello che conosci come strumento è un martello, è difficile che il resto del mondo non venga visto come chiodi.

    Mi è stato chiesto di recente perché abbia utilizzato Golang per scrivere delle architetture back end.
    La cosa divertente è che chi me lo ha chiesto si è risposto da solo, “per passione”, non prendendo nemmeno in considerazione che questa strana scelta stravagante possa aver funzionato bene, o portato a casa un qualche risultato economico rilevante (tipo l’essere riuscito a raggiungere un certo risultato con mezzi economici veramente scarsi, in tempi rapidi e con buon successo prestazionale).

    A questo scopo è interessante notare la presenza di modelli e matrici per valutare la competenza di uno sviluppatore che sono semplicemente sconosciuti, lettera morta in Italia, tipo questa:

    Il problema è che da noi purtroppo viene spesso da dubitare che ci occupiamo davvero di informatica, da paese civile ed industrializzato.
    Troppo spesso chi seleziona cerca solo una conferma dei propri pregiudizi, visione del mondo, che spesso sono o semplici miti, o proiezioni e ricerche di autoconferme. E le decisioni sono spesso prese per sentito dire, senza nessuna riflessione critica, nessun esperimento. E dire che l’informatica nasce come disciplina scientifica, come ramo di matematica applicata, poi, purtroppo, sono arrivati gli ingegneri, ed in particolare gli ingegneri italiani.

    Esempi di miti:

    I più giovani sono innovatori: Falso, essere un innovatore è un attributo personale, e sono innovatori radicali ed early adopters pochissime persone. È difficile che un innovatore non sia un early adopter anche in altri campi, se manifesta posizioni “conservative” troppo spesso, sarà ben difficile che non effettui scelte conservatrici anche quanto a progetti.
    E il caso in cui si cerca, con approccio cerchiobottista, di prendere due piccioni con una fava: essere innovativi (a parole) ma senza voler davvero rischiare.
    Es.: medio dirigente di aziende non particolarmente innovative fonda startup, in cui prosegue sostanzialmente con continuità rispetto alla mansione precedente una “azienda innovativa” in cui continua a fare esattamente quello che faceva presso il suo primo datore di lavoro, sostanzialmente con gli stessi strumenti, informatici e concettuali. Vi aspettate delle innovazioni radicali?
    Siete degli ingenui ottimisti, e, cari investitori, otterrete un prevedibile ritorno sull’investimento di una normale piccola azienda di nicchia. Se per caso avete successo, dovrete buttare via e ricominciare tutto daccapo.

    Una persona competente conosce bene il linguaggio di programmazione che mi serve: Falso, una persona competente ragiona a livello concettuale e mappa il problema sul linguaggio e sulla soluzione più valida, il linguaggio ed il framework non è necessariamente l’unico elemento importante.
    Conoscenza è sapere, skill è sapere fare. Skill senza conoscenza vale esattamente zero, tanto quanto la conoscenza puramente teorica .
    Un buon praticante riflette sulla teoria e la applica praticamente, spesso producendo risultati propri.

    In questo senso vale più una conoscenza come “cultura generale” dell’esistenza del concetto di pattern software, unita ad esperienza di vita concreta, che non il pedestre tentativo di memorizzazione dei pattern ed il gioco ad “infila quanti più pattern puoi nel tuo progetto”. L’apprendimento puramente mnemonico, se devo dire la mia, in genere identifica i soggetti meno capaci: gente che conosce un linguaggio perfettamente, ha studiato, ma all’atto pratico non è in grado di scrivere dei programmi in modo originale, ed a volte non è nemmeno in grado di effettuare una banale decomposizione funzionale in modo autonomo.

    Fissarsi sulla conoscenza mnemmonica di linguaggi e piattaforme toglie poi letteralmente ossigeno alla possibilità che vengano sviluppate soluzioni davvero innovative in modo disruptive, per pochezza culturale e concettuale, l’uso di strutture dati complesse e di algoritmi sofisticati non viene mai preso in considerazione, nemmeno quando potrebbe portare concretissimi e decisamente netti vantaggi in termini di efficienza, produttività, prestazioni.

    Anzi, in un ambiente retrogrado, il “pensatore originale” viene di solito accusato di essere “poco concreto”, dimenticandosi che l’intera industria informatica è una costruzione concettuale, costruita letteralmente su astrazioni e livelli di astrazione.

    Conoscere bene le strutture dati e la teoria è più importante che non avere la padronanza di un particolare framework o linguaggio di programmazione (ed anzi, se conosci un unico linguaggio di programmazione in genere questo la dice lunga sul tuo personale ruolo di late adopter e motivazioni: ti sei fossilizzato presto, nel corso della tua carriera).

    Il problema delle piccole aziende in genere è il successo, non appena arriva, si passa rapidamente all’autocompiacimento, e ci si costruisce una visione del mondo in cui il capo decide, ed i sottoposti eseguono. Si chiede formalmente “di pensare ed essere propositivi”, ma qualsiasi proposta viene rapidamente scartata. La ricerca dell’efficienza a tutti i costi conduce paradossalmente proprio a questo: best practices e controllo strettissimo su processi, competenze (quelle “giuste”, già decise, ed architetture e soluzioni scolpite nel granito). Il risultato è nessuna flessibilità e zero tempo per fare qualsiasi esperimento che contraddica la visione del mondo di chi dirige e che è l’unico ad avere la delega di pensare in modo autonomo.
    Risultato: le best practices spinte all’eccesso spengono qualsiasi innovazione.
    Si fa tutto perfettamente, ma il mondo cambia, e si rimane fermi sulla propria posizione.

    Vuoi innovazione? Ci vuole Slack!
    Nonaka e Takeuchi, due ricercatori giapponesi che hanno fondato la disciplina del knowledge management affermano che per innovare occorre avere tempo a disposizione “slack”, in cui sia possibile “esplorare”.
    Ricordo come esempi di eccellenza la Google iniziale, con il 20% del tempo lavorativo a disposizione per progetti “propri” dei dipendenti, a volte sfociati in nuovi prodotti di Google (e poi istituzionalizzata con la creazione di Alphabet, o la HP dei tempi in cui era ancora una delle prime aziende di ingegneria e strumentazione del mondo, in cui il laboratorio e gli strumenti erano in modo molto innovativo “aperti” e disponibili.

    Volete riconoscere una azienda morta dentro?: è passata ad ISO9000, ma senza una vera cultura della qualità, e si concentra su formalizzazione dei processi in stile ITIL. L’idea di base,  è che le persone non siano importanti, e tutte le scelte mirano non a trovare una soluzione migliore, ma una in cui minimizzare l’importanza del fattore umano, con l’idea che i progettisti debbano in qualche modo essere ingranaggi, facilmente sostituibili.  Le procedure e la documentazione servono, ma non nascono con l’intento di reprimere qualsiasi innovazione. Il processo è un mezzo per lavorare meglio, ma non certo un fine da perseguire, altrimenti diventa solo un rituale, privo di significato, se non completamente deleterio.

    Il risultato di una efficienza rigidamente eseguita sulla base di best practices, con compiti assegnati e tempistiche inflessibili, strettamente monitorate, è che si producono sistemi non scalabili, non aggiornati, si ignorano le possibilità offerte da nuovi approcci, e si buttano via fiumi di soldi e di opportunità, naturalmente credendo di risparmiare e sicuri di fare tutto benissimo. Infatti chi è costretto a lavorare sulla base di task con tempo di soluzione assegnato per la soluzione di problemi piccoli e ripetitivi, perché mai dovrebbe “rischiare” ed esplorare nuove soluzioni? Non ne ha il tempo, e se lo facesse verrebbe escluso dal sistema.

    Purtroppo poi molte best practices sono semplici mode, diffuse da gruppi e società come brand per servizi di consulenza che non necessariamente sono allineate con gli obiettivi dei propri clienti, ma che hanno come unico fine l’aumento delle billable hours (le ore fatturatili impiegate in un progetto).
    Le grandi aziende di consulenza sono gli ultimi a fare da innovatori: devono accontentare clienti retrogradi, che le scelgono proprio perché sono dei conservatori. Per loro fare innovazione significa catturare delle parole chiave e cercare di inserirle nella propria organizzazione, ma spesso seguendo idee, ricette ed uomini secondo vecchi rituali. Si riuscirà ad essere conservatori anche nel perseguire progetti su Intelligenza Artificiale, Big Data e block chain? Si accettano scommesse, anche se sarà difficile superare autoinganno ed autocelebrazione.

    Alcune idee apparentemente sensate, quanto ad architetture informatiche, in realtà sono pessime: l’approccio a componenti software per UI in Java (un po’ come il socialismo reale, idea bellissima ed utopica, che però attuata produce grande sofferenza). Provate ad usare JSF, ed un normale MVC scelto a caso, notate delle differenze?

    Altre sono idee che sembrano buone sulla carta, ma non sono basate su riflessione e prova concreta sperimentale (che altrimenti ucciderebbe rapidamente questi approcci). Per esempio tra queste l’idea di utilizzare degli ORM per la persistenza dei dati, spesso sostituendo a gestione di codice dei complicati file XML di analoga o superiore complessità, nel disperato tentativo di riconciliare logica object oriented (java) con database intrinsecamente tabulari e basati su linguaggi dichiarativi di tipo SQL, tra l’altro così facendo infilando nello scarico del lavandino tutto il patrimonio di pratiche e conoscenze sul trattamento delle basi dati, con principi di integrità referenziale che rimangono, ma meno visibili allo sviluppatore, e che così generano ulteriore complessità, senza parlare di sciocchezze come le prestazioni del sistema…

    Risultato pratico: un ragazzo scrive un framework in cui non si usa direttamente SQL, ma un simpatico file XML di configurazione per mappare tabelle su oggetti java, e tutti i selezionatori HR (capre, quanto chi li assume) a chiedere non qualcuno che conosca i DB e ragioni di architettura a livello di sistema, ma qualcuno che conosca quel preciso framework…
    Il framework viene adottato da centinaia di migliaia di sviluppatori, e poi passa di moda. Non necessariamente l’innovazione è sempre buona, in particolare quando è solo una moda, e le basi fondamentali hanno maggior valore.
    Come sempre bisogna saper pensare, valutare, riflettere e fare esperimenti, pensare di poter limitarsi ad applicare un framework, una metodologia, genera solo mostri, vedi Scrum ed Agile usati senza testa, solo come cerimoniale o per “rendere più produttive” persone di cui sostanzialmente non si capisce e non si rispetta il lavoro.

     

    Ci sarebbe molto altro da aggiungere, ma per oggi mi fermo qui.

Lascia un commento

You are not allowed to enter any URLs in the comment area.