Quando i progetti di innovazione aziendale cominciano a maturare, ad esempio nel passaggio dai Proof Of Concept all’industrializzazione, arriva il momento in cui è fondamentale strutturarsi per convivere con le modalità operative e i processi primari dell’impresa madre, in modo da poterne cogliere appieno il vantaggio competitivo. Ad esempio, se dopo un pilota su un campione ristretto si punterà a raggiungere l’intera base clienti, bisognerà rispettare determinate regole di ingaggio in termini contrattuali, di compliance, di sistemi informativi e di trattamento dei dati. È in queste fasi che, pur non essendo un programmatore, mi sono trovato spesso a dover gestire tre diversi concetti nati nello sviluppo software, ma di grande rilevanza per la gestione dell’innovazione: si tratta dell’integration hell, del feature creep e del technical debt.
Cos’è l’inferno da integrazione
Quando si sviluppano in parallelo diversi elementi e sottosistemi, che testati in isolamento funzionano perfettamente, capita spesso che al momento di metterli insieme si generi una complessità molto superiore alla somma delle parti: ci troviamo allora nell’integration hell, o inferno da integrazione. Se non si fa attenzione, ne risultano costose rilavorazioni e cambi di perimetro in corsa, che possono impattare anche significativamente ciascun elemento individuale. Questo non accade solo nel software, ed è di particolare rilevanza quando bisogna far scalare i progetti dopo la validazione iniziale. In ogni fase del ciclo di vita di una iniziativa, è bene quindi chiedersi con un po’ di anticipo quali saranno le dipendenze fondamentali per passare alla fase successiva, e dedicare una piccola quota di tempo e risorse per identificare e preparare le integrazioni strettamente necessarie per il prossimo passo. Tornando all’esempio di apertura, a pilota ancora in corso potrebbe essere necessario capire come ottenere l’accesso ai sistemi CRM aziendali e disegnare i processi e gli incentivi per la vendita del nuovo prodotto o servizio alla clientela allargata.
Attenzione al sovraccarico di funzionalità
Attenzione però a non farsi prendere la mano: se si asseconda indiscriminatamente la prospettiva di lungo termine è facile cadere nella tentazione del feature creep, ovvero del sovraccarico di funzionalità. Man mano che aumenta il numero degli stakeholder aziendali da soddisfare, la pressione rischia di tradursi in una lista crescente di nuovi requisiti, compromessi all’apparenza innocui (“cosa ti costa?”), e idee ottime ma applicabili solo a stadi di sviluppo più avanzati. Diventa quindi fondamentale prioritizzare aggressivamente le energie e le risorse disponibili, concentrandosi sulle attività e gli obiettivi fondamentali della fase attuale, come sanno fare i bravi product manager. Questo però non significa censurare o ignorare gli spunti meno prioritari, che si possono catturare in un backlog da rivedere poi periodicamente per integrare la visione originale.
Come gestire il debito tecnico
Abbiamo visto che le scelte difficili e i trade-off si moltiplicano rapidamente: per affrontarli con maggiore coscienza torna allora utile la metafora del technical debt, o debito tecnico: ogni volta che si “prende una scorciatoia” per andare più veloci (ad esempio svolgendo manualmente processi che potrebbero essere automatizzati), si sta di fatto prendendo in prestito dalle risorse future, che prima o poi andranno spese per fare la stessa cosa in modo più robusto, scalabile e compatibile con i sistemi aziendali. Il debito tecnico ha due importanti caratteristiche in comune con quello finanziario: lo svantaggio è che per tutto il tempo in cui non viene ripagato bisognerà pagare degli interessi (ad esempio sotto forma di maggiori costi di gestione o maggiore complessità); il vantaggio è che, attraverso l’effetto leva, permette di raggiungere i primi esiti ed apprendimenti senza necessariamente impegnare una grande quantità di risorse.
Questo è un pregio non da poco per attività ad alta incertezza come quelle innovative: infatti qualora si scoprisse che una particolare direzione non è interessante o sostenibile, si potrà evitare del tutto di ripagare il debito – diversamente, per i soli percorsi validati, bisognerà gestirlo con attenzione e non lasciarlo crescere fuori controllo.
