Idea principale

Una specifica descrive un'intenzione. Un PRD descrive un obiettivo, delle regole attese, degli scenari. Un mockup descrive un'interfaccia desiderata. Nessuno di questi documenti descrive ciò che il cliente si troverà davanti: tra loro e la messa in produzione si fanno compromessi, si aggiustano dettagli, compaiono casi limite, vincoli tecnici obbligano a modificare leggermente il comportamento, e si prendono decisioni nel corso di una pull request senza che risalgano fino al documento iniziale.

Queste scelte non sono incidenti da eliminare: un prodotto vivo non si costruisce come un documento congelato. Hanno però una conseguenza su ciò che bisogna guardare per conoscere un prodotto. La specifica resta un'approssimazione utile in un dato momento; la versione in produzione è l'unica descrizione completa di ciò che è stato consegnato.

L'effetto si vede anche negli strumenti di tracciamento: i ticket si disallineano esattamente come le specifiche, perché le scelte fatte durante la realizzazione non risalgono né negli uni né nelle altre.

Contributo di «Il backlog non è una discarica: è uno strumento d'azione» (2026-06-03).

Contributo di «PM, sviluppatori e IA: i ruoli si confondono, le responsabilità restano» (2026-08-01). Queste scelte hanno un nome e un autore: sono decisioni di prodotto, e a prenderle sono gli sviluppatori. Una specifica completa è una finzione — anche quando è buona, lascia zone mute: casi limite, messaggi di errore, comportamenti impliciti, regole di sicurezza, timeout, priorità invisibili, micro-interazioni, decisioni di fallback. La constatazione non descrive quindi soltanto uno scarto tra il documento e la produzione: indica chi, nei fatti, decide ciò che il cliente si troverà davanti.

Perché è importante

Sposta il luogo in cui si va a cercare la verità di una funzionalità: nel comportamento consegnato, non nel ticket che l'ha richiesta. Gli scarti non sono errori di conformità, sono la materia stessa della decisione di prodotto.

Dice anche che cosa si perde restando a monte: la parte delle scelte che determina l'esperienza del cliente si è giocata dopo il documento, in scambi che quel documento non registra.

Sfumature e limiti

Su certi perimetri lo scarto è minimo e l'intenzione regge: la modifica di un'etichetta, un parametro, una regola di business semplice arrivano in produzione così come sono stati scritti.

E un prodotto soggetto a un vincolo normativo ribalta in parte la regola: lì la conformità si dimostra sul documento tanto quanto sul comportamento consegnato, e lo scarto diventa di per sé un difetto.

Domande aperte

• Con quale meccanismo una scelta fatta in una pull request potrebbe risalire fino a chi ha progettato la funzionalità, senza ricreare il carico documentale che si cerca di evitare?