# Perché spendiamo i primi giorni a mettere in dubbio il tuo progetto

> Domande scomode, ricerca dell'MVP, funzioni tagliate: come funziona la fase di analisi di fattibilità di un progetto software, perché riduce il rischio e protegge il budget, e tre progetti andati meglio dopo essere stati rimpiccioliti.

- **URL**: https://www.spsproject.net/perche-spendiamo-i-primi-giorni-a-mettere-in-dubbio-il-tuo-progetto/
- **Autore**: Anna De Carolis
- **Pubblicato**: 04/08/2026
- **Categorie**: Sviluppo Software

---

La prima settimana di lavoro insieme, di solito, delude un po’. Ti aspetti entusiasmo e ti ritrovi qualcuno che ti chiede perché quella funzione ti serve, chi la userà davvero e cosa succede se non la facciamo. Non è scetticismo per posa: è il lavoro. L’**analisi di fattibilità** di un progetto software serve esattamente a questo, a mettere in dubbio l’idea finché non resta solo la parte che regge. È la fase che costa qualche giorno e che, quando funziona, ne fa risparmiare mesi.

Non è una cosa che facciamo per rallentare. È che l’alternativa la conosciamo bene: si parte subito, si scrive codice per quattro mesi, e la domanda scomoda arriva alla fine, quando costa dieci volte tanto.

## Cosa succede davvero nei primi giorni

Nei primi incontri non parliamo di tecnologie. Non serve sapere se sarà un’app, un gestionale o una web app: sono risposte, e le risposte vengono dopo. Quello che ci interessa è capire il problema con abbastanza precisione da poterlo riconoscere quando lo vediamo risolto.

