Il punto di partenza
Sul mio CV, la riga «sviluppatore full-stack Symfony/React» attira naturalmente l'occhio. Ma accanto ce n'è un'altra, altrettanto reale: oltre 3 anni di esperienza nell'assistenza tecnica multilingue, oggi come Operatore Service Desk presso Horsa Digital Retail. Un'esperienza che non metto abbastanza in evidenza, anche se ha plasmato profondamente il mio modo di lavorare.
Il quotidiano: diagnosticare prima di risolvere

Il supporto tecnico non significa rispondere al telefono aspettando che passi. Significa applicare, sotto pressione e in tempo reale, un metodo molto vicino a quello del debugging: ascoltare un sintomo vago descritto da un utente non tecnico, porre le domande giuste per isolare la causa reale, verificare un'ipotesi, proporre una soluzione e poi confermare che regga. L'unica differenza con il codice è che il «bug » a volte è umano oltre che tecnico.

Un vincolo in più: il multilinguismo
Questa diagnosi la conduco in italiano, in francese e in inglese tecnico, a seconda dell'utente che ho davanti. Questo impone una chiarezza raddoppiata: niente gergo superfluo, spiegazioni che devono essere comprese al primo colpo e una riformulazione costante per assicurarsi che il messaggio sia passato. È una ginnastica che ha migliorato direttamente il mio modo di documentare, di redigere un ticket o di spiegare una scelta tecnica a un cliente non sviluppatore.
Cosa mi ha realmente insegnato questo ruolo:

  • Isolare un problema a partire da un segnale incompleto, ancora prima di toccare il codice.
  • Comunicare un argomento tecnico in modo semplice, in tre lingue, senza perdere in precisione.
  • Gestire la pressione e le priorità: ticket, SLA, escalation, senza perdere la calma né il rigore.
  • Mantenere una traccia utile: un buon ticket di supporto si legge come una buona issue GitHub.
  • Mettersi nei panni dell'utente finale — un riflesso che si riversa direttamente nel modo in cui progetto un'interfaccia o un messaggio di errore in fase di sviluppo.

Il legame con lo sviluppo
Non vedo queste due esperienze come parallele, ma come complementari. Il supporto tecnico mi ha dato una comprensione concreta della frustrazione di un utente bloccato da un bug — la stessa frustrazione che cerco di evitare quando scrivo un'applicazione. E il rigore della diagnosi, ripetuto centinaia di volte su casi reali, si applica quasi tale e quale all'analisi di uno stack trace o di un comportamento inatteso in produzione.
Sempre orientato allo sviluppo

La programmazione resta la mia passione e il mio obiettivo principale. Ma considero questi oltre 3 anni di service desk multilingue un vero punto di forza nel mio profilo, in particolare per posizioni che richiedono di dialogare con gli utenti, di comprendere un'esigenza di business o di gestire un supporto di livello 2/3 parallelamente allo sviluppo. Un percorso atipico, ancora una volta — ma che costruisce un modo più completo di affrontare i problemi.
Da questa esigenza è nata un'applicazione
È proprio per rendere più affidabile questo lavoro quotidiano che ho finito per uscire dalla logica del "foglio Excel condiviso" che di solito serve a tenere traccia dei ticket, delle note di procedura e dei template di risposta nel supporto. Come sviluppatore, non potevo accontentarmi di un file che diventa illeggibile man mano che i casi si accumulano: ho quindi ideato e sviluppato una mia applicazione di gestione del service desk, con template di ticket organizzati per cliente, note di procedura centralizzate e consultabili in pochi secondi, e un monitoraggio strutturato molto più efficace di un foglio di calcolo. Questo progetto, nato da un'esigenza molto concreta sul campo, è diventato uno strumento che uso quotidianamente — e ne racconto la genesi in un articolo dedicato.