La domanda che precede il preventivo
Chiedere quanto costa una web app è come chiedere quanto costa un'automobile: la risposta dipende da cosa deve fare. La domanda che porta a una decisione è un'altra: quanto ci costa oggi non averla?
- 01
Contate le ore
Quante ore a settimana il team dedica al processo che volete digitalizzare. Chiedetelo a chi lo fa, non stimatelo: la differenza tra il tempo percepito e quello reale è quasi sempre a favore del secondo.
- 02
Contate gli errori
Quante volte al mese quel processo produce un errore e cosa costa rimediare. È la voce che i calcoli dimenticano e che spesso pesa più delle ore.
- 03
Contate i ritardi
Quanto tempo passa tra una richiesta e la risposta, e cosa vi costa. Un preventivo che arriva in due giorni invece che in due ore ha un effetto commerciale misurabile.
- 04
Sommate su un anno
Quel numero è il costo annuo del problema. Un investimento che si ripaga entro uno o due anni di quel costo è un investimento ragionevole.
Distribuire l'investimento
Un progetto costruito per moduli non costa meno di uno costruito tutto insieme, ma cambia due cose che contano: quando arriva il primo valore, e quanto potete correggere strada facendo.
| Tutto insieme | Per moduli | |
|---|---|---|
| Primo valore in azienda | Alla fine | Dopo il primo modulo |
| Possibilità di correggere | Bassa: le specifiche sono fissate all'inizio | Alta: ogni modulo impara dal precedente |
| Rischio se le priorità cambiano | Alto: avete costruito ciò che serviva un anno fa | Basso: si cambia rotta al modulo successivo |
| Distribuzione della spesa | Concentrata | Distribuita nel tempo |
| Possibilità di fermarsi | Solo perdendo tutto | Dopo qualsiasi modulo, con qualcosa che funziona |
L'ultima riga è quella che riduce di più il rischio: un progetto che si può fermare dopo il primo modulo lasciando in azienda qualcosa che funziona è un progetto che si può iniziare con molta più tranquillità.
Con un budget limitato
Un budget contenuto non impedisce di partire: impone di scegliere. La regola è ridurre lo scopo, mai la qualità di ciò che si costruisce — perché il pezzo costruito male va rifatto e costa il doppio.
| Si può ridurre | Non si deve ridurre |
|---|---|
| Il numero di funzioni della prima versione | L'analisi del processo |
| Il numero di ruoli e permessi | I test prima del rilascio |
| Le integrazioni, tenendone una sola | La qualità della struttura dei dati |
| La reportistica, partendo da report fissi | La formazione di chi lo userà |
| L'esperienza mobile, se non è essenziale | La proprietà del codice e degli accessi |
| La migrazione dei dati storici | L'assistenza nelle prime settimane |
La colonna di destra contiene le cose che, se tagliate, fanno fallire il progetto anche quando il software funziona. Sono anche quelle che vengono tagliate per prime quando il budget stringe.
Il costo che continua
Un errore ricorrente è mettere a budget solo la costruzione. Un software usato genera richieste di miglioramento — è un buon segno — e richiede manutenzione tecnica che non si vede: librerie, sicurezza, compatibilità.
- Manutenzione tecnica: non è opzionale, e a tre anni un sistema non mantenuto diventa intoccabile.
- Evoluzioni funzionali: arrivano da chi lo usa, e sono la prova che serve.
- Infrastruttura: cresce con utenti e dati.
- Supporto: concentrato nei primi mesi, poi cala.
Mettere a budget una quota annuale del progetto per queste voci fin dal primo anno è ciò che distingue un software che invecchia bene da uno che, a tre anni, nessuno osa toccare.