"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 fatica a rispondere in modo davvero onesto, perché la risposta più corretta molto spesso sarebbe: "dipende da ciò che scopriremo mentre lo facciamo".
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. È come funziona il cervello umano con le stime, indipendentemente dall'onestà di chi stima. Si chiama planning fallacy, cioè la tendenza a sottostimare sistematicamente il tempo necessario, anche quando abbiamo già vissuto casi 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, cioè un breve blocco di esplorazione tecnica: 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 già emerse.
Il costo delle stime sbagliate
Per chi gestisce budget e roadmap, le stime sbagliate hanno un costo molto concreto. Il primo è fatto di promesse non mantenute: dici al cliente che la feature sarà pronta in sei settimane, il team la consegna in quattordici e la credibilità che si brucia è quella dell’azienda intera.
Il secondo costo riguarda la pianificazione. Se ogni progetto sfora del 100 o 200 per cento, come pianifichi il trimestre, come allochi le risorse, come fai previsioni finanziarie? Stai costruendo piani sopra numeri che sai già essere troppo fragili.
Poi c’è la pressione sul team. Quando la stima viene trattata come una deadline, il gruppo taglia qualità per rispettarla: meno test, meno refactoring, più scorciatoie. Il debito tecnico si accumula, e dopo sei mesi tutto procede ancora più lentamente.
Infine arriva il 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. È l’opposto 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 quella feature che ha davvero valore, perché costringe il team a pensare per incrementi e non per monoliti. Chiedi anche quali sono le incognite principali: se il team identifica i rischi prima di stimare, le stime migliorano. Ha senso domandare cosa si può mostrare già tra una settimana, così il focus resta sui progressi tangibili, e di cosa il team ha bisogno per andare più veloce. A volte la risposta non è “più tempo”, ma meno interruzioni, meno meeting e meno cambi di priorità.
È un problema di aspettative
Le stime nel software difficilmente diventeranno precise come in altri ambiti. Tool migliori, processi più rigidi e sviluppatori più esperti aiutano fino a un certo punto: l'incertezza resta intrinseca a questo 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
