Idea principale

Una specifica, un PRD, un mockup vengono accusati di mentire appena si scopre lo scarto tra ciò che annunciano e ciò che il prodotto fa. L'accusa sbaglia bersaglio: questi documenti non si sono sbagliati, hanno smesso di svolgere la funzione per cui erano stati scritti.

Prima del rilascio in produzione, una specifica serve al dialogo. Dà al Product Manager, agli sviluppatori e alle funzioni aziendali qualcosa da contestare: permette di esplorare un'ipotesi, di inquadrare un perimetro, di far emergere un disaccordo prima che costi caro, di decidere. Il suo valore non sta nella sua esattezza ma nella sua capacità di suscitare obiezioni — un documento che nessuno ha discusso ha fallito, anche se descrive esattamente ciò che verrà consegnato.

Il passaggio in produzione le toglie questa funzione. I compromessi presi durante lo sviluppo, i casi limite scoperti, le scelte fatte in una merge request sono entrati nel prodotto senza ripassare dal documento. Ciò che diceva del comportamento non è più una proposta da discutere: è una descrizione in concorrenza con quella contenuta nel repository, e perdente. L'artefatto non diventa falso, diventa rigenerabile — ciò che enuncia del comportamento si ricostruisce dal codice, e mantenerlo a mano significa accudire un doppione che va alla deriva.

Il cambio di status ha quindi una data, e non è quella di redazione. Uno stesso documento è legittimo prima del rilascio e illegittimo dopo, senza che una sola delle sue frasi sia cambiata.

Perché è importante

Scioglie il falso dilemma tra «servono spec migliori» e «bisogna smettere di scriverle». I due campi presuppongono che la specifica abbia un solo status; ne ha due, e l'errore frequente consiste nel prolungare il primo oltre il momento in cui scade.

Riorienta anche lo sforzo: invece di riscrivere un documento dopo ogni rilascio perché resti vero, lo si scrive apertamente per la conversazione che deve aprire, e si accetta che sia superato appena va in produzione. La cura si sposta verso la qualità della discussione a monte e verso la capacità di rigenerazione a valle — due cose che, a differenza dell'aggiornamento manuale, non si degradano con il tempo.

Sfumature e limiti

Il cambio di status riguarda solo la parte descrittiva. Una specifica contiene quasi sempre, mescolati negli stessi paragrafi, la descrizione di un comportamento e il motivo per cui è stato scelto — il secondo non si rigenera da alcun repository e deve sopravvivere al documento.

Una specifica può inoltre avere valore vincolante: allegato di un contratto con un cliente, documento di un fascicolo normativo, impegno scritto in una gara d'appalto. Conserva allora un'autorità giuridica che il rilascio in produzione non le toglie, anche quando il prodotto se ne discosta — ed è proprio lo scarto a diventare il tema.

Infine, «il rilascio in produzione» presuppone un confine netto. Un deploy progressivo dietro un feature flag, un rilascio a pochi clienti pilota, un rollback dilatano il momento del cambio di status invece di segnarlo.

Domande aperte

• Che cosa, concretamente, segna questo cambio di status sul documento stesso, perché chi lo riapre otto mesi dopo sappia quale dei due regimi sta consultando?
• Una specifica scritta sapendo che sarà superata al rilascio si scrive in modo diverso — più breve sul comportamento, più lunga sulle alternative scartate?