Sviluppare un gestionale per fasi: scegliere cosa entra nella prima versione

La domanda «che cosa mettiamo nella prima versione» riceve quasi sempre la stessa risposta sbagliata: un po’ di tutto. Un pezzo di anagrafiche, un pezzo di ordini, un pezzo di magazzino. È la scelta che sembra più prudente ed è quella che non si può usare: nessun processo arriva fino in fondo, e il sistema resta una cosa da compilare in più rispetto a quello che si fa già.

Il criterio è opposto: la prima versione copre un processo intero, dall’inizio alla fine, anche se ristretto. Meglio poco e completo che molto e interrotto.

Un processo intero, con un risultato che si vede

«Intero» ha un significato preciso: chi lo usa deve poter smettere di usare il metodo di prima per quel pezzo di lavoro. Se dopo aver inserito i dati nel sistema si continua a compilare anche il foglio di sempre, la prima versione non è finita: è un doppio lavoro, e verrà abbandonata appena l’azienda avrà una settimana difficile.

Il risultato deve essere visibile a qualcuno: un documento che esce, un elenco che prima non esisteva, una telefonata che non serve più. Serve a due cose insieme: dà una ragione concreta per usare il sistema e dà una prova che il progetto sta andando da qualche parte.

Separare l’indispensabile dai miglioramenti

Le richieste arrivano tutte insieme e tutte urgenti. Servono domande che dividano, e sono sempre le stesse quattro.

• Senza questa funzione, il processo si ferma? Se qualcuno può fare la stessa cosa in un altro modo, per ora, non è indispensabile.
• Chi la usa, e quanto spesso? Le funzioni che servono due volte all’anno possono restare manuali a lungo, e spesso restano manuali per sempre senza che nessuno se ne lamenti.
• Se manca, che cosa succede davvero? «Perdiamo tempo» e «non possiamo fatturare» non sono la stessa risposta.
• È una funzione o è un’abitudine? Capita di dover riprodurre un passaggio che esisteva solo perché lo strumento vecchio non sapeva fare altro.

Attenzione alle richieste brevi che portano dietro un mondo: uno stato in più su un documento può richiedere permessi, avvisi, storico e una regola su chi lo può cambiare. Il costo non si misura dalla lunghezza della frase che lo descrive.

Le dipendenze che non si possono rimandare

Il rilascio per moduli funziona solo se alcune decisioni vengono prese subito, anche quando riguardano parti che arriveranno molto dopo. Sono poche, e cambiarle più tardi costa quanto rifare.

• I dati condivisi: come si identifica un cliente, un articolo, una commessa. Se la prima versione inventa una numerazione sua, la seconda dovrà riconciliare due archivi.
• Chi vede che cosa: i permessi si progettano all’inizio anche se all’inizio il sistema lo usano in tre. Aggiungerli dopo significa rivedere ogni schermata.
• Da dove arrivano i dati che non nascono qui: se le giacenze stanno altrove, si decide adesso chi comanda su una quantità, anche se il collegamento verrà poi.
• Come si registra la storia: se serve sapere chi ha cambiato che cosa, va previsto subito, perché a posteriori non si ricostruisce.

Esempio: prima versione per le commesse

Un’azienda che installa impianti vuole un gestionale per le commesse. La lista dei desideri contiene una ventina di funzioni. La prima versione ne prende quattro, ma arriva in fondo.

Le funzioni lasciate fuori non sono cancellate: restano elencate, con il motivo accanto e con la condizione che le farà rientrare. È la differenza fra rimandare e dimenticare, ed è anche quello che permette di rispondere a chi le aveva chieste.

Criteri di accettazione: come si dice che è finita

«Funziona» non è un criterio. Un criterio è una frase che chiunque può verificare, scritta prima di cominciare a sviluppare.

1. Descrivere il caso reale, non la funzione: «il capocantiere apre la commessa da un preventivo accettato, assegna la squadra e compila il rapportino dal telefono, in cantiere».
2. Dire chi lo verifica: chi farà quel lavoro tutti i giorni, non chi ha commissionato il progetto.
3. Includere i casi storti: la commessa annullata, il rapportino compilato senza rete, l’intervento che si sposta di data.
4. Stabilire con quali dati si prova: dati veri e recenti, perché quelli inventati sono sempre più ordinati della realtà.

Le richieste che arrivano durante

Arriveranno, ed è un buon segno: significa che qualcuno sta usando il sistema. Il problema non è riceverle, è classificarle in fretta.

• Errore: quello che c’è non fa quello che era stato concordato. Si corregge subito.
• Dimenticanza: serve al processo e nessuno l’aveva detta. Si valuta se entra, e la data di consegna si muove di conseguenza.
• Miglioramento: rende il lavoro più comodo. Va in elenco, non nella versione in corso.
• Cambio di rotta: l’azienda ha cambiato modo di lavorare. Va discusso a parte, perché non è una richiesta ma un altro progetto.

Senza questa distinzione ogni richiesta diventa urgente e la prima versione non esce mai. È il modo più comune in cui questi progetti si fermano: non per un ostacolo tecnico, ma per accumulo.

Quello che questa guida non copre

Qui si parla di perimetro e sequenza: che cosa entra nella prima versione, che cosa si rimanda e in che ordine. Le prove da fare prima di affidarsi a un sistema tutti i giorni sono un capitolo a sé. E se la funzione da valutare riguarda l’uso di un assistente automatico, i criteri di giudizio sono diversi, perché il risultato non è prevedibile allo stesso modo.