In pratica ascoltiamo come lavora l’azienda oggi — anche [nelle giornate in cui va storto tutto](https://www.spsproject.net/perche-iniziamo-ogni-progetto-con-una-giornata-storta/) — e scriviamo tre cose: qual è il problema, chi lo subisce, quanto costa lasciarlo com’è. Poi, solo poi, si guarda cosa si può costruire.

> Se un progetto non sopravvive a una settimana di domande, non sarebbe sopravvissuto a sei mesi di sviluppo. Meglio scoprirlo adesso.

## Le quattro domande che facciamo prima di qualsiasi preventivo

Sono sempre le stesse quattro, e sembrano banali finché non provi a rispondere.

**Chi userà questa cosa, con nome e cognome?** Non «l’ufficio acquisti»: la persona. Se non riusciamo a identificarla, il software verrà usato male o non verrà usato. Capita più spesso di quanto sembri che la funzione più richiesta sia per un ruolo che nessuno ha ancora assunto.

**Cosa succede se non la facciamo?** È la domanda che divide le funzioni vere da quelle decorative. Se la risposta è «continuiamo come adesso» e nessuno si scompone, quella funzione può aspettare. Se la risposta è «si blocca la produzione», siamo nel cuore del progetto.

**Come si fa oggi questa cosa?** Ogni processo esiste già, anche quando esiste sotto forma di un file Excel che si passano in tre e di una telefonata alle sette di sera. Guardare il metodo attuale dice più di qualsiasi elenco di requisiti, perché mostra i passaggi che le persone hanno inventato per farlo funzionare.

**Come faremo a sapere che ha funzionato?** Serve un segnale osservabile, deciso prima: le ore di riconciliazione dei dati che scendono, gli ordini sbagliati che spariscono, la pratica che si chiude in giornata. Senza un criterio scritto all’inizio, alla fine si discute a sensazione — e a sensazione vince chi parla più forte.

## La ricerca dell’MVP: la versione più piccola che risolve il problema

Quando le quattro risposte ci sono, il lavoro cambia direzione: da «cosa potremmo fare» a «qual è la cosa più piccola che risolve davvero il problema». È quello che in gergo si chiama MVP, versione minima utilizzabile, e la parola minima è la parte che disturba di più. Non è una versione al risparmio, e non è un prototipo da buttare: è il progetto ridotto all’osso che deve funzionare in produzione, con persone vere che ci lavorano dentro.

Il criterio che usiamo è semplice: se togliendo una funzione il problema resta risolto, quella funzione esce dalla prima versione. Non muore — finisce in una lista, con la data in cui la riguarderemo. Quasi sempre, quando arriva quel giorno, metà della lista non interessa più a nessuno: il software vero, nel frattempo, ha mostrato dove serviva davvero intervenire.

Questo è anche il momento in cui capita di scoprire che la tecnologia immaginata all’inizio non è quella giusta — succede spesso con le app, tanto che ci abbiamo scritto un articolo su [quando un’app non serve e cosa serve al posto suo](https://www.spsproject.net/quando-non-ti-serve-unapp-e-cosa-ti-serve-davvero/).

## Le funzioni che togliamo (e che nessuno rimpiange)

Ci sono categorie di richieste che, nell’**analisi di fattibilità software**, saltano fuori quasi ogni volta.

La prima è la **dashboard con tutto**. Grafici, filtri, indicatori: bella da vedere in demo, guardata per due settimane e poi mai più, perché le decisioni vere si prendono su tre numeri che si possono mandare per mail il lunedì mattina.

La seconda è il **caso limite che capita una volta l’anno**. Gestirlo dentro al software può costare quanto un terzo del progetto. Gestirlo a mano costa venti minuti, una volta l’anno. Si scrive nella procedura e si va avanti.

La terza è la **configurabilità totale**: rendere tutto parametrico «così poi lo cambiamo da soli». Nella pratica nessuno lo cambia mai, e intanto il software è diventato più complicato da usare per tutti.

La quarta è l’**integrazione con il sistema che state per cambiare**. Se il gestionale verrà sostituito fra un anno, collegarlo adesso significa pagare due volte lo stesso lavoro.

![Progetto ridotto all'essenziale dopo l'analisi di fattibilità software: web app usata dal telefono in cantiere](https://www.spsproject.net/wp-content/uploads/2026/08/corpo-analisi-fattibilita-software-cantiere.jpg)

## Tre progetti che sono andati meglio dopo essere stati rimpiccioliti

Gli esempi che seguono sono situazioni ricorrenti, raccontate senza nomi perché il punto non è il caso singolo ma lo schema, che si ripete quasi identico.

**Il portale clienti diventato una pagina sola.** La richiesta iniziale era un’area riservata completa: profilo, storico, documenti, messaggistica, notifiche. Alle quattro domande è emerso che i clienti chiamavano per una cosa sola, sapere a che punto era il loro ordine. La prima versione è stata una pagina con lo stato dell’ordine e la data prevista. Le telefonate sono calate subito; il resto del portale, tre anni dopo, non è mai stato chiesto.

**Il gestionale su misura che è rimasto un modulo.** Un’azienda voleva rifare tutto da zero perché il software esistente «non andava bene». Guardando il lavoro reale, il problema stava in un punto solo: la preparazione delle offerte, fatta a mano ricopiando dati. Abbiamo costruito quel pezzo e lo abbiamo collegato al gestionale esistente, che per tutto il resto funzionava. Costo e rischio di un decimo rispetto alla sostituzione totale.

**L’app che è diventata un sito da telefono.** Serviva ai tecnici in cantiere per registrare gli interventi. Un’app significava due sviluppi, gli store, gli aggiornamenti e — il vero ostacolo — convincere le persone a installarla. È diventata una web app che si apre dal browser del telefono, con un collegamento sulla schermata iniziale. Nessuno si è accorto della differenza, e i mesi di sviluppo risparmiati sono finiti nella parte che contava: la sincronizzazione quando il cantiere è senza campo.

## Cosa ci guadagni: rischio più basso, budget protetto

Il vantaggio non è filosofico, è aritmetico. Un progetto piccolo si consegna prima, e un progetto consegnato prima comincia prima a restituire qualcosa. Ma soprattutto: le cose che non hai costruito non le devi mantenere, correggere, aggiornare, spiegare a chi arriva nuovo.

Poi c’è la parte del budget. Quando la prima versione è piccola, la quota di soldi esposta all’errore è piccola. Se qualcosa non va come previsto — e ogni tanto succede — te ne accorgi dopo otto settimane e non dopo otto mesi, con la maggior parte del budget ancora disponibile per correggere la rotta. È l’esatto contrario di quello che accade quando [un progetto parte senza un obiettivo fermo](https://www.spsproject.net/i-progetti-software-non-falliscono-alla-fine-falliscono-allinizio/) e si gonfia a ogni riunione.

> Il modo più affidabile per non sforare un budget non è stimare meglio. È avere meno cose da stimare.

C’è anche un effetto meno ovvio: le priorità cambiano da sole. Dopo tre mesi di software in uso, la lista delle funzioni «indispensabili» scritta all’inizio è quasi sempre diversa da quella che scriveresti oggi. Averla congelata in un contratto di sei mesi ti avrebbe fatto costruire la lista sbagliata.

## Quando l’analisi dice di non farlo

Va detto anche questo, altrimenti il discorso è comodo solo per noi. Ogni tanto la fase di validazione porta a una conclusione scomoda: il progetto non va fatto. Perché il problema si risolve con una procedura invece che con del codice, perché il risparmio non ripaga l’investimento, o perché l’azienda sta per cambiare qualcosa a monte e conviene aspettare sei mesi.

È il risultato più difficile da comunicare, e paradossalmente il più utile: un lavoro non fatto è denaro che resta in cassa. In altri casi la conclusione è «sì, ma non adesso e non tutto»: si parte dal pezzo che fa più male, si guarda come va, si decide il resto con dati veri invece che con previsioni.

Se stai valutando un progetto e vuoi capire da dove si comincia, la [fase di analisi e validazione](https://www.spsproject.net/consulenza-e-analisi-progetti/) è il momento in cui farsi queste domande costa poco. Dopo, per farle, si paga in mesi. Puoi anche partire dal quadro completo di [quello che facciamo](https://www.spsproject.net/servizi/), ma il consiglio resta lo stesso: prima il dubbio, poi il codice.

## Domande frequenti

### Che cos'è l'analisi di fattibilità di un progetto software?

È la fase iniziale in cui, prima di scrivere codice, si verifica che il progetto abbia senso: qual è il problema reale, chi lo subisce, quanto costa lasciarlo com'è e da cosa si capirà che è stato risolto. Serve a mettere in dubbio l'idea finché non resta la parte che regge davvero, ed è quello che evita di scoprire i problemi a sviluppo finito.

### Quanto dura la fase di validazione iniziale?

Nella maggior parte dei progetti si parla di giorni, non di mesi: qualche incontro per osservare come si lavora oggi, il tempo di scrivere obiettivo, vincoli e priorità e di definire la prima versione. È tempo che rientra quasi sempre, perché riduce le funzioni da costruire e le riscritture in corsa.

### Cos'è un MVP e perché conviene partire da lì?

L'MVP è la versione più piccola del software che risolve comunque il problema, usata in produzione da persone vere. Non è un prototipo da buttare né una versione al risparmio: è il progetto ridotto all'osso. Conviene perché si consegna prima, espone meno budget all'errore e fa emergere le priorità vere, che dopo tre mesi di uso sono quasi sempre diverse da quelle scritte all'inizio.

### Quali funzioni vengono tagliate più spesso in fase di analisi?

Le dashboard con tutti i grafici possibili, i casi limite che capitano una volta l'anno e si gestiscono a mano in venti minuti, la configurabilità totale che poi nessuno usa e le integrazioni con sistemi che l'azienda sta per sostituire. Non vengono cancellate: finiscono in una lista da rivedere, e spesso a quel punto metà non interessa più.

### Può capitare che l'analisi consigli di non fare il progetto?

Sì, e succede. A volte il problema si risolve cambiando una procedura invece che scrivendo software, a volte il risparmio non ripaga l'investimento, a volte conviene aspettare perché l'azienda sta per cambiare qualcosa a monte. È la risposta più scomoda da dare, ma un lavoro non fatto è denaro che resta in cassa.

---

Fonte: https://www.spsproject.net/perche-spendiamo-i-primi-giorni-a-mettere-in-dubbio-il-tuo-progetto/ — SpsProject