Ridurre il divario tra teoria e progetti reali

Una chiacchierata con Matteo Forni, product designer.

Alessia: Parliamo di come ridurre il gap tra la teoria e il mondo dei progetti reali. Matteo Forni, il nostro product designer, ci introdurrà nel contesto.

Matteo, quando si verifica questo scollamento?

Matteo: Questo gap si verifica soprattutto nel settore industriale B2B, quando fornitore e cliente sono due grandi organizzazioni strutturate. In entrambe ci sono ruoli che si sono sviluppati nel tempo i quali ritengono – anche grazie ad una comprovata esperienza – di possedere le conoscenze per poter ideare e progettare un nuovo prodotto; nel nostro caso, un prodotto tecnologico. Queste figure, che potremmo definire “di accentramento”. detengono sia la conoscenza attuale, quindi ciò che serve a mettere in pratica il processo di sviluppo del nuovo prodotto, anche quella pregressa, che di fatto “contiene” anche le modalità di progettazione che spesso il cliente vuole mantenere; poi c’è anche un aspetto legato al futuro, ossia dove il prodotto tecnologico si deve dirigere.

Il gap nella pratica si verifica fra chi idea e pianifica la progettazione del prodotto tecnologico e coloro che devono realizzarlo, che mettono a terra tutto ciò che deriva dalla fase preliminare di progettazione.

Capita che, per accordare questi due silos interni alle due organizzazioni (cliente e fornitore), si tenda a generare un vero e proprio “libretto di istruzioni”, un documento di specifiche nel quale sia il fornitore sia il cliente sono convinti che vi si trovino tutte le informazioni per costruire perfettamente un prodotto tecnologico desiderabile, sostenibile e fattibile.

In questa fase dunque non esiste una strategia fra le parti che miri a considerare il contributo di più stakeholder nella fase di analisi del progetto che rischia di rimanere incompleta.  

Alessia: E perché si pensa che questo documento di specifiche sia sufficiente per realizzare un progetto?

Matteo: È quasi automatico, forse addirittura fisiologico, pensare di poter dare delle informazioni solo scrivendole o rappresentandole. Proprio questa urgenza di rappresentare caratterizza molto gli ambienti che ho appena descritto ed è molto legata anche alle organizzazioni di tipo gerarchico, dove queste figure accentratrici di informazioni usano di fatto solo un mezzo, quello della scrittura di specifiche, per poter comunicare con coloro che il prodotto lo realizzano. Poche persone che riportano informazioni insufficienti.

Alessia: Matteo, quindi se ho capito bene quello che mi stai dicendo, ci sono dei problemi che generano questo gap. In sintesi, quali sono i principali problemi? 

Matteo: Noi individuiamo il primo problema nell’assenza quasi totale di stakeholder management. Quando si va a progettare un nuovo prodotto, prima di tutto non viene fatta una selezione delle persone che potrebbero portare un valore con la loro conoscenza e ci si affida solamente a  “pochi esperti”. Questa assenza di stakeholder management condiziona il lavoro degli esperti, che si ritrovano a dover sostenere una moltitudine di compiti, compreso quello della redazione delle specifiche e dell’ideazione delle funzionalità del nuovo prodotto tecnologico.

Questo, a mio avviso, è un punto molto importante e, laddove si verifica questa lacuna, è compito dei progettisti intervenire agli albori del progetto: il progetto senza stakeholder management non può partire. 

Un altro punto è legato, specialmente nel mondo industriale, a considerare la progettazione e quindi il design un accessorio che può aiutare lo sviluppo del nuovo prodotto tecnologico, ma che di fatto è limitato.

In realtà il design, cioè il processo di progettazione, offre una serie di attività e di opportunità per poter risolvere il gap di cui stiamo parlando. È compito del fornitore riuscire a dimostrare che, con un determinato approccio, queste problematiche si possono abbattere o almeno limitare.

Alessia: Da quello che stai dicendo, il documento di specifiche rischia di portare in realtà più disagi che benefici effettivi. Ne hai viste tante di situazioni “documentocentriche”, chiamiamole così?

