La scelta tra un contratto a prezzo fisso e il time and materials viene quasi sempre presentata come una scelta sul rischio, il che è corretto, e subito dopo gestita male, perché entrambe le parti danno per scontato che il rischio sparisca invece di limitarsi a spostarsi.

Non sparisce. In un accordo a prezzo fisso il fornitore si assume il rischio che la stima sia sbagliata e inserisce quel rischio nel numero che presenta. Nel time and materials se lo assume il cliente. La domanda non è mai quale delle due formule elimini l’incertezza. È quale delle due parti sia nella posizione migliore per governarla, e se il prezzo del trasferimento valga la spesa.

Il test che prevede quale formula funzionerà: riesce a mettere per iscritto che cosa significa «finito», con abbastanza dettaglio perché due persone siano d’accordo sul fatto che quel punto sia stato raggiunto? Se sì, il prezzo fisso è una strada percorribile e probabilmente sensata. Se non ci riesce, un contratto a prezzo fisso non elimina l’ambiguità, si limita a trasformare ogni futuro disaccordo in una trattativa commerciale invece che in una conversazione tecnica.


Che cosa compra davvero un contratto a prezzo fisso

Certezza sulla fattura, e nient’altro. In particolare non compra certezza sul risultato, sulla data o sulla qualità, che invece molti committenti danno per inclusi nel pacchetto.

Ha anche un costo. Un fornitore che quota a prezzo fisso aggiunge una riserva per il rischio, perché è lui ad assorbire lo sforamento, e l’entità di quella riserva cresce con la vaghezza della specifica. Su un lavoro ben delimitato può restare contenuta. Su un lavoro definito in modo approssimativo può avvicinarsi al costo del lavoro stesso, e la si paga a prescindere dal fatto che il rischio si concretizzi.

Il secondo costo è di natura comportamentale. Una volta fissato il prezzo, ogni ambiguità si risolve nella direzione di meno lavoro, perché è lì che ora si colloca l’interesse del fornitore. Non è malafede, è l’incentivo creato dal contratto stesso. Un fornitore che a metà realizzazione individua un approccio migliore non ha alcun motivo per proporlo, e un cliente che si accorge che un requisito era sbagliato si trova davanti a una change request anziché a una conversazione.

Il prezzo fisso funziona bene sul lavoro davvero delimitato: una migrazione con sorgente e destinazione note, un’integrazione contro una API documentata, un insieme definito di schermate su un design già approvato. Funziona male su qualsiasi cosa abbia natura esplorativa.

Quando il time and materials costa meno

Contro ogni intuizione, capita spesso, perché non si paga la riserva per il rischio e non si paga la gestione delle change request.

Si adatta al lavoro il cui perimetro cambierà per motivi legittimi: una prima versione la cui direzione dipende da quello che fanno gli utenti, un’integrazione con un sistema che nessuno ha documentato, il recupero di una base di codice il cui stato resta ignoto finché qualcuno non ci guarda dentro. In tutti questi casi un prezzo fisso è in realtà un prezzo fisso su una supposizione.

Quello che chiede al cliente è attenzione. Il time and materials senza coinvolgimento diventa una fattura aperta, e il classico modo di fallire è un progetto che va avanti per mesi mentre nessuno chiede che cosa sia stato consegnato la settimana scorsa. Il controllo non è contrattuale, è operativo: un backlog visibile, una dimostrazione a intervalli regolari e una persona lato cliente autorizzata a cambiare le priorità.

Se nessuno dalla vostra parte può garantire quell’attenzione, è meglio dirlo apertamente, perché il time and materials non funzionerà bene e nessuna clausola lo sistema.

L’opzione che la maggior parte dei progetti dovrebbe scegliere

Un accordo con tetto di spesa oppure diviso in fasi, che non è nessuna delle due formule precedenti e si adatta a più lavoro software di entrambe.

Time and materials con tetto. Il lavoro viene fatturato a tempo, con un massimale concordato. Il cliente conserva la flessibilità di cambiare direzione e il fornitore si assume il rischio residuo oltre il tetto. Entrambe le parti mantengono un interesse all’efficienza, che nessuno dei due modelli puri riesce a produrre.

Prezzo fisso per fasi. Una breve fase di analisi a pagamento produce una specifica, e solo a quel punto la realizzazione viene quotata a prezzo fisso su qualcosa di reale. È la versione onesta del prezzo fisso, perché la stima nasce dopo che le incognite sono state ridotte e non prima. La nostra guida alla richiesta di offerta software spiega che cosa deve contenere quella specifica.

