Idea principal

Una parte de los defectos no viene del código sino de lo que lo precedió: una especificación incompleta, una decisión de producto ambigua, un caso límite nunca contemplado, un flujo mal entendido. La constatación sirve de ordinario para exculpar: "no es un bug, la especificación era vaga". En realidad lleva a otra parte.

Si el marco no está lo bastante claro como para entregar correctamente, quien tiene que entregar puede decirlo y parar. Negarse no es bloquear: es devolver la petición hacia una aclaración — el comportamiento esperado, los casos límite, los criterios de aceptación, los datos, las dependencias, los riesgos. Preguntar antes de programar cuesta una conversación; programar en la vaguedad cuesta una funcionalidad coja, luego defectos, soporte, retrabajo y arbitrajes que rehacer.

El fundamento es simple: no se puede garantizar la calidad de lo que no se entiende. Un desarrollador que ejecuta una petición ambigua resuelve las ambigüedades por su cuenta, sin decirlo, y a menudo sin saberlo.

Por qué es importante

Esto transforma una queja recurrente en un derecho acompañado de un deber. Mientras la especificación vaga sea solo un agravio, produce defectos que después se imputan a quien no hizo la pregunta.

Precisa también dónde se encuentran responsabilidad de producto y responsabilidad técnica: a producto le toca aclarar su elección, a técnica no convertir una ambigüedad fuerte en código frágil.

Matices y límites

El derecho a negarse se corrompe deprisa. Usado para obtener una especificación exhaustiva antes de todo código, reconstituye un ciclo en V y niega la parte de incertidumbre que se supone que el equipo debe absorber.

La línea no es "todo está escrito" sino "sé qué comportamiento debo hacer verdadero" — una frontera que depende del contexto compartido del equipo, y que ninguna plantilla fija en su lugar.

Preguntas abiertas

• ¿Quién decide cuando producto considera la petición suficientemente clara y el equipo de desarrollo considera lo contrario?