Non fingiamo certezza dove non c'è.

In ogni progetto c'è una parte che conosciamo bene e una parte che conosceremo soltanto costruendo. Non è un difetto di preparazione: è come sono fatti i progetti software.

Quello che proviamo a evitare è il passaggio in cui questa differenza sparisce. Succede quando una stima diventa una promessa, quando un elenco di funzionalità scritto a gennaio diventa il metro con cui si giudica il lavoro di giugno, o quando si continua a costruire qualcosa che non serve più soltanto perché era nell'accordo.

Il modo di regolare il rapporto economico non è uno solo e non lo decidiamo in astratto: dipende da quanta incertezza ha davvero quel progetto e da come vogliamo distribuirla. Quello che deve valere sempre è la premessa. Siamo chiari su ciò che sappiamo, espliciti su ciò che non sappiamo, e scegliamo un accordo coerente con la distanza fra le due cose.

La forma precisa la definisce il contratto del progetto. Il principio è che quella forma venga scelta guardando l'incertezza reale, non nascondendola.