Forward-Deployed Software Engineer: il ponte tra strategia, software e operazioni

Molte aziende B2B hanno già individuato processi che potrebbero essere più veloci, accurati o semplici. Il problema è trasformare quell'intuizione in un prodotto software che le persone usino davvero. Tra la strategia espressa in una riunione direzionale e il lavoro quotidiano esistono sistemi legacy, eccezioni, dati incompleti, approvazioni, responsabilità e vincoli che una demo non mostra. È in questo spazio che si inserisce il Forward-Deployed Software Engineer, spesso abbreviato in FDSE.

Il termine inglese unisce due idee. Software engineer indica una persona capace di progettare e costruire sistemi. Forward-deployed significa schierato in avanti, quindi vicino al contesto operativo in cui il software deve produrre valore. Non è semplicemente uno sviluppatore assegnato a un cliente e non è un consulente che consegna raccomandazioni. È un profilo tecnico e di prodotto che osserva il lavoro, comprende il problema, costruisce una soluzione funzionante, la misura e la porta verso un uso affidabile.

Per un'azienda italiana che valuta software custom o AI agent, questo ruolo offre un modo concreto per ridurre la distanza tra idea e risultato. Un FDSE può capire perché gli ordini restano bloccati, quali informazioni mancano a un tecnico sul campo, come una richiesta entra nell'helpdesk e perché il CRM non rappresenta il processo reale. Poi può trasformare quella conoscenza in integrazioni, workflow, interfacce e automazioni con un perimetro chiaro. In questo articolo vediamo come funziona il ruolo, cosa aspettarsi e come decidere se assumerlo, esternalizzarlo o combinarlo con il team interno.

Da dove nasce il forward-deployed engineering

Il modello nasce dall'incontro tra engineering, professional services e product development. Nei software enterprise il valore non dipende solo dalle funzionalità disponibili, ma dalla capacità di adattarle a dati, processi e vincoli del cliente. Un team centrale può costruire una piattaforma eccellente e fallire l'adozione se non comprende come lavora l'azienda che la compra. Il modello forward-deployed porta una parte della capacità tecnica a contatto diretto con il cliente, senza confonderla con una personalizzazione senza limiti.

Il concetto si è affermato soprattutto in aziende che costruiscono prodotti complessi, infrastrutture dati, sistemi di sicurezza o applicazioni basate sull'intelligenza artificiale. Il team ha bisogno di imparare rapidamente il dominio del cliente e di restituire quel sapere al prodotto. In un contesto italiano, lo stesso approccio è utile in manifattura, logistica, servizi professionali, distribuzione, energia e software B2B, dove i processi dipendono spesso da ERP, fogli di calcolo, email, portali fornitori e conoscenza tacita.

Le origini spiegano anche una caratteristica importante: l'FDSE non è un ruolo definito da un singolo linguaggio o da una tecnologia. Il suo valore sta nella velocità con cui collega contesto e implementazione. Può scrivere un servizio, interrogare un database, configurare un connettore, analizzare un log, condurre un'intervista o preparare un business case. La profondità tecnica resta essenziale, ma viene applicata al problema che crea costo, rischio o ritardo.

Che cosa fa un FDSE, in parole semplici

Un Forward-Deployed Software Engineer prende un problema operativo e ne costruisce una soluzione software verificabile nel contesto in cui il problema si presenta. Il suo lavoro comincia spesso da una domanda vaga: possiamo automatizzare la gestione dei ticket? Possiamo dare ai commerciali informazioni migliori? Possiamo usare un agente per il back office? Prima di scegliere il modello o il framework, l'FDSE ricostruisce l'evento che genera il lavoro, le decisioni necessarie, i sistemi coinvolti e il risultato che definisce la chiusura.

Il ciclo completo può includere discovery, mappatura del processo, definizione dei requisiti, accesso ai dati, prototipazione, sviluppo, integrazione, test, adozione, monitoraggio e miglioramento. L'FDSE non opera da solo: collabora con operatori, manager, IT, sicurezza, data owner e product leader. Tuttavia, mantiene una responsabilità particolare sulla traduzione tra linguaggi diversi. Deve riuscire a dire al direttore operations che cosa è possibile, al developer come funzionano le eccezioni e all'utente perché il nuovo flusso gli permette di lavorare meglio.

