"Basta aggiungere un bottone." Cinque parole che per chi le pronuncia significano una piccola modifica, e per chi deve realizzarla significano giorni di lavoro. La comunicazione tra team tecnico e business è una delle sfide più sottovalutate nello sviluppo software.
Questa scena si ripete continuamente. Il business chiede qualcosa che sembra semplice. Il team tecnico sa che non lo è. Ma tra i due c’è un muro fatto di modelli mentali diversi, che nessuno ha davvero interesse a rendere visibile. E il costo di quel muro si misura in sprint buttati, rework e frustrazione da entrambe le parti.
Le incomprensioni tipiche
Ci sono frasi che generano sempre lo stesso cortocircuito.
“È una cosa semplice”
Per il business significa: il comportamento è chiaro. Per lo sviluppatore significa: non è chiaro cosa comporta a livello di sistema. Dietro a quel “bottone” ci sono validazioni, permessi, gestione errori, casi limite. Ma spiegare tutto questo richiede tempo, e spesso chi ascolta perde interesse.
“È urgente”
Quando tutto è urgente, le priorità perdono significato. Ogni urgenza sposta qualcos’altro, interrompe il lavoro in corso e genera context switch continui. Il risultato è che alla fine della giornata non si è concluso nulla, pur avendo lavorato tutto il giorno.
“Lo facciamo e poi miglioriamo”
Per il business è velocità. Per lo sviluppatore è l’inizio di un debito tecnico che probabilmente non verrà mai ripagato. Entrambi hanno una logica corretta, ma stanno parlando di due effetti diversi nel tempo.
“Quanto ci vuole?”
Il business vuole pianificare. Lo sviluppatore sa che ci sono troppe variabili sconosciute. Ma un numero viene comunque dato, diventa una promessa implicita, e quando non viene rispettato nasce sfiducia. È la dinamica tipica delle stime che non tornano.
Perché il gap esiste
Il gap nasce dai modelli mentali, più che dalle competenze.
Chi lavora sul business pensa in termini di risultati, tempi e valore economico. Il software è un mezzo.
Chi sviluppa pensa in termini di sistemi, complessità e manutenibilità. Il software è il centro del lavoro.
Entrambi gli approcci hanno senso. Senza un ponte tra loro, producono attrito costante.
In più, c’è un’asimmetria informativa:
- Il business non vede il costo tecnico delle decisioni.
- Il team tecnico non vede il valore economico delle richieste.
Le priorità diventano così un confronto tra percezioni, non una decisione informata.
Quanto costa davvero
Queste incomprensioni hanno effetti molto concreti.
Sprint sprecati. Feature sviluppate sulla base di requisiti fraintesi che poi vanno rifatte.
Scope creep silenzioso. Dettagli aggiunti a voce che non erano pianificati e che fanno slittare tutto.
Rework continuo. Il ciclo “fai, mostra, rifai” diventa la norma.
Frustrazione e turnover. Le persone migliori si stancano di lavorare in un contesto dove il lavoro viene spesso rifatto — e trovarle è già un problema.
Una parte significativa del tempo di sviluppo viene assorbita non dalla complessità tecnica, ma dalle incomprensioni.
Come costruire un linguaggio comune
Non servono grandi teorie. Servono pratiche semplici e ripetute.
Mostrare invece di descrivere
Un prototipo cliccabile chiarisce più di qualsiasi documento. Mostrare presto riduce drasticamente il rischio di fraintendimenti.
Coinvolgere uno sviluppatore nelle riunioni chiave
Quando il PM è l’unico ponte tra cliente e team tecnico, il messaggio si distorce. La presenza di uno sviluppatore senior nelle riunioni importanti evita settimane di lavoro sbagliato.
Definire un vocabolario condiviso
Termini come “deploy”, “staging”, “pronto”, “completo” devono avere un significato chiaro e condiviso. Molti malintesi nascono proprio da parole usate con significati diversi.
Rendere visibili i trade-off
A ogni richiesta, il team tecnico dovrebbe spiegare non solo il tempo stimato, ma anche le conseguenze: cosa viene spostato, che debito tecnico si crea, che rischi si introducono. Dare al business elementi per decidere in modo consapevole.
Il ruolo del product owner come traduttore
Un buon product owner capisce entrambi i mondi e traduce continuamente tra i due. È una delle figure con il maggiore impatto sulla qualità dei progetti.
Retrospettive orientate alle incomprensioni
Analizzare a fine sprint dove ci si è fraintesi, non solo cosa è andato storto tecnicamente. Spesso il problema sta in come ci si è parlati, prima ancora che nel codice.
È un problema di comunicazione
Molti problemi attribuiti alla complessità del software nascono in realtà da una comunicazione inefficace tra chi decide e chi realizza.
Il codice più costoso è quello che risolve il problema sbagliato perché nessuno si è fermato a verificare di aver capito davvero la domanda.
Simone Giusti
Consulente software strategico
