Salvataggio di un progetto software: come salvare un progetto software in difficoltà

Il salvataggio di un progetto software è il processo con cui si prende in carico un progetto software in difficoltà, fuori budget, in ritardo rispetto alla tabella di marcia o semplicemente non funzionante, e lo si riporta sulla giusta traiettoria senza buttare via tutto ciò che è stato realizzato. Un incarico di salvataggio inizia con una valutazione tecnica schietta, stabilizza ciò che esiste e ricostruisce quindi lo slancio della delivery attorno a un piano realistico.

Questa guida spiega come capire se il progetto ha bisogno di essere salvato, come decidere tra un salvataggio e una ricostruzione completa, come si svolge un processo professionale di salvataggio e come scegliere il partner giusto per il lavoro.

Che cos’è il salvataggio di un progetto software?

Il salvataggio di un progetto software è un incarico specializzato in cui un team di ingegneria esperto prende in carico un progetto in difficoltà, diagnostica cosa è andato storto e lo porta a uno stato funzionante. A differenza di un incarico di sviluppo standard, che parte dai requisiti, un salvataggio parte dalla realtà: codice esistente, un team esistente (o la sua assenza), scadenze già fissate e frustrazione già presente.

Un salvataggio non è manutenzione e non è una riscrittura per impostazione predefinita. L’obiettivo è preservare l’investimento già effettuato e trasformarlo in software funzionante nel minor tempo possibile, in modo responsabile. Di solito questo richiede una combinazione di triage, refactoring mirato, correzione dei processi e ridefinizione onesta dell’ambito.

Il recupero di un progetto software è la stessa disciplina con un nome più rassicurante. I fornitori usano i termini in modo intercambiabile: “salvataggio” sottolinea l’urgenza, mentre “recupero” sottolinea il risultato.

7 segnali che indicano che il progetto software è in difficoltà

I progetti raramente falliscono da un giorno all’altro. Falliscono al rallentatore e i segnali d’allarme sono ricorrenti:

• Le milestone slittano ripetutamente senza un piano di recupero credibile. Un ritardo spiegato una volta è normale; la terza revisione della tabella di marcia senza alcun cambiamento nell’approccio è un modello ricorrente.
• Il budget cresce mentre i progressi visibili si fermano. Ogni mese si paga di più, ma le demo sembrano uguali a quelle di tre mesi fa.
• Il fornitore si mette sulla difensiva o smette di farsi sentire. Gli aggiornamenti sullo stato diventano vaghi, le domande ricevono risposte lentamente e le cattive notizie arrivano tardi.
• Le persone chiave continuano ad andarsene. Il turnover nel team del fornitore o il disimpegno dei propri stakeholder sono indicatori anticipatori.
• Il team e gli stakeholder continuano a cambiare. Il turnover frequente nel team del fornitore o tra i propri stakeholder, oppure il disimpegno delle persone chiave, compromette la continuità, la titolarità e il processo decisionale.
• Nulla è dimostrabilmente funzionante. Non esiste un ambiente di staging che si possa esplorare facendo clic, oppure la demo funziona solo su un laptop.
• I requisiti cambiano continuamente senza decisioni. A ogni riunione si riaprono questioni già risolte e il backlog cresce più velocemente di quanto si riduca.
• I problemi tecnici si accumulano. Ogni correzione ne rompe altre due, si teme di effettuare i deployment e nessuno vuole mettere mano a determinate parti della codebase.

La presenza congiunta di due o tre di questi segnali di solito significa che il progetto ha bisogno di un intervento esterno, non di un’altra riunione sullo stato di avanzamento.

Perché i progetti software falliscono

Qui l’onestà è importante, perché le stesse cause si ripetono in tutti i settori:

• Requisiti poco chiari o instabili. Il progetto è iniziato senza un accordo su che cosa significhi “completato”.
• Nessuna leadership aziendale o tecnica senior realmente responsabile. Le decisioni non ricevono una guida tecnica qualificata né il contributo di responsabili aziendali con un interesse chiaro per il risultato, quindi il progetto perde l’allineamento con la roadmap aziendale.
• Un’architettura scelta per la velocità, non per il problema da risolvere. Scorciatoie iniziali che hanno reso possibile la demo, ma non hanno gettato basi stabili e scalabili e ora rendono costosa ogni modifica.
• Stime basate sulla speranza. Tempistiche promesse per aggiudicarsi il contratto invece che per riflettere il lavoro da svolgere.
• Disallineamento del fornitore. Un’agenzia che dà priorità alle ore fatturabili invece che ai risultati del progetto, oppure un team senza il livello di seniority adeguato alla complessità.
• Nessun processo di qualità. Nessun test automatizzato, nessuna revisione del codice, nessuna disciplina nell’ambiente di staging: così i difetti si accumulano silenziosamente.
• Perdita di allineamento con gli stakeholder. Le persone che hanno bisogno del software non sono più coinvolte, le priorità concorrenti distolgono la loro attenzione oppure non dedicano tempo al progetto, lasciando il team a sviluppare sulla base di supposizioni.

