Non chiedermi un preventivo. Dimmi il tuo budget

"Quanto costa fare un'app per gestire i miei ordini?" Chiedere un preventivo software senza contesto produce quasi sempre una semplificazione: il costo dipende da decisioni che spesso emergono solo quando si analizzano davvero processi, eccezioni, integrazioni e vincoli.

Se invece mi dici quanto hai da investire, la conversazione diventa più utile: possiamo decidere insieme cosa costruire prima, cosa rimandare, quali trade-off accetti e come ridurre il rischio di sorprese.

È un modo più realistico di lavorare sul software.

Perché un preventivo “al buio” è fragile

Non è chiaro cosa stai comprando (spesso nemmeno per te)

Tu hai in testa un problema da risolvere. Tra problema e soluzione, però, ci sono molte scelte: permessi, eccezioni, integrazioni, flussi alternativi, requisiti non esplicitati.

“Gestione ordini” può voler dire:

• listino semplice o logiche di pricing con eccezioni (a volte il software finisce per codificare il caos);
• integrazione con contabilità o export manuale;
• portale clienti o gestione interna;
• reportistica base o avanzata.

Ogni risposta sposta costi e tempi. E molte risposte emergono durante l’analisi, non prima.

È lo stesso motivo per cui le stime nel software sono spesso imprecise: non è un lavoro “a pezzi indipendenti”, è esplorazione guidata.

Il preventivo fisso incentiva comportamenti difensivi

Quando il contratto è “scope fisso, prezzo fisso”, le parti tendono a proteggersi:

• il fornitore aggiunge margine “di sicurezza” oppure sottostima e recupera dopo con change request;
• il cliente cerca di infilare tutto “tanto era incluso”.

Non sempre succede, ma succede abbastanza spesso da rendere questo modello rischioso nei progetti dove i requisiti non sono già cristallizzati.

Perché parlare di budget migliora la qualità delle decisioni

Quando dici “ho 30.000 euro”, smettiamo di discutere di un software ideale e iniziamo a discutere di un software realistico.

1) Le priorità diventano visibili

Con un vincolo chiaro, possiamo separare:

• Must have: senza questi elementi non risolvi il problema.
• Should have: migliorano molto, ma si possono rimandare.
• Nice to have: utili, ma non determinanti.

Senza un vincolo, tutto tende a diventare “must”. Con un vincolo, il prodotto prende focus.

2) Posso proporti l’approccio adatto alla fascia

Un progetto da 10K e uno da 40K possono risolvere lo stesso problema, ma con strumenti diversi e con compromessi diversi. Come ho spiegato nell’articolo su preventivi 5K vs 50K, sono “prodotti” differenti.

Se non so il budget, rischio di proporti:

• una soluzione troppo rigida (che poi esplode quando chiedi personalizzazioni),
• oppure una soluzione sovradimensionata (che ti fa spendere senza ottenere valore proporzionato).

3) Possiamo essere espliciti sui limiti (ed evitare sorprese)

Esempio di conversazione utile: “Con 15K facciamo versione 1 con queste 3 funzionalità core, solide e usabili. La reportistica avanzata e il portale clienti sono fase 2, stimata 10–15K.”

Questo è più onesto di un “ti costa X” senza chiarire cosa resta fuori.

“Se ti dico il budget, lo userai tutto”

Obiezione legittima. E infatti serve una regola chiara: il budget non deve diventare il prezzo. Deve diventare il vincolo.

In pratica:

• Prima definiamo un obiettivo minimo misurabile (cosa deve fare la v1 per essere un successo).
• Poi costruiamo una roadmap di opzioni: cosa aggiungere se resta budget, cosa rimandare se il budget stringe.
• Rendiamo trasparente cosa stiamo comprando: sviluppo, test, deploy, documentazione minima.

Nel software, “cose da fare” ce ne sono sempre più del budget disponibile. Il punto è spendere sulle cose con più ritorno.

Tre regole operative per farla funzionare davvero

1. Definisci un minimo non negoziabile. Se il prodotto non riesce a fare X (core flow), non ha senso costruire il resto.
2. Congela lo scope per blocchi brevi. Due–tre settimane alla volta: consegni, misuri, poi decidi cosa fare nel blocco successivo. È coerente con l’approccio lancia, ascolta, migliora.
3. Metti nel “minimo” anche continuità e controllo. Repo tuo, accessi tuoi, deploy ripetibile, istruzioni per avvio in locale. Senza questo, stai comprando velocità oggi e fragilità domani.

Come funziona in pratica

Fase 1: problema + vincolo

“Questo è il problema, questo è il budget.” Una call focalizzata su flussi reali, eccezioni, integrazioni, utenti.

Fase 2: piano, non lista infinita

Una proposta che esplicita:

• cosa include la v1,
• cosa rimane fuori,
• trade-off accettati,
• tempi e milestone,
• cosa serve da te (dati, accessi, decisioni).

Fase 3: iterazioni brevi

Ogni 2–3 settimane qualcosa di funzionante. Le priorità si aggiustano con costi visibili, non a fine progetto.

Fase 4: il budget finisce, il prodotto resta in piedi

Obiettivo: arrivare a fine budget con un prodotto utilizzabile, non con “tante cose a metà”.

Il budget non è solo un limite: è uno strumento di focus

La maggior parte dei progetti che vanno bene non sono quelli con budget infinito. Sono quelli con:

• budget chiaro,
• obiettivi misurabili,
• priorità stabili a blocchi brevi,
• scelte esplicite su cosa rimandare.

Questo riduce sprechi, rework e conflitti. E rende molto più probabile arrivare a qualcosa che funziona davvero per il business.