Il nostro metodo in 4 fasi (e perché la prima è la più importante)

Quasi tutti i progetti software che vanno storti hanno una cosa in comune: sono partiti dalla soluzione. Qualcuno aveva già deciso che serviva un’app, un portale o un gestionale nuovo, e da lì in poi si è solo costruito. Il nostro metodo parte un passo prima, dal problema. Le fasi di sviluppo di un software su misura, per come le facciamo noi, sono quattro: diagnosi, architettura, sviluppo a sprint e go-live. Te le raccontiamo una per una, con quello che succede davvero e con quello che resta in mano a te alla fine di ciascuna.

Non è un metodo inventato per sembrare ordinati. È il modo che abbiamo trovato per togliere le sorprese dove costano di più.

Le 4 fasi di sviluppo di un software su misura, in breve

• Diagnosi. Capire il problema con abbastanza precisione da riconoscerlo quando sarà risolto. Qui si decide cosa fare, e sopratutto cosa non fare.
• Architettura. Scegliere dove vivono i dati, come si parla con i sistemi che hai già, con quali tecnologie e in che ordine si costruisce.
• Sviluppo a sprint. Blocchi di lavoro di due settimane, con una demo ogni settimana sul software vero, non su una presentazione.
• Go-live. Il passaggio in produzione: dati migrati, collaudo, formazione, e la consegna di codice sorgente e documentazione.

Detta così sembra la sequenza che trovi in qualsiasi manuale. La differenza sta nel peso che diamo a ciascuna fase, e nella prima ci passiamo più tempo di quanto la maggior parte dei clienti si aspetti.

Fase 1: la diagnosi, e perché è la più importante

Nella diagnosi non si parla di tecnologie. Si guarda come lavora l’azienda oggi, con le persone che il problema lo vivono ogni giorno: chi ricopia i dati da un programma all’altro, chi tiene il file Excel che nessun altro sa aggiornare, chi risponde al telefono quando un ordine si perde per strada.

Da queste conversazioni tiriamo fuori tre cose, scritte nero su bianco:

• Qual è il problema, descritto in modo che tutti in azienda lo riconoscano allo stesso modo.
• Chi lo subisce, con ruoli precisi e non con uffici generici.
• Quanto costa lasciarlo com’è, in ore, errori, clienti scontenti o opportunità perse.

Poi mettiamo in dubbio l’idea di partenza. Ogni funzione richiesta passa da una domanda semplice: cosa succede se non la facciamo? Quelle che reggono entrano nel progetto, le altre aspettano. Abbiamo raccontato questo passaggio nel dettaglio in perché spendiamo i primi giorni a mettere in dubbio il tuo progetto.

Il motivo per cui la diagnosi pesa più delle altre fasi è quasi aritmetico. Un errore di comprensione scoperto qui si corregge con una riunione. Lo stesso errore scoperto durante lo sviluppo costa settimane di codice da rifare. Scoperto dopo il go-live, costa anche la fiducia delle persone che dovevano usare il software e hanno smesso.

Tutto quello che decidiamo male nella diagnosi lo paghiamo in ogni fase successiva. Tutto quello che decidiamo bene lo ritroviamo gratis.

Ogni tanto la diagnosi arriva a una conclusione scomoda: il software nuovo non serve, basta sistemare un processo o collegare due strumenti che hai già. Succede, e lo diciamo. È lo stesso ragionamento di quando non ti serve un’app: meglio un progetto più piccolo che funziona di uno grande che nessuno usa.

Cosa ti resta in mano: un documento con il problema, le priorità, i vincoli e la soluzione consigliata, più una roadmap con un preventivo diviso per fasi. È lo stesso lavoro che facciamo nella consulenza e analisi dei progetti software, e resta tuo anche se decidi di non andare avanti con noi.

Fase 2: l’architettura, le decisioni che non si vedono

L’architettura è la fase che il cliente vede meno e che condiziona di più la vita del software nei prossimi anni. Qui si prendono decisioni come queste:

• Dove vive ogni dato. Se un’anagrafica esiste sia nel gestionale sia nel nuovo software, uno dei due deve avere l’ultima parola. Deciderlo adesso evita anni di dati che non tornano.
• Come ci si collega a quello che c’è già. Gestionale, e-commerce, CRM, macchinari: cosa si integra, in che direzione passano le informazioni, cosa succede quando uno dei sistemi non risponde.
• Con quali tecnologie. Scegliamo strumenti diffusi e supportati nel lungo periodo, non linguaggi esotici o framework fatti in casa. Il criterio è semplice: domani un altro professionista deve poterci mettere le mani senza ricominciare da zero.
• In che ordine si costruisce. Prima le parti che sbloccano valore o che nascondono più rischio, poi il resto. Ogni blocco diventa una milestone con un risultato verificabile.