Salvare o ricostruire: come decidere

È la prima domanda a cui risponde una valutazione di recupero, e la risposta onesta a volte è: ricostruire. La decisione dipende da alcuni fattori:

• Quanto del codice esistente funziona davvero ed è coperto dai test.
• Se l’architettura è in grado di supportare i requisiti reali o se li ostacola.
• Quanta conoscenza del dominio è racchiusa nelle menti dell’attuale team.
• Pressione sulle tempistiche: il recupero è solitamente più rapido per arrivare alla prima versione funzionante; la ricostruzione è più ordinata nel lungo periodo.
• Costi sommersi rispetto ai costi residui: confrontate il costo della correzione con quello della ricostruzione, non con quanto è già stato speso.

Recupero o ricostruzione a colpo d’occhio:

Fattore	Il recupero è indicato quando	La ricostruzione è indicata quando
Condizioni della codebase	Le funzionalità principali funzionano; i problemi sono circoscritti	Difetti diffusi; nessun test; ogni modifica rompe qualcosa
Architettura	Il design supporta i requisiti con correzioni mirate	Il design contrasta i requisiti a livello fondamentale
Conoscenza del team	Competenze del dominio che vale la pena preservare	La conoscenza è già andata perduta o non è mai esistita
Tempistiche	Vi serve rapidamente una versione funzionante	Le vostre tempistiche consentono una partenza pulita
Logica del budget	La correzione costa chiaramente meno della ricostruzione	Il costo del recupero si avvicina a quello della ricostruzione

Un buon partner per il recupero vi dirà quando ricostruire è la scelta migliore, anche se per lui significa meno lavoro di recupero. È un modo per valutarlo.

Come funziona il recupero di un progetto software

La maggior parte dei recuperi professionali segue le stesse quattro fasi, compresse o estese per adattarsi alla situazione:

• Fase 1: triage e valutazione (1–2 settimane). Un ingegnere senior legge il codice, esamina l’architettura, intervista il team e confronta i requisiti con ciò che esiste realmente. Il risultato è una valutazione scritta del recupero: cosa è guasto, cosa è recuperabile e un piano realistico con milestone ridefinite. È anche il momento in cui si decide, sulla base di evidenze anziché opinioni, se recuperare o ricostruire.
• Fase 2: stabilizzazione (2–4 settimane). Fermare l’emorragia: congelare i cambiamenti caotici all’ambito, correggere la pipeline di distribuzione, ripristinare un ambiente di staging funzionante e risolvere i difetti critici che impediscono qualsiasi demo. L’obiettivo è un progetto che possa essere mostrato e valutato, non un progetto finito.
• Fase 3: esecuzione del recupero. Il lavoro riprende sulla base del piano ridefinito, in iterazioni brevi con demo visibili. Il debito tecnico viene ridotto nelle aree che bloccano i progressi, non ovunque contemporaneamente. È qui che si ricostruisce la fiducia: consegne prevedibili, aggiornamenti onesti e software funzionante a ogni milestone.
• Fase 4: passaggio di consegne e prevenzione. Documentazione, trasferimento delle conoscenze al vostro team e correzioni dei processi che impediscono il ripetersi del problema: disciplina CI/CD, standard di revisione del codice, stime realistiche e una definizione di completamento sottoscritta da entrambe le parti.

Cosa comprende una valutazione per il recupero

Una valutazione per il recupero è un incarico di due diligence tecnica, con durata definita, sul vostro progetto. In genere comprende:

• Revisione del codebase: qualità, struttura, copertura dei test, stato di salute delle dipendenze.
• Revisione dell’architettura: se il design è adatto ai requisiti e alla scala prevista.
• Baseline di sicurezza: vulnerabilità note, controlli degli accessi, gestione dei dati.
• Processo di delivery: come viene pianificato, revisionato, testato e distribuito il lavoro.
• Valutazione del team e del fornitore: capacità, seniority e possibilità che l’assetto attuale consenta di consegnare il progetto.
• Analisi delle lacune nei requisiti: ciò che è stato promesso rispetto a ciò che esiste.

Il risultato è un report scritto con evidenze, rischi e un piano di recupero su cui potete agire, indipendentemente dal fatto che affidiate o meno al valutatore il recupero vero e proprio.

Quanto costa il recupero di un progetto software?

I prezzi del recupero variano troppo per consentire un listino universale: dipendono dalle dimensioni del codebase, dallo stack tecnologico, da quanto è recuperabile e dalla rapidità con cui ne avete bisogno. Ciò che è costante sul mercato è quanto segue:

• La valutazione è solitamente un incarico a tariffa fissa e con durata definita, così conoscete il costo della diagnosi prima di impegnarvi nel trattamento.
• Il recupero costa in genere una frazione del budget originale di sviluppo, perché state correggendo e completando il progetto invece di costruirlo da zero.
• L’opzione più costosa è solitamente non fare nulla per altri sei mesi mentre il consumo di risorse continua.

