Quando un’organizzazione decide di sviluppare un nuovo software, la prima discussione riguarda quasi sempre ciò che il sistema dovrà fare. Si parla di utenti, dashboard, documenti, notifiche, autorizzazioni, report. È comprensibile: sono gli elementi più visibili di un’applicazione e, quindi, quelli più facili da immaginare. Eppure, nella progettazione di un software su misura, le funzionalità non sono quasi mai il vero punto di partenza.
Prima delle schermate esiste un processo. Prima dei pulsanti esistono decisioni, responsabilità, informazioni e regole. Prima del database esiste un’organizzazione che, bene o male, sta già svolgendo quel lavoro.
Il primo compito di chi progetta il sistema consiste, quindi, nel capire quel lavoro. È un passaggio apparentemente ovvio, ma decisivo. Molti problemi attribuiti alla mancanza di uno strumento digitale derivano infatti da processi difficili da governare: informazioni distribuite tra più applicazioni, documenti che circolano per email, fogli Excel utilizzati come archivi, approvazioni non sempre tracciabili, attività manuali ripetitive, procedure conosciute soprattutto da chi le svolge da anni.
In questi casi sviluppare un software senza mettere prima a fuoco bene il processo o i processi sottostanti significa correre un rischio concreto: trasferire nel digitale le stesse inefficienze che si vorrebbero eliminare.
In DEV4U affrontiamo questo tipo di progetti attraverso un percorso che possiamo ricondurre a cinque momenti: capire il processo, disegnare la soluzione, costruire progressivamente, verificare sul campo e migliorare nel tempo.
Non sono cinque compartimenti stagni né una sequenza burocratica di documenti da produrre. Sono piuttosto cinque prospettive attraverso le quali il progetto viene continuamente osservato e corretto.
Per rendere il metodo più concreto, immaginiamo un caso tipico: un’organizzazione vuole realizzare un software per gestire l’iter di approvazione dei bandi di gara.
La richiesta iniziale potrebbe essere formulata con parole simili a queste: «Vogliamo digitalizzare la gestione dei bandi» (come è successo, per esempio, nel progetto per ARS Progetti).
Da qui comincia il nostro lavoro che andiamo a descrivervi.
1. Capire il processo
La prima attività non consiste nel compilare una lista di funzionalità, ma nel ricostruire ciò che accade oggi.
Come nasce un nuovo bando? Chi lo prepara? Chi deve controllarlo? Quali uffici intervengono? Chi può approvare una pratica e chi può soltanto consultarla? In quali casi è necessario richiedere una modifica? Esistono procedure diverse in funzione dell’importo, della tipologia di gara o dell’ente finanziatore? Quali documenti devono essere prodotti e conservati? Quali passaggi devono essere tracciati?
Queste domande servono a trasformare una richiesta generica di digitalizzazione in un problema progettuale definito.
Supponiamo, per esempio, che il processo attuale funzioni in questo modo. Un responsabile redige il bando e invia la documentazione via email a un secondo ufficio. Il documento viene verificato, eventualmente modificato e restituito al responsabile. Dopo una nuova versione interviene un dirigente, che può approvare il contenuto oppure richiedere ulteriori correzioni. Solo al termine di questi passaggi un altro ufficio procede alla pubblicazione.
Il processo funziona, ma lascia dietro di sé una quantità significativa di informazioni distribuite: messaggi di posta elettronica, allegati, versioni successive dello stesso documento, note, approvazioni e richieste di modifica.
A distanza di qualche mese potrebbe diventare difficile rispondere a domande molto semplici: qual era la versione approvata? Chi aveva richiesto una modifica? Quando è stato effettuato un determinato controllo? Per quanto tempo la pratica è rimasta in attesa presso un ufficio?
A questo punto il bisogno cambia natura. Non serve semplicemente un programma «per gestire i bandi». Serve un sistema capace di rappresentare il processo, governarne i passaggi e conservarne la storia.
Questa distinzione è importante perché impedisce di confondere la digitalizzazione con la semplice sostituzione degli strumenti. Eliminare Excel e la posta elettronica non è, di per sé, innovazione. Lo diventa quando il nuovo sistema rende il processo più chiaro, affidabile e controllabile.
2. Disegnare la soluzione
Una volta compreso il processo attuale, possiamo iniziare a rappresentare quello futuro.
Nel nostro esempio, una prima versione del workflow potrebbe sembrare elementare:
Bozza → Revisione → Approvazione → Pubblicazione.
È sufficiente però approfondire ogni passaggio per scoprire che la realtà è più articolata.
Durante la revisione il documento può essere respinto. In quel caso deve tornare all’autore. Una nuova versione potrebbe richiedere un ulteriore controllo. Alcune procedure potrebbero prevedere un’approvazione aggiuntiva. Alcuni utenti potrebbero avere accesso soltanto a determinate tipologie di gara. Un dirigente potrebbe essere autorizzato ad approvare soltanto pratiche entro una determinata soglia.
È proprio in questo momento che il processo organizzativo comincia a trasformarsi in un modello software.
Occorre definire gli stati della pratica, le transizioni possibili, i ruoli, i permessi, le informazioni obbligatorie, i documenti, le notifiche e le regole che determinano ciò che ogni utente può fare.
La progettazione non avviene però soltanto attraverso documenti descrittivi.
Quando possibile preferiamo rendere la soluzione visibile rapidamente, attraverso schemi di processo, wireframe e prototipi delle schermate principali.
Una dashboard può mostrare le pratiche che richiedono attenzione. La scheda di un bando può raccogliere dati, documenti e stato di avanzamento. Una timeline può rendere immediatamente leggibile la sequenza delle revisioni e delle approvazioni.
Il prototipo svolge una funzione molto precisa: permette di discutere non più di ciò che il software potrebbe essere, ma di qualcosa che il cliente può osservare e mettere in relazione con il proprio lavoro quotidiano.
La domanda diventa quindi molto concreta: se il sistema funzionasse così, il processo sarebbe corretto?
È in questa fase che spesso emergono eccezioni, vincoli e necessità non esplicitati in precedenza. Ed è esattamente ciò che deve accadere.
Un requisito scoperto mentre si osserva un prototipo richiede una modifica. Lo stesso requisito scoperto quando una parte consistente del software è già stata sviluppata può richiedere una revisione dell’architettura, del database e delle logiche applicative.
Prototipare non significa quindi rallentare lo sviluppo. Significa ridurre il costo delle decisioni sbagliate.
3. Costruire progressivamente
Quando la struttura del sistema è sufficientemente chiara, comincia lo sviluppo vero e proprio.
Anche in questa fase cerchiamo di evitare un approccio monolitico nel quale l’intera applicazione viene costruita per mesi e mostrata al cliente soltanto alla fine.
Preferiamo procedere per componenti funzionali progressivamente utilizzabili.
Nel caso del software per i bandi potremmo cominciare dalla creazione della pratica e dalla gestione dei suoi stati. Successivamente implementare revisione e approvazioni, quindi la gestione documentale, le notifiche, le dashboard operative, la reportistica e le funzioni di amministrazione.
La suddivisione in blocchi non significa però frammentare il progetto. Ogni funzione deve essere progettata tenendo conto del sistema nel suo insieme.
Consideriamo una funzione apparentemente semplice: Richiedi modifiche.
Dal punto di vista dell’interfaccia potrebbe essere soltanto un pulsante. Dal punto di vista del sistema comporta una serie di conseguenze.
Quale stato assume la pratica? Chi può modificarla dopo la richiesta? Il responsabile deve ricevere una notifica? È obbligatorio indicare la motivazione? La richiesta deve essere conservata nello storico? La precedente versione del documento rimane disponibile? Chi aveva già approvato la pratica deve effettuare nuovamente il controllo?
È in questo livello di dettaglio che una funzione diventa parte di un sistema informativo.
Lo sviluppo software non consiste infatti soltanto nel tradurre una specifica in codice. Significa dare forma a un insieme coerente di regole, dati e comportamenti.
Per questo analisi e sviluppo non possono essere completamente separati. La programmazione stessa mette alla prova il modello iniziale e fa emergere nuove domande.
Un team compatto facilita questo scambio. Chi segue l’analisi può confrontarsi rapidamente con chi sviluppa; chi incontra un problema tecnico può riportarlo immediatamente sul piano funzionale. La distanza tra una domanda e una decisione si riduce.
Per un progetto su misura è un vantaggio sostanziale, perché molte delle decisioni più importanti nascono proprio nel punto di contatto tra conoscenza del processo e conoscenza tecnica.
4. Verificare sul campo
Esiste una differenza significativa tra verificare che un software sia corretto e verificare che sia utile.
La prima attività riguarda il funzionamento tecnico: dati salvati correttamente, permessi rispettati, operazioni eseguite senza errori, integrazioni funzionanti.
La seconda riguarda il lavoro delle persone. Per questo, non appena una parte del sistema è sufficientemente stabile, è utile provarla attraverso scenari realistici.
Torniamo al nostro esempio.
Un responsabile crea un nuovo bando, inserisce le informazioni e carica i documenti. Il revisore apre la pratica, effettua il controllo e richiede una modifica. Il responsabile riceve la richiesta, aggiorna il documento e invia una nuova versione. Il revisore approva e la pratica passa al dirigente, che completa l’ultimo controllo.
È durante prove di questo tipo che emergono osservazioni difficili da ottenere in una riunione iniziale.
Il revisore potrebbe accorgersi che ricevere un’email per ogni variazione è inutile e preferire una dashboard con tutte le pratiche in attesa della propria azione. Il dirigente potrebbe aver bisogno di una vista sintetica e non dell’intero contenuto della pratica. Un responsabile potrebbe chiedere di visualizzare immediatamente da quanti giorni ogni pratica si trova nello stesso stato.
Nessuna di queste osservazioni mette necessariamente in discussione il progetto. Al contrario, lo rende più aderente alla realtà.
Un requisito descritto verbalmente e un comportamento osservato durante l’uso non hanno lo stesso valore informativo. Le persone sono spesso molto brave a descrivere ciò che fanno, ma molto meno nel prevedere ciò di cui avranno bisogno all’interno di uno strumento che ancora non esiste.
Per questo l’utilizzo è parte integrante dell’analisi.
Il criterio con cui valutiamo il risultato non è soltanto la conformità alle specifiche. Un’applicazione può rispettare perfettamente i requisiti iniziali e risultare comunque poco efficace.
La verifica più importante riguarda quindi il processo: il nuovo sistema ha ridotto i passaggi inutili? Le responsabilità sono più chiare? È più semplice trovare un’informazione? È possibile ricostruire ciò che è accaduto? Gli utenti comprendono cosa devono fare senza ricorrere continuamente a istruzioni esterne?
Quando la risposta è positiva, il software sta iniziando a produrre valore.
5. Migliorare nel tempo
La messa in produzione non conclude l’apprendimento sul sistema. Ne apre una fase diversa.
Fino al go live abbiamo lavorato soprattutto con processi descritti, casi di prova e scenari simulati. Da quel momento disponiamo di qualcosa di molto più significativo: l’utilizzo reale.
Possiamo osservare quali funzioni vengono impiegate più frequentemente, quali attività richiedono più tempo, dove si accumulano le pratiche, quali informazioni vengono cercate più spesso e quali passaggi potrebbero essere ulteriormente semplificati.
È anche il momento in cui alcune ipotesi iniziali vengono confermate o smentite. Una funzione ritenuta fondamentale durante l’analisi può rivelarsi marginale. Un piccolo dato inserito in una dashboard può invece diventare essenziale per il lavoro quotidiano. Non è un’anomalia. È la naturale evoluzione di un sistema che entra in relazione con un’organizzazione reale.
Anche l’organizzazione, del resto, cambia. Cambiano le procedure, le persone, le norme, i volumi di attività, i sistemi esterni con cui occorre comunicare.
Un software su misura deve quindi essere progettato non soltanto per rispondere al problema iniziale, ma anche per poter evolvere senza dover essere ricostruito ogni volta da zero.
Nel nostro esempio, un sistema nato per gestire l’approvazione dei bandi potrebbe in seguito estendersi alla composizione delle commissioni, alla gestione delle offerte, al monitoraggio delle scadenze contrattuali, alla reportistica o all’integrazione con altre piattaforme.
Il criterio, tuttavia, dovrebbe rimanere invariato: una nuova funzione ha senso quando risolve un problema riconosciuto o produce un vantaggio concreto.
Aggiungere continuamente funzionalità non rende necessariamente migliore un software. A volte lo rende soltanto più complesso.
Il metodo non è la somma delle sue fasi
Descrivere un progetto attraverso cinque fasi può far pensare a una sequenza lineare: prima si conclude l’analisi, poi si progetta, quindi si sviluppa, si testa e infine si mette il sistema in produzione.
Nella pratica raramente accade in modo così ordinato.
La progettazione può far emergere un problema nell’analisi. Lo sviluppo può obbligare a rivedere una regola. Un test può suggerire una modifica all’interfaccia. L’utilizzo reale può portare a ripensare una funzione sviluppata mesi prima.
È proprio questa capacità di tornare sulle decisioni, senza perdere la coerenza complessiva del progetto, a rendere il metodo efficace.
Per una realtà come DEV4U, lavorare con un gruppo ristretto di persone consente inoltre di mantenere vicine competenze che nelle organizzazioni più grandi vengono spesso distribuite tra molti ruoli: analisi, gestione del progetto, UX e sviluppo.
Non significa eliminare responsabilità o competenze specialistiche. Significa limitare i passaggi nei quali le informazioni possono essere interpretate, sintetizzate o perse.
Il cliente non consegna un documento a qualcuno che lo passa a qualcun altro fino a quando, molti passaggi dopo, arriva allo sviluppatore. Il confronto tra problema organizzativo e soluzione tecnica rimane più diretto.
È un aspetto particolarmente importante nello sviluppo su misura, dove raramente tutti i requisiti sono conoscibili all’inizio e dove la qualità del risultato dipende anche dalla capacità di fare le domande giuste durante il percorso.
Prima il processo. Poi la tecnologia.
Naturalmente un sistema informativo è fatto anche di tecnologia. Architetture, database, interfacce, API, sicurezza, prestazioni, infrastrutture e qualità del codice sono componenti indispensabili e richiedono competenze specifiche.
Ma arrivano dopo una domanda più elementare: che cosa deve migliorare? Se non sappiamo rispondere con precisione, la discussione sulla tecnologia rischia di essere prematura.
È anche per questo che, quando affrontiamo un nuovo progetto, cerchiamo di non valutare il risultato soltanto chiedendoci se il software funzioni. La domanda più utile è un’altra: il processo funziona meglio di prima?
Significa verificare se sono diminuite le attività manuali, se le informazioni sono più accessibili, se le responsabilità sono più leggibili, se gli errori sono più difficili da commettere, se le decisioni possono essere ricostruite e se le persone riescono a dedicare meno tempo alla gestione dello strumento e più tempo al proprio lavoro.
In fondo, è questa la ragione per cui vale la pena sviluppare un software su misura.
Non per trasformare ogni processo in un’applicazione. Ma per progettare un’applicazione quando può rendere quel processo più semplice, più controllabile e, soprattutto, migliore.
Alcune letture di approfondimento
- Leggi la scheda del nostro portfolio dove descriviamo sinteticamente la piattaforma sviluppata per ARS progetti.
- Ascolta e leggi l’intervista fatta a Dario Berardi, dove raccontiamo con un video l’esigenza progettuale, la soluzione proposta e l’esperienza lavorativa vissuta con ARS Progetti
- Leggi, sul nostro blog, la notizia relativa al progetto ARS Progetti.
Per avere maggiori informazioni su questo argomento vi invitiamo a contattarci.
Fisseremo un incontro per parlarne e approfondire il tema.
Contattaci via mail scrivendo a info@dev4u.it, non perdere altre opportunità!
Autore/i dell’articolo:
Maurizio Patitucci – BIO – Linkedin – Email
Business Analyst | Project Manager | Account Manager
Dario Berardi – BIO – Linkedin – Email
System Analyst | Senior Developer | Database Architect
