Cambiare il partner che sviluppa un software è una situazione molto più frequente di quanto si possa immaginare. Può accadere perché il rapporto con il fornitore si è deteriorato, perché i tempi di evoluzione non sono più compatibili con le esigenze dell’azienda, perché il team originario non esiste più o, semplicemente, perché il progetto è cresciuto fino a richiedere competenze diverse da quelle disponibili in passato. In tutti questi casi emerge inevitabilmente una domanda: ha senso proseguire il lavoro esistente oppure è più conveniente sviluppare una nuova applicazione?
La risposta, però, non può essere ricercata nell’età del software, nel linguaggio con cui è stato sviluppato o nella notorietà delle tecnologie utilizzate. Sono aspetti importanti, ma raramente rappresentano il vero elemento discriminante. Ciò che determina la possibilità di subentrare con successo è, piuttosto, la qualità del patrimonio tecnico che quel progetto ha costruito negli anni e, soprattutto, la sua capacità di essere compreso e preso in carico da un nuovo team senza dover ricostruire da zero tutto il percorso che lo ha generato.
È un concetto che spesso sorprende chi non vive quotidianamente il mondo dello sviluppo software, perché si tende a pensare che un passaggio di consegne consista semplicemente nel consegnare il codice sorgente, le credenziali degli ambienti e qualche documento tecnico. In realtà il codice rappresenta soltanto una parte del patrimonio di un’applicazione. Tutto il resto è costituito dalla conoscenza accumulata nel tempo: le motivazioni che hanno portato a determinate scelte progettuali, le logiche di business implementate, le integrazioni con altri sistemi aziendali, le eccezioni introdotte per gestire casi particolari, le modalità di rilascio, le configurazioni degli ambienti e, più in generale, tutto ciò che permette di capire non solo come il software funziona, ma anche perché è stato costruito in quel modo.
Quando questa conoscenza è stata documentata e organizzata, il subentro di un nuovo fornitore diventa un’attività certamente complessa, ma perfettamente affrontabile. Un team con esperienza può analizzare l’architettura, comprendere rapidamente il funzionamento dell’applicazione, validare le scelte esistenti e iniziare ad evolvere il prodotto senza dover ripercorrere anni di decisioni prese da altri. In queste situazioni il valore costruito nel tempo viene preservato e l’investimento già sostenuto dall’azienda continua a produrre benefici.
Purtroppo non sempre accade questo: esistono progetti nei quali il patrimonio di conoscenza non è mai stato realmente trasferito dal team che lo ha sviluppato al software stesso. La documentazione è assente o obsoleta, le logiche applicative sono distribuite in modo incoerente, le convenzioni cambiano da un modulo all’altro e molte decisioni progettuali risultano comprensibili soltanto a chi le ha prese. In questi casi il nuovo fornitore non eredita un progetto: eredita un problema da ricostruire.
È importante sottolineare che questo scenario non dipende necessariamente dalla qualità delle persone che hanno lavorato al software. Molti progetti nascono in contesti nei quali le priorità operative prevalgono sistematicamente sulla documentazione, sulla pulizia del codice e sulla progettazione architetturale. Le richieste del business si susseguono rapidamente, le scadenze diventano sempre più stringenti e ogni nuova funzionalità viene sviluppata con l’obiettivo di rispondere a un’esigenza immediata. Nel breve periodo tutto sembra funzionare, ma nel corso degli anni il sistema accumula una quantità di complessità che rende ogni intervento successivo sempre più difficile.
Per questo motivo un software perfettamente funzionante non è necessariamente un software sul quale convenga investire. Può sembrare una contraddizione, ma non lo è. Il fatto che un’applicazione continui a svolgere correttamente il proprio compito non dice nulla sulla sua manutenibilità. Un codice disordinato, fortemente accoppiato, privo di test automatici e costruito senza una chiara architettura può continuare a funzionare per anni, pur richiedendo uno sforzo enorme per ogni modifica evolutiva. In queste situazioni il costo principale non è rappresentato dallo sviluppo della nuova funzionalità, bensì dal tempo necessario per comprendere quali conseguenze quella modifica potrà avere sul resto del sistema.
È proprio qui che si trova uno degli errori più frequenti nelle decisioni aziendali. Si tende infatti a confrontare il costo di una riscrittura con il costo dello sviluppo di una singola evoluzione, mentre il vero confronto dovrebbe essere molto diverso: da una parte il costo necessario per comprendere, mettere in sicurezza e mantenere un’applicazione esistente; dall’altra quello richiesto per progettare un nuovo sistema costruito su basi solide e realmente sostenibili nel lungo periodo.
Esistono quindi situazioni nelle quali la scelta economicamente più razionale è quella di ripartire da zero. Non perché le tecnologie siano obsolete o perché il software sia troppo vecchio, ma perché il patrimonio tecnico disponibile non consente un passaggio di consegne efficace. Se ogni modifica richiede settimane di analisi, se nessuno è in grado di spiegare il funzionamento di componenti fondamentali, se la documentazione è inesistente e il codice non offre alcuna garanzia di qualità, continuare a investire sull’applicazione esistente rischia di diventare più costoso che realizzarne una nuova.
Naturalmente vale anche il ragionamento opposto. Abbiamo visto applicazioni sviluppate molti anni fa che, grazie a un’architettura coerente, a una buona qualità del codice e a una documentazione mantenuta nel tempo, hanno consentito un subentro piuttosto rapido, permettendo di preservare completamente gli investimenti già effettuati dal cliente. Allo stesso modo, ci siamo imbattuti in software realizzati con framework modernissimi che, nonostante la giovane età, risultavano talmente complessi e privi di struttura da rendere irrealistico qualunque tentativo di evoluzione. È la dimostrazione che la tecnologia, da sola, non rappresenta un indicatore affidabile della qualità di un progetto.
Per questo motivo la decisione di subentrare o riscrivere non dovrebbe mai essere guidata da percezioni, convinzioni personali o pregiudizi nei confronti delle tecnologie utilizzate. Richiede invece un’analisi tecnica approfondita, capace di valutare lo stato reale dell’applicazione, la qualità dell’architettura, il livello di documentazione disponibile, la manutenibilità del codice, il grado di dipendenza dalle persone che lo hanno sviluppato e i rischi connessi a ciascuna delle possibili strategie. Solo partendo da queste informazioni è possibile stimare con ragionevole accuratezza tempi, costi e benefici delle diverse alternative.
In lab51 affrontiamo frequentemente situazioni di questo tipo. Prima di proporre un piano evolutivo o una completa riscrittura, riteniamo fondamentale comprendere quale sia il reale stato di salute del software e verificare se esistano le condizioni per un subentro efficace. In molti casi il patrimonio tecnologico costruito negli anni può essere valorizzato e fatto evolvere; in altri, invece, un’analisi oggettiva dimostra che ripartire da basi nuove rappresenta la scelta più sostenibile sia dal punto di vista tecnico sia da quello economico.
Se la tua azienda sta valutando un cambio di fornitore, deve decidere come evolvere un’applicazione esistente o desidera semplicemente capire quale sia la strategia più conveniente, lab51 può affiancarti con un assessment tecnico indipendente e con la progettazione del percorso più adatto a garantire continuità, qualità e valore nel tempo.
