Prompt para documento de requisitos de producto

Cuándo usarlo

Utilízalo cuando necesites un PRD inicial para una funcionalidad acotada y busques una base técnica y operativa sólida en lugar de un esquema abstracto. Sustituye la información con los datos reales de tu producto, las restricciones del sistema y las métricas de tu equipo antes de presentárselo a ingeniería.

El prompt

## Rol
Actúa como un senior product manager. Aplica un pensamiento sistémico estructurado y claridad técnica, manteniendo la documentación accesible para equipos multidisciplinares.

## Contexto
BeaconHR es una plataforma de operaciones internas para clínicas de salud medianas. Actualmente, los supervisores de turno coordinan los intercambios de turnos de emergencia del personal de enfermería mediante llamadas telefónicas y pizarras físicas, lo que genera duplicidades de turnos y retrasos en la cobertura. BeaconHR va a incorporar un módulo optimizado para móviles llamado "Solicitudes de intercambio de turnos". El lanzamiento previsto es el segundo trimestre (Q2) para un grupo piloto existente de 12 clínicas regionales.

## Objetivo
Redactar un PRD exhaustivo que especifique el flujo de trabajo integral para una solicitud de intercambio de turnos entre compañeros (peer-to-peer), el filtro de aprobación del supervisor y la actualización del registro de auditoría.

## Audiencia
Los lectores principales son ingenieros de software, diseñadores de UI/UX y responsables de operaciones clínicas. Proporciona una lógica sin ambigüedades y criterios de aceptación prácticos y accionables sin teoría innecesaria.

## Requisitos
Incluir: planteamiento del problema; personas usuarias (Personal solicitante, Personal receptor, Supervisor de la clínica); historias de usuario con criterios de aceptación explícitos; especificaciones funcionales que cubran el inicio de la solicitud, la aceptación por parte del compañero y la aprobación final del supervisor; gestión de errores y casos extremos (p. ej., turnos solapados, solicitudes caducadas); y una tabla de métricas para la adopción de la funcionalidad y el tiempo de respuesta del intercambio.

## Restricciones
Limita el alcance estrictamente a intercambios de turnos 1:1 dentro de la misma ubicación de la clínica y clasificación de rol. No introduzcas regeneración automatizada de horarios, integración con procesamiento de nóminas, traslados entre distintas sedes ni pasarelas externas de notificaciones por SMS. Trabaja únicamente con el escenario planteado. Etiqueta todas las asunciones funcionales de forma explícita.

## Tono y estilo
Sé conciso, riguroso y funcional. Emplea un lenguaje inequívoco (p. ej., "debe", "debería") y tablas markdown estructuradas para los estados y casos extremos. Evita la jerga corporativa o las generalidades vagas.

## Formato de salida
Presenta el PRD directamente bajo encabezados estandarizados de documentación de producto. Ubica los supuestos arquitectónicos y las preguntas abiertas pendientes de resolución en una sección independiente al final. Concluye con una lista de verificación de dependencias para la validación final por parte de ingeniería y cumplimiento normativo.

## Qué evitar
No des por sentadas capacidades de API no especificadas ni herramientas de proveedores externos. Evita mezclar requisitos funcionales con especificaciones de diseño visual. No omitas estados de error ni condiciones límite.

## Criterios de éxito
Un responsable de ingeniería puede estimar el esfuerzo técnico y un ingeniero de QA puede derivar casos de prueba directamente a partir de los requisitos, sin necesidad de solicitar aclaraciones sobre las reglas de negocio principales.

## Preguntas de clarificación
Haz un máximo de tres preguntas específicas solo si existe una ambigüedad que bloquee de forma fundamental la redacción de los requisitos. De lo contrario, continúa aplicando supuestos operativos razonables señalados claramente como elementos pendientes de validación por los stakeholders.

Por qué funciona

• El escenario proporciona al modelo restricciones de dominio y roles de usuario concretos en lugar de una idea de funcionalidad difusa.
• Los requisitos exigen casos extremos funcionales, criterios de aceptación y estados de error explícitos que a menudo se pasan por alto en los primeros borradores.
• Las restricciones descartan explícitamente desviaciones del alcance (scope creep), como algoritmos de programación automatizada o integraciones externas de nóminas.
• Los criterios de éxito orientan el resultado hacia la preparación para ingeniería y la capacidad de ser probado, en lugar de hacia una exhaustividad meramente superficial.

Adáptalo a tus necesidades

Crea una versión personalizada con PromptDeck sustituyendo el escenario ficticio por tu propio contexto, audiencia y restricciones. Conserva los pasos de verificación para que el resultado final refleje fielmente lo que ya conoces.