Come spiego Laravel a mia nonna (e ai miei clienti)

L'altro giorno un cliente mi ha chiesto: "Ma questo Laravel... è come WordPress?". E io, invece di partire con la solita supercazzola tecnica su framework MVC e dependency injection, mi sono fermato un attimo. Perché il punto vero è un altro: se non riesco a spiegare quello che faccio a chi non è del mestiere, sono io che ho un problema, non loro.

Nella mia esperienza qui a Trento, ho capito che la tecnologia la conosco. Ma il linguaggio giusto per raccontarla? Quello l'ho imparato sbattendo la testa contro il muro per anni. E credetemi, all'inizio facevo pena.

Il mio primo disastro comunicativo

Era il 2003, stavo presentando un progetto a un artigiano di Civezzano. Gli dovevo spiegare come avrei fatto il suo gestionale e io, fresco di entusiasmo e ancora convinto che usare paroloni mi facesse sembrare più professionale, gli ho sparato: "Implementeremo un'architettura three-tier con layer di persistenza separato e un'API RESTful per l'interfacciamento".

Lui mi ha guardato per tre secondi buoni. Poi ha detto: "Guarda Alex, io voglio solo sapere se domani mattina posso vedere quanti pezzi ho in magazzino senza dover chiamare mia moglie che sta in ufficio". Fine. Lezione imparata a suon di silenzio imbarazzato.

Da quel giorno ho iniziato a tradurre. Non semplificare troppo, perché i clienti non sono scemi. Tradurre. C'è una bella differenza.

Le metafore che uso (e funzionano)

Quando devo spiegare Laravel, parto sempre da quello che serve al cliente, mai dalla tecnologia in sé. Per esempio, se sto parlando di un software gestionale su misura, la conversazione va più o meno così:

"Laravel è come avere una cassetta degli attrezzi già pronta. Invece di costruirmi ogni volta martello, cacciavite e trapano da zero, ho già tutto lì. Così mi concentro su quello che serve a te: il tuo magazzino, i tuoi preventivi, il tuo modo di lavorare. Non devo reinventare la ruota ogni volta, e questo si traduce in tempi più rapidi e costi più bassi per te".

Funziona perché collego subito la tecnologia a un beneficio concreto. Non gli sto parlando di framework PHP, gli sto dicendo che risparmia soldi e tempo. Che è quello che gli interessa davvero.

Un altro esempio: una volta dovevo spiegare la differenza tra un sito statico e una web app dinamica a una ristorante di Rovereto. Le ho detto: "Il sito vetrina è come il menu che hai fuori dal locale. La gente lo guarda, si fa un'idea, magari entra. Una web app su misura invece è come se i tuoi clienti potessero prenotare il tavolo, scegliere i piatti in anticipo, vedere gli allergeni, e tu ricevere tutto già organizzato in cucina. Stessa base, utilizzo completamente diverso".

Ha capito subito. E ha capito anche quanto le sarebbe costata una cosa rispetto all'altra, senza che io dovessi tirare in ballo database relazionali o sessioni utente.

Evito il gergo (o lo spiego subito)

Diciamocelo: noi sviluppatori parliamo una lingua nostra. API, backend, frontend, deployment, staging... per noi è normalissimo. Per chi non è del mestiere è arabo. E io ci sono cascato talmente tante volte che ora ho una regola ferrea: ogni termine tecnico che uso, lo spiego immediatamente dopo. O meglio ancora, uso una parola normale al suo posto.

Esempi dal mio vocabolario tradotto:

• Backend → "la parte che gira sul server, quella che gestisce i dati e la logica" → ancora meglio: "il motore che fa funzionare tutto dietro le quinte"
• API → "il modo in cui due programmi parlano tra loro" → o semplicemente: "il canale di comunicazione tra il tuo gestionale e il sito"
• Deploy → "mettere online" → basta
• Database → "l'archivio dove teniamo tutti i dati" → se serve, "come un magazzino digitale organizzato"

Non è questione di trattare male il cliente. È questione di non mettergli ostacoli inutili tra lui e la comprensione di quello che gli stai proponendo.

Mostro, non racconto (quando posso)

Ho imparato che un prototipo veloce vale più di mille parole. Se devo spiegare come funzionerà la realizzazione di un sito web con una certa funzionalità, invece di descriverla a parole preparo una demo cliccabile.

Per esempio, tempo fa dovevo spiegare a uno studio professionale come avrei fatto il loro sistema di gestione appuntamenti. Invece di raccontargli il flusso utente, gli ho preparato in mezza giornata un prototipo funzionante (brutto graficamente, ma funzionante). Gli ho detto: "Ecco, guarda. Tu clicchi qui, scegli il giorno, selezioni il tipo di consulenza, inserisci i dati. Ricevi una mail di conferma, e tu vedi tutto nel pannello admin". Ha capito in trenta secondi.