• Capire il lavoro reale osservando persone, strumenti, decisioni ed eccezioni.
• Definire un risultato misurabile e un perimetro abbastanza piccolo da essere testato.
• Costruire software che usi dati e sistemi esistenti, invece di creare un'isola separata.
• Portare il prototipo in produzione con permessi, log, fallback, documentazione e owner.
• Raccogliere feedback e trasformarlo in prodotto, processo o requisito più preciso.

La differenza rispetto ai ruoli più vicini

Un sviluppatore tradizionale lavora principalmente su un prodotto, una piattaforma o un backlog tecnico. Può avere contatto con gli utenti, ma spesso opera attraverso requisiti già filtrati. L'FDSE è più vicino alla fonte del problema e affronta una maggiore ambiguità. Non significa che lo sviluppatore tradizionale sia distante dal business o che l'FDSE sia superiore. Sono posizioni diverse: il primo ottimizza profondità, qualità e coerenza di una base software; il secondo accelera l'apprendimento e l'applicazione in un ambiente specifico.

Un consulente analizza, raccomanda e spesso accompagna il cambiamento, ma non necessariamente costruisce e gestisce il sistema finale. Un FDSE deve lasciare un artefatto funzionante, integrato e verificabile. Se suggerisce di ridurre i passaggi di un processo, deve sapere quali API, tabelle, autorizzazioni e stati lo rendono possibile. La consulenza può essere parte del lavoro, ma non è il punto di arrivo.

Un solutions engineer di solito aiuta un potenziale cliente a capire come un prodotto risolve i suoi requisiti. Partecipa a discovery commerciale, demo, proof of concept e risposte tecniche. Un FDSE può usare competenze simili, ma lavora più a fondo sull'implementazione e sul risultato operativo, spesso dopo la vendita o all'interno del team che consegna il prodotto. Il solutions engineer dimostra adeguatezza; l'FDSE costruisce e rende sostenibile l'uso.

Un product manager definisce problemi prioritari, visione, utenti, trade-off e roadmap. L'FDSE contribuisce con evidenze dal campo e competenze tecniche, ma non sostituisce la responsabilità di portafoglio del product manager. Una software house, infine, consegna un progetto secondo uno scope, una relazione contrattuale e un piano di lavoro. Un FDSE può operare dentro una software house, ma il modello richiede una collaborazione più continua, più apprendimento sul campo e più responsabilità sul valore dopo il rilascio.

Una giornata tipo tra cliente e codice

La giornata non consiste nel programmare ininterrottamente. Al mattino l'FDSE può osservare il team customer service mentre gestisce una coda di richieste e annotare dove l'informazione si interrompe. In seguito può confrontare un ticket con il relativo contratto nel CRM, la disponibilità nell'ERP e una procedura nella knowledge base. Nel pomeriggio può costruire un piccolo endpoint, correggere un mapping, valutare un set di risposte o preparare una demo basata su dati realistici.

Una parte rilevante del lavoro è rendere esplicite le decisioni. Chi può modificare un ordine? Quando una richiesta è urgente? Quale fonte prevale se CRM ed ERP sono discordanti? Quale output può essere inviato automaticamente e quale richiede approvazione? Queste domande emergono osservando casi normali e casi anomali. L'FDSE le documenta in modo comprensibile e le usa per progettare regole, interfacce e test.

Il ritmo alterna esplorazione e consegna. Una settimana può terminare con un workflow manuale più chiaro e un piccolo prototipo; quella successiva con un'integrazione in staging e un campione valutato dagli utenti. Questo rende visibili i vincoli presto. Se l'API non consente una scrittura sicura, se i dati non hanno un identificativo comune o se la policy è ambigua, il problema emerge prima di investire in un progetto ampio.

La discovery nell'ambiente operativo del cliente

La discovery efficace non è un questionario di requisiti compilato in una sala riunioni. È l'osservazione del lavoro mentre accade. Occorre seguire un caso dall'evento iniziale alla chiusura: una email ricevuta, un ordine creato, un allarme generato, un ticket riaperto o un documento arrivato da un fornitore. Bisogna vedere quali sistemi vengono aperti, quali dati vengono copiati, chi viene chiamato, dove si attende e come viene registrata la decisione.

