Quando un progetto comincia ad affondare?
Ogni progetto informatico inizia in modo simile. Ci sono piani ambiziosi, una timeline, la presentazione delle prime bozze e la convinzione che dopo alcuni mesi l'azienda utilizzerà un sistema moderno. All'inizio tutto sembra promettente, ma col tempo compaiono i primi ritardi. La scadenza si sposta di una settimana, poi di un mese. Il numero di bug aumenta, la comunicazione con il fornitore diventa sempre più difficile, e le risposte successive sono: "Ancora un attimo", "È solo una piccola correzione" oppure "Siamo quasi alla fine."
A un certo punto si scopre che invece di un prodotto finito l'azienda ha un progetto incompiuto che nessuno vuole prendere in carico.
Questo scenario è molto più comune di quanto si possa pensare.
Il problema principale non è il codice
La maggior parte degli imprenditori presume che se un progetto non funziona la colpa sia del codice scritto male. Certo, a volte è proprio così. Nella pratica però il problema più spesso è più profondo.
Manca la documentazione. L'architettura è stata costruita "al volo". Non ci sono test automatici. Le integrazioni sono state fatte in modo provvisorio. Funzionalità successive sono state aggiunte senza analizzare l'impatto sul sistema complessivo. Di conseguenza anche una piccola modifica genera nuovi bug.
È un po' come ristrutturare una casa senza progetto. Ogni stanza si può ancora finire, ma col tempo si scopre che i muri non sono dove dovrebbero essere, gli impianti sono posati a caso e la ristrutturazione diventa sempre più costosa.
Quando è il caso di dire "stop"?
Uno dei momenti più difficili per il proprietario di un'azienda è decidere di interrompere la collaborazione con il fornitore attuale. Molti imprenditori aspettano troppo a lungo.
Perché?
Perché il progetto ha già inghiottito molti soldi.
Perché è un peccato sprecare tempo.
Perché forse "si risolverà".
La psicologia chiama questo effetto dei costi sommersi. Più abbiamo investito, più è difficile ammettere che l'attuale direzione non porta da nessuna parte.
Tuttavia talvolta la decisione migliore non è continuare a versare budget nello stesso problema, ma fermare il progetto e analizzare la situazione con calma.
Ogni progetto può essere salvato?
No. - E va detto onestamente.
Ci sono progetti la cui riparazione costerebbe più che ricrearli da zero. Può anche succedere che la tecnologia usata sia ormai obsoleta o che l'architettura sia stata concepita in modo da impedire l'evoluzione.
Perciò il primo passo non dovrebbe mai essere fare promesse.
Il primo passo dovrebbe essere un audit.
Solo dopo un'analisi approfondita del codice, della documentazione, dell'infrastruttura e dei processi si può rispondere alla domanda se convenga riparare la soluzione esistente o avviarne una nuova.
Un buon partner tecnologico non dirà quello che il cliente vuole sentirsi dire.
Dirà quello che è meglio per lui dal punto di vista del business.
Come si salvano i progetti nella pratica?
Contrariamente a quanto si potrebbe pensare non si parte dalla programmazione.
Prima bisogna capire con cosa abbiamo a che fare.
Analizziamo l'architettura del sistema, la qualità del codice, il modo in cui i moduli comunicano, la sicurezza dei dati, le prestazioni e le possibilità di sviluppo futuro. Verifichiamo la documentazione, la cronologia delle modifiche e le tecnologie utilizzate. Spesso già dopo pochi giorni si individua dov'è il problema reale.
Solo allora si redige un piano d'azione.
A volte basta mettere ordine nel codice e correggere alcuni elementi chiave. Altre volte è necessaria la ricostruzione di moduli selezionati. Può anche capitare che la soluzione più sensata sia creare un nuovo sistema riutilizzando ciò che è stato già realizzato.
Non esistono due progetti identici.
Così come non esiste una sola ricetta per salvarli.
Perché prendere in carico un progetto è più difficile che crearne uno nuovo?
Questa è una domanda che spesso ci pongono i clienti.
La risposta è semplice.
Creando un sistema da zero conosciamo ogni decisione progettuale. Sappiamo perché è stata scelta una soluzione e quali erano le premesse.
Prendendo in carico il progetto di altri, dobbiamo prima ricostruire quella conoscenza.
È un po' come subentrare nei lavori di costruzione di una casa lasciati da una squadra che ha abbandonato il cantiere senza piani, documentazione e senza indicazioni su quanto è stato fatto.
Perciò salvare i progetti richiede non solo competenze di programmazione, ma anche esperienza architettonica, analitica e di progettazione.
Un partner tecnologico dovrebbe restare al tuo fianco anche quando sorgono problemi
Un buon software house si riconosce non da come avvia un progetto.
Si riconosce da come reagisce quando emergono difficoltà.
Non tutto si può prevedere. I requisiti di business, le tecnologie e le esigenze degli utenti cambiano. L'importante è se il team è in grado di trovare soluzioni, comunicare chiaramente i rischi e prendere insieme al cliente le decisioni migliori.
È in quei momenti che si costruisce la fiducia.
Come lavoriamo in Web24?
Ci avviciniamo ai progetti che richiedono subentro con grande prudenza.
Non facciamo promesse dopo la prima conversazione.
Prima analizziamo la situazione. Verifichiamo cosa è stato realizzato, cosa si può riutilizzare e cosa richiederà una ricostruzione. Solo dopo prepariamo una raccomandazione e un piano d'azione.
Il nostro obiettivo non è scrivere altre migliaia di righe di codice.
Il nostro obiettivo è portare il progetto al punto in cui possa realmente supportare lo sviluppo del business.
Riepilogo
Se il tuo progetto è bloccato, il fornitore ha smesso di rispondere, il piano temporale esiste solo sulla carta e le correzioni successive generano nuovi errori, non significa ancora che sia tutto perduto.
In molti casi il problema può essere risolto.
Bisogna però partire da un passo: un'analisi seria della situazione.
Perché prima di salvare un progetto, conviene capire perché ha iniziato ad affondare.
