Una software house che realizzava software su commessa sbagliava sistematicamente i preventivi. Un progetto da 20.000 euro costava 30.000 in sviluppo effettivo. Il margine, nei rari casi in cui la stima era centrata, non superava il 10%. Il problema non era la qualità del software — era il modo in cui venivano raccolti i requisiti.
01 / 04
La situazione
- Margine di errore sulle stime del ~50%, quasi sempre in difetto
- Margine operativo al ~10% solo nei casi migliori — spesso in perdita sui progetti
- Requisiti raccolti in modo narrativo, difficili da tradurre in stime precise
- Analisi iniziale di ogni progetto: giorni o settimane di lavoro
02 / 04
Raccolta strutturata dei requisiti
- Un singolo incontro da 3-4 ore per coprire tutto il perimetro funzionale richiesto
- Requisiti raccolti in forma agnostica rispetto all’implementazione — già nella forma giusta per produrre stime precise
03 / 04
Sviluppo incrementale con approvazioni progressive
- Rilascio di componenti al cliente in modo progressivo con approvazione a ogni step
- Eliminazione quasi completa del rischio di interpretazioni divergenti a lavori avanzati
04 / 04
BDD + AI per test automatici
- Requisiti funzionali tradotti con l’AI in comportamenti attesi del software
- Test eseguibili generati automaticamente — codice prodotto ridotto del 70%: il team sviluppava esattamente quello che serviva
I risultati
- 100%stime rispettate (da ~50% di errore sistematico)
- 10% → 40%margine operativo medio
- +30%fatturato nell'anno — con una persona in meno nel team