È anche il momento in cui si prepara l’ambiente di staging: una copia del software separata da quella di produzione, dove vedrai e proverai ogni avanzamento senza toccare il lavoro quotidiano dell’azienda.

Cosa ti resta in mano: lo schema dell’architettura con le scelte motivate, l’elenco delle integrazioni e un piano di milestone con tempi e costi collegati a ciascuna.

Fase 3: sviluppo a sprint, con una demo ogni settimana

Lo sviluppo procede a sprint di due settimane. Ogni sprint ha un obiettivo concordato prima di iniziare, e dentro ogni sprint ci vediamo una volta a settimana per una demo.

La demo settimanale non è un aggiornamento a voce e non sono slide. È il software vero, aperto in staging, con le funzioni costruite in quei giorni. Chiediamo che ci sia anche chi lo userà tutti i giorni, non solo chi ha firmato il preventivo, perché sono quelle persone ad accorgersi subito che un campo è nel posto sbagliato o che manca un passaggio che in ufficio si fa da sempre.

Una settimana è abbastanza lunga per mostrare qualcosa di concreto e abbastanza corta perché un fraintendimento costi pochi giorni di lavoro, non un mese. Se qualcosa non va nella direzione giusta, te ne accorgi mentre è ancora facile correggerla.

Una demo a settimana vuol dire che il progetto non può allontanarsi da quello che ti serve per più di sette giorni senza che tu lo veda.

Durante le demo nascono inevitabilmente idee nuove. Le accogliamo, ma non le infiliamo nello sprint in corso «già che ci siamo». Ogni richiesta nuova viene scritta, valutata per impatto su tempi e costi, e decidi tu se e quando farla entrare. È così che il perimetro resta sotto controllo senza diventare rigido.

Cosa ti resta in mano: un software che puoi provare in qualsiasi momento, un elenco aggiornato di cosa è fatto e cosa manca, e nessuna scoperta rimandata alla fine del progetto.

Fase 4: il go-live, cioè il giorno in cui il software diventa tuo

Il passaggio in produzione è un lavoro a sé, non un clic. Comprende:

• La migrazione dei dati dal sistema precedente, aggiornati fino all’ultimo momento utile.
• Il collaudo con dati reali, fatto insieme alle persone che useranno il software, sui casi di tutti i giorni e su quelli che capitano una volta al mese.
• La formazione di chi lo userà, e l’affiancamento nei primi giorni, quelli in cui le domande arrivano tutte insieme.
• La consegna del codice sorgente completo, della documentazione tecnica e degli accessi.

Dopo il go-live il software ha bisogno di manutenzione, come qualsiasi strumento di lavoro. La concordiamo in modo flessibile, sulla base di quanto il sistema è critico per l’azienda. Se ti interessa capire come ogni fase pesa sul costo finale, lo abbiamo scomposto in cosa c’è davvero dentro il prezzo di un software su misura.

Trasparenza e controllo: cosa resta sempre a te

Un metodo ordinato serve a poco se il cliente resta fuori dalla stanza. Per questo, lungo tutte le fasi di sviluppo del software su misura, alcune cose non sono in discussione:

• Il codice sorgente è tuo. Nessun canone di licenza e nessun vendor lock-in: puoi farlo evolvere con noi o con chi preferisci.
• La documentazione esiste. Scritta per chi verrà dopo di noi, con il perché delle scelte e non solo il come.
• Gli accessi e i dati sono tuoi. Server, domini, servizi esterni: intestati all’azienda, non a noi.
• Vedi il lavoro mentre avanza. Staging sempre disponibile, demo ogni settimana, milestone con risultati verificabili.
• I costi sono legati alle fasi. Sai in anticipo quanto costa ogni blocco, e le richieste nuove passano da una tua decisione.

Sul tema della proprietà del codice abbiamo scritto un articolo intero, perché è la domanda che conta di più quando si sceglie un fornitore: ma poi ci sarete ancora?

Perché lavoriamo così

Lavoriamo da Castelnuovo del Garda con aziende del Veneto e del Nord Italia, e il metodo è sempre lo stesso anche quando il progetto cambia completamente: un gestionale, un’integrazione fra sistemi, un’app per chi lavora in produzione. Le quattro fasi si adattano alla dimensione del lavoro, ma l’ordine no.

Il senso è tutto qui: spostare le decisioni difficili all’inizio, quando costano poco, e rendere visibile tutto il resto mentre succede. Il software che funziona non nasce da una grande idea scritta bene. Nasce da un problema capito bene, e da tante piccole verifiche fatte presto. Se vuoi vedere come il metodo si applica ai diversi tipi di progetto, trovi tutto nella pagina dei nostri servizi di sviluppo software su misura.