Certo, non sempre è fattibile. Ma quando posso, mostro invece di spiegare. E poi spiego quello che hanno appena visto, che è molto più facile.

Ascolto più di quanto parlo

Questa è forse la cosa più importante che ho imparato in oltre vent'anni. Se parto in quarta a spiegare la mia visione tecnica senza aver prima capito cosa gli passa per la testa al cliente, ho già perso.

Faccio domande. Tante. "Cosa ti aspetti che faccia?", "Come lo useresti nella tua giornata tipo?", "Cosa ti fa imbestialire del sistema che hai adesso?". E poi ascolto. Davvero. Prendo appunti, anche.

Perché spesso, mentre mi raccontano il loro problema, loro stessi trovano il modo giusto per esprimerlo. E quello diventa il mio vocabolario per quel progetto. Se un parrucchiere mi dice "vorrei vedere a colpo d'occhio chi viene domani senza dover aprire l'agenda", io uso esattamente quelle parole quando gli rispiego la soluzione. Non "dashboard con overview degli appuntamenti in real-time". Ma "così vedi a colpo d'occhio chi viene domani".

La tecnica del "e quindi?"

Quando mi accorgo che sto per partire in tecnicismi, mi fermo e mi chiedo: "E quindi? Che beneficio concreto porta questa roba?". Se non trovo una risposta chiara in termini di tempo risparmiato, soldi guadagnati, rotture di scatole evitate, allora probabilmente non serve dirlo.

Per esempio, potrei dire: "Utilizzerò Laravel perché ha un ORM molto potente chiamato Eloquent che mi permette di fare query complesse in modo elegante".

Oppure posso dire: "Userò Laravel perché mi permette di gestire i dati in modo sicuro e veloce, e questo significa che il tuo gestionale sarà più affidabile e meno soggetto a errori".

La seconda versione dice la stessa cosa, ma in un linguaggio che parla al cliente. Non sto nascondendo niente, sto solo traducendo in benefici tangibili.

Quando invece alzo il livello tecnico

Ci sono casi in cui invece vado nel dettaglio tecnico. Quando? Quando il cliente me lo chiede esplicitamente, o quando parliamo con il loro reparto IT (se ce l'hanno), o quando so che la persona davanti a me ha un background tecnico anche se non fa il mio lavoro.

Un commercialista mi ha chiesto l'altro giorno: "Ma come gestisci la sicurezza dei dati sensibili?". Lì sì, ho tirato fuori crittografia, HTTPS, certificati SSL, GDPR, backup incrementali. Perché era una domanda tecnica che meritava una risposta tecnica. Ma sempre spiegando il "perché" dietro ogni scelta.

Il punto è questo: adatto il linguaggio a chi ho davanti. Non uso lo stesso tono con un ristoratore e con il CTO di un'azienda tech. E va bene così.

Gli errori che continuo a vedere

Vedo ancora troppi colleghi che parlano come se fossero a un convegno per sviluppatori quando invece sono davanti a un piccolo imprenditore che vuole solo capire se gli conviene investire in un gestionale o continuare con Excel.

Gli errori classici:

• Usare acronimi senza spiegarli (CMS, CRM, ERP... io ormai li spiego sempre)
• Partire dalla soluzione tecnica invece che dal problema del cliente
• Dare per scontato che "ovviamente" certe cose si sappiano
• Non fare esempi concreti, rimanere sul vago e sul teorico
• Non controllare se dall'altra parte hanno capito (io chiedo sempre: "Ti è chiaro o ti spiego meglio questa parte?")

E poi c'è il contrario: quelli che trattano i clienti come se fossero tonti. Anche quello non va bene. I miei clienti magari non sanno cosa sia un framework PHP, ma sanno benissimo gestire un'azienda, cosa che io non saprei fare. Meritano rispetto e chiarezza, non condiscendenza.

Il test della nonna (funziona davvero)

Ogni tanto mi chiedo: "Se dovessi spiegare questo progetto a mia nonna, come lo direi?". E vi assicuro che è un esercizio illuminante. Se non riesco a trovare parole semplici per spiegare una soluzione tecnica complessa, probabilmente neanche io l'ho capita fino in fondo.

Non sto dicendo di banalizzare tutto. Sto dicendo di trovare l'essenza della cosa. Perché se so spiegare un concetto difficile con parole semplici, allora vuol dire che lo padroneggio davvero.

Poi certo, con mia nonna vera non parlo di Laravel. Le dico che "faccio i siti internet e i programmi per le aziende". E lei è contentissima così.

Se anche tu hai bisogno di qualcuno che ti spieghi la tecnologia in italiano prima di costruirti qualcosa, scrivimi pure. Parliamo della tua situazione senza paroloni inutili, ti dico cosa si può fare e quanto viene a costare. Senza fregature e soprattutto senza farmi bello con termini incomprensibili.