Quality Guard: El Portero que Protege al Equipo de los PRDs Incompletos (Artículo 2 de 7)
Serie Gemba: AI Mercadona User Story Framework — La separación QUÉ/CÓMO como quality gate
Introducción: Cuando el Problema No Es Problema
En el artículo anterior de esta serie sobre el “AI Mercadona User Story Framework”, establecimos la visión general: un camino desde el descubrimiento profundo del problema hasta la entrega de historias de usuario que realmente resuelven el negocio. Hablamos de por qué el descubrimiento importa, de cómo la mayoría de los fracasos de producto no vienen de implementar mal la solución, sino de resolver el problema equivocado.
Hoy nos enfrentamos a una pregunta incómoda: ¿cómo sabemos cuándo un problema está realmente bien definido?
Introducción: Cuando el Problema No Es Problema
En el artículo anterior de esta serie sobre el “AI Mercadona User Story Framework”, establecimos la visión general: un camino desde el descubrimiento profundo del problema hasta la entrega de historias de usuario que realmente resuelven el negocio. Hablamos de por qué el descubrimiento importa, de cómo la mayoría de los fracasos de producto no vienen de implementar mal la solución, sino de resolver el problema equivocado.
Hoy nos enfrentamos a una pregunta incómoda: ¿cómo sabemos cuándo un problema está realmente bien definido?
La respuesta que hemos descubierto en Mercadona es que la mayoría de los equipos no lo saben. Y más preocupante aún: la mayoría de los PRDs (Documentos de Requisitos de Producto) que llegan a manos de los ingenieros no contienen suficiente información para que el producto pueda tomar decisiones inteligentes.
Esto no es culpa de nadie. Es un síntoma de una confusión estructural que existe en prácticamente todas las organizaciones tecnológicas: la falta de claridad sobre dónde termina el trabajo de entender el problema (responsabilidad del negocio) y dónde comienza el trabajo de diseñar la solución (responsabilidad del producto).
Cuando esos límites se difuminan, pasan cosas. Se mezclan responsabilidades. Se empieza a construir sin claridad. Y tres sprints después, descubrimos que nunca entendimos realmente qué estábamos tratando de resolver.
Para evitar eso, necesitamos un guardián en la puerta. Alguien (o algo) que diga: “Espera. Antes de que el producto comience a diseñar, verifiquemos que el problema esté realmente bien definido.”
Ese guardián se llama Quality Guard.
El Problema: PRDs que No Son Realmente Especificaciones
Imaginemos un escenario típico en cualquier equipo de tecnología de Mercadona:
Un gerente de tienda en Barcelona entra en una reunión con el equipo de producto de In-Store. El gerente dice: “La gente tarda mucho en hacer recuento de inventario. Necesitamos una app que lo haga más rápido.”
El PM asiente. Suena como un problema legítimo. El PM escribe un PRD:
“El equipo de In-Store debe desarrollar una herramienta de recuento rápido que permita a los empleados completar inventarios en la mitad del tiempo actual.”
¿Ves el problema? No hay métricas baseline. ¿Cuánto tiempo tarda hoy? ¿Qué significa “la mitad”? No hay observación de campo. ¿Por qué tarda tanto? ¿Es porque el proceso está mal diseñado? ¿Porque hay demasiados SKUs? ¿Porque la app actual es lenta? No hay claridad sobre restricciones. ¿Pueden trabajar en paralelo? ¿Necesitan estar online o offline? ¿Qué datos son críticos vs. secundarios?
El PM pasa este PRD al equipo de producto. El equipo de producto comienza a diseñar una interfaz moderna, optimizada, con sinc automático y dashboards en tiempo real. Bonita. Compleja.
Diez semanas después, el equipo de In-Store comienza a usar la herramienta. Descubren que el verdadero problema nunca fue la velocidad de la UI, sino que los recuentos se hacen con dos personas que se comunican verbalmente, una llamando los SKUs y otra marcándolos. La app que se diseñó es para una sola persona. El problema real era: ¿cómo hacemos que dos personas puedan trabajar juntas sin perder sincronía?
Tres semanas de ajustes. Conversación tensa entre producto e In-Store. La pregunta incómoda: “¿Por qué no preguntaron esto antes de empezar?”
La respuesta es sencilla: porque el PRD nunca pidió que preguntaran. El PRD era un deseo vagamente articulado, no una especificación de un problema.
La Teoría: Separación Estricta entre QUÉ y CÓMO
Para entender por qué Quality Guard existe, necesitamos primero entender una verdad fundamental sobre cómo se construye bien en organizaciones maduras:
La distinción entre QUÉ y CÓMO es sagrada.
El QUÉ es: ¿Cuál es el problema que existe en la realidad?
El CÓMO es: ¿Cuál es la mejor solución tecnológica para ese problema?
Estos dos espacios tienen dueños diferentes:
El negocio es responsable de especificar el QUÉ. El negocio vive en las tiendas, en los almacenes, en los repartos. El negocio conoce los procesos, las restricciones, los usuarios finales, las métricas que importan.
El producto es responsable de diseñar el CÓMO. El producto entiende de experiencia, arquitectura, escalabilidad, factibilidad técnica.
Cuando estos espacios están bien separados, pasan cosas buenas:
El negocio tiene claridad. Se enfoca en lo que importa: definir el problema, los datos, los actores.
El producto tiene libertad. Puede explorar soluciones creativas sin estar atado a prescripciones del negocio.
La comunicación es clara. Sin límites claros, todo se vuelve adivinanzas.
Pero en la mayoría de las organizaciones, estos espacios se contaminan mutuamente. El negocio pide soluciones específicas (CÓMO). El producto asume lo que quiere el negocio (QUÉ) sin preguntar.
Las Tres Dimensiones de Quality Guard
Quality Guard evalúa el PRD en tres dimensiones independientes. Cada dimensión se califica de 0 a 10. El puntaje final es el mínimo de las tres.
Dimensión 1: Completitud del Problema
Pregunta fundamental: ¿Existe suficiente información cuantitativa y cualitativa para que el producto entienda qué está siendo resuelto?
Esta dimensión verifica que el PRD contenga tres tipos de evidencia:
1.1. Métricas cuantitativas con baseline y target
Un problema sin números no es especificación, es opinión.Veamos ejemplos malos:
❌ “Los empleados tardan mucho tiempo en hacer recuento de inventario”
❌ “Queremos mejorar la experiencia de checkout”
❌ “La gente está frustrada con la app de rutas”
Todas son intuiciones. Ninguna es datos.
Ejemplos buenos:
✅ “El recuento de inventario toma 3.5 horas hoy (medido en 5 tiendas piloto, Feb 2026). Meta: 2.0 horas. Impacto: 1.5 horas × 50 tiendas × 365 días = 27,375 horas/año.”
✅ “En checkout, el 23% de los carritos que inician no se completan. Baseline: 23% (Oct-Dec 2025). Meta: <15%. Impacto: +180 transacciones/mes en tienda media.”
✅ “La app de rutas se usa 8 minutos/sesión. Competidor usa 5 minutos. Meta: <4 minutos.”
Los ejemplos buenos tienen: un estado actual medible (baseline), un estado deseado medible (target), una unidad de medida clara, una muestra o período especificado, y un impacto cuantificado.
1.2. Observaciones de campo con citas directas
Los datos sin contexto son números huérfanos. Quality Guard busca que el PRD contenga visitas a tiendas o almacenes (Gemba walk), notas verbatim, observaciones de cómo hacen las cosas hoy, y fricción observada.
Ejemplo malo: “El sistema de picking genera mucho rechazo entre los colaboradores de almacén.”
Ejemplo bueno: “Durante la Gemba walk del 10 de febrero en el almacén de Lleida, observamos a 4 preparadores. Uno comentó: ‘Esto es un show. Tengo que estar constantemente revisando si el item ya fue preparado’. Otro: ‘Los olvidos pasan porque la batería se me muere a mitad de la jornada’. Observamos que 23 de 80 preparaciones tuvieron pick errors en 2 horas. 18 de esos 23 errores fueron en las últimas 2 horas de la jornada, cuando la batería se agota.”
1.3. Impacto claro en personas, procesos, herramientas
El problema debe conectarse a: ¿Quién sufre? ¿Cómo sufre? ¿Qué herramientas están implicadas?
Scoring Dimensión 1: 9-10: Métricas baseline y target claras, observaciones de campo recientes, impacto articulado. 7-8: Métricas parciales, observaciones presentes. 5-6: Datos parciales, impacto vago. 3-4: Algún número, sin observaciones. 0-2: Sin métricas ni claridad.
Dimensión 2: Calidad del Proceso
Pregunta fundamental: ¿Está documentado cómo funciona hoy el proceso? ¿Y cómo debería funcionar idealmente?
Quality Guard busca dos documentos:
2.1. Mapa AS-IS — Cómo funciona hoy, paso a paso, con todos los actores y herramientas.
2.2. Mapa TO-BE — Cómo debería funcionar idealmente, abstrayendo de la tecnología. No dice “usa app mobile” sino “cómo debería ser la experiencia de proceso”.
2.3. Actores y Handoffs — Quiénes son, qué hacen, dónde están, cuándo interactúan.
Scoring Dimensión 2: 9-10: AS-IS detallado, TO-BE idealizado, actores claros. 7-8: AS-IS presente, TO-BE parcial. 5-6: Superficial. 3-4: Vago. 0-2: Sin descripción de proceso.
Dimensión 3: Separación QUÉ/CÓMO (Contaminación de Solución)
Pregunta fundamental: ¿Hay pistas de que alguien en el negocio está prescribiendo la solución en lugar de describir el problema?
Esta es la dimensión más peligrosa. Cuando el negocio dicta soluciones en el PRD, el producto pierde toda libertad de diseño.
Quality Guard detecta antipatrones de contaminación:
Antipattern 1: Jobs-to-be-Done en el PRD — Los JTBD son responsabilidad del producto, no del negocio. Malo: “Los preparadores necesitan visualizar la ruta de picking optimizada en tiempo real para minimizar desplazamiento.” Bueno: “El preparador tarda 45 min en completar 80 items en almacén de 8000 m². Anda ~2.3 km por ruta (datos GPS). Benchmark: almacén comparable anda ~1.2 km. Diferencia: 1.1 km × 10 min/km = 11 min/ruta × 8 rutas/día = 88 min/día/persona. Con 15 preparadores = 22 horas/día perdidas.”
Antipattern 2: Prescripciones técnicas — “Usa API REST”, “usa blockchain”, “usa inteligencia artificial”. Malo: “Se requiere integración vía REST API con SAP para sincronizar inventario en tiempo real.” Bueno: “Hoy hay retraso de 4 horas entre preparación de item y reflejo en sistema de inventario. Causa sobreventa: 8-12 devoluciones/día. Se necesita actualización dentro de 15 min del evento.”
Antipattern 3: Prescripciones de UI/UX — “Necesita un botón para...”, “La app debe tener...”. Malo: “Se requiere pantalla táctil de 10 pulgadas en cada posición de picking.” Bueno: “Hoy los preparadores cometen error en 2.3% de picks (confunden artículos similares). Con foto de referencia, error baja de 2.3% a 0.6%. El preparador necesita acceso a información visual clara.”
Antipattern 4: Lenguaje de solución — “La solución debería...”, “necesitamos software que...”. Sin contaminar: “Cuando una devolución ocurre en campo, el registro toma 6 horas. En 40% de casos, driver re-entrega a almacén equivocado. Necesitamos información en punto de devolución inmediatamente.”
Antipattern 5: Hipótesis de solución disfrazada de requerimiento — “Reducir número de clics en 50%” es hipótesis, no problema. Problema puro: “40% de usuarios abandonan carrito en paso de pago. 65% abandona después de ver opciones. Flujo actual: 7 pantallas, 45 campos. Benchmark competidor: 3 pantallas, 20 campos.”
Scoring Dimensión 3: Quality Guard comienza asumiendo 10 puntos. Por cada antipattern: crítico (-3), alto (-2), medio (-1).
La Prueba de Herramienta Alternativa
Quality Guard usa una técnica elegante para detectar contaminación de solución: el Alternative Tool Test.
La idea: si reemplazas la herramienta digital por papel/manual y la descripción SIGUE SIENDO VÁLIDA, entonces es descripción de problema legítima. Si la descripción se disuelve, era prescripción de solución.
Ejemplo: “El equipo de recepción necesita verificar que lo que llega en el pallet coincide con la orden esperada, y registrar las discrepancias.” ¿Sigue siendo válido en papel? Sí. Totalmente. De hecho, hacerlo en papel es exactamente lo que hacían antes.
Ejemplo: “En tiempo real, cada cambio en la posición de preparador debe actualizarse en un mapa.” ¿Sigue siendo válido? El problema real es “supervisor necesita visibilidad de ubicación preparadores”. La versión original prescribe “en tiempo real” y “mapa”, que son detalles de solución.
Los Tres Veredictos
Cuando Quality Guard termina de evaluar un PRD, entrega uno de tres veredictos:
PASS (≥ 7.0)
El PRD está listo. El problema está bien definido. Las tres dimensiones están en buen estado. El producto puede comenzar a diseñar con confianza.
CONDITIONAL (5.0 - 6.99)
El PRD está cerca, pero tiene agujeros específicos. Quality Guard genera un documento de handoff estructurado que le dice al negocio exactamente qué falta. No es un rechazo. Es una guía: “Vuelve, agrega esto, y estaremos listos.”
Ejemplos: “Métrica baseline clara pero falta target. ¿Cuál es el estado deseado?”, “Observaciones de campo de solo 2 personas. Necesitamos 5+ para validar patrón.”, “AS-IS documentado pero TO-BE falta.”
FAIL (< 5.0)
El PRD está muy lejos. Falta información crítica o hay tanta contaminación que no se puede confiar en que el problema esté bien entendido. Quality Guard genera un documento de escalada con: qué dimensión es más débil, qué información falta, y sugerencia de próximos pasos (Gemba walk, entrevistas, mapping de proceso).
La Filosofía detrás de Quality Guard
Quality Guard no está juzgando si el problema es importante. Lo que verifica es diferente: está verificando que la información necesaria para que el producto tome buenas decisiones esté realmente presente.
Es un check de integridad de información, no de importancia estratégica.
Imagine que está a punto de hacer cirugía. El cirujano necesita: diagnóstico claro, datos de laboratorio, comparativa, y anatomía. Si el doctor no tiene eso, no importa cuánto quiera operar. Podría operar en el lugar equivocado.
Quality Guard es el enfermera que dice: “Doctor, ¿tenemos todos los datos que necesita antes de entrar al quirófano?”
Un Caso Real: Recepción en Almacén de Lleida
El equipo de Supply trae un PRD: “Mejorar eficiencia de recepción de merchandise en almacenes mediante modernización del proceso.”
Análisis D1 (Completitud): No hay métrica baseline. Dice “recepción lenta” sin decir qué tan lenta. Hay nota de una visita a Lleida con una persona. Impacto vago. Score: 4/10.
Análisis D2 (Proceso): Diagrama vago sin actores ni herramientas. TO-BE falta. Actores mencionados sin claridad. Score: 3/10.
Análisis D3 (Separación): “Sistema digital que integre escaneo de código de barras, sincronización automática con inventario central, y reportes automáticos.” Esto prescribe arquitectura completa sin especificar el problema. Score: 7/10 (10 - 3 por antipattern crítico).
Score final (mínimo): 3/10. Veredicto: FAIL.
Quality Guard genera documento de handoff con qué falta: datos baseline, observación de campo (Gemba walk 4 horas en Lleida, 20+ recepciones), entrevistas a 5+ recepcionistas, mapeo de proceso AS-IS/TO-BE, y limpieza de prescripciones técnicas.
El equipo de Supply hace la Gemba walk. Descubre: recepción toma 12 min/pallet, 1800 pallets/mes = 360 horas/mes. 18% de pallets tienen discrepancias. Investigar discrepancia toma 8 min/pallet en papel + sistema. 4 recepcionistas (turno 6-14h), 1 analista (turno 8-16h) — recepcionistas esperan al analista. Operador logístico recibe reporte por email 2 horas después, cuando ya se fue.
Supply trae PRD v2: D1: 9/10 (métricas, observaciones, impacto). D2: 8/10 (AS-IS y TO-BE claros). D3: 8/10 (sin prescripciones). Score final: 8/10. Veredicto: PASS.
Por Qué Quality Guard Importa: Separar Descubrimiento de Entrega
La idea central de Agile era correcta: no esperes a tener todo especificado, comienza a construir, itera. Pero una generación de gestores lo mal-interpretó como: “No necesitamos especificación de problemas.”
Lo que una organización madura necesita es diferente:
Fase 1: Descubrimiento (semanas o meses) — Negocio entiende el problema profundamente. Producto investiga alternativas. Resultado: PRD que PASS Quality Guard.
Fase 2: Entrega (semanas) — Producto diseña y construye. Negocio responde preguntas tácticas. Resultado: incremento completado.
Quality Guard es el guardián que separa estas dos fases. Para Mercadona, esto significa: menos sorpresas en sprints, mejor productividad del equipo de producto, y mejor velocidad general. Es una inversión de 1-2 semanas extra en descubrimiento para ahorrar 6-8 semanas en re-trabajo.
Conclusiones: El Guardián de la Claridad
La calidad de un PRD no se mide por cuánto detalle tiene, sino por cuánta CLARIDAD tiene sobre el problema, separado de la solución.
Aprendizajes clave: La separación QUÉ/CÓMO es sagrada. Tres dimensiones de evaluación (Completitud, Proceso, Separación). Tres veredictos claros (PASS, CONDITIONAL, FAIL). El Alternative Tool Test. La filosofía de integridad de información. Y el costo de no hacerlo: re-hacer cuesta 6-8 semanas; hacer bien desde el inicio cuesta 1-2 semanas extra.
La pregunta final: ¿Cuál es el costo de comenzar a construir sin saber realmente qué se está construyendo? En Mercadona, donde los cambios pueden afectar a 250 puntos de venta y miles de empleados, ese costo es extremadamente alto. Quality Guard existe para reducirlo.
En el siguiente artículo de esta serie, exploraremos cómo Research Mom Test toma estos PRDs claros y extrae de ellos las verdaderas necesidades del usuario, contrastadas contra la realidad. Porque “problema bien definido” no es lo mismo que “problema realmente entendido”.
Próximo artículo: Artículo 3 — “Research Mom Test: Validación de Problemas contra la Realidad del Campo”
Serie “AI Mercadona User Story Framework” — Febrero 2026