Quando il cliente mi chiede: ma cos'è Laravel?

L'altro giorno ero da un cliente, proprietario di una ferramenta storica qui a Trento. Dovevamo parlare del suo nuovo gestionale per il magazzino. A un certo punto mi fa: «Alex, ma tu lo fai con questo... come si chiama... Laraver?». Laravel, gli ho corretto sorridendo. E poi ha aggiunto: «Ma cos'è esattamente? È tipo WordPress?».

Ecco, questa domanda me la fanno almeno una volta a settimana. E ogni volta devo fare una scelta: posso tirar fuori termini come framework, MVC, architettura software. Oppure posso spiegare davvero cosa sto facendo, in un modo che abbia senso per chi mi sta davanti.

Il problema non è la tecnologia, è il linguaggio

Quando ho iniziato, nel 2000, pensavo che essere bravo significasse conoscere tutti i termini tecnici. Mi piaceva usare parole complicate, mi facevano sentire professionale. Poi ho capito una cosa fondamentale: il mio lavoro non è impressionare il cliente con quello che so. Il mio lavoro è fargli capire cosa sto costruendo per lui e perché dovrebbe importargliene.

Un parrucchiere che viene da me non deve sapere cos'è un database relazionale. Deve capire che il suo sistema di prenotazioni sarà più veloce, più affidabile, e che non perderà più appuntamenti perché qualcuno ha dimenticato di segnare il foglietto.

La svolta è stata quando ho smesso di tradurre e ho iniziato a raccontare. Perché spiegare la tecnologia non è questione di trovare parole più semplici. È questione di cambiare completamente prospettiva.

Come spiego Laravel senza nominare il codice

Torniamo al ferramenta. Gli ho detto: «Guarda, pensa al tuo magazzino. Hai scaffali, etichette, un sistema per sapere dove sta ogni cosa. Laravel è come avere un magazziniere perfetto che sa esattamente dove mettere e dove trovare tutto, che controlla sempre che i conti tornino, e che ti avvisa se qualcosa non va. WordPress invece è come avere una vetrina già montata: va bene se devi solo mostrare i prodotti, ma se vuoi fare cose più complesse ti serve qualcosa costruito su misura».

Mi ha guardato, ha annuito, e mi ha detto: «Ah ok, quindi è più robusto». Esatto. Non gli serviva sapere che Laravel è un framework PHP con dependency injection e service container. Gli serviva capire che stavo costruendo qualcosa di solido per le sue esigenze specifiche.

Con un ristoratore uso un'altra metafora. Gli dico che WordPress è come comprare un piatto già pronto: veloce, funziona, ma è uguale per tutti. Laravel è come avere uno chef che ti prepara il piatto esattamente come lo vuoi tu, con gli ingredienti che ti piacciono. Costa di più in tempo e denaro, ma è fatto per te.

La regola del "e quindi?"

Ogni volta che mi viene voglia di usare un termine tecnico, mi fermo e mi chiedo: e quindi? Al cliente cosa cambia? Se non riesco a rispondere a questa domanda in modo concreto, allora quel termine non serve.

Esempio pratico. Un cliente mi chiede perché uso Git per il suo progetto. Potrei spiegargli cos'è un sistema di versionamento distribuito. Oppure posso dirgli: «È come avere una macchina del tempo per il tuo software. Se domani sbaglio qualcosa, posso tornare indietro a ieri in dieci secondi. E se lavoriamo in due, possiamo vedere chi ha fatto cosa e quando». Capisce subito il valore.

Gli errori che facevo (e che vedo fare)

All'inizio cercavo di spiegare tutto. Pensavo che più informazioni davo, più il cliente si sarebbe sentito sicuro. Sbagliato. Il cliente non vuole un corso di programmazione, vuole la sicurezza che tu sappia quello che stai facendo e che il risultato funzionerà.

Un altro errore classico: usare analogie sbagliate. Ho visto colleghi paragonare un database a un foglio Excel. Il problema è che poi il cliente si aspetta davvero di vedere qualcosa tipo Excel, e quando gli mostri un'interfaccia diversa si confonde. Le metafore devono essere evocative, non letterali.

E poi c'è l'errore più grande: presumere che il cliente non capisca. Ho clienti che gestiscono aziende da vent'anni, che prendono decisioni complesse ogni giorno. Non sono stupidi, semplicemente parlano un'altra lingua. Se io vado dal mio meccanico e lui mi parla di fasatura e distribuzione, non capisco niente. Ma se mi dice che quella parte serve a far girare il motore senza problemi e che se si rompe mi costa un sacco di soldi, ho capito tutto quello che mi serve.

Il test della nonna

Ho sviluppato un sistema personale che chiamo "test della nonna". Prima di mandare una mail o fare una presentazione a un cliente, mi chiedo: se dovessi spiegare questa cosa a mia nonna, come lo farei? Mia nonna è una persona intelligente, ma non ha mai usato un computer in vita sua.

Se riesco a spiegarglielo in modo che capisca l'essenza, allora sono sulla strada giusta. Non i dettagli tecnici, l'essenza. Cosa fa quel software, perché è utile, cosa risolve.

L'anno scorso ho lavorato su un sistema di AI per categorizzare automaticamente le foto di un e-commerce a Trento. Avrei potuto parlare di intelligenza artificiale per aziende, neural networks, training sets. Invece ho detto al cliente: «È come assumere una persona che guarda le tue foto tutto il giorno e le mette negli scaffali giusti, solo che è velocissima e non si stanca mai». Ha capito subito il valore e ha approvato il preventivo.

Quando invece serve entrare nel tecnico

Attenzione però: c'è una differenza tra semplificare e nascondere. Se un cliente mi chiede perché il suo progetto costa più di quello del concorrente, devo essere onesto e specifico. Gli dico che sto usando tecnologie più moderne, che il codice sarà più manutenibile, che avrà meno problemi nel tempo. E se mi chiede cosa significa "manutenibile", glielo spiego.

La trasparenza è fondamentale. Non si tratta di tenere il cliente all'oscuro, ma di dargli le informazioni nel modo giusto e al momento giusto.

Quello che ho imparato in tutti questi anni è che comunicare bene la tecnologia non è un optional, è parte del lavoro. Un progetto può essere tecnicamente perfetto, ma se il cliente non capisce cosa hai fatto e perché, non sarà mai davvero soddisfatto. E alla fine, spiegare bene è anche un modo per costringerti a capire davvero quello che stai facendo. Perché se non riesci a spiegarlo con parole semplici, forse non l'hai capito nemmeno tu.