Matteo: Nel settore B2B in ambito industriale è prevalente la presenza del “libretto di istruzioni” per il prodotto tecnologico e quindi sì, devo dire che ne ho viste molte e posso imputare ad esso il gap che si genera fra le due parti del progetto. Il documento di specifiche, quando si presenta, porta con sé innumerevoli rischi che mettono in crisi le relazioni che ci sono fra coloro che sono coinvolti nel progetto.

Un documento tecnico va capito e capirlo porta via del tempo, va analizzato, e la ghigliottina finale arriva quando, associata al documento tecnico, si chiede anche una stima. È impossibile pensare che i tecnici, anche i più bravi del mondo che vorrebbero lavorare in modalità agile, possano fare una stima precisa, che porti valore al progetto in termini di sostenibilità, leggendo un documento tecnico. 

Negoziare alcune funzionalità, suggerire soluzioni tecnologiche o di usabilità diventa davvero difficile se c’è di mezzo un dettagliatissimo documento di specifiche. 

Inoltre, nel documento tecnico, a mio personalissimo avviso, c’è anche un problema di tipo etico.

Alessia: In che senso?

Matteo: Il problema di tipo etico si genera quando le persone che pianificano, che sanno cosa devono fare o quantomeno pensano di saperlo, non mettono in pratica delle procedure per rimanere aderenti a una serie di informazioni che alcuni stakeholder, che non vengono coinvolti inizialmente, avrebbero potuto portare.
Faccio un esempio: uno stakeholder che lavora in ambito sales o in customer service, può portare al progetto una serie di informazioni a tutela reale dell’utilizzatore finale. In una fase preliminare del progetto, il suo coinvolgimento è preziosissimo poiché nell’ambito B2B o B2B2C l’end user non è sempre immediatamente accessibile, anzi, ma il modus operandi descritto precedentemente tende a scartare la partecipazione dello stakeholder che lavora a stretto contatto con l’utente finale.

Le informazioni che si perdono proprio in questa primissima fase generano, secondo me, un problema etico che è verificabile quando il prodotto è finito, perché di fatto il prodotto non sarà in grado di soddisfare alcune peculiarità che invece sono fondamentali per l’end user che il prodotto lo dovrà utilizzare.

Alessia: Sempre parlando dei disagi più che dei benefici effettivi, facciamo un giochino: se il documento di specifiche fosse uno stakeholder, come sarebbe secondo te?

Matteo: Sicuramente, se fosse uno stakeholder, lo immagino un po’ come uno studente alla lavagna che ripete a pappagallo un argomento di cui ha letto il libro che gli è piaciuto di più tralasciando gli altri assegnati. Ciò limita lo sviluppo di concetti e la possibilità di formulare alternative che potrebbero magari essere vantaggiose al fine della progettazione.
Potrebbe essere anche uno studente che invece di preparare una ricerca in gruppo preferisce far tutto da sé…

Sarebbe una persona in grado di descrivere come si può realizzare qualcosa, ma avrebbe difficoltà a esporre i motivi per cui è necessario intraprendere una determinata strada. Secondo noi, la strada che porta alla realizzazione di una funzionalità o del prodotto per intero deve essere costruita in base alle relazioni fra fornitore e cliente.

Uno stakeholder che impersonifica un documento di specifiche, invece, avrebbe sempre la risposta pronta e potrebbe faticare nel lasciare la possibilità di essere aiutato a trovare delle strade alternative. Inoltre, e lo vediamo spesso quando sono necessarie delle nuove tecnologie, questo stakeholder potrebbe cadere in contraddizione perché dovrebbe costantemente rinegoziare le proprie convinzioni.

Faccio un altro esempio: nel documento di specifiche sono spesso menzionati dei linguaggi con cui il prodotto tecnologico deve essere sviluppato. Dopo un’analisi e una rapida discussione, spesso capita che si trovino delle alternative più convenienti: attenzione, non più convenienti in assoluto, ma più appropriate perché per quel tipo di progetto, per quel tipo di opportunità e per quel tipo di soluzione si può anche pensare una soluzione diversa. Questo tipo di valutazione, con un documento di specifiche sarebbe un po’ difficile da innescare.

