Un vecchio adagio ci ricorda che solitamente “Chi sa, fa, chi non sa, parla”. La questione è che bombardati da facili slogan intrisi di buzzword all’insegna dello storytelling, dove l’elemento narrativo sovrasta l’elemento pratico e concreto, si finisce per raccontare che la “Trasformazione Digitale” sia un qualcosa di perseguibile con la sola pronuncia di qualche parola inglese smart farcita da una dose di entusiasmo, come se la realtà si piegasse necessariamente al racconto che ne facciamo.
Il tuo interlocutore è una persona seria?
Ecco alcune delle buzzword che dovrebbero costituire un campanello d’allarme e uno spartiacque sostanziale tra il ci fa e il ci è:
- Soluzioni Win Win,
- Strategie Quick and Dirty,
- Happy problem,
- È banale.
Una delle cose più importanti che ho imparato dopo anni nella gestione di progetti digitali è che una soluzione quick and dirty si rivelerà quasi certamente molto dirty e decisamente poco quick.
Un’opzione che si rivelerà molto presto fallace, vuoi perché scritto in maniera poco pulita e comprensibile a causa di un approccio frettoloso (creando così un divario cognitivo notevole per chiunque abbia necessità di intervenire successivamente), vuoi perché la soluzione ha generato un inevitabile debito tecnico, essendo magari adeguata all’esigenza del momento, ma del tutto inadeguata per scalare. Insomma, le esigenze di business richiedono un processo maieutico più profondo di interazione.
Questo genere di atteggiamento ha via via indotto le organizzazioni a concentrarsi maggiormente sugli aspetti di Presale e Sale, e spesso in una logica al ribasso con l’idea che, tutto sommato, vendere un progetto costituisca un “happy problem” e che superato lo scoglio contrattuale il resto del processo si riduca ad un meccanico “batter tasti” dei programmatori.
Invece, adottare una soluzione software per potenziare, sostituire e duplicare (vedi il concetto di Digital Twin) un processo aziendale, un servizio o un prodotto, implica necessariamente scontrarsi con:
- la complessità data dal dominio di business,
- la complessità data dagli aspetti tecnici di implementazione,
- la necessità di far interagire questi due aspetti in modo sinergico all’interno di un sistema interdipendente.
Questa operazione non si può banalizzare e non può essere ridotta a un’attività compilativa da catena di montaggio o paragonare allo sviluppo di un videogioco già pronto su uno scaffale.
Tra l’altro, quante volte anche di recente abbiamo assistito al naufragio di prodotti videoludici? Un esempio su tutti il caso di Cyberpunk 2077 (un gioco che si è rivelato essere un “pasticcio” pieno di bug) finito per essere addirittura ritirato dal commercio dalle prime release.
SCOMPORRE IL PROBLEMA, NON SCALARE LA MONTAGNA
La questione fondamentale di qualsiasi processo di Trasformazione Digitale è la scomposizione del problema: prendere un problema complesso e scomporlo in “pezzi” che possano essere risolti in modo indipendente.
Ciò che distingue un’azienda solida in campo digitale da un’azienda fuffa (storytelling addicted) è l’abilità di progettazione; questa qualità è la stessa che distingue i grandi programmatori di software da quelli mediocri.
Il processo di Digital Transformation è un lavoro cognitivo che richiede esercizio di intelligenza e un certo grado di visionarietà. Tuttavia, non si tratta di un talento innato o di una lavorazione da fabbrica di bulloni, ma, per capirci, assomiglia di più a un corso di scrittura durantel quale gli studenti applicano un processo iterativo: scrivono una bozza, ricevono dei feedback e tornano sullo scritto per apportare miglioramenti.
Nel caso della progettazione software, spesso ci si trova di fronte a problemi che rasentano il filosofico, come ad esempio la gestione dell’ubiquità del dato; in questo caso va definito il significato di un determinato oggetto e costruita una propria ontologia. Un processo che richiede uno sforzo decisamente maggiore a un esercizio di mera astrazione. Infatti, nella progettazione del sistema che si andrà a implementare, si impara attivamente scrivendo codice e commettendo errori, e si sperimenta come gli errori stessi e le successive correzioni si riferiscano ai principi da cui si è partiti.
La Trasformazione Digitale consente all’organizzazione che si avventura in questa impresa di acquisire un vantaggio competitivo – “fare più schei” si direbbe qui in Veneto. Questo processo richiede però una comprensione approfondita del percorso che comporterà la messa in campo di menti creative e la capacità di tradurre i pensieri in requisiti chiari e distinti.
Se puoi schematizzare e visualizzare un sistema, probabilmente lo puoi implementare in un programma per computer.
Cosa significa.
Significa che il limite maggiore nella scrittura di software è esattamente la nostra capacità di comprendere il sistema che stiamo creando. Un sistema che progressivamente si evolve acquisendo nuove funzionalità, aumentando così la sua complessità e incrementando le dipendenze tra i suoi componenti.
La complessità è un elemento dall’incremento esponenziale nell’esperienza umana e in quella professionale, e allo stesso modo anche nel software. Più grande e impegnativo è il programma, più persone ci lavorano e più difficile diventa la gestione della complessità che ne deriva.
La qualità fondamentale per attuare un processo di Trasformazione Digitale è la capacità di leggere le relazioni tra le componenti organizzative di business e tradurle in requisiti da implementare.
La complessità si può superare attraverso quattro approcci complementari:
Visualizzando le componenti del sistema, le relazioni, i flussi, le strutture, e cercando di ottenere “fotografie” dinamiche di ciò che si intende realizzare
Cercando di scomporre il problema e i requisiti di business fino a ridurli alla loro unità più semplice e ovvia
Costruendo un linguaggio condiviso con il cliente o il partner di business (spesso la complessità e i problemi si annidano in questioni ritenute “banali”)
Incapsulando la complessità e dividendola in moduli autosufficienti, così da direzionare il lavoro dei programmatori del team su porzioni del sistema
Semplificando, si tratta di scomporre l’applicazione da realizzare in moduli progettati per essere relativamente indipendenti l’uno dall’altro in modo da affrontare lo sviluppo di singoli moduli senza dover comprendere i dettagli degli altri.
LO SVILUPPO INCREMENTALE
È importante sottolineare come ormai circolino negli ambienti di business due tipologie di Agile:
- l’Agile raccontato, che è afferente al mondo delle chiacchiere,
- l’Agile praticato, che diventa uno stile quotidiano di approcciare la produzione, la vita professionale e per alcuni la vita.
In concreto, Agile è uno sviluppo incrementale che tutela fornitore e cliente massimizzando l’investimento di risorse. Lo fa attraverso una progettazione in grado di concentrarsi su un piccolo sottoinsieme di funzionalità, rispetto alle complessive desiderate. Questo sottoinsieme di funzionalità, o micro requisiti, viene progettato, implementato e infine valutato. Eventuali problemi inerente a un design iniziale vengono scovati e corretti. A questo punto si procede con una nuova e più funzionale progettazione, implementando e valutando ulteriori altre funzionalità. Un procedimento a cerchi concentrici che va dalle funzionalità “core”, alle funzionalità più esterne “nice to have”.
Distribuendo e dosando la complessità in questo modo, eventuali problemi del progetto iniziale possono essere risolti mentre il sistema è ancora “piccolo”; inoltre, le funzionalità successive traggono vantaggio dall’esperienza acquisita durante l’implementazione di quelle precedenti, presentando di conseguenza meno problemi.
Questo approccio distingue lo sviluppo software dall’edilizia. Per capirci, l’approccio incrementale funziona per il software perché è un prodotto cognitivo, un po’ come il testo che sto scrivendo che è malleabile al punto da consentire correzioni di progettazione significative durante l’implementazione. Mentre in ambito edilizio, dove la dimensione è fisica, i cambiamenti di progettazione sarebbero decisamente più impegnativi, se non impossibili – a chi verrebbe in mente di modificare il numero di piloni che supportano un ponte nel bel mezzo della sua costruzione!
Insomma, tornando al paragone iniziale, la Trasformazione Digitale di un processo di business non è raffrontabile all’acquisto di un videogioco o un prodotto a scaffale. Fin dalla sua progettazione esso si basa sul tipo di sviluppo incrementale descritto, ciò significa che la progettazione stessa, in fin dei conti, non viene mai pienamente completata.
Riesco a immaginare che, a questo punto, se sei un feticista dei diagrammi di Gantt, delle milestone e di cose analoghe, tu abbia già sbottato indignato e probabilmente non mi starai più leggendo. Me ne farò una ragione.
LA TRASFORMAZIONE DIGITALE COME ORGANISMO VIVENTE
Quello che invece vorrei farti capire, se stai proseguendo la lettura, è che la progettazione avviene continuamente durante la vita di un sistema: dovresti sempre pensare ai problemi di progettazione come se stessi approcciando un organismo vivente.
Un buon esercizio di paragone è considerare i processi di progettazione e sviluppo software in un’ottica di apprendimento costante, come l’educazione di un figlio. Così come per le fasi biologiche di una creatura, un progetto di sviluppo software (o anche un’Intelligenza Artificiale), ha fasi e cicli che ne determinano la “stagione” di vita; ciò non toglie la possibilità di fissare scadenze, milestone e mettere delle barre in un foglio di calcolo elettronico (Excel o simili), ma presuppone la comprensione che tali previsioni siano l’equivalente del tirare a indovinare la professione da adulto di tuo figlio di tre anni.
Il nostro lavoro come sviluppatori di software è quello di accompagnare le Aziende in un processo di Trasformazione Digitale che non implichi unicamente “creare del codice” per lavorare facilmente, ma scriverlo in maniera che anche altri possano, a loro volta, essere facilitati nel lavoro ottenendo sistemi informatici semplici, efficaci e accessibili.
Trasformare equivale a saper leggere i contesti di business, appropriarsi di un dominio, gestire la complessità e ridurre il carico cognitivo. Affrontare il carico cognitivo significa semplificare, significa poche informazioni e chiare; vuol dire consentire agli sviluppatori di non sprecare tempo prezioso nello studio di astruse richieste consentendogli di creare software in base a requisiti di business più precisi, riducendo di conseguenza il rischio di bug, perché non si sono persi qualcosa di importante lungo il percorso.
Disinnescare incognite di progetto, condividere i metodi di implementazione, ridurre le variabili globali del sistema da implementare e minimizzare le incongruenze e dipendenze tra i moduli implicano una maggior qualità del software.
In conclusione, se stai cercando un compagno di viaggio che ti affianchi con serietà e concretezza in un processo di vera Trasformazione Digitale queste sono le qualità che dovresti cercare.
Aziende con un bagaglio di esperienze consolidate nella gestione di progetti e nella loro implementazione, competenze maturate sul campo e con la visione giusta per scomporre i tuoi problemi, trovando soluzioni che giovino al tuo business e abili nel tradurre queste stesse soluzioni in codice di qualità.
Per tutti gli altri, soprattutto per gli storyteller, c’è questo adagio: A ship on the beach is a lighthouse on the Sea (proverbio olandese citato in “The Mythical Man-Month” di Fred Brooks).
TI È PIACIUTO QUESTO ARTICOLO? LEGGI ANCHE:
Digital Transformation in azienda: leadership e cambiamento culturale
5 atteggiamenti possibili di fronte allo sviluppo tecnologico (ma solo uno è pienamente etico)
Narrazione creativa d’impresa: video storytelling emozionale
