Metodo

Prima capiamo come lavorate. Poi decidiamo cosa vale la pena automatizzare.

Il rischio di un progetto software non è tecnico: è arrivare alla fine e scoprire di aver costruito qualcosa che non serviva. Ogni fase produce qualcosa che potete verificare mentre siamo ancora in tempo a cambiare idea.

Le quattro fasi

Comprendiamo

Veniamo a vedere come lavorate e parliamo con chi il lavoro lo fa tutti i giorni, non solo con chi lo descrive.

Esito: mappa del processo, elenco dei problemi, cosa conviene affrontare per primo.

Progettiamo

Decidiamo come sono fatte le informazioni e quali stati può attraversare una pratica. È la parte che si vede meno ed è quella che determina se fra tre anni il sistema si potrà ancora estendere.

Esito: struttura dei dati, schermate chiave, ordine dei rilasci.

Costruiamo

Sviluppiamo per parti utilizzabili, così potete provarle con dati veri invece di immaginarle a partire da un documento.

Esito: versioni funzionanti che entrano in uso una alla volta.

Evolviamo

Quando il sistema è in uso emergono le esigenze vere. Restiamo per correggerle e per aggiungere ciò che si è rivelato necessario.

Esito: manutenzione e sviluppi successivi, decisi insieme.

Nel dettaglio

Cosa succede davvero in ogni fase

1. Comprendiamo

Le prime domande non riguardano il software. Riguardano il lavoro: chi riceve cosa, chi decide, dove si aspetta, cosa succede quando qualcosa va storto. Ci interessano soprattutto le eccezioni, perché sono quelle che fanno fallire i gestionali generici: la procedura ideale la gestiscono tutti, i casi strani no.

In questa fase guardiamo anche i file che usate oggi. Un foglio di calcolo cresciuto negli anni è la migliore documentazione esistente del vostro processo reale: contiene le colonne che qualcuno ha aggiunto perché servivano davvero.

Al termine sapete quali problemi sono risolvibili con il software, quali no, e quali conviene affrontare per primi perché costano poco e restituiscono molto.

2. Progettiamo

Progettare significa decidere come sono fatte le informazioni: quali entità esistono, come si collegano, quali stati può attraversare una pratica. È la parte che si vede meno ed è quella che determina se fra tre anni il sistema si potrà ancora estendere.

Insieme alla struttura definiamo le schermate principali e soprattutto l'ordine dei rilasci: cosa entra nella prima versione utilizzabile e cosa può aspettare. Su un progetto ampio questa è la decisione che riduce di più il rischio, perché accorcia il tempo che passa prima di vedere qualcosa di reale.

3. Costruiamo

Sviluppiamo per parti che si possono usare. La prima consegna non è una presentazione: è un pezzo di software che comincia a fare il suo lavoro, con i vostri dati.

Da quel momento il confronto cambia natura: non si discute più su cosa si immagina, si discute su cosa si vede. È anche il momento in cui emergono le richieste che nessuna analisi avrebbe potuto anticipare, e conviene che emergano presto.

4. Evolviamo

Un software gestionale entra davvero in funzione mesi dopo il rilascio, quando tutti hanno smesso di usare il vecchio metodo in parallelo. Lì emergono le richieste vere, che quasi mai coincidono con quelle immaginate all'inizio.

Restiamo per seguirle. Il sistema che seguiamo da più tempo è in esercizio dal 2012, il gestionale principale dal 2019, ed entrambi ricevono ancora sviluppo: per noi la manutenzione non è la coda del progetto, è la parte più lunga.

Come si lavora insieme

Cosa serve da parte vostra

Un progetto riesce quando dall'altra parte c'è qualcuno che conosce il processo e può decidere. Non serve che sia una figura tecnica.

Una persona di riferimento che conosca il lavoro e possa rispondere alle domande senza dover convocare una riunione ogni volta.
Accesso a chi opera. Chi usa il sistema tutti i giorni sa cose che nessun responsabile può raccontare.
Qualche decisione, presa in tempi ragionevoli. Le domande che vi facciamo sono poche ma bloccanti.

I documenti veri. I modelli che compilate, anche quelli fatti male: servono più di qualunque descrizione.
Disponibilità a provare le versioni intermedie. Un rilascio che nessuno apre non produce informazioni utili.
Onestà sulle eccezioni. Le scorciatoie che usate quando la procedura non funziona vanno raccontate: se non entrano nel software, il software verrà aggirato.

Imprevisti

Cosa facciamo quando qualcosa cambia

Cambia sempre qualcosa: una norma, un fornitore, un modo di lavorare. Il punto non è evitarlo, è accorgersene presto e decidere cosa farne.

Quando una richiesta nuova arriva a lavoro iniziato, la valutiamo per quello che è: vi diciamo che impatto ha, se conviene farla adesso o dopo, e cosa eventualmente conviene rimandare per farle spazio. Non ci sono richieste rifiutate per principio né accettate senza dire cosa costano.

Lo stesso vale per gli errori: se sbagliamo una previsione preferiamo dirlo quando ce ne accorgiamo, non alla scadenza.