La mayoría de los debates sobre calidad ocurren demasiado tarde — el viernes por la tarde, cuando la feature está construida y nadie quiere rehacerla. El PO efectivo en un modelo de entrega con IA no debate calidad al final: la define al principio, con criterios que no dejan margen de interpretación.
Criterios de aceptación que son verificables, no aspiracionales
Un criterio aspiracional suena así: «La experiencia debe ser intuitiva y fluida.» Un criterio verificable: «El usuario puede completar el registro en menos de 3 pasos sin ver mensajes de error si ingresa un email válido.» Si dos personas del equipo leen el criterio y llegan a conclusiones distintas sobre si la feature lo cumple, el criterio está mal escrito. Vuélvelo a escribir antes del lunes.
El PO como guardián de la definición, no de la construcción
El PO no es el QA ni el arquitecto. Es el guardián de la definición. Su trabajo es garantizar que lo que entra al proceso es lo suficientemente preciso para salir como valor entregable el viernes. Esto significa que el PO no interviene durante la construcción para «mejorar» la feature. Si hay algo que mejorar, va al backlog. La semana en curso tiene un alcance fijo.
«Velocidad y calidad no son opuestos — son el resultado natural de una definición precisa hecha con tiempo suficiente.»
El ritual de QA del viernes en FAST Delivery
El viernes no es el día en que se improvisa la revisión — es el día en que se ejecuta un ritual estructurado. Cuatro momentos: (1) el QA ejecuta los criterios de aceptación definidos el lunes; (2) el DM revisa los puntos técnicos; (3) el PO firma el «listo» contra los criterios originales; (4) si algo no pasa, va al backlog como nueva feature, no como bloqueador del deploy. Un bug menor que no afecta el valor principal de la feature se convierte en deuda técnica documentada — no en pretexto para retrasar la entrega. El PO que aprende a decir «esto cumple los criterios» con confianza libera a su equipo para seguir construyendo.