Critical Decision-making: scelte tecnologiche e reali esigenze di business

David Saitta intervista Francesco Strazzullo

Le scelte che un team tecnico si trova ad affrontare - ad esempio, per poter iniziare a scrivere codice - sono innumerevoli, sia a livello di tool sia di conoscenza. La partita poi si fa ancora più complessa quando si passa a livello architetturale, cloud, serverless…
Un mondo di infinite possibilità che, spesso, può spaventare chi deve gestire un cambiamento o fare una scelta tecnologica.

Di questo e del perché prendere decisioni consapevoli è un game changer in molte realtà, ne parlano David Saitta e Francesco Strazzullo in questa intervista.
Buona lettura!

David: Ciao Strazz, mi fa molto piacere ritrovarti e fare questa piccola chiacchierata. Se non ricordo male ci siamo conosciuti grazie ad Avanscoperta al tuo corso Frameworkless nel “lontano” febbraio 2018. Uno degli aspetti che mi aveva colpito di quel corso era proprio una parte sul decision-making. Cos’è cambiato da allora?

Francesco: Ciao David, fa molto piacere anche a me. Effettivamente ho iniziato proprio in quel frangente a interessarmi a come i team prendono decisioni, in quell’occasione mi ero concentrato sulle guerre tra framework. Ora dopo un paio d’anni ho ampliato lo spettro anche ad altre decisioni critiche che i team spesso si trovano ad affrontare.

David: Tu ti definisci un sviluppatore front-end, e proprio in questo ambito di sviluppo si parla di “fatigue” e delle scelte che un team si trova ad affrontare: solo per poter iniziare a scrivere codice queste scelte sono innumerevoli, non solo a livello di tool ma anche di conoscenza. Senza contare aspetti non secondari come scelta architetturale, cloud/no-cloud, serverless/no-serveless… insomma un mondo di infinite opportunità che spesso può spaventare chi si approccia a un cambiamento o a una scelta tecnologica nel proprio team di lavoro. Da dove si parte per poter prendere decisioni consapevoli?

Francesco: Un primo step è quello di assicurarsi di avere davanti a sé varie opzioni, studiando e valutando varie tecnologie che possono risolvere in maniera diversa lo stesso problema. Altrimenti si ricade nel problema: “se l’unico strumento che hai è un martello, tutto quello che hai davanti sembra un chiodo”. Di solito questo però non è un problema, a patto di lavorare in un ambiente sano che in qualche modo permetta la formazione continua dei propri team.

Una volta che ci siamo assicurati che il nostro ecosistema ci permette di avere una cassetta degli attrezzi abbastanza fornita, parte il vero problema decisionale. La parola chiave della tua domanda è proprio la consapevolezza, ma consapevolezza rispetto a cosa?
Ciò che consiglio di solito è allineare le scelte tecnologiche alle reali esigenze di business. Proprio perché di solito mi occupo di front-end, faccio un esempio in questo campo. Molto spesso i team che si trovano a dover fare questo tipo di scelte si confrontano sulle performance e, per quanto credo che nel web moderno “performance is UX”, la verità è che per molte aziende l’aver guadagnato qualche millisecondo di rendering front-end è completamente ininfluente.
Quei team avrebbero dovuto parlare di altri temi tecnologici, ma che abbiano un reale impatto sul business. Questo è la base delle decisioni “consapevoli”: accertarsi che la decisione che stai prendendo sia influenzata da reali esigenze del business.

David: Concordo. Spesso noi programmatori ci concentriamo su aspetti tecnici rischiando di perdere di vista il vero obiettivo. Quindi queste decisioni, anche se tecniche o architetturali, acquistano più valore se nella discussione sono presenti altre competenze, siano esse di business, strategiche o, per esempio, del team UX con cui il team di sviluppo dovrà interfacciarsi.
Come si coinvolgono queste figure per abilitarle a portare valore in questo processo decisionale?