L'FDSE intervista almeno tre prospettive: chi svolge il lavoro, chi ne risponde e chi gestisce i sistemi. L'operatore conosce le scorciatoie e le eccezioni; il manager conosce SLA, costi e priorità; IT conosce integrazioni, sicurezza e vincoli di cambiamento. Le differenze tra le risposte sono dati utili, non un inconveniente da eliminare. Spesso mostrano che lo stesso processo ha definizioni diverse in reparti diversi.

Un buon output di discovery contiene una mappa del flusso, un glossario, gli attori, gli stati, le fonti, le decisioni, gli errori frequenti, le dipendenze e una baseline. Deve anche dichiarare ciò che non sappiamo. Frasi come «il sistema aggiorna il dato in tempo reale» vanno sostituite da una prova: quale evento, quale endpoint, quale ritardo osservato e quale comportamento in caso di errore. La precisione evita di costruire su supposizioni.

Dal problema operativo al software

La traduzione comincia dal risultato, non dalla funzionalità. «Vogliamo un agente che legge le email» è un mezzo. «Vogliamo classificare le richieste di ricambi, individuare i campi mancanti e creare una bozza di attività nel CRM entro cinque minuti» è un obiettivo più utile. Ha un evento, un output, un tempo, un sistema di destinazione e un possibile criterio di qualità.

Il passo successivo è separare fatti, regole e giudizi. Un fatto può essere estratto da un documento. Una regola può stabilire che un ordine sopra una soglia richieda approvazione. Un giudizio può richiedere esperienza commerciale e non dovrebbe essere nascosto dietro una percentuale di confidenza. Questa separazione aiuta a decidere che cosa automatizzare, che cosa assistere e che cosa lasciare a una persona.

Il software risultante può essere un'applicazione interna, un servizio in background, un'estensione del CRM, una coda di approvazione o un agente con strumenti limitati. L'FDSE sceglie la forma più semplice che chiuda il ciclo. Una dashboard che mostra eccezioni può creare più valore di un chatbot generico. Un job idempotente che aggiorna dati con approvazione può essere più utile di un agente autonomo che promette di fare tutto.

Integrare CRM, ERP, helpdesk e dati

Nelle aziende B2B il valore è quasi sempre distribuito tra più sistemi. Il CRM contiene account e opportunità, l'ERP ordini e disponibilità, l'helpdesk conversazioni e SLA, il sistema documentale contratti e procedure, mentre email e fogli spesso conservano il lavoro informale. Un agente che non attraversa questo confine produce una risposta interessante ma non completa. L'integrazione deve quindi essere parte della discovery, non una fase da aggiungere alla fine.

L'FDSE mappa identificativi, proprietà dei dati, frequenza di aggiornamento, permessi e qualità. Un cliente può avere nomi diversi nel CRM e nell'ERP; un ticket può riferirsi a un ordine con un codice scritto in modo non uniforme; un documento può essere accessibile solo a un gruppo. Il sistema deve mostrare la provenienza e non inventare un collegamento quando la corrispondenza è incerta.

Dal punto di vista tecnico servono autenticazione corretta, separazione degli ambienti, gestione dei segreti, timeout, retry, idempotenza, code e osservabilità. Bisogna sapere se una scrittura è stata completata, se è stata duplicata o se è rimasta a metà. Ogni chiamata importante dovrebbe avere un correlation ID. Quando un connettore fallisce, il caso deve diventare visibile a un owner, con una procedura manuale e una scadenza.

• CRM: arricchimento account, aggiornamento attività, sintesi opportunità e controllo dei dati mancanti.
• ERP: verifica di ordini, fatture, disponibilità, consegne e anomalie senza bypassare le approvazioni.
• Helpdesk: classificazione, ricerca della soluzione, suggerimento della risposta e routing delle eccezioni.
• Dati e documenti: estrazione, normalizzazione, deduplicazione e collegamento a fonti con permessi.

AI agent e automazione con un perimetro reale

Un AI agent non è solo una chat con un modello linguistico. È un sistema che interpreta un obiettivo, consulta fonti, decide quali strumenti usare e produce un risultato o un'azione. La sua affidabilità dipende dal contesto, dalle autorizzazioni e dai confini, non solo dalla qualità del modello. Un agente per il customer service può cercare in una knowledge base, verificare lo stato di una spedizione e preparare una risposta, ma non dovrebbe modificare un rimborso senza una regola e una conferma.

