Una falsa dicotomia

Nel mondo del software custom molte discussioni iniziano e finiscono sempre nello stesso modo: “Meglio progetto chiavi in mano o Time & Material?”

È una domanda comprensibile. Ma è anche, quasi sempre, la domanda sbagliata.

La questione riguarda piuttosto chi si assume il rischio dell’incertezza e se questa distribuzione del rischio è coerente con la realtà del progetto. Quando questa coerenza manca, il progetto entra in difficoltà prima ancora che venga scritto il primo rigo di codice.

L’incertezza è una caratteristica dei sistemi complessi

In molti contesti aziendali l’incertezza viene trattata come qualcosa da eliminare rapidamente. I requisiti vengono chiusi il prima possibile, le stime rese più precise di quanto sia realistico e le roadmap costruite come se il contesto fosse stabile.

Nei sistemi complessi però l’incertezza è strutturale. Un progetto che coinvolge processi organizzativi reali, integrazioni con sistemi legacy, dati critici, vincoli normativi e più team interdipendenti difficilmente può essere definito completamente all’inizio.

Quando si assume il contrario, l’incertezza non scompare. Viene semplicemente spostata più avanti nel tempo, dove diventa più costosa, più conflittuale e più difficile da gestire.

Cosa fanno davvero i modelli contrattuali

Ogni modello di collaborazione fa una cosa molto semplice: decide dove finisce il rischio.

Nel Time & Material il rischio dell’incertezza resta in larga parte sul cliente. Il fornitore mette a disposizione capacità, non un risultato garantito. Questo modello funziona bene quando il contesto è relativamente stabile, le priorità sono chiare, esiste una figura interna in grado di prendere decisioni rapide e l’architettura di base è già solida. Diventa invece problematico quando viene utilizzato per compensare una mancanza di chiarezza strategica. In quel caso si accumulano ore, ma non necessariamente si riduce l’incertezza.

Nel progetto a obiettivo definito, invece, obiettivo, budget e scadenze vengono stabiliti fin dall’inizio e il rischio viene trasferito formalmente al fornitore. Questo funziona quando il perimetro è davvero chiaro, i vincoli tecnici sono noti e i casi alternativi sono stati esplorati. Le tensioni emergono quando il contratto presuppone stabilità in un dominio che stabile non è. In queste condizioni ogni variazione diventa una change request e ogni decisione si trasforma in una negoziazione.

Quando il modello scelto non regge

I segnali sono ricorrenti. Requisiti formalmente “chiusi” ma continuamente ridiscussi. Stime difese più per contratto che per buon senso. Tensione costante tra chi “paga” e chi “fornisce”. Change request vissute come abusi. Discussioni infinite su cosa fosse “incluso”.

In questi casi il problema non è tecnico. È strutturale. Il modello scelto non è coerente con il livello reale di incertezza.

Un esempio ricorrente

Un’azienda decide di riscrivere un sistema interno diventato nel tempo critico per l’operatività. La documentazione è incompleta, i processi sono cambiati più volte e alcune integrazioni con altri sistemi sono nate in modo informale.

Per ragioni di budget e governance viene richiesto un progetto a prezzo fisso. Sulla carta il sistema sembra definito; nella pratica molte regole di business emergono solo quando si prova a formalizzarle.

Dopo pochi mesi, il fornitore difende il perimetro iniziale mentre il cliente scopre funzionalità che dava per scontate. Il rapporto si irrigidisce e ogni modifica diventa oggetto di trattativa. Il problema nasce dal trattare un contesto ad alta incertezza come se fosse stabile.

L’errore più costoso

Nei progetti software gli errori più costosi raramente sono tecnici. Spesso nascono dal presupposto implicito che tutto sia già chiaro.

Le ipotesi non esplicitate diventano aspettative implicite, e queste aspettative finiscono per trasformarsi in conflitti. Nessun modello contrattuale riesce a compensare un progetto costruito su presupposti non dichiarati. 

Governare l’incertezza

Gestire l’incertezza non significa rinunciare al controllo. Significa renderla esplicita e proporzionare l’impegno al livello di chiarezza raggiunto.

In molti casi questo comporta partire con un’analisi mirata e limitata nel tempo, validare mockup e flussi prima dell’implementazione completa, affrontare per prime le parti più rischiose e mantenere flessibile lo scope quando l’obiettivo non è ancora completamente definito.

Non significa “prendere tempo”.

Si tratta di evitare decisioni irreversibili su basi fragili. Ogni scelta architetturale importante (tecnologia, modello di integrazione, suddivisione dei servizi) è difficile da correggere a posteriori. Ridurre l’incertezza prima di prenderla è un atto di responsabilità, non di prudenza eccessiva. 

Una questione di maturità

Affrontare l’incertezza richiede maturità da entrambe le parti.

Dal lato cliente significa discutere apertamente i trade-off, accettare che alcune decisioni non possano essere prese subito e riconoscere che alcune parti del sistema possono essere definite più avanti. Dal lato fornitore significa evitare promesse irrealistiche, distinguere con chiarezza ciò che è definito da ciò che non lo è e adottare un metodo per ridurre progressivamente il rischio.

Quando entrambe le parti trattano l’incertezza come una variabile reale, il dialogo cambia. La discussione non riguarda più solo costi e scadenze, ma anche i rischi principali, cosa conviene esplorare prima e dove ha senso impegnarsi davvero.

Una decisione di allocazione del rischio

La scelta tra Time & Material e progetto a obiettivo definito non è una questione ideologica. È una decisione di allocazione del rischio.

Quando l’incertezza è alta serve un modo per ridurla prima di assumere impegni pesanti. Quando il perimetro è chiaro e stabile, un obiettivo definito può essere efficiente. Nei contesti maturi e continuativi un modello di capacità può avere senso.

Il punto resta sempre lo stesso: allineare il livello di commitment al livello di incertezza residua. Quando questo allineamento esiste, il progetto ha spazio per funzionare. Quando manca, le tensioni tendono a emergere nel tempo.