Francesco: Come tutto quello che riguarda le persone, non è mai semplice. Ci sono una serie di format che si possono mettere in campo per disegnare tutto il processo di delivery intorno al valore che consegna al business, ma il tutto dipende dalla cultura e dal modo di lavorare dell’azienda. Mi è capitato di fare da consulente in alcune aziende dove il fatto di lavorare a silos tra business, ops, UX e sviluppo non solo era all’ordine del giorno, ma era anche parte di un precisa volontà aziendale.

In queste situazioni si può gestire la cosa in due modalità: la prima opzione è quella di cercare di coinvolgere il resto del gruppo, spiegando che questo è fondamentale per permettere al team tecnico di lavorare al meglio. In questo caso infatti stiamo ponendo l’accento sul fatto che se i team non collaborano sull’allineamento attorno a un goal si perde in efficacia.

Se ci troviamo in una situazione in cui il business non accetta di lavorare in modo collaborativo, abbiamo una seconda opzione. Prendere decisioni in autonomia con le informazioni che si hanno, ma mettendo in chiaro al team (e al resto dell’azienda) che queste decisioni sono prese facendo delle ipotesi. Avere chiaro che si sta lavorando non con dati ma per supposizioni è importante, perché nel tempo il team tecnico dovrà fare una serie di operazioni per validare o scartare quelle ipotesi.

David: Nella tua esperienza, ti è capitato di vedere team che propendevano verso una data soluzione ma che hanno cambiato idea grazie a delle maggiori informazioni portate dal business o da persone esterne al team stesso?

Francesco: Sì, mi sta capitando sempre più di frequente di fare delle consulenze specifiche proprio sulla validazione di architetture tecnologiche, e spesso mi trovo a aiutare i team a trasformare le richieste del business in veri e propri requisiti non funzionali che cambiano completamente le decisioni tecnologiche.
Per esempio, mi è capitato di lavorare con una startup che era partita con un’architettura basata sui microservizi e su un linguaggio funzionale non conosciuto dal team. Il tutto era sensato da un punto di vista prettamente tecnologico: il team voleva assicurarsi scalabilità e correttezza. Ma analizzando insieme elementi quali un modello di business e un’analisi SWOT, il team si è reso conto che il bisogno di velocità richiesto dal management era completamente sensato. Il time to market era fondamentale. Alla fine il team ha deciso di lavorare con un monolite con un linguaggio più alla loro portata in quel momento. Devo però dire che questo lavoro è più facile se sei un consulente esterno, ti dà un occhio critico che da dentro un team di sviluppo non è sempre semplice sviluppare.

David: Le decisioni, quindi, sono influenzate dal contesto, dal momento in cui si trova un’azienda e dallo scopo finale: tutti elementi che, in qualche modo, evolvono, e quindi una decisione “giusta” presa in un determinato momento potrebbe non esserlo più in un altro. Come si può affrontare il caso in cui ad un certo punto il team scopre che la decisione che è stata presa era sbagliata o comunque non più valida?

Francesco: Quando parlo di decisioni tecnologiche “consapevoli”, questo è un punto fondamentale. Capire che essendo legate al contesto, e quindi anche al momento, tutte le decisioni sono a “tempo”. Prendendo consapevolezza di questo, si può disegnare un’architettura che permetta a se stessa di essere messa in discussione più avanti. Questo approccio è quello che Martin Fowler chiama Sacrificial Architecture.

Un esempio che si riflette nella decisionalità è il dilemma tra librerie e framework. A parità di altri fattori quali il throughput del team o le perfomance, un set di librerie permette un grado di evolvibilità più alto rispetto al framework proprio perché un singolo pezzo può essere sacrificato nel tempo. In pratica, più che chiedersi come risolvere una decisione sbagliata, si può ragionare su come rendere le decisioni “reversibili”.

Il punto è proprio chiedersi costantemente in che contesto stiamo sviluppando software. Il rischio infatti non è tanto aver preso una decisione sbagliata, ma continuare a perseverare su una strada che non è giusta senza neanche rendersene conto. In questo modo si accumula un debito tecnico difficilmente recuperabile.