Gli esempi più adatti alla prima implementazione hanno volume, segnali disponibili e una verifica semplice. Un agente può preparare il riepilogo di una riunione e creare attività, confrontare un ordine con una conferma del fornitore, assegnare ticket in base a categorie definite, trovare documenti pertinenti o spiegare una variazione in un report. In tutti i casi il risultato deve essere verificabile e il fallimento deve lasciare una traccia.

L'autonomia va aumentata gradualmente. Prima l'agente osserva e suggerisce. Poi compila una bozza che una persona approva. Successivamente può eseguire azioni a basso rischio con controlli automatici. Solo per casi molto delimitati si può valutare un'esecuzione senza approvazione. Ogni passaggio richiede test su casi normali, incompleti, contraddittori e malevoli. Un agente fluido ma non controllabile non è pronto per le operations.

Dal prototipo alla produzione

Il prototipo serve a imparare, non a dimostrare che il progetto è già pronto. Deve usare un campione rappresentativo, magari anonimizzato, e rispondere a una domanda precisa. L'FDSE definisce esempi attesi, soglie, errori accettabili e criteri di stop. Se l'output è una classificazione, si misura la qualità per categoria. Se è un'estrazione, si controllano i campi e le eccezioni. Se è una risposta, si valutano correttezza, fonte, tono e utilità.

Il passaggio alla produzione aggiunge ciò che una demo tende a nascondere: identità, ruoli, logging, gestione dei dati personali, rate limit, monitoraggio, alert, costi, backup, supporto e rollback. Serve anche un owner che sappia cosa fare quando la fonte è obsoleta, il modello cambia comportamento o un sistema a valle non risponde. La produzione non è il momento in cui il progetto finisce; è l'inizio del ciclo di gestione.

Una release controllata può partire da un reparto, una tipologia di ticket o una percentuale di casi. Il team misura il risultato contro la baseline e raccoglie correzioni. Se il flusso migliora tempi ma aumenta errori, si corregge o si ferma. Se funziona, si estende con lo stesso metodo. La velocità è importante, ma la velocità di apprendimento e di correzione conta più della velocità di mettere online una demo.

Sicurezza, privacy, governance e ownership

Un sistema vicino alle operations vede dati commerciali, informazioni personali, contratti, prezzi, procedure e talvolta dati sensibili. La sicurezza deve quindi essere progettata insieme al flusso. Si applicano least privilege, segregazione dei ruoli, cifratura, gestione dei segreti, accessi temporanei, audit log e retention coerente. L'agente deve ricevere solo i dati necessari per quella richiesta e non usare un accesso tecnico più ampio di quello dell'utente.

La privacy richiede uno scopo chiaro, basi giuridiche appropriate, minimizzazione, conservazione definita e controllo dei fornitori. Occorre sapere dove vengono trattati i dati, se vengono usati per addestrare modelli, quali subfornitori sono coinvolti e come si gestiscono cancellazione e richieste degli interessati. Una policy generica sull'AI non sostituisce la valutazione specifica del caso d'uso e dei dati.

La governance assegna responsabilità. Il process owner risponde del risultato operativo, il data owner della fonte, il technical owner dell'affidabilità, il security owner dei controlli e il management delle decisioni di rischio e investimento. L'FDSE aiuta a rendere queste responsabilità concrete con un registro, una scheda del sistema, una suite di test, un piano di incident response e una procedura di cambiamento.

Ownership significa anche poter mantenere il software quando il progetto iniziale termina. Il cliente deve possedere o controllare codice, configurazioni, prompt, schemi, documentazione, dati di valutazione e accessi necessari. Il contratto deve chiarire supporto, livelli di servizio, portabilità, dipendenze e uscita. La soluzione più rapida oggi diventa un debito se nessuno sa modificarla domani.

Team e collaborazione

Un piccolo team efficace può includere un FDSE, un process owner, un referente IT o data engineer, un utente esperto e una persona responsabile del prodotto o del programma. Sicurezza, privacy e legale partecipano quando il rischio lo richiede. Non servono tutti a tempo pieno, ma devono essere disponibili nei punti decisionali. L'FDSE coordina il lavoro tecnico sul campo senza diventare l'unico proprietario del cambiamento.

