Software rescue: quando conviene salvare un progetto fallito

Gli errori che bloccano un progetto software, uno per uno

“Abbiamo speso due anni e un budget enorme, e il software non funziona ancora. Adesso non sappiamo nemmeno se vale la pena continuare.”
Chi lavora con PMI sente questa frase spesso. Cambia qualche dettaglio, il settore, il fornitore, la cifra, ma la struttura è sempre la stessa: un progetto partito con aspettative alte, poi rallentato, poi bloccato, poi abbandonato. E adesso qualcuno deve decidere se salvarlo o buttarlo.
Il software rescue, cioè il recupero di un progetto software fallito o fermo, è un’attività che richiede metodo. Non è una questione di ottimismo o di testardaggine: ci sono casi in cui recuperare conviene, e casi in cui ogni euro speso in rescue è uno spreco. Quello che segue è una lista degli errori più comuni che portano un progetto al blocco, con tre informazioni per ognuno: come si manifesta, quanto pesa, e come si evita o si risolve.

Nessuno ha mai letto il codice prima di firmare il contratto

Come si manifesta. Il progetto va avanti per mesi, poi arriva il momento di aggiungere una funzione nuova o correggere un bug strutturale. A quel punto il fornitore dice che “ci vuole più tempo del previsto” perché “il codice precedente era scritto male”. Se c’è stato un cambio di fornitore nel mezzo, la situazione peggiora: il nuovo team scopre che il vecchio aveva costruito su fondamenta che non reggono.
Quanto costa. Il costo diretto è il tempo perso a riscrivere pezzi di codice che sembravano completati. Il costo indiretto è il ritardo sull’operatività, che in certi casi blocca processi aziendali reali per settimane.
Come si evita. Prima di firmare qualsiasi contratto di continuazione o di rescue, serve un audit tecnico indipendente. Non un’ora di call con il nuovo fornitore: una lettura vera del codice, con un report scritto che dica cosa c’è, cosa manca, e cosa va rifatto. Chi ti dà un preventivo senza aver letto il codice sta lavorando alla cieca. Per capire cosa aspettarti da questo processo, il pezzo su come evitare gli errori quando si commissiona un software custom a un’agenzia copre bene i segnali da cercare già in fase di selezione.

I requisiti erano vaghi, e nessuno se n’è accorto

Come si manifesta. Il progetto parte con un documento di requisiti scritto in fretta, pieno di “da definire” e “come concordato verbalmente”. Ogni sprint porta nuove interpretazioni. Il fornitore implementa una cosa, il cliente si aspettava un’altra. A un certo punto le modifiche accumulano talmente tanto debito tecnico che il progetto si inceppa.
Quanto costa. Ogni ciclo di correzione su un requisito mal definito può costare il doppio rispetto a implementarlo correttamente la prima volta. Nei progetti più complessi, questo effetto si moltiplica.
Come si evita. I requisiti vanno scritti in modo che chi li legge possa costruire un test di accettazione. Se non riesci a rispondere alla domanda “come faccio a sapere che questa funzione è fatta?”, il requisito non è pronto. In fase di rescue, questo significa ricostruire i requisiti a ritroso dal codice esistente, il che è lento ma necessario prima di toccare qualsiasi cosa.

Il fornitore è sparito, e con lui le credenziali

Come si manifesta. L’agenzia chiude, il freelance smette di rispondere, il referente tecnico cambia lavoro. Il software è in produzione, ma nessuno in azienda ha accesso al server, al repository, al pannello di hosting. Ogni modifica richiede di chiamare qualcuno che forse risponde.
Questo errore è più comune di quanto si pensi, e ha conseguenze operative immediate. Se il server va giù nel momento sbagliato, l’azienda è ferma senza poter fare nulla.
Quanto costa. Dipende da quanto il software è critico per l’operatività. Nei casi peggiori, blocca vendite, logistica o comunicazione con i clienti per giorni. Il costo del recupero delle credenziali e della migrazione su ambienti controllati può richiedere settimane di lavoro tecnico.
Come si evita. Ogni progetto software aziendale dovrebbe avere, dall’inizio, un documento di “accesso e continuità” che l’azienda cliente tiene aggiornato e possiede. Repository, credenziali server, domini, certificati SSL, accessi al database: tutto deve essere sotto il controllo dell’azienda, non del fornitore. Se non è così, il problema non è il fornitore sparito, è l’architettura contrattuale che lo permetteva. Il pezzo su come costruire un’exit strategy software per la tua PMI entra nel dettaglio di come strutturare questa protezione.

Il debito tecnico è stato ignorato finché non ha bloccato tutto

Come si manifesta. Il progetto funziona, ma ogni nuova funzione richiede sempre più tempo. I bug si moltiplicano. Aggiungere un campo a un form rompe qualcosa di non correlato. Il team tecnico parla di “codice legacy” anche su un progetto di due anni. A un certo punto il fornitore dice che “bisogna riscrivere tutto”.
Quanto costa. Il debito tecnico accumulato senza controllo porta quasi sempre a uno di due esiti: una riscrittura parziale costosa, o l’abbandono del progetto. Entrambi significano sprecare parte del lavoro già fatto.
Come si evita. Il debito tecnico non si elimina, si gestisce. Ogni progetto accumula scorciatoie, e alcune sono accettabili se pianificate. Il problema è quando non vengono tracciate e nessuno sa dove sono. In fase di rescue, il primo passo è mappare il debito esistente prima di decidere se recuperare o riscrivere. Il pezzo sul refactoring del software legacy aziendale descrive i criteri per fare questa scelta senza affidarsi all’istinto.