David: Mi è capitato di incontrare dei team che, per molti anni (decenni), sono stati talmente concentrati sul proprio prodotto/servizio da non essersi "accorti" dei vari cambiamenti che sono avvenuti nel nostro settore, con la conseguenza di essere rimasti indietro "ere geologiche". Ora si trovano spiazzati dal mercato che richiede certi cambiamenti come, per esempio, l'uso sempre maggiore delle applicazioni web-based in contrasto con quelle client-server. Se ci pensi, per un team come questo, la mole di energia che dovrebbe mettere in campo per recuperare terreno (e potenzialmente mercato) è enorme. Quasi sempre la richiesta è quella di chiedere consulenza per scegliere il nuovo stack, quasi come per dire: non ho esperienza su queste nuove tecnologie, dimmi tu (consulente) cosa devo usare e come. Oltre ad un abbraccio fraterno, cosa consiglieresti a questi team?

Francesco: Fino a ora abbiamo sempre parlato del contesto come di un elemento fondamentale per prendere decisioni consapevoli, ma non è il solo. L’altro importante elemento è proprio “l’identità” di quel team.
Cosa intendo con “identità” di un team? Possiamo partire da una Skill Matrix che metta in chiaro il livello del team su una serie di tecnologie o metodologie. Questo tipo di esercizio di solito fa anche emergere una serie di “smell” nella cultura aziendale. Un rifiuto da parte del team di compilare una Skill Matrix spesso nasconde per esempio la paura di essere giudicati, vuoi per una cultura aziendale che instilla il terrore dell’errore o vuoi per meccanismi di premi aziendali che basano tutto sull’individualità.

Quindi di solito, quando mi trovo in situazioni simili a quella da te descritta, cerco di far capire al team che il percorso da affrontare è lungo e sicuramente impegnativo. Scegliere un nuovo stack scintillante, non solo non risolve nulla, ma spesso peggiora la situazione.

David: Hai parlato di cultura aziendale, credi che anche questo aspetto influisca direttamente quando si parla di scelte tecnologiche?

Francesco: Sicuramente lo fa. Ma la cultura aziendale è anche uno strumento con il quale si può aiutare tutta l’azienda a evolvere e a imparare a prendere decisioni. Ricordo (anche con affetto) il mio primo giorno di lavoro in extrategy (che sarebbe poi diventata Flowing), durante il primo meeting a cui partecipai mi dissero “Non aver paura di sbagliare”.

Instillare una cultura aziendale che sproni tutti i collaboratori a prendere decisioni, senza instillare la paura del fallimento, è un catalizzatore potentissimo.

Vale ovviamente anche il contrario: una pessima cultura aziendale può completamente affossare la capacità decisionale di un team.

David: Tutti questi temi verranno affrontati nel tuo workshop Decision-making for Software Development Teams che, pur essendo da remoto sarà, come tutti i tuoi workshop, molto interattivo. C’è un aspetto in particolare che ti sta a cuore e che vorresti che i partecipanti si portassero a casa?

Francesco: Direi che la cosa più importante da cogliere sarà sicuramente che “Prendere una decisione buona in modo giusto è molto più importante di prendere una decisione giusta”. Quello che faremo durante il workshop è definire insieme un processo utilizzabile per prendere alcuni delle decisioni tecnologiche iniziali di un progetto. Questo ci darà l’occasione di capire (tramite alcuni esercizi) come distillare in termini misurabili i concetti astratti che abbiamo usato in questa intervista quali contesto e identità.

David: Prendere decisioni consapevoli è sicuramente un game changer in molte occasioni e realtà. Grazie Francesco per la bella chiacchierata, spero di rivederti presto magari in uno dei prossimi eventi organizzati da Avanscoperta.

Francesco: Grazie a te!

Foto di Maarten van den Heuvel on Unsplash

Learn with Francesco Strazzullo

Francesco è trainer del Decision-making for Software Development Teams Workshop e autore del libro Decision-making for Software Development Teams (edito da Avanscoperta e disponibile su LeanPub).

La lista completa dei nostri corsi: Avanscoperta Workshops.