Il prodotto esistente è il punto di partenza
Chi prende la guida di una software house, per successione, acquisizione o nuovo incarico, spesso trova due realtà nello stesso momento. Da una parte ci sono clienti che usano il prodotto, funzioni indispensabili e un patrimonio di conoscenza del settore. Dall'altra ci sono dipendenze poco chiare, personalizzazioni accumulate e un'interfaccia che può sembrare distante dalle aspettative attuali. Ridurre tutto alla data della tecnologia nasconde sia il valore sia il rischio.
Un inventario iniziale deve distinguere ciò che i clienti comprano davvero da ciò che il team mantiene per abitudine. Quali flussi generano lavoro quotidiano? Quali dati non si possono perdere? Quali integrazioni e stampe sono necessarie? Chi sa spiegare le eccezioni? È utile ascoltare sviluppo, assistenza e clienti: ognuno vede una parte diversa del prodotto.
Controlla anche gli elementi che permettono di intervenire: repository, istruzioni di build, ambienti, componenti di terze parti, procedure di rilascio, accessi e disponibilità dei fornitori. I diritti sul codice e i contratti richiedono una verifica appropriata con i professionisti competenti. Sul piano tecnico, senza sapere come si distribuisce e si ripristina il programma, promettere una nuova versione web sarebbe prematuro.
Tre modi di entrare nel web senza azzerare il prodotto
«Portarlo online» può indicare risultati diversi. La prima strada è pubblicare l'applicazione esistente: continua a girare in un ambiente controllato, mentre l'utente la usa da un browser tramite una sessione remota. La documentazione di Apache Guacamole mostra come un gateway HTML5 possa rendere accessibile un desktop nel browser; Microsoft documenta la pubblicazione remota di applicazioni installate. Sono possibilità tecniche da valutare, non garanzie di compatibilità per ogni gestionale.
La seconda strada è aggiungere una nuova interfaccia o alcuni servizi web che usano le funzioni del programma attuale. Può servire, per esempio, un portale dove il cliente consulta una pratica mentre gli operatori continuano a lavorare nel gestionale desktop. Qui occorre trovare un confine affidabile per identità, autorizzazioni e dati. Collegare un'interfaccia nuova direttamente alle tabelle senza conoscere le regole applicative può introdurre errori difficili da vedere.
La terza strada arriva quando una parte del prodotto limita davvero la crescita: sostituire progressivamente quel modulo, lasciando in funzione il resto. È un passo successivo, che può convivere con le prime due strade. Martin Fowler descrive la modernizzazione graduale come un percorso che parte dai risultati desiderati e individua pezzi gestibili, invece di imporre un unico passaggio a tutto il sistema.
- Applicazione esistente nel browser: cambia soprattutto la distribuzione; l'interfaccia e molte regole restano quelle note. Da provare: sessioni, periferiche, licenze e qualità della connessione.
- Nuova esperienza web sul core: cambia il percorso di alcuni utenti; il motore può restare. Da provare: integrazione, identità, permessi e coerenza dei dati.
- Sostituzione di un modulo: cambia una parte del core alla volta. Da provare: confini funzionali, dati condivisi, test e possibilità di tornare indietro.
Fonti: Apache Guacamole — documentazione ufficiale · Microsoft Learn — pubblicare applicazioni con RemoteApp · Martin Fowler — Strangler Fig
Le verifiche che rendono credibile una scelta
Prima di decidere tempi, preventivo o piattaforma, occorre osservare il prodotto in esercizio. Un gestionale installato presso ogni cliente ha vincoli diversi da uno che gira già su un server centrale. Una funzione usata da tre persone in ufficio non ha gli stessi requisiti di un portale aperto a tutti i clienti. La fattibilità di ciascuna strada dipende dai dettagli, non dall'etichetta «legacy».
- Esecuzione: sistemi operativi supportati, componenti esterni, processi schedulati e dipendenze hardware.
- Dati: posizione degli archivi, separazione tra clienti, procedure di backup e modalità di recupero dopo un errore.
- Uso quotidiano: utenti simultanei, postazioni, stampe, scanner, file locali, dispositivi mobili e qualità delle connessioni.
- Accesso: identità, autorizzazioni, registrazione delle operazioni e requisiti di sicurezza applicabili.
- Continuità: flussi che non possono fermarsi, capacità di ripetere una build, installare un aggiornamento e ripristinare la versione precedente.
- Economia: costi ricorrenti dell'infrastruttura, licenze, supporto e impatto sulle modalità commerciali del prodotto.
Scenario illustrativo: clienti attivi, due richieste diverse
Questo è un esempio inventato, non un progetto di MadeInCode. Una software house ha un gestionale desktop per laboratori e riceve due richieste. Gli operatori vogliono usarlo da sedi diverse; i clienti finali vogliono soltanto vedere lo stato dei lavori dal telefono. Trattare entrambe le richieste come «rifare il gestionale sul web» confonderebbe i risultati.
Una prova sul prodotto reale potrebbe valutare la pubblicazione remota dell'applicazione per gli operatori. In parallelo, il team potrebbe progettare una pagina web che espone solo lo stato dei lavori ai clienti autorizzati. Le regole del gestionale resterebbero nel core finché sono affidabili. Se in seguito il modulo di gestione lavori diventasse il limite principale, si valuterebbe una migrazione di quel solo modulo, con test e piano di ritorno.
La sequenza cambia se una periferica, la modalità di licenza o la separazione dei dati rendono impraticabile la pubblicazione remota. L'esempio serve a mostrare il metodo: scegliere le strade dopo aver verificato il prodotto e distinto i bisogni degli utenti.
Un percorso che produce decisioni, non solo documenti
Un Legacy Assessment ricostruisce architettura, vincoli e uso reale del prodotto. Una prova di fattibilità verifica la strada più promettente su un ambiente controllato e con un flusso rappresentativo. Il QA Assessment ricostruisce i comportamenti attuali, distingue quelli da preservare da quelli da chiarire o correggere e introduce verifiche sui flussi essenziali. Su questa base si definisce il primo Web Bridge da proporre ai clienti.
La consegna utile per chi guida l'azienda è una scelta spiegabile: quale risultato arriva al cliente, che cosa resta uguale, quali costi continuativi compaiono, quali rischi sono stati provati e che cosa accade se il primo rilascio non funziona come previsto. Questa base permette anche di discutere con il team commerciale senza trasformare un'ipotesi tecnica in una promessa assoluta.
Prima di commissionare il progetto, chiedi: chi userà il browser e per fare cosa? Quali parti del programma possiamo mantenere? Come proveremo periferiche, permessi e prestazioni? Quali comportamenti proteggiamo con test? Chi gestirà esercizio e supporto dopo il rilascio? Se queste risposte mancano, il prossimo investimento è una verifica, non una riscrittura. MadeInCode può lavorare anche in white-label accanto al tuo team, mentre la tua software house mantiene il rapporto con i propri clienti.