Nessuno ha testato niente, o quasi

Come si manifesta. Il software viene rilasciato in produzione con test manuali fatti in fretta. I bug emergono dagli utenti reali. Ogni correzione introduce nuovi problemi. Il ciclo di fix diventa la routine, e il progetto perde credibilità interna.
Questo errore è particolarmente insidioso perché non si vede subito. Un progetto senza test funziona per mesi, poi crolla quando la complessità supera una soglia.
Quanto costa. Un bug trovato in produzione costa mediamente molto di più dello stesso bug trovato durante lo sviluppo. La ragione è semplice: in produzione ha già causato danni, richiede comunicazione verso gli utenti, e spesso va corretto in emergenza con meno attenzione.
Come si evita. In fase di rescue, prima di aggiungere qualsiasi funzione, serve costruire una rete di test sul codice esistente. Non necessariamente copertura totale, ma almeno i flussi critici. Chi ti propone di “continuare lo sviluppo” senza passare prima per una fase di test sta accettando di lavorare su sabbie mobili.
Se stai gestendo questo problema senza un team QA interno, le strategie di testing per PMI senza QA dedicato offrono un punto di partenza pratico.

Se ti riconosci in uno o più di questi errori e stai valutando se ha senso recuperare il progetto, raccontaci la situazione: un’analisi tecnica iniziale aiuta a capire cosa c’è da fare prima di prendere qualsiasi decisione.

Quando il rescue non conviene: la risposta scomoda

Questa è la parte che pochi dicono chiaramente: a volte il software rescue è uno spreco.
Se il codice non ha test, la struttura non è documentata, il fornitore originale è irraggiungibile, la logica di business è nella testa di chi non lavora più lì, e il progetto copre meno del 40% dei requisiti originali, recuperarlo costa più che ricominciare con un approccio strutturato. Dirlo non è pessimismo, è onestà verso il budget.
Il segnale più affidabile che il rescue conviene è questo: un tecnico esterno riesce a leggere il codice, capire cosa fa, e spiegarlo senza assistenza. Se invece ogni risposta è “dipende da come lo aveva pensato il vecchio fornitore”, il progetto è già in territorio pericoloso.
Un’altra condizione necessaria è che il dominio applicativo sia ben definito. Il software rescue funziona quando sai cosa vuoi costruire e il problema è che qualcuno non l’ha costruito bene. Se i requisiti sono ancora nebulosi, il rescue diventa un modo per rimandare una conversazione che andava fatta all’inizio.

Ripartire: cosa fare nei primi giorni

Quando si decide di procedere con un rescue, i primi giorni contano più di tutto il resto. L’ordine delle operazioni è questo:

1. Recuperare tutti gli accessi (repository, server, database, domini) e metterli sotto controllo dell’azienda.
2. Fare un audit tecnico scritto, non verbale, con un team indipendente.
3. Congelare lo sviluppo finché l’audit non è completato.
4. Decidere, sulla base dell’audit, se recuperare il codice esistente o riscrivere le parti critiche.
5. Definire i requisiti mancanti prima di scrivere una riga di codice nuova.

Saltare uno di questi passi per risparmiare tempo è l’errore più comune nella fase di rescue. E di solito si paga caro.

Se stai valutando se recuperare un progetto software fermo o abbandonato, in Press Start possiamo fare un audit tecnico iniziale e darti una risposta chiara su cosa c’è da fare. Scrivici e raccontaci il tuo caso.

Q: Cos’è il software rescue per una PMI?
A: È il processo di analisi e recupero di un progetto software bloccato o abbandonato. Può includere audit del codice, cambio di fornitore, riscrittura parziale o completa. Conviene quando il codice di base è recuperabile e il dominio applicativo è già ben definito.
Q: Come capire se un progetto software fallito vale la pena di essere salvato?
A: Tre segnali positivi: la logica di business è già implementata almeno in parte, la documentazione esiste anche se incompleta, il team attuale può leggere il codice senza assistenza del vecchio fornitore. Se tutti e tre mancano, spesso ripartire da zero costa meno.
Q: Quanto tempo richiede un audit di software rescue?
A: Un audit tecnico iniziale richiede tipicamente tra una e tre settimane, a seconda della dimensione del progetto. Chi ti dà un preventivo senza aver letto il codice sta sparando numeri.
Q: Quando è meglio abbandonare il progetto e ripartire da zero?
A: Quando il codice non ha test, la struttura non è documentata, il fornitore è sparito con le credenziali e la logica di business è tutta nella testa di chi non lavora più lì. In quel caso il rescue costa più di un nuovo MVP.
Q: Chi deve fare l’audit tecnico in un software rescue?
A: Un team esterno e indipendente, non il fornitore che ha sviluppato il progetto originale. Chi ha creato il problema non può essere l’unico a valutarne la gravità.