Il Cono dell’Incertezza nel processo delle Stime di Progetto

Gennaio. Il progetto è un’idea in tre slide e qualcuno chiede quanto ci vuole. Dici dodici mesi. Nessuno scrive da nessuna parte che quel numero, in quel momento, vuol dire fra tre mesi e quattro anni — e non perché tu sia impreciso: perché a gennaio non esiste nessuna informazione capace di restringerlo. È quello che il cono dell’incertezza descrive, e che quasi nessuno riporta per intero.

Il Cono dell’Incertezza serve a dire questa cosa senza sembrare evasivi. È la forma dell’errore possibile mentre un progetto avanza: larga all’inizio, stretta alla fine. Quasi tutti la conoscono. Quasi nessuno riporta le due cose che la rendono utile.

Quanto è larga, davvero, la bocca del cono

Nella fase iniziale, prima che i requisiti esistano, la stima porta un fattore quattro in tutte e due le direzioni. Non «più o meno qualche settimana»: da un quarto a quattro volte.

Fatti il conto sui tuoi dodici mesi e viene fuori un intervallo che nessuno vuole sentire in riunione: da tre mesi a quattro anni. Sembra inutilizzabile, ed è esattamente il punto: a gennaio quella è l’informazione vera, e il numero secco di dodici mesi non lo è.

Il fattore quattro non è pessimismo. È il modo in cui si compongono le cose che a gennaio non sai: chi sarà nella squadra, se le integrazioni sono due o cinque, se il cliente per «report» intende un foglio o una piattaforma. Ognuna di quelle è un moltiplicatore, e i moltiplicatori non si mettono in fila: si moltiplicano fra loro.

Da dove viene il cono, e chi gli ha dato il nome

L’idea è molto più vecchia del software. La base concettuale nasce alla fine degli anni Cinquanta fra gli ingegneri di costo dell’industria chimica, che avevano già capito che un preventivo vale secondo lo stadio in cui lo fai.

I numeri — il fattore quattro sopra e sotto — li pubblica Barry Boehm nel 1981, in Software Engineering Economics. Il nome arriva ancora dopo: lo usa Steve McConnell nel 1997, in Software Project Survival Guide, ed è quello che è rimasto.

Vale la pena saperlo per un motivo pratico: la metà delle discussioni sul cono finisce in «è roba da sviluppo software». Non lo è mai stata. È una proprietà delle stime fatte sotto incertezza, e i primi ad accorgersene costruivano impianti.

La parte che quasi nessuno riporta: non si chiude da solo

Questa è la frase che cambia l’uso di tutta l’idea. L’incertezza tende a diminuire lungo il progetto, ma quella diminuzione non è garantita. Il cono si restringe per le ricerche fatte e per le decisioni prese — quelle che tolgono di mezzo le fonti di variabilità. Non perché passa il tempo.

Detta al contrario: il cono disegnato sui libri è il caso migliore. È il più stretto a cui l’incertezza possa arrivare se il progetto fa il suo lavoro. Non è una promessa che ti viene fatta all’inizio.

Quando resta una nuvola

Lascia aperte le scelte — il perimetro ancora fluido al quarto mese, l’integrazione «da confermare», la squadra non ancora nominata — e la forma non è un cono. È una nuvola: la stessa larghezza, dall’inizio alla consegna.

E qui c’è la diagnosi che vale il pezzo. Se le stime non migliorano, il problema non è che le stime non convergono: è che non converge il progetto, che non elimina abbastanza variabilità da rendere possibile una stima migliore.

La differenza non è accademica, è su chi ricade la colpa. Nella lettura sbagliata si cambiano gli estimatori, si chiedono stime «più serie», si aggiunge un foglio di calcolo. Nella lettura giusta si va a vedere quali decisioni non sono state prese, e le si prende.

Che cosa restringe davvero il cono dell’incertezza

Non il calendario, non le riunioni di avanzamento, non un secondo giro di stime fatto con le stesse informazioni del primo. Lo restringono le cose che eliminano una possibilità:

