Un software aziendale nasce bene quando si parte dal processo che deve migliorare. Il percorso tipico ha sette passaggi: analisi del processo e degli obiettivi, requisiti e progettazione, prototipo, prima versione minima (MVP), sviluppo per cicli brevi con i test, rilascio in produzione, manutenzione ed evoluzione. I tempi dipendono dal perimetro, e una stima seria arriva solo dopo l’analisi. Il vostro contributo serve in ogni passaggio, soprattutto all’inizio e quando il software si prova con i dati veri.
Quali sono le fasi per sviluppare un software?
Le fasi sono sette e in parte si sovrappongono: l’MVP nasce dai primi cicli di sviluppo, che proseguono a ogni rilascio. Ecco cosa succede in ciascuna e cosa serve da voi.
| Fase | Cosa succede | Cosa serve da voi |
|---|---|---|
| Analisi del processo e degli obiettivi | Si ricostruisce come si lavora oggi, eccezioni comprese, e si fissano obiettivi misurabili | Le persone che fanno il lavoro, documenti e file reali, i numeri del processo |
| Requisiti e progettazione | Si decide cosa fa il software, come sono organizzati i dati, con quali sistemi parla e in che ordine si rilascia | Un referente che decide le priorità, regole aziendali scritte, vincoli su privacy e sicurezza |
| Prototipo | Schermate navigabili, senza logica vera, per verificare che il percorso sia chiaro | Alcuni utenti che lo provano e lo commentano |
| MVP | La prima versione funzionante, ridotta al caso principale, usata con dati veri | La scelta di cosa resta fuori dalla prima versione |
| Sviluppo per iterazioni e test | Cicli brevi, ognuno chiuso da una dimostrazione e da verifiche | Presenza alle demo, risposte rapide, casi di prova con le eccezioni |
| Rilascio in produzione | Migrazione dei dati, formazione, avvio dell’uso quotidiano | Dati ripuliti, tempo per la formazione, una data concordata |
| Manutenzione ed evoluzione | Correzioni, aggiornamenti tecnici, nuove funzioni, misura dei risultati | Segnalazioni ordinate, un budget annuale, le nuove priorità |
Nel metodo DigiFluss lo stesso percorso è organizzato in quattro fasi. Process intelligence è l’analisi del processo reale. Flow architecture è la progettazione del sistema: modello dei dati, mappa delle integrazioni e piano dei rilasci, cioè cosa serve subito e cosa va validato per primo. Build sprint è lo sviluppo per cicli brevi, con test e rilasci progressivi. Scale loop è la fase dopo il rilascio: si misura il software in uso, lo si mantiene e lo si fa evolvere. Da noi chi analizza il processo è anche chi progetta e scrive il codice, così le informazioni non passano di mano.
Perché si parte dall’analisi del processo?
Perché il software deve funzionare sul processo reale, che spesso è diverso da quello descritto nelle procedure. Come si gestisce ogni giorno un ordine, con telefonate, eccezioni e file di appoggio, emerge solo parlando con chi lo fa.
In questa fase si ricostruisce il flusso dall’inizio alla fine: dove parte il lavoro, chi lo passa a chi, quali dati servono, dove si inceppa. Si fissano anche obiettivi misurabili, come meno ore per evadere un ordine. Se oggi il processo vive in fogli di calcolo condivisi, quei file sono un buon punto di partenza, perché contengono i dati reali e le regole che nessuno ha scritto. Ne abbiamo parlato nell’articolo sui segnali che dicono quando Excel non basta più.
L’analisi serve anche a stimare. Robert Glass, in un elenco di fatti fondamentali dell’ingegneria del software pubblicato su IEEE Software nel 2001, osserva che la maggior parte delle stime si fa all’inizio, prima di aver capito il problema. Aggiunge che le stime troppo ottimistiche sono una delle due cause più comuni dei progetti che sfuggono al controllo. Per questo una cifra data prima dell’analisi va presa come ordine di grandezza. Le fasce indicative della nostra Flow Audit per il software su misura vanno da 7.500 a 25.000 euro per uno strumento mirato o un processo integrato, e partono da 25.000 euro per un gestionale completo. Il preventivo arriva dopo l’analisi.
Cosa sono i requisiti e chi li decide?
I requisiti descrivono cosa deve fare il software e con quali vincoli. Li scrive chi sviluppa insieme a voi, ma le scelte spettano all’azienda, attraverso un referente che ha il mandato per decidere.
Si distinguono in due gruppi:
- Requisiti funzionali. Sono le operazioni che il software permette. Per esempio: il commerciale crea un’offerta partendo dal listino e, sopra una certa soglia di sconto, serve l’approvazione del responsabile.
- Requisiti non funzionali. Riguardano il modo in cui il software lavora: quanti utenti contemporanei, tempi di risposta, chi vede quali dati, dove sono ospitati, per quanto tempo si conservano.
Sui dati personali c’è un obbligo preciso. L’articolo 25 del GDPR chiede al titolare del trattamento, cioè a voi, di integrare la protezione dei dati fin dalla progettazione e di trattare, per impostazione predefinita, solo i dati necessari. Dati raccolti, permessi e tempi di conservazione vanno quindi decisi in questa fase, quando cambiarli costa poco.
Nella progettazione si disegnano poi il modello dei dati, cioè come sono organizzate le informazioni, e la mappa dei collegamenti con gli altri software. Le strade possibili sono nella guida su come far comunicare due software diversi. Infine si decide cosa entra nel primo rilascio e cosa nei successivi.
Secondo Glass, i requisiti instabili sono l’altra causa più comune dei progetti fuori controllo. Per tenerli stabili serve qualcuno che abbia l’ultima parola. La Scrum Guide, il testo che definisce il metodo Scrum, affida l’ordine delle priorità a una sola persona, il Product Owner (responsabile del prodotto), e precisa che non deve essere un comitato. In un progetto per una PMI è il ruolo del vostro referente.
Che differenza c’è tra prototipo e MVP?
Il prototipo serve a provare un’idea prima di costruirla. L’MVP è la prima versione che funziona e si usa con dati veri.
Un prototipo è di solito un insieme di schermate navigabili (in gergo mockup cliccabile): si clicca e si passa da una pagina all’altra, ma dietro non ci sono dati né regole. Costa poco e serve a scoprire presto se gli utenti capiscono il percorso. Non occorre un test grande: secondo Jakob Nielsen (Nielsen Norman Group), con 5 utenti simili tra loro emerge circa l’85% dei problemi di usabilità. Meglio quindi più test piccoli, correggendo tra l’uno e l’altro.
MVP sta per minimum viable product, cioè prodotto minimo funzionante. Eric Ries, autore di The Lean Startup, lo definisce come la versione di un nuovo prodotto che permette di imparare il massimo sui clienti con il minimo sforzo. Ries avverte che il nome inganna: lo scopo dell’MVP è imparare, e la dimensione giusta dipende dal contesto.
Per un software interno, l’MVP è la versione più piccola che regge il caso principale del processo per un primo gruppo di utenti. Un esempio ipotetico: in un gestionale delle commesse, la prima versione potrebbe coprire apertura della commessa, registrazione delle ore e stato di avanzamento, lasciando a un rilascio successivo report e fatturazione. Lo usano poche persone, e quello che emerge decide le priorità successive. A voi spetta la scelta più difficile: cosa lasciare fuori.
Come si sviluppa e si testa per iterazioni?
Si lavora per cicli brevi, chiamati sprint, ognuno con un obiettivo che si può dimostrare. Alla fine di ogni ciclo vedete funzionare una parte del software e decidete come proseguire.
Le durate variano. I principi del Manifesto Agile (2001) suggeriscono di consegnare software funzionante con cadenza da un paio di settimane a un paio di mesi, preferendo i periodi brevi. E aggiungono: “Il software funzionante è il principale metro di misura di progresso”. La Scrum Guide prevede sprint di durata fissa, di un mese o meno. Nel nostro metodo gli sprint durano da una a tre settimane, con demo periodiche e note di rilascio a ogni sprint che descrivono cosa è cambiato. Se una scelta era sbagliata lo scoprite dopo un ciclo, quando correggerla costa ancora poco.
I test accompagnano ogni ciclo. Una parte spetta a chi sviluppa: i test automatici, cioè piccoli programmi che a ogni modifica verificano che le funzioni già pronte non si siano rotte, e la revisione del codice da parte di un secondo sviluppatore. Poi c’è il test di accettazione, che spetta a voi. Gli utenti chiave provano il software con casi reali, eccezioni comprese, in un ambiente di prova separato da quello in uso (lo staging, una copia del sistema dove si può sbagliare senza conseguenze).
Secondo Glass, trovare e correggere gli errori assorbe circa il 40% dei costi di sviluppo. Anche dopo i controlli più rigorosi qualche difetto resta, e l’obiettivo è ridurne numero e gravità. Preparate per tempo, con chi conosce il lavoro, l’elenco dei casi da provare.
Cosa succede al rilascio, e dopo?
Al rilascio il software passa dall’ambiente di prova a quello in uso, con i dati veri. Da lì comincia la manutenzione, che dura quanto la vita del software.
Il rilascio in produzione
- Migrazione dei dati. Anagrafiche, listini e storici vanno ripuliti, abbinati ai nuovi campi e importati prima nello staging. Una prova completa evita sorprese il giorno della partenza.
- Formazione. Sessioni brevi per ruolo e una guida essenziale.
- Modalità di partenza. Tutti insieme o per gruppi, con il vecchio strumento in sola consultazione per un periodo stabilito. Serve anche un piano per tornare indietro se qualcosa si blocca.
- Consegna. Codice sorgente, documentazione tecnica e accessi a server e account devono restare all’azienda. La legge sul diritto d’autore tutela i programmi per elaboratore, compreso il materiale preparatorio di progettazione (legge 633/1941, articolo 2). Chi ne detiene i diritti va scritto nel contratto: verificatelo con un legale.
Manutenzione ed evoluzione
Un software in uso cambia. Si correggono errori, si aggiornano librerie e server, ci si adegua quando cambiano i sistemi collegati e si aggiungono funzioni. Secondo Glass la manutenzione assorbe in media il 60% del costo di vita di un software, con un intervallo tra il 40 e l’80%. Circa il 60% di quella spesa va in nuove funzioni; la correzione degli errori pesa intorno al 17%. Quindi gran parte della manutenzione serve a far evolvere il software.
Nel nostro metodo è la fase Scale loop: si misurano gli indicatori fissati in progettazione e si aggiorna l’elenco delle evoluzioni. Per voi significa mettere a budget un costo annuale fin dall’inizio. Il confronto con un abbonamento SaaS va fatto su più anni: lo trovate nella guida software su misura o SaaS.
Chi lavora a un progetto software?
Dalla parte di chi sviluppa servono competenze di analisi, progettazione, sviluppo, test e gestione dei server. Dalla vostra servono un referente che decide e le persone che conoscono il lavoro.
Lato sviluppo lavorano l’analista, che traduce il processo in requisiti, e il progettista, che decide struttura, dati e collegamenti. Poi il designer dell’interfaccia, che disegna schermate e percorsi, gli sviluppatori, che scrivono codice e test automatici, e chi gestisce server, backup e rilasci. In un team piccolo una persona copre più ruoli.
Dalla parte dell’azienda servono queste figure:
- Il referente di progetto: decide le priorità e cosa entra in ogni rilascio. Gli servono il mandato e il tempo per farlo.
- Gli utenti chiave: spiegano il lavoro, provano prototipo e versioni intermedie, fanno i test di accettazione.
- Chi conosce i sistemi esistenti: l’IT interno o il fornitore del gestionale, per accessi e integrazioni.
- I consulenti: il responsabile della protezione dei dati, se c’è, e il commercialista quando il software tocca fatturazione e contabilità.
Quali errori allungano un progetto software?
Molti nascono prima della prima riga di codice. Ecco quelli da evitare:
- Partire da un elenco di funzioni. Senza analisi si costruisce quello che è stato chiesto, che spesso non coincide con quello che serve.
- Decidere in comitato. Priorità che cambiano a ogni riunione rendono instabili i requisiti.
- Un MVP che contiene tutto. Se deve coprire ogni eccezione, arriva tardi e insegna poco.
- Saltare il test di accettazione. I casi difficili emergono in produzione, dove correggerli costa di più.
- Dimenticare dati e formazione. Con anagrafiche sporche o persone non formate, il software rischia di restare inutilizzato.
- Non mettere a budget la manutenzione. Senza aggiornamenti il software invecchia e va rifatto.
In sintesi
Un software nasce in sette passaggi: analisi del processo e degli obiettivi, requisiti e progettazione, prototipo, MVP, sviluppo per iterazioni con i test, rilascio in produzione, manutenzione ed evoluzione. Il metodo DigiFluss li organizza in quattro fasi: Process intelligence, Flow architecture, Build sprint e Scale loop. Una stima affidabile arriva dopo l’analisi. Lo sviluppo procede per cicli brevi chiusi da una demo, e secondo Glass, lungo la vita del software, la manutenzione pesa in media più dello sviluppo iniziale. Dalla vostra parte servono un referente con il mandato di decidere e le persone che conoscono il lavoro, soprattutto all’inizio e nei test.
Fonti: DigiFluss, il metodo in quattro fasi e fasce di investimento della Flow Audit (indicative, non preventivi); R. L. Glass, Frequently Forgotten Fundamental Facts about Software Engineering, IEEE Software (2001); E. Ries, Minimum Viable Product: a guide (2009); principi del Manifesto Agile (2001); K. Schwaber e J. Sutherland, The Scrum Guide (2020); J. Nielsen, Nielsen Norman Group, Why You Only Need to Test with 5 Users (2000); GDPR, articolo 25; legge 633/1941, articolo 2. Dati verificati il 2 ottobre 2026.