IT

Come spiegare le scelte tecniche a clienti non tecnici

Come spiegare le scelte tecniche ai clienti non tecnici: parla di risultati e compromessi, mostra invece di descrivere, proponi opzioni con i costi, niente codice.

Nicolas Ricardi6 min di lettura

In breve

  • Ai clienti non serve sapere come funziona. Serve sapere quanto costa, quanto tempo ci vuole, qual è il rischio e cosa cambia per loro.
  • Mostra l'effetto sullo schermo, come la pagina lenta o il checkout che non funziona, invece di descriverlo.
  • Un'analogia presa dal mondo del cliente aiuta; di' dove smette di funzionare.
  • Proponi due o tre opzioni con costo, tempi e rischio, e consigliane una.
  • Non mostrare mai codice che il cliente non ha chiesto, e mai credenziali.

Per spiegare le scelte tecniche ai clienti che non sono tecnici, parla di cosa cambia per loro, non di come funziona: quanto costa, quanto tempo ci vuole, cosa succede se non lo fai e cosa cambia per il loro team. Mostra il problema sullo schermo invece di descriverlo, proponi due o tre opzioni con i loro compromessi e consigliane una. Una breve registrazione dello schermo è un buon formato per farlo, perché il cliente vede con i suoi occhi la pagina lenta o il pulsante che non funziona.

Questa guida è pensata per sviluppatori freelance e team di agenzia che hanno bisogno di una decisione del cliente su qualcosa che il cliente non può valutare da solo.

Parla di risultati e compromessi

Al tuo cliente non interessano il framework, il database o il plugin. Gli interessano quattro cose:

  1. Il costo: quanto adesso, e quanto ogni mese dopo.
  2. I tempi: quanto ci vuole, e se il lancio si sposta.
  3. Il rischio: cosa succede se non lo facciamo.
  4. Il cambiamento: cosa cambia dopo per lui e per il suo team.

Traduci ogni punto tecnico in questi termini prima di spiegarlo:

Dal linguaggio da sviluppatore a quello del cliente
Cosa diresti a un collega Cosa deve sentirsi dire il cliente
“Il plugin delle prenotazioni non è più mantenuto.” “Il sistema di prenotazione non riceverà più aggiornamenti di sicurezza. Oggi funziona, ma ogni mese che resta lì il rischio aumenta.”
“Dovremmo aggiungere la cache.” “Le pagine si caricheranno più in fretta. Quando modifichi una pagina, la modifica potrebbe metterci qualche minuto a comparire.”
“Passiamo a un CMS headless.” “Più libertà nel design, ma due sistemi da mantenere invece di uno, e un costo mensile più alto.”
“C’è parecchio debito tecnico.” “Le scorciatoie prese in passato rendono ogni nuova funzione più lenta e più cara da sviluppare.”

Se una frase ha ancora bisogno di una parola tecnica per stare in piedi, spiega la parola una volta, di passaggio, e vai avanti.

Mostra, non descrivere

“La pagina è lenta da mobile” è un’opinione. Una registrazione della pagina che ci mette una vita a mostrare le foto dei prodotti in una finestra grande come un telefono è un fatto che il cliente può vedere. Il video è il modo più semplice per mostrare un problema tecnico a chi non è davanti al tuo schermo:

  • Il problema come lo vede il cliente finale: il pulsante del checkout che su Safari non fa niente, il modulo che perde quello che hai scritto.
  • Il prima e il dopo: la vecchia pagina e quella più veloce, affiancate.
  • La schermata che userà: il pannello di amministrazione dopo la modifica, così “un nuovo editor” smette di essere astratto.

Mentre parli, cerchia la parte che conta. Disegnare sullo schermo durante la registrazione funziona bene; leggi come disegnare sullo schermo mentre registri su Mac.

Usa le analogie con attenzione

Una buona analogia presa dal mondo del cliente fa scattare la comprensione. Alcune che di solito funzionano:

  • Manutenzione e aggiornamenti sono come il tagliando della macchina: se lo salti, la macchina va lo stesso, finché non si ferma.
  • Il debito tecnico è come la cucina di un ristorante che non viene pulita tra un servizio e l’altro: ogni servizio è più lento del precedente.
  • I backup sono come un’assicurazione, solo che conviene controllare che funzionino prima di averne bisogno.

Usane una per decisione, non una per frase. E di’ dove non regge: “a differenza di una macchina, una falla di sicurezza può essere sfruttata da qualcun altro prima che si noti qualcosa”. Un’analogia che nasconde un costo o un rischio è peggio di nessuna analogia.

Proponi opzioni con i loro costi

Quasi tutte le scelte tecniche hanno più di una risposta. Presentane due o tre, compreso il “non fare niente” quando è un’opzione reale, e mettile una accanto all’altra:

Esempio: tre opzioni per un plugin di prenotazione non più mantenuto
Opzione Tempi Costo continuativo Rischio
Lasciarlo com’è Nessuno ora Nessuno Cresce ogni mese senza aggiornamenti
Sostituirlo con un plugin mantenuto Circa due giorni Una licenza annuale Basso; le prenotazioni vengono trasferite
Sviluppare un modulo di prenotazione su misura Circa due settimane Il nostro tempo di manutenzione Basso, ma c’è più da seguire

