Una presentación de requisitos de producto no es un PRD copiado. Pone delante lo que la revisión debe resolver: problema, alcance, no objetivos, criterios de aceptación y decisiones abiertas. Con texto a presentación puedes crear un primer borrador editable desde un esquema revisado; los requisitos y sus límites deben seguir procediendo de tu PRD.
Aclara el problema y el objetivo
Empieza por el problema del usuario y la decisión que debe tomarse en la revisión. Incluye evidencias útiles, como observaciones de uso o patrones de soporte, sin atribuirles una certeza que no tienen. El objetivo describe el cambio buscado, no la solución técnica.
Separa alcance y no objetivos
Enumera por separado los casos incluidos y los que quedan fuera de forma intencionada. Los no objetivos evitan que el proyecto se amplíe en silencio. Marca los supuestos y preguntas abiertas en lugar de presentarlos como requisitos confirmados.
Escribe criterios comprobables
Describe un resultado observable: quién puede hacer qué, en qué condición y cómo se comprobará. Evita palabras como «fácil» o «rápido» si no hay una medida. Relaciona cada criterio con una prioridad y una dependencia conocida.
Haz visibles dependencias y riesgos
Muestra integraciones, fuentes de datos, revisiones legales y decisiones de otros equipos. Una dependencia no siempre bloquea; indica su estado, responsable y siguiente acción. No conviertas una fecha sin validar en un compromiso.
Incluye un registro de decisiones
Termina con una tabla breve: decisión, opciones, recomendación, motivo, responsable y fecha. Distingue lo decidido, lo propuesto y lo pendiente. Así la reunión deja un registro de lo que realmente se acordó.
Estructura recomendada para la revisión
- Problema, objetivo y pregunta de revisión
- Público y contexto respaldado
- Alcance y no objetivos
- Requisitos y criterios de aceptación
- Dependencias, riesgos y supuestos
- Decisiones abiertas y próximos pasos
Deja una decisión o una evidencia en el centro de cada diapositiva. La presentación agiliza la revisión; no sustituye al PRD completo.
Límites del formato
La presentación es una interfaz para decidir. No reemplaza la especificación completa ni la implementación. Conserva el enlace al PRD, identifica los cambios y presenta como confirmado solo lo que se haya validado.
Nombra la pregunta de revisión
Abre con una frase como «aprobar el alcance de la primera versión de la bandeja compartida». Añade responsable de la decisión, fecha prevista y problema de usuario o negocio. Un nombre de proyecto no permite juzgar si el soporte responde a la pregunta correcta.
Explica el problema con evidencia observada y un límite. Separa necesidad y solución: «los agentes pierden contexto cuando una conversación cambia de cola» es un problema; «construir un servicio de enrutamiento» es una hipótesis. La primera diapositiva debe servir también a quien llega tarde: decisión, recomendación, alcance y riesgo abierto.
Haz explícito el alcance
Muestra tres capas: incluido, fuera de alcance y aplazado. Lo incluido describe comportamiento o resultado observable. En una bandeja compartida puede ser asignar una conversación a una cola, mostrar su responsable y registrar una transferencia; el enrutamiento automático por sentimiento o una aplicación móvil pueden quedar fuera. Son ejemplos, no funciones prometidas.
Cuando dos requisitos chocan, muestra el intercambio. Una primera versión más rápida puede admitir un solo proveedor de identidad y dejar otros para una fase posterior. Nombra la consecuencia y a la persona que debe aceptar el compromiso.
Explica el flujo mínimo útil
Elige un flujo principal: detonante, decisiones importantes y resultado esperado. Mantén los casos límite aparte hasta entender el camino principal. En cada paso incluye información necesaria, acción del usuario y respuesta recibida. Marca políticas y servicios externos, y no inventes controles para completar la pantalla.
Señala accesibilidad y errores cuando cambien el requisito: ¿qué ocurre si se rechaza la solicitud, no hay conexión o falta permiso? Un flujo que solo funciona en el caso ideal no es un requisito completo.
Haz verificable la aceptación
Escribe un comportamiento observable: dada una condición, cuando ocurre una acción, entonces se ve un resultado. Agrupa criterios funcionales, de calidad y operativos. Relaciona los criterios de riesgo con un método de comprobación: prueba automatizada, sesión de usabilidad, revisión de seguridad, carga o inspección manual. El método es el control acordado, no una prueba de éxito futuro.
Muestra dependencias y opciones
Enumera proveedor de identidad, migración, revisión legal, componente del sistema de diseño o API de otro equipo con responsable y estado. El calendario solo debe mostrar puntos de integración, prueba y decisión útiles para esta revisión; una estimación incierta no es un compromiso. Para cada opción compara tiempo para aprender, reversibilidad, riesgo para usuarios y mantenimiento, y explica qué criterio la hace preferible.
Cierra con una aprobación registrable
Pide aprobar el alcance, aprobarlo con condiciones o devolverlo para un cambio concreto. Añade un registro de decisiones: qué se aprobó, qué quedó fuera, quién es responsable y cuándo se revisará. Si la evidencia es débil, propone una tarea de descubrimiento o prototipo con objetivo de aprendizaje. Envía el soporte junto al PRD y la fecha de versión para conservar lo que se sabía, se eligió y quedó abierto.