Una cosa fondamentale, che rientra sempre nel gap fra chi pianifica e chi realizza, è legata poi al giusto match che ogni prodotto dovrebbe rispettare fra tre concetti fondamentali: desiderabilità del prodotto, sostenibilità economica e fattibilità tecnica.

Spesso però, nel documento di specifiche, si tende a favorire uno dei tre aspetti rispetto agli altri. Questo perché? Perché, tornando al punto iniziale, le persone che pianificano sono poche, sono dei decisori che basano le loro conoscenze sull’esperienza pregressa. Il documento di specifiche, invece di essere un modo per aprire una serie di opzioni, per come la vediamo noi è un punto di rottura.

Alessia: Allora io ho vagamente intuito che il documento di specifiche non ricade nelle tue simpatie. Ma sai cosa mi è sempre stato insegnato? Che se esiste un problema e non fornisci una soluzione, sei anche tu parte del problema. Quindi, secondo te, come si colma questo gap che potrebbe essere davvero distruttivo per le sorti di una buona idea?

Matteo: In realtà, nella progettazione di tipo collaborativo portare i problemi, portare evidenze e portarle in un determinato contesto può aiutare collettivamente a risolvere problemi che poi ricadono sul progetto per intero.

Alessia: In quale modo?

Matteo: Allora sicuramente, agli albori del progetto, ancora prima forse di firmare l’offerta commerciale, una attività di stakeholder management che definisce il team che seguirà la progettazione del nuovo prodotto tecnologico è essenziale, e questo già individua quali sono i ruoli che possono portare valore. 

Secondo noi, la chiave per abbattere l’eccessiva centralità del documento di specifiche – e garantire una qualità delle relazioni che portino a risultati migliori – è il workshop. Per workshop intendiamo una serie di riunioni strutturate che seguono un’agenda di attività, e queste attività sono volte a individuare opportunità, ideare delle soluzioni per poterle poi realizzare, validarle, stimarle e metterle in pratica. In questa frase che ho detto, se ci pensi bene, c’è un po’ tutto il processo.

Quindi, se in origine le opportunità erano quelle definite dal nostro decisore della grande organizzazione, con il workshop vengono portate ad un livello di discussione più orizzontale, in cui partecipano tutti gli stakeholder.

Ecco perché abbiamo fatto lo stakeholder management; stakeholder che possono discutere e negoziare, di quanto è portato dal nostro decisore e poi arrivare insieme a definire una soluzione che contempli i tre punti di cui parlavamo prima: desiderabilità del prodotto finito, sostenibilità di tipo economico e fattibilità di tipo tecnico. 

Questo in pratica. Perché l’obiezione potrebbe essere: “Beh, sì, tutto molto bello. Ma dopo il workshop qual è nella pratica il risultato omologo del documento di specifiche? Che anche se il documento di specifiche come concetto è sbagliato, però mi dice un po’ dove andare.”

Il risultato del workshop è la definizione, raccolta e redazione graduale di requisiti funzionali che viene affrontata in modo collettivo.

Ciò che consente poi, a chi sviluppa e realizza il prodotto, di leggere le istruzioni e mettere in moto la macchina di costruzione vera e propria del prodotto tecnologico finale. Questi sono alcuni aspetti. 

Con l’esperienza abbiamo però constatato che il workshop ha anche un importante impatto dal punto di vista economico.

Scrivere un documento di specifiche che magari ha vissuto tre, quattro, cinque versioni ed è fatto da 100, 200, 300 pagine, per quanto possa essere complesso e completo, porta via molto tempo. Abbiamo verificato che il workshop è una logica un pochino meno precisa e specifica, ma che in breve tempo risolve un numero di domande maggiore rispetto a quello che si utilizza per poter redigere il nostro documento di specifiche.

Anche organizzando più workshop, della durata di 2 o 3 ore, il beneficio ottenuto rimane significativo. Di solito cerco comunque di stimare il costo per la redazione di un eventuale documento di specifiche, e confronto questo costo con quello relativo a delle sessioni di workshop. In genere, anche se con i due metodi si arriva ad un diverso livello di dettaglio, i workshop collaborativi risultano vincenti per raggiungere gli obiettivi finali di prodotto in modo efficiente.