Un esempio ipotetico: tempi e costi dipendono dal progetto.

Poi consigliane una e spiega perché, in una frase: “Noi lo sostituiremmo con il plugin mantenuto: due giorni di lavoro e il rischio sparisce.” I clienti decidono prima quando il ragionamento l’hai già fatto tu e a loro resta solo da dire sì. Per la parte economica, presentare un preventivo al cliente con un video segue lo stesso approccio.

Una struttura per la spiegazione

Che tu registri un video o scriva un’email, quest’ordine funziona:

  1. La decisione in una frase. “Dobbiamo decidere cosa fare con il sistema di prenotazione.”
  2. Perché adesso. Cosa succede se aspetti, nei suoi termini.
  3. Fallo vedere. Il problema sullo schermo, in trenta secondi o meno.
  4. Le opzioni, con tempi, costi e rischi.
  5. Il tuo consiglio e il motivo.
  6. La richiesta, con una data. “Mi fai sapere entro venerdì quale opzione preferisci?”

Scelta tecnica: un plugin non più mantenuto

Da sviluppatore freelance al cliente di una piccola attività · Circa 3 minuti

Ciao Giulia, mi serve una tua decisione sul sistema di prenotazione. Oggi non c’è niente di rotto, ma il plugin che lo fa funzionare non è più mantenuto, quindi non riceverà più aggiornamenti di sicurezza.

Questa è la pagina delle prenotazioni come la vedono i tuoi clienti. Le opzioni sono tre: lasciarlo così, che adesso non costa niente ma ogni mese diventa più rischioso; sostituirlo con un plugin mantenuto, circa due giorni di lavoro più una licenza annuale; oppure sviluppare un modulo nostro, circa due settimane. Io sceglierei la seconda: elimina il rischio e il tuo team non si accorgerà nemmeno del cambio. Mi fai sapere entro venerdì?

Mandalo con la richiesta anche per iscritto, così Giulia può rispondere dal telefono senza riguardare il video:

WhatsApp· a Giulia

Ciao Giulia, tre minuti sul sistema di prenotazione. Non c’è niente di rotto, ma il plugin non riceverà più aggiornamenti di sicurezza. Ti consiglio di sostituirlo (circa due giorni di lavoro). Mi fai sapere entro venerdì quale opzione preferisci?

Sistema di prenotazione: tre opzioniJustRec · 3:05

Cosa non mostrare

Una registrazione dello schermo per un cliente non è una code review. Lascia fuori:

  • Il codice. A meno che il cliente non l’abbia chiesto, il codice comunica solo “è complicato”.
  • Le credenziali. Password, chiavi API, file di ambiente, cronologia del terminale con dei token. Gli accessi mandali con un password manager, mai in un video.
  • Log con dati dei clienti. I log degli errori contengono spesso nomi, email e dettagli degli ordini.
  • Progetti di altri clienti. La barra laterale dell’editor e le schede del browser possono mostrarli.
  • Le chat interne sul cliente o sul problema.

Quando spiegarlo dal vivo

Alcune scelte tecniche sono troppo grandi per un video da solo: un rifacimento, un cambio di piattaforma, qualsiasi cosa che sposti molto il budget. Manda il video come materiale da guardare prima, poi decidete in una breve call. Spieghiamo dove passa il confine tra le due cose in quando non mandare un video a un cliente.

E tieni da parte le spiegazioni per dopo. A fine progetto, lo stesso approccio diventa una buona consegna: i video di consegna del sito mostrano al cliente come funzionano le cose senza una sola riga di codice. La guida completa ai video asincroni per comunicare con i clienti mette tutto insieme, e la nostra pagina per i freelance mostra come JustRec si adatta a chi lavora da solo.

Domande frequenti

Come si spiega una scelta tecnica a un cliente non tecnico?

Parti da cosa cambia per lui: costi, tempi, rischi e lavoro di tutti i giorni. Mostra il problema sullo schermo, proponi due o tre opzioni con i loro compromessi, consigliane una e chiedi una decisione con una data.

Devo mostrare il codice a un cliente?

Quasi mai. A un cliente non tecnico il codice dice che qualcosa è complicato, non perché è importante. Mostra invece la pagina, l'errore o la schermata di amministrazione che userà.

Le analogie sono una buona idea per spiegare argomenti tecnici?

Sì, una alla volta e prese dal mondo del cliente. Di' dove l'analogia smette di funzionare, così non nasconde un costo o un rischio.

E se il cliente chiede i dettagli tecnici?

Daglieli, in breve, dopo il risultato. Alcuni clienti hanno un tecnico dalla loro parte che li vorrà; proponi una breve nota scritta per quella persona.

Le scelte tecniche vanno spiegate in video o in riunione?

Per la maggior parte delle decisioni basta un breve video, perché il cliente può vedere il problema e riguardare le opzioni. Per le scelte grandi o costose, manda prima il video e decidete in call.

Scritto da

Nicolas Ricardi

Maker of JustRec, at Nube

Nicolas makes JustRec at Nube, a web studio in Italy. He built it for the videos Nube sends to its own clients: design reviews, handovers and quotes explained in a few minutes instead of a meeting.

www.wearenube.dev
Video per i clienti