Indice
C’è una domanda che tormenta da sempre chi guida team tech: “Quando sarà pronto?”
Sembra una domanda semplice. Ma dietro quelle tre parole si nasconde uno dei più grandi fraintendimenti nella storia dell’ingegneria del software.
Perché, diciamolo chiaramente: non è il problema delle stime ad essere irrisolvibile, è la domanda a essere sbagliata.
Lo spiegano bene due veterani dell’ingegneria moderna in un confronto che vale più di un corso di project management: Kevin Rutherford e Kent Beck.
La loro tesi è provocatoria ma lucidissima: “Il problema non è stimare. È capire cosa ti stanno davvero chiedendo quando ti chiedono una stima.”
E, aggiungo io, è proprio qui che si gioca la differenza tra un’azienda tecnologica che cresce in modo sano e una che finisce intrappolata nel micro-management del calendario.
Il problema non è la stima, è la domanda
Quando qualcuno chiede “quando sarà pronto?”, in realtà può voler dire almeno cinque cose diverse:
- “Posso prometterlo a un cliente per questa data?”
- “Quanto budget devo stanziare?”
- “Mi serve capire se è più grande di questo altro progetto.”
- “Quanto tempo ci metterete per darmi una demo?”
- “Devo scegliere tra due priorità e mi serve un criterio oggettivo.”
Il punto è che ogni domanda ha un bisogno diverso, ma nella maggior parte dei casi la risposta viene data sempre nello stesso modo: una data sul calendario.
E da lì in poi, quella che era una stima diventa automaticamente un impegno, anche se nessuno lo ha detto esplicitamente.
Ecco dove nascono la tensione, la frustrazione e la spirale di sfiducia reciproca tra IT e business.
Un buon leader tecnico o un vero Tech CEO deve imparare a interrompere questo riflesso automatico.
Prima di dare una data, dovrebbe chiedere:
“Chi vuole sapere questa cosa, e per prendere quale decisione?”
È una domanda apparentemente banale, ma cambia tutto.
Perché trasforma la conversazione da “quanto ci mettiamo” a “cosa dobbiamo decidere”.
E le decisioni si prendono sui range di possibilità, non sulle illusioni di certezza.
Precisione e accuratezza: la differenza tra realtà e fiction
Una volta, durante un audit tecnologico in Axelerant, un manager mi mostrò con orgoglio un Gantt in Microsoft Project: decine di righe, durate precise al giorno, percentuali di completamento con tre decimali.
“Vedi? Siamo al 52,5% di avanzamento”, mi disse.
Quel numero era bellissimo. Peccato che fosse anche completamente inventato.
La verità è che la precisione numerica in contesti di incertezza radicale come lo sviluppo software è solo una forma sofisticata di autoinganno.
Un progetto nuovo, con requisiti parziali, stakeholder multipli e scoperte in corso, non può essere misurato come una catena di montaggio.
Ogni feature apre altre feature. Ogni bug rivela un pezzo di architettura nascosta. Ogni test cambia la percezione del valore.
È un processo frattale, che cresce mentre lo osservi.
Proprio come cercare di pesare un cucciolo di elefante: il tempo che impieghi a misurarlo basta perché nel frattempo diventi più grande.
Perché le stime falliscono (e perché continuano a servirci)
Le stime falliscono non perché siamo incapaci di farle bene, ma perché ci illudiamo che debbano dire “quando finiamo”.
In realtà, nella maggior parte dei casi chi le chiede vuole solo capire “quanto è grande”.
È una domanda di proporzione, non di predizione.
Il Product Manager vuole sapere se qualcosa vale un mese o un anno.
Il CEO vuole capire se serve assumere o esternalizzare.
L’investitore vuole valutare la scalabilità e il rischio.
Ma nessuno ha davvero bisogno che tu dica “sarà pronto il 14 novembre”.
Quella data serve solo a rassicurare, non a decidere.
Il problema è che nel momento in cui dai un numero, anche solo come stima informativa, quel numero diventa automaticamente una promessa implicita.
E quando, inevitabilmente, la realtà si discosta da quella promessa, non importa quanto poco: la fiducia si incrina.
E a quel punto il team si chiude, comincia a difendersi, e la distanza tra IT e business aumenta.
Una nuova grammatica per stimare (e decidere meglio)
Ciò che serve non è “aggiustare” le stime, ma riscrivere la grammatica del modo in cui le usiamo.
Nel metodo GamePlan, usiamo tre concetti fondamentali per rimettere ordine:
- Target – è un obiettivo di mercato o di business. Non si negozia nel tempo, si negozia nel contenuto. Se il lancio è a settembre, allora il lavoro è ridurre lo scope per centrare la data, non fingere che bastino meno settimane.
- Commitment – è una promessa. Va fatta solo dopo che hai capito bene scope, rischi e dipendenze.
- Estimate – è un’intervallo probabilistico, non una data. Serve a decidere, non a giurare.
Il primo errore che vediamo in quasi tutte le aziende tech che analizziamo durante i GamePlan Check Up è la confusione tra questi tre livelli.
Una stima viene comunicata come se fosse un impegno, e da lì inizia l’effetto domino di stress e overwork.
Le stime come strumento di allineamento
In Axelerant, quando conduciamo un GamePlan Workshop con team che hanno perso la fiducia nel processo di delivery, partiamo sempre da un esercizio:
“Classifichiamo tutto quello che avete in backlog in tre bucket.”
- Bucket 1: Piccolo e tattico. Se stimare costa più che fare, non stimare. Fai e misura dopo.
- Bucket 2: Simile a qualcosa che conosciamo. Usa i dati storici e dai un range realistico (“2–3 sprint, 6–8 settimane”).
- Bucket 3: Ignoto. Non stimare affatto. Fai un time-boxed spike di qualche giorno per ridurre l’incertezza, poi ne riparliamo.
Questo semplice esercizio cambia il clima della riunione.
Le persone smettono di difendersi. Il Board inizia a capire che non tutte le domande meritano una risposta immediata, e che a volte la risposta più onesta è: “Non lo sappiamo ancora, ma possiamo scoprirlo”.
Collegare le stime al linguaggio del business
Il vero salto di qualità arriva quando smettiamo di parlare in settimane e cominciamo a parlare in impatti economici.
È qui che entra in gioco la logica del GamePlan.
Ogni stima può (e deve) essere collegata a una Key Initiative Plan, cioè a un’iniziativa strategica con obiettivi e metriche chiave.
E quelle metriche non sono “giorni uomo”, ma indicatori di valore:
- Tempo medio di rilascio = velocità di creazione di valore.
- Bug per release = costo di rework e rischio reputazionale.
- Uptime / MTTR = affidabilità percepita dai clienti.
- Costo dei problemi irrisolti = margine nascosto che puoi recuperare.
Quando il Board comincia a leggere le stime in questi termini, tutto cambia.
Il dialogo tra business e IT non è più “quando finiamo?”, ma “cosa otteniamo se investiamo qui invece che lì?”.
Le stime tornano a essere ciò che dovevano essere all’inizio: uno strumento per decidere, non per punire.
Conclusione: la stima è una relazione, non un numero
La verità è che non possiamo “aggiustare” le stime nel senso tradizionale del termine.
Non esiste una formula magica per indovinare il futuro.
Ma possiamo migliorare radicalmente il modo in cui le usiamo.
Possiamo imparare a:
- Chiarire la domanda prima di dare la risposta;
- Usare range probabilistici invece di date fisse;
- Aggiornare le stime come parte di un processo continuo;
- E soprattutto collegarle a decisioni reali di business.
In fondo, stimare non è mai stato un problema di numeri.
È sempre stato un problema di conversazioni.
E come dico spesso nei nostri GamePlan Advisory, una stima onesta vale più di una promessa perfetta.
Perché costruisce fiducia, e la fiducia, non le date, è ciò che tiene insieme i team che fanno vera innovazione.
FAQ
1. Come posso introdurre questo approccio in un team Agile?
Inizia nei retrospettivi o nei planning meeting. Ogni volta che qualcuno chiede “quanto ci mettiamo?”, chiedi tu “per decidere cosa?”.
Distinguere tra target, commitment e stima può diventare una micro-abitudine culturale.
Poi integra i checkpoint di revisione ogni 2 sprint: serve più al business che al team.
2. Come comunico ai manager che le stime sono probabilistiche senza sembrare evasivo?
Usa un linguaggio economico. Parla di intervalli di confidenza e rischi di investimento, non di “incertezza tecnica”.
Esempio: “Possiamo consegnare in 8 settimane con l’80% di confidenza, ma serve un 20% di buffer per i rischi noti.”
Le persone che ragionano in termini di business capiscono i rischi, non le linee di codice.
3. E se il board vuole comunque una data precisa?
Dalla pure, ma definisci insieme cosa significa “successo” se la data cambia.
Le organizzazioni mature accettano che la data è un target, non un vincolo.
L’obiettivo reale è consegnare valore in modo sostenibile, non rispettare un numero scritto tre mesi prima in una slide.
4. Come collegare il processo di stima al GamePlan?
Ogni stima importante deve entrare in un Key Initiative Plan.
Lì puoi legarla a metriche di outcome (tempo di rilascio, stabilità, impatto).
Durante le Sessioni GamePlan, rivedi range, assunti e rischi — non solo progressi.
Questo è ciò che chiamiamo “allineamento dinamico”.
5. Le stime hanno ancora senso con l’AI e l’automazione?
Sì, ma cambiano natura. L’automazione riduce il lavoro ripetibile, ma aumenta il lavoro ignoto: valutare, integrare, sperimentare.
Quindi la stima serve più per prioritizzare e testare ipotesi che per pianificare.
Nel mondo AI-first, la vera stima è: “quanto ci costa scoprire se funziona?”
Vuoi capire come rendere le tue stime finalmente utili, realistiche e strategiche?
Inizia dal GamePlan Check Up: in poche settimane puoi mappare i tuoi processi, scoprire dove perdi valore e creare un sistema di pianificazione che il Board capisce al volo.