Chiedete innanzitutto a qualsiasi partner di recupero il costo e il processo della valutazione. Un team credibile stabilisce il prezzo della diagnosi separatamente e vi consegna il report, che rimane a vostra disposizione.

Come scegliere un partner per il recupero di un progetto

Cosa chiedere:

• Avete recuperato progetti con il nostro stack e su questa scala? Chiedete dettagli specifici, non loghi.
• Cosa comprende la vostra valutazione e conserveremo il report?
• Ci direte se il progetto dovrebbe essere ricostruito invece di essere recuperato?
• Chi lavorerà esattamente al nostro progetto e quale sarà il suo livello di seniority?
• Come gestite la transizione con il nostro fornitore o team attuale?
• Come si svolgeranno concretamente i primi 30 giorni?

Segnali d’allarme: un preventivo per il recupero senza una valutazione preliminare, promesse di risolvere tutto senza aver letto il codice, nessun riferimento specifico a precedenti attività di recupero e chiunque parli male del vostro fornitore attuale prima di aver visto il repository. Diffidate inoltre del team che raccomanda una riscrittura completa già dal primo giorno senza prove; a volte è la scelta giusta, ma dovrebbe emergere dalla valutazione, non dal discorso commerciale.

Quando il recupero non è la risposta

Anche qui l’onestà è importante. Non paghi un intervento di recupero se:

• l’obiettivo aziendale alla base del progetto non è più valido. Recuperare un software di cui nessuno ha bisogno è la forma più costosa di spreco.
• La tecnologia è fondamentalmente inadatta al problema e non può essere adattata.
• La Sua organizzazione non può mettere a disposizione personale per il prodotto. Un team di recupero può risolvere i problemi di ingegneria, ma non può sostituire un product owner assente.
• Ha bisogno di qualcuno da incolpare, non di qualcuno che risolva il problema. Il recupero richiede la collaborazione dell’attuale fornitore o team durante la transizione; se il rapporto è puramente conflittuale, inizi dai contratti, non dal codice.

Cosa fare nelle prime due settimane

Se il Suo progetto sta fallendo proprio ora, prima di coinvolgere qualsiasi partner:

1. Blocchi le modifiche all’ambito finché la valutazione non sarà completata.
2. Metta in sicurezza gli accessi: repository, infrastruttura, credenziali, documentazione. Si assicuri che le chiavi siano in possesso di più di una persona.
3. Ottenga una demo funzionante o un ambiente di staging, anche se approssimativo, così che tutti vedano la stessa realtà.
4. Metta per iscritto in una pagina cosa significa “completato”, in termini aziendali.
5. Smetta di pagare per una velocità di sviluppo che non può verificare. Colleghi i pagamenti successivi a milestone dimostrabili.

Domande frequenti

Come faccio a sapere se il mio progetto software può essere recuperato?

La maggior parte dei progetti in difficoltà può essere recuperata se l’architettura di base è recuperabile e l’obiettivo aziendale è ancora valido. I progetti che non possono essere recuperati sono generalmente quelli in cui i requisiti non sono mai stati reali oppure in cui la tecnologia è fondamentalmente incapace di svolgere il lavoro. Una valutazione tecnica fornisce una risposta basata su elementi concreti in una o due settimane.

Quanto tempo richiede il recupero di un progetto software?

Dipende dalle dimensioni e dai danni del progetto, ma uno schema comune è: valutazione in 1–2 settimane, stabilizzazione in 2–4 settimane e recupero completo nell’arco di 2–6 mesi. I progetti piccoli possono stabilizzarsi in poche settimane; i sistemi enterprise di grandi dimensioni richiedono più tempo.

Dovremmo mantenere l’attuale fornitore durante il recupero?

A volte. Se il fornitore possiede conoscenze del settore e il problema riguardava il processo o il livello di seniority, anziché la competenza, un partner per il recupero può assumere la guida mentre il fornitore esegue le attività. Se la fiducia è compromessa o mancano le capacità necessarie, una transizione completa funziona meglio. La valutazione dovrebbe fornire una raccomandazione in entrambi i casi.

Dovremo riscrivere tutto da zero?

Di solito no. In un intervento di recupero professionale, l’approccio predefinito consiste nel preservare il codice funzionante e risolvere ciò che blocca i progressi. Una riscrittura completa è raccomandata solo quando la base di codice o l’architettura non possono supportare i requisiti; questa decisione dovrebbe derivare dalla valutazione, non da una proposta commerciale.

Chi possiede il codice e la proprietà intellettuale durante il recupero?

Dovrebbe essere Lei. Prima dell’inizio di qualsiasi attività di recupero, confermi per iscritto l’accesso al repository, la titolarità della proprietà intellettuale e le credenziali. Se il precedente fornitore controlla il codice, risolvere questo problema è il passo zero, prima dell’inizio di qualsiasi attività di ingegneria.

Se questa pagina descrive il Suo progetto, il passo successivo è una conversazione, non un impegno.