La collaborazione funziona quando esistono rituali brevi e artefatti condivisi: mappa del processo, backlog delle ipotesi, registro decisioni, demo su dati realistici, report di valutazione e dashboard KPI. Ogni settimana il gruppo dovrebbe poter rispondere a tre domande: che cosa abbiamo imparato, che cosa è cambiato nel comportamento degli utenti e quale rischio dobbiamo affrontare prima del prossimo passo?

Il team interno non deve essere escluso dall'implementazione. Affiancare chi manterrà il sistema riduce dipendenza e migliora il design. Le sessioni di pairing, la documentazione eseguibile, i runbook e la revisione del codice trasferiscono conoscenza. Se il fornitore è l'unico a capire integrazioni e decisioni, l'azienda non ha realmente acquisito una capacità, anche se il progetto è stato consegnato.

KPI e ROI: misurare lavoro completato

Il ROI di un FDSE non è il numero di prompt, di demo o di integrazioni costruite. È il valore ottenuto nel processo. Una baseline può includere tempo di ciclo, backlog, ore manuali, errori, rilavorazioni, escalation, SLA, conversione, margine o costo per pratica. Il progetto definisce prima quali di questi indicatori può influenzare e in quale periodo.

Per un agente di supporto si possono misurare prima risposta, tempo medio di gestione, risoluzione al primo contatto, qualità valutata, riaperture e soddisfazione. Per l'automazione documentale sono utili accuratezza dei campi, percentuale senza intervento, tempo di ciclo, eccezioni e correzioni. Per vendite e account management contano preparazione, copertura delle attività, qualità dei dati, tasso di conversione e tempo liberato per conversazioni utili.

Il calcolo deve includere costi ricorrenti e una tantum: sviluppo, integrazioni, licenze, consumo del modello, sicurezza, valutazione, formazione, supporto e manutenzione. Il tempo risparmiato non è automaticamente un risparmio di cassa: può diventare capacità per gestire più clienti, ridurre ritardi o evitare nuove assunzioni. Dichiarare questa differenza rende il business case credibile e impedisce promesse irrealistiche.

Quando il modello funziona e quando no

Il forward-deployed engineering funziona quando il problema è importante ma non ancora completamente definito, il contesto del cliente è decisivo, esiste un owner operativo e gli utenti possono fornire feedback frequente. È particolarmente utile quando bisogna collegare sistemi diversi, apprendere eccezioni di dominio o testare rapidamente un'idea prima di trasformarla in una capability di prodotto.

Funziona meno quando il requisito è già stabile, standard e ben servito da un prodotto pronto. In quel caso una configurazione ordinaria può essere sufficiente. Non risolve nemmeno un processo senza sponsor, dati affidabili o disponibilità degli utenti. Se nessuno può decidere, verificare o adottare il risultato, un FDSE produrrà prototipi ma non cambiamento.

È inadatto anche quando l'azienda cerca una scorciatoia per evitare governance, procurement o manutenzione. La vicinanza al cliente accelera le decisioni, ma non elimina obblighi di sicurezza, privacy o conformità. Se il caso d'uso coinvolge decisioni ad alto impatto e non esiste modo di creare supervisione significativa, la risposta corretta può essere non automatizzare, almeno per ora.

Assumere, esternalizzare o scegliere un ibrido

Assumere un FDSE ha senso quando l'azienda ha un portafoglio continuo di problemi, accesso stabile a utenti e sistemi, capacità di gestione tecnica e volontà di sviluppare una competenza interna. Il vantaggio è la conoscenza cumulativa del dominio e una maggiore continuità. Il costo è trovare un profilo raro, dargli supporto e costruire attorno a lui pratiche di sicurezza, product management e engineering.

Esternalizzare è utile quando serve velocità, esperienza specifica o una capacità temporanea per validare un caso. Un partner può portare metodo, architettura e implementazione senza richiedere un'assunzione immediata. Il contratto deve però chiarire accessi, codice, documentazione, ownership, supporto e trasferimento. Un partner serio misura il risultato e prepara il team cliente a prendere il controllo.

Il modello ibrido combina un FDSE esterno con un process owner e un referente tecnico interni. Il partner accelera discovery e prima implementazione; il team aziendale mantiene decisioni, dati, approvazioni e operatività. È spesso il compromesso migliore per PMI e aziende in crescita. La condizione è nominare presto chi sarà responsabile dopo il progetto e coinvolgerlo nelle scelte fin dall'inizio.