Alessia: Parliamo di intelligenza artificiale. Potrebbe l’intelligenza artificiale, in futuro, aiutarci in questi processi che sono alla fine abbastanza semplici da come li hai descritti, ma che comunque portano dei grandi rischi?

Matteo: Per quanto mi riguarda, la volontà di mettere in pratica processi come quello della progettazione collaborativa dipende dalle persone e non dipenderà mai dalle macchine. Quello che immagino possa servire in questo tipo di processi è avere un giudizio su quello che è l’attività di selezione e di raccolta dei requisiti, ed è una cosa che stiamo studiando.

Immaginiamo di poter dare a un’intelligenza artificiale un po’ di contesto sul progetto che stiamo avviando; immaginiamo che questo contesto possa essere condito anche di numeri perché, parliamoci chiaro, non stiamo realizzando opere d’arte astratta. Sappiamo perfettamente, se i nostri Tech Leader sono sufficientemente esperti, quanto può costare la realizzazione di una funzionalità core nel nuovo prodotto di tipo tecnologico.

Penso che usare l’intelligenza artificiale per aiutare questa valutazione, specialmente quando si vanno a fare delle stime che poi definiscono una roadmap di progetto, possa essere estremamente utile.

Questo può ridurre il gap fra la pianificazione e la realizzazione, fra questi due ambienti che sono apparentemente scollati? Beh, sicuramente no, perché si inserisce in una fase abbastanza finale del processo che abbiamo descritto.

Però potrebbe rivelare gli errori che questo scollamento genera. E rivelare questo tipo di errori a uno stato dell’arte in cui la macchina della costruzione effettiva non è ancora partita può dare numerosi vantaggi.

Alessia: Ma quindi, mi pare di capire che una sperimentazione comunque la collochiamo in una fase finale del processo. Ma se invece si facesse nella fase iniziale? Che ne pensi?

Matteo: In una fase iniziale, l’intelligenza artificiale potrebbe aiutare nello scovare informazioni e spunti che potrebbero essere di supporto a quegli accentratori nelle grandi organizzazioni di cui parlavamo all’inizio. Certo, dovrebbe essere “domata” da un processo, perché altrimenti avrebbe lo stesso scopo, la stessa finalità e anche gli stessi termini di usabilità di un motore di ricerca.

Su questo, per quanto riguarda appunto il coinvolgimento dell’intelligenza artificiale sia nella fase pre-ideativa sia nella fase di definizione di una roadmap, stiamo facendo delle sperimentazioni, cercando di capire come suggerire all’intelligenza artificiale informazioni confezionate in un determinato modo, per poi ottenere delle risposte che possono essere utili all’intero processo. Quindi, sia in fase iniziale sia nella fase finale. È però importante che ci sia un processo e il processo devono definirlo le persone. Questo è fondamentale.

Alessia: In Develer siamo parecchio interessati a questi argomenti e so che organizziamo anche dei corsi di progettazione collaborativa. Ci vuoi raccontare cosa sono?

Matteo: Diciamolo in modo simpatico: in Develer, la nostra battaglia al documento di specifiche è iniziata qualche anno fa e poi si è trasformata in un format più colloquiale. Organizziamo dei corsi per figure che operano nel settore B2B, in particolare quelle che detengono le conoscenze che servono per progettare nuovi prodotti tecnologici.

Questi corsi servono a sponsorizzare un approccio basato più sulle relazioni e che considera l’intero ecosistema di prodotto. Cerchiamo di spiegare con esempi pratici quanto possa essere rischioso iniziare a scrivere un documento di specifiche senza considerare tutte le peculiarità di cui abbiamo parlato oggi.

Alessia: So che abbiamo fatto già un corso a Firenze, un corso a Bologna e abbiamo in programma anche altre edizioni. Chi fosse interessato a partecipare, può iscriversi alla lista di attesa del corso e rimanere aggiornato sulle prossime date.

Matteo: Bene, io vi aspetto numerosi!