Prezzo fisso per incremento. Ogni fase viene quotata a parte e approvata a parte. Si ottiene prevedibilità di budget a blocchi e la possibilità di fermarsi, che è il diritto più prezioso di un committente e proprio quello che i lunghi contratti a prezzo fisso eliminano.

Il filo conduttore è sempre lo stesso: la precisione delle stime migliora enormemente una volta che una parte del lavoro è stata fatta. Costruire l’assetto commerciale in modo da sfruttare questo fatto vale più di qualunque clausola.

Dove falliscono davvero i progetti a prezzo fisso

Non sul prezzo. Sul confine tra perimetro e modifica.

Ogni progetto a prezzo fisso genera change request, perché le specifiche vengono scritte prima che qualcuno abbia usato la cosa. La salute dell’accordo dipende interamente da come vengono trattate, e questo si decide su quanto precisamente è stato definito il perimetro all’inizio, non sulla buona volontà delle persone coinvolte.

Due cose riducono l’attrito. Mettete per iscritto che cosa succede a una modifica: chi la valuta, su quale base viene quotata e in quanto tempo. E tenete una riserva anche dalla parte del cliente, perché un prezzo fisso senza budget di modifica lato cliente trasforma ogni scoperta in una discussione.

L’altro fallimento frequente riguarda il collaudo. Se il contratto non definisce come si dimostra il completamento, il pagamento finale diventa una trattativa su opinioni. Scrivete i criteri di accettazione accanto al perimetro e preferite criteri che qualcuno può verificare a criteri che qualcuno deve giudicare.

Scegliere nella pratica

Chiedetevi che cosa sia davvero ignoto. Se la risposta è «molto poco», il prezzo fisso è ragionevole e dovete aspettarvi di pagare una riserva per quella certezza. Se invece resta ignoto moltissimo, un prezzo fisso si limita a convertire l’incertezza tecnica in attrito commerciale.

Chiedetevi poi che cosa siete in grado di seguire. Il time and materials premia l’attenzione e punisce la sua assenza. Il prezzo fisso chiede meno settimana dopo settimana e molto di più all’inizio, nella specifica, dove gli errori costano meno ma si notano con più difficoltà.

Chiedetevi infine quanto vale la certezza. A volte un consiglio di amministrazione ha bisogno di un numero, e la riserva è un prezzo equo per averlo. È una ragione legittima per scegliere il prezzo fisso, ed è una ragione molto migliore del credere che elimini il rischio.

Mecanik lavora con tutte e tre le formule nell’ambito del servizio di sviluppo software, e consiglia più spesso la versione per fasi. La stima prodotta dopo due settimane di analisi vale più di quella prodotta prima, per entrambe le parti.



Domande frequenti

Un contratto a prezzo fisso è più sicuro del time and materials? È più prevedibile, che non è la stessa cosa. Il prezzo fisso trasferisce al fornitore il rischio di stima, e il fornitore lo mette a prezzo come riserva, quindi lo pagate che si concretizzi o meno. Compra certezza sulla fattura, non sul risultato, sulla data o sulla qualità.

Quando il time and materials costa meno? Quando il perimetro cambierà per motivi legittimi: una prima versione la cui direzione dipende dal comportamento degli utenti, un’integrazione con un sistema non documentato oppure il lavoro su una base di codice il cui stato resta ignoto finché qualcuno non ci guarda dentro. In quei casi si evitano sia la riserva sia il costo di gestione delle change request, perché un prezzo fisso sarebbe un prezzo fisso su una supposizione.

Che cos’è il time and materials con tetto? Lavoro fatturato a tempo con un massimale concordato. Il cliente conserva la flessibilità di cambiare direzione mentre il fornitore si assume il rischio oltre il tetto. Lascia a entrambe le parti un interesse all’efficienza, cosa che né il prezzo fisso puro né il time and materials puro riescono a ottenere.

Perché i progetti software a prezzo fisso vanno male? Quasi sempre sul confine tra perimetro e modifica, non sul prezzo. Le specifiche vengono scritte prima che qualcuno abbia usato il software, quindi le change request sono inevitabili. La salute del progetto dipende dall’aver concordato in anticipo chi valuta una modifica e come viene quotata, e dal fatto che il cliente tenga una propria riserva di budget.

Devo definire i criteri di accettazione nel contratto? Sì, accanto al perimetro. Senza un modo definito di dimostrare il completamento, il pagamento finale diventa una trattativa su opinioni. Preferite criteri che qualcuno può verificare a criteri che qualcuno deve giudicare, perché i criteri verificabili chiudono i disaccordi mentre quelli di giudizio li allungano.