• Una decisione di perimetro. «Le integrazioni sono due, non cinque.» Da sola taglia via un ramo intero di scenari.
• Un fornitore scelto. Finché è una gara, la durata della fornitura è un intervallo; alla firma diventa una data con una penale sotto.
• Un prototipo che ha funzionato. È la forma più economica di certezza che esista: costa due settimane e cancella la domanda «si può fare?».
• Una squadra nominata. Non «tre sviluppatori» ma tre persone con un nome: la produttività smette di essere una media di settore.

Il criterio per riconoscerle è semplice: dopo quella cosa, qualcosa che prima era possibile non lo è più. Se dopo una riunione tutti gli scenari sono ancora in piedi, il cono non si è mosso di un millimetro, per quante ore siate stati seduti.

Come si usa in riunione, senza sembrare evasivi

Il cono è uno strumento di conversazione prima ancora che di calcolo. Tre frasi, e la conversazione cambia di segno.

1. Dai l’intervallo, non il punto. «Fra sei e ventiquattro mesi» non è una scappatoia: è la larghezza del cono nel punto in cui siamo.
2. Di’ che cosa lo restringerebbe. «Decidete se le integrazioni sono due o cinque e il tetto scende di un terzo.» Così l’incertezza diventa una decisione loro, non una tua debolezza.
3. Fissa quando lo dirai di nuovo. Una data di riemissione, con un numero più stretto. Senza, il primo numero resta la promessa per sempre.

E una regola che vale la pena tenere: non dare mai un intervallo senza dire che cosa lo chiuderebbe. Un intervallo da solo sembra reticenza; un intervallo con accanto la decisione che lo stringe è una proposta.

Tenere la storia delle stime, dentro il piano

Il cono diventa verificabile solo se conservi i numeri che hai detto mentre si restringeva. In Microsoft Project il posto giusto sono le previsioni numerate: ogni volta che l’intervallo si stringe perché è stata presa una decisione vera, salvi il piano in una previsione libera.

Sei mesi dopo hai le versioni una accanto all’altra e puoi vedere il cono che si chiude — oppure che non si chiude, e quella è la scoperta più utile delle due. Come si tengono e con che cosa si confrontano sta in Aggiornare un piano in Microsoft Project.

Senza quelle fotografie l’unico numero sopravvissuto è l’ultimo, e la discussione su perché il primo era sbagliato si fa a memoria. Non è una discussione che si vince a memoria.

Domande frequenti

Il cono dell’incertezza vale solo per il software?

No, e la sua storia lo dimostra: la base concettuale nasce fra gli ingegneri di costo dell’industria chimica alla fine degli anni Cinquanta, molto prima che qualcuno lo applicasse ai progetti software. Vale per qualunque stima fatta sotto incertezza.

Il cono si restringe da solo con il passare del tempo?

No, ed è l’errore più comune. Si restringe per le decisioni prese e le ricerche fatte, cioè per le cose che eliminano possibilità. Un progetto che tiene tutte le opzioni aperte arriva alla consegna con la stessa incertezza del primo giorno.

Che differenza c’è fra il cono e la nuvola?

Il cono è il caso migliore, la nuvola è quello che succede quando la variabilità non viene eliminata. La nuvola non dice che gli estimatori sono scarsi: dice che il progetto non sta convergendo, e il posto dove intervenire è lì, non nel foglio delle stime.

Come si comunica un intervallo così largo senza perdere credibilità?

Accompagnandolo sempre con due cose: che cosa lo restringerebbe e quando lo riemetterai. Un intervallo da solo sembra reticenza. Un intervallo con accanto la decisione che lo chiude è una proposta, e sposta la conversazione su quello che il committente può fare per avere una data.

Il cono giustifica una stima sbagliata?

Al contrario: la rende verificabile. Se hai dichiarato l’intervallo e la data di riemissione, a consuntivo si controlla se il risultato ci stava dentro e se il restringimento è avvenuto quando doveva. È molto più scomodo di un numero secco, ed è per questo che funziona.