Idea principale

Una parte dei difetti non viene dal codice ma da ciò che lo ha preceduto: una specifica incompleta, una decisione di prodotto ambigua, un caso limite mai considerato, un flusso mal compreso. Di solito questa constatazione serve a discolparsi — «non è un bug, la spec era vaga». In realtà porta altrove.

Se il quadro non è abbastanza chiaro per consegnare correttamente, chi deve consegnare può dirlo e fermarsi. Rifiutare non significa bloccare: significa rimandare la richiesta verso un chiarimento — il comportamento atteso, i casi limite, i criteri di accettazione, i dati, le dipendenze, i rischi. Chiedere prima di scrivere codice costa una discussione; scrivere codice nel vago costa una funzionalità traballante, poi difetti, supporto, rework e decisioni da rifare.

Il fondamento è semplice: non si può garantire la qualità di ciò che non si capisce. Uno sviluppatore che esegue una richiesta ambigua scioglie le ambiguità da solo, senza dirlo, e spesso senza saperlo.

Perché è importante

Trasforma una lamentela ricorrente in un diritto accompagnato da un dovere. Finché la specifica vaga resta solo una rimostranza, produce difetti che vengono poi imputati a chi non ha fatto la domanda.

Precisa anche dove si incontrano responsabilità di prodotto e responsabilità tecnica: al prodotto spetta chiarire la propria scelta, alla tecnica non trasformare un'ambiguità forte in codice fragile.

Sfumature e limiti

Il diritto di rifiuto si snatura in fretta. Usato per ottenere una specifica esaustiva prima di scrivere qualsiasi riga di codice, ricostruisce un ciclo a V e nega la quota di incertezza che il team dovrebbe assorbire.

La linea non è «è tutto scritto» ma «so quale comportamento devo rendere vero» — un confine che dipende dal contesto condiviso del team, e che nessun template può fissare al suo posto.

Domande aperte

• Chi decide quando il prodotto ritiene la richiesta abbastanza chiara e il team di sviluppo pensa il contrario?