"Quanto ci vuole?" è la domanda più frequente che chi gestisce un prodotto fa al team di sviluppo. Ed è anche la domanda a cui il team non può rispondere onestamente — perché la risposta vera è "non lo sappiamo", e quella risposta non è mai ben accolta.
Le stime sviluppo software sono spesso imprecise. Non per caso — ma per motivi strutturali. E non perché il team è incompetente, pigro, o disonesto. Sono imprecise per motivi intrinseci al modo in cui funziona lo sviluppo software. Capire perché cambia completamente il modo in cui dovresti pianificare.
Perché le stime funzionano peggio di quanto ci aspettiamo
Lo sviluppo software è ricerca, non costruzione
Quando costruisci una casa, sai quanti mattoni servono. Hai fatto case simili prima. I materiali hanno specifiche note. Le incognite sono poche e gestibili.
Lo sviluppo software non funziona così. Ogni feature è diversa dalla precedente. Le incognite emergono durante lo sviluppo, non prima. L'integrazione con quel servizio esterno sembrava semplice nella documentazione ma ha tre casi limite non documentati. Il framework gestisce quel pattern in modo diverso da quello che il team si aspettava. Il requisito "semplice" nascondeva una complessità che nessuno poteva prevedere finché non ci si è messo le mani.
Chiedere una stima precisa per alcune attività di sviluppo software è più simile a un’attività di ricerca che a un lavoro ripetitivo. Può darti un'ipotesi ragionevole, ma le incognite sono l'essenza del lavoro.
L'effetto dell'ottimismo strutturale
Gli sviluppatori, quando stimano, pensano allo scenario migliore. Il percorso senza ostacoli. Il codice che funziona al primo tentativo. L'integrazione che va liscia. I test che passano subito.
Non è disonestà — è come funziona il cervello umano con le stime. Si chiama planning fallacy: tendiamo sistematicamente a sottostimare il tempo necessario per completare un task, anche quando abbiamo esperienza di task simili che hanno richiesto più tempo.
Il risultato: le stime del team sono quasi sempre il lower bound, non la media. Il tempo reale sarà tra 1.5x e 3x la stima, con una distribuzione asimmetrica verso l'alto. Raramente un task finisce in metà del tempo stimato, mentre è molto più comune che richieda molto più tempo del previsto, a volte anche il triplo.
I requisiti cambiano (quasi sempre)
Anche se la stima fosse perfetta al momento in cui viene fatta — e non lo è — i requisiti cambiano durante lo sviluppo. Il PM vede un prototipo e vuole una modifica. Chi guida l'azienda parla con un cliente e cambia priorità. Il designer nota un problema di UX e propone un'alternativa.
Ogni cambio invalida la stima originale. E i cambi sono inevitabili: sono il segno che il team sta imparando man mano che il prodotto prende forma.
Cosa fare al posto delle stime tradizionali
Lavora per incrementi piccoli
Invece di stimare un progetto di 3 mesi, chiediti: qual è la cosa più piccola che possiamo rilasciare in 1-2 settimane che ci dà informazioni utili?
Non un prototipo incompleto. Una versione ridotta ma funzionante che un utente reale può usare. Poi, sulla base di quello che impari, pianifica il passo successivo.
Questo approccio non elimina l'incertezza. La rende gestibile. Invece di una grande scommessa su una stima inevitabilmente incerta, fai piccole scommesse frequenti con feedback rapido.
Usa intervalli, non numeri singoli
Se proprio serve una stima, chiedi un intervallo: "caso migliore, caso realistico, caso peggiore". Il caso migliore è quello che il team ti dice spontaneamente. Il caso realistico è 2x. Il caso peggiore è 3-4x.
Pianifica per il caso realistico, metti a budget il caso peggiore. Se va meglio del previsto, hai guadagnato tempo. Se va peggio, sei coperto.
Misura la velocità storica, non le stime future
Dopo qualche mese di lavoro, il team avrà dati reali su quanto tempo richiedono diversi tipi di task. Usa quei dati. "Task simili a questo in passato hanno richiesto tra 3 e 8 giorni" è molto più affidabile di "penso che ci vogliano 4 giorni".
Non è perfetto, ma è basato sulla realtà invece che sull'ottimismo.
Separa la scoperta dall'esecuzione
Per feature complesse o nuove, aggiungi una fase di spike: un timebox di 2-3 giorni in cui il team esplora il problema, prototipa le parti rischiose, e identifica le incognite. Solo dopo lo spike puoi chiedere una stima — e sarà enormemente più accurata perché le incognite principali sono state scoperte.
Il costo delle stime sbagliate
Per chi gestisce budget e roadmap, le stime sbagliate non sono solo un fastidio. Sono un costo reale.
Promesse non mantenute. Dici al cliente che la feature sarà pronta in 6 settimane. Il team la consegna in 14. La credibilità è bruciata — non del team, dell'azienda.
Pianificazione impossibile. Se ogni progetto sfora del 100-200%, come pianifichi il trimestre? Come allochi le risorse? Come fai previsioni finanziarie? Stai costruendo piani su numeri che sai essere falsi.
Pressione sul team. Quando la stima diventa una deadline, il team taglia qualità per rispettarla. Meno test, meno refactoring, più scorciatoie. Il debito tecnico si accumula, e tra sei mesi tutto è ancora più lento.
Feature bloat. Senza la disciplina degli incrementi piccoli, la tendenza è pianificare feature grandi e complete. Se qualcosa va storto — e succede spesso — hai investito mesi in qualcosa di inutilizzabile perché incompleto. È esattamente il contrario dell'approccio lancia prima, migliora dopo.
La conversazione che dovresti avere col tuo team
Smetti di chiedere "quanto ci vuole" e inizia a chiedere:
- "Qual è la versione più piccola di questa feature che ha valore?" Forza il team a pensare in incrementi, non in monoliti.
- "Quali sono le incognite principali?" Se il team identifica i rischi prima di stimare, le stime migliorano.
- "Cosa possiamo mostrare tra una settimana?" Mantiene il focus su progressi tangibili.
- "Di cosa avete bisogno per andare più veloci?" A volte la risposta non è più tempo — è meno interruzioni, meno meeting, meno cambi di priorità.
Non è un problema di sviluppatori. È un problema di aspettative.
Le stime nel software difficilmente diventeranno precise come in altri ambiti. Non con tool migliori, non con processi più rigidi, non con sviluppatori più esperti. L'incertezza è intrinseca al tipo di lavoro.
Quello che può migliorare è come gestiamo quell'incertezza. Incrementi piccoli, feedback rapido, aspettative realistiche, e la volontà di adattarsi man mano che impariamo.
Le aziende che lo capiscono rilasciano più spesso, con meno sorprese, e con team più sereni. Quelle che continuano a chiedere stime precise e a trattarle come promesse finiscono molto spesso per creare aspettative che poi è difficile rispettare.
Simone Giusti
Consulente software strategico
