Quando aggiungere un numero al cruscotto richiede una release
Ogni gestionale maturo ha un cruscotto: cinque, dieci, venti numeri in prima pagina che dicono come sta andando l’azienda. E ogni gestionale maturo ha la stessa conversazione, una o due volte l’anno: «ci servirebbe anche il totale di…». La risposta tecnica è sempre la stessa — si può fare — e il preventivo pure: analisi, sviluppo, collaudo, rilascio. Per un numero.
Il sintomo non è il numero: è che la richiesta torna
Scrivere un indicatore dentro il codice è una scelta legittima la prima volta. Alla terza richiesta con un contenuto diverso, quello che l’azienda sta pagando non è lo sviluppo dell’indicatore: è il fatto di non poter cambiare idea senza chiamare un fornitore.
E il costo non è il preventivo, è il ritardo. Tra il «ci servirebbe» e il «eccolo» passano settimane, e in quelle settimane la decisione viene presa lo stesso — con i numeri che c’erano. Un cruscotto che non segue il business non viene ignorato: viene creduto.
Questo non significa rendere tutto configurabile
L’errore opposto è altrettanto caro, e più difficile da smontare perché ha l’aria di essere lungimirante. Si costruisce una piattaforma di regole parametriche per casi che nessuno ha mai chiesto, ogni parametro diventa una superficie in cui sbagliare, e dopo un anno nessuno tocca più quella configurazione per paura di rompere qualcosa.
Il confine utile non è tecnico: va fuori dal codice ciò che cambia con il business, resta dentro ciò che cambia con il software. Due domande bastano a collocare quasi tutto. La richiesta è già arrivata più di due volte? Il valore giusto è diverso da sede a sede, da cliente a cliente, da esercizio a esercizio? Se la risposta è sì, è una decisione aziendale scritta nel posto sbagliato. Altrimenti resta nel codice, e va bene così.
Un parametro senza governo è un difetto in attesa
Spostare una decisione dal codice alla configurazione la rende modificabile, ma la toglie anche da tutti i controlli che il codice aveva intorno. È il punto in cui questi progetti falliscono. Quello che va costruito insieme al parametro:
- Validazione all’inserimento. Un indicatore che punta a un dato inesistente va rifiutato nel momento in cui lo si crea, non mostrato come zero in prima pagina. Uno zero in un cruscotto non dice «manca il dato», dice «è zero».
- Provenienza e data di riferimento. Per ogni numero deve essere leggibile da dove arriva e a quando è aggiornato. Due indicatori affiancati ma allineati a date diverse sono un confronto sbagliato presentato come corretto.
- Ordine e identità stabili. Se rinominare una voce ne cambia la posizione o ne perde lo storico, la configurazione è diventata un’altra fonte di instabilità.
- Un’interfaccia guidata, non un file da editare. Se per aggiungere una voce serve la sintassi giusta in un file di testo, la decisione non è uscita dalle mani degli sviluppatori: è solo diventata più fragile.
Il criterio con cui giudicare un fornitore
La domanda da fare non è quanto costa aggiungere un indicatore. È quanti, dei cambiamenti che chiederò nei prossimi tre anni, richiederanno una release. Quella percentuale è la misura più onesta di quanto un sistema sia davvero vostro.