Una roadmap concreta a 30, 60 e 90 giorni

Nei primi 30 giorni lo scopo è capire e scegliere. Si nomina uno sponsor, si individua un process owner, si osservano casi reali, si mappano CRM, ERP, helpdesk, documenti e accessi. Si misura la baseline e si selezionano uno o due problemi con valore, dati disponibili e rischio gestibile. Il risultato non è ancora un agente, ma una decisione motivata sul primo flusso e sui suoi criteri di successo.

Tra il giorno 31 e il giorno 60 si costruisce un prototipo delimitato. Si definiscono input, output, revisione umana, fonti autorizzate, campione, test, soglie e fallback. Il prototipo viene provato da utenti reali con dati rappresentativi. Si misurano qualità, tempo, costi, errori, utilità e sicurezza. A fine fase il gruppo decide se fermare, correggere o preparare un pilot controllato.

Tra il giorno 61 e il giorno 90 si prepara la produzione. Si collegano i sistemi con accessi minimi, si aggiungono log, monitoraggio, alert, gestione degli incidenti e documentazione. Il rollout parte da un perimetro ristretto. Il team confronta KPI con la baseline, raccoglie correzioni e decide l'estensione. Se il valore non emerge o il rischio supera la soglia, fermare il flusso è una decisione di qualità, non un fallimento.

Tre esempi concreti

Immaginiamo un distributore B2B che riceve richieste di disponibilità via email. Oggi un operatore legge il messaggio, cerca il cliente nel CRM, controlla disponibilità e tempi nell'ERP, poi prepara una risposta. Un primo agente può estrarre codice e quantità, proporre il collegamento al cliente, recuperare dati con accesso in sola lettura e generare una bozza con le fonti. La persona conferma i casi ambigui e l'azienda misura tempo di risposta, errori e richieste riaperte.

Pensiamo poi a un'azienda manifatturiera con ticket di manutenzione e manuali tecnici dispersi. L'FDSE osserva come i tecnici cercano una procedura, collega asset e storico interventi, classifica i guasti e costruisce un assistente che risponde citando documenti approvati. L'agente non ordina ricambi né modifica parametri macchina. Suggerisce la procedura, segnala quando la fonte manca e indirizza un esperto. Il successo è misurato con tempo di diagnosi, correttezza e sicurezza, non con il numero di risposte generate.

Infine, consideriamo una software company B2B che vuole ridurre il tempo di triage dei ticket. L'agente identifica prodotto, severità, cliente e possibile causa, cerca incidenti simili e prepara una scheda per supporto e engineering. La scrittura nel sistema resta soggetta a controlli e le richieste critiche seguono un percorso distinto. Nel tempo, i casi corretti dagli operatori diventano esempi di valutazione e aiutano il product manager a individuare difetti ricorrenti del prodotto.

Il punto non è aggiungere tecnologia

Un Forward-Deployed Software Engineer crea valore quando rende possibile un cambiamento che altrimenti resterebbe bloccato tra strategia e operatività. Porta il problema nel suo ambiente reale, costruisce una soluzione abbastanza concreta da essere testata e abbastanza disciplinata da essere mantenuta. Questo richiede codice, ma anche ascolto, misurazione, gestione del rischio e rispetto per chi userà il sistema ogni giorno.

Per i manager la domanda non è se il ruolo sia di moda. È se l'azienda abbia un problema operativo che richiede apprendimento sul campo, integrazione e consegna rapida. Se la risposta è sì, il modello può ridurre il tempo tra opportunità e prova del valore. Se la risposta è no, un prodotto standard o un miglioramento di processo può essere una scelta più semplice. La tecnologia giusta è quella che rende migliore il lavoro, non quella con l'etichetta più nuova.

Cosa possiamo fare per te?

Magna Products aiuta aziende B2B italiane a trasformare problemi operativi in software custom e AI agent utili, integrati e manutenibili. Possiamo affiancare il tuo team nella discovery, mappare CRM, ERP, helpdesk e dati, definire un caso d'uso, costruire un prototipo, misurare il ROI e accompagnare il percorso fino alla produzione con sicurezza, governance e ownership chiare. Parla con Magna Products per raccontarci il processo che vuoi migliorare e costruire insieme una roadmap concreta a 30, 60 e 90 giorni.