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.
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. La guía para presentar hallazgos de investigación de usuarios explica cómo conectar las observaciones con una decisión de producto sin generalizar una pequeña muestra cualitativa a toda la población.
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, prueba de carga o inspección manual. El método es el control acordado, no una prueba de éxito futuro.
La guía de PRD de Atlassian explicita supuestos y exclusiones; los comportamientos sin decidir también deben seguir visibles.
En el ejemplo de bandeja compartida, una conversación ya está en la cola Q y la primera versión permite que un agente autorizado se haga responsable. Los siguientes criterios se proponen para un producto ficticio: no describen funciones de Presenti ni pruebas completadas. El enrutamiento automático por sentimiento y la aplicación móvil siguen fuera, tal como indica la diapositiva de alcance.
| Situación y acción | Resultado observable o decisión pendiente | Método y rol responsable |
|---|---|---|
| Una conversación de Q no tiene responsable y un agente autorizado en Q se la asigna | El agente aparece como responsable; al volver a abrirla se conserva la asignación, y el registro de transferencia identifica a la persona y la conversación | QA prueba con una cuenta autorizada, examina la asignación guardada y el registro, y entrega el resultado al responsable de producto |
| Un agente sin permiso para Q intenta la misma asignación, también mediante una petición directa fuera de la interfaz normal | Se deniega la asignación; responsable y registro de transferencia no cambian, y la respuesta no revela contenido protegido de la conversación | El responsable de seguridad define la prueba negativa; QA prueba la interfaz y las peticiones y comprueba que el estado no cambió |
| Dos agentes autorizados ven la misma conversación sin asignar e intentan asignársela casi al mismo tiempo | Política pendiente: ¿se rechaza la asignación en conflicto con un aviso para actualizar, o se aplica otra regla acordada? La última escritura no es automáticamente el comportamiento aprobado | Producto e ingeniería acuerdan la regla y el mensaje esperado antes de que QA prepare una prueba de concurrencia repetible |
El caso concurrente no puede superar la aceptación mientras su resultado esperado siga sin decidir. Registra la regla, quién decide y la fecha de revisión; actualiza después el PRD y la diapositiva juntos. Ocultar un control no demuestra que se aplican los permisos: prueba también la petición directa sin autorización. Conserva los resultados junto a cada criterio, sin presentar esta matriz propuesta como un informe de pruebas.
Asigna a cada criterio una prioridad y sus dependencias conocidas para identificar qué condiciones determinan la aceptación.
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.
Una dependencia no siempre bloquea el proyecto. Indica su estado, responsable y próxima acción; si no tiene responsable, debe figurar entre los riesgos o las decisiones pendientes.
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. Las diapositivas no sustituyen la especificación completa ni la implementación. Distingue en el registro lo confirmado en la revisión de los requisitos todavía propuestos.
