Requisitos de producto: cómo redactar un PRD a partir de entrevistas
Convierte entrevistas en un documento de requisitos: problema, escenarios, restricciones, alcance de la versión y criterios de verificación. Incluye plantilla y ejemplo.
Pedir un botón no basta para entender la tarea
Un cliente dice «Añadid un botón de exportación». Queda por saber quién necesita el archivo, qué contiene y qué hará con él. Un documento de requisitos de producto, o PRD, permite que el equipo entienda igual la tarea y sus límites.
Esta guía aborda un documento breve para una función. La arquitectura, el contrato y los requisitos técnicos de la organización conservan su función. El PRD hace verificable el problema antes de elegir una implementación.
De la petición del usuario a los requisitos
Vuelve al último caso real
Pregunta cuándo necesitó exportar, qué hizo en su lugar, qué datos trasladó y dónde tuvo dificultades. Marca el ejemplo y la consecuencia en la transcripción. «Es incómodo» necesita detalles para poder comprobar una mejora.
Describe el escenario antes de decidir la interfaz
Anota quién inicia la acción, con qué datos y qué resultado espera. Un botón, un correo o un informe automático son soluciones posibles. Revisa la necesidad y las restricciones antes de convertir la primera propuesta en requisito.
Delimita la versión
Escribe qué incluye la tarea y qué queda fuera deliberadamente. Enumera aparte los permisos, los datos y los casos sin resultados. Acuerda las condiciones de medición antes de fijar requisitos de velocidad o volumen.
Redacta la verificación
Describe un resultado observable y entradas de ejemplo para cada requisito. Relaciona la prueba con el problema original. Si un punto sigue sin confirmar, déjalo como pregunta abierta con una persona responsable y una fecha para resolverlo.
Exportar una lista de consultas cerradas
El ejemplo es ficticio. Nombres, condiciones y resultados solo ilustran el método.
Cada viernes copio a mano las consultas cerradas a una hoja. Al responsable le hacen falta el asunto, la fecha de cierre y la persona asignada. La conversación no hace falta.
La necesidad es compartir determinados datos de un periodo. La entrevista no pide exportar toda la base, los adjuntos ni la conversación completa.
Criterio de ejemplo: al elegir un periodo, la exportación incluye las consultas cerradas en ese periodo y solo los campos acordados. Aclara aparte cómo se tratan los límites de fechas.
| Elemento del PRD | Ejemplo completado | Estado |
|---|---|---|
| Usuario | Responsable de soporte | Confirmado en la entrevista |
| Campos | Asunto, fecha de cierre, responsable | Comprobar con el destinatario |
| Fuera de esta versión | Conversación y adjuntos | Pendiente de acuerdo |
| Pregunta abierta | ¿Qué zona horaria define los límites del periodo? | Requiere respuesta |
Plantilla PRD para una función
Vincula cada requisito con una observación. Una fuente puede respaldar varios puntos, pero hay que confirmar que estén acordados.
Nombre y versión de la función: Problema del usuario: Caso concreto de la entrevista: Usuario y contexto: Escenario principal: Resultado esperado: Datos y restricciones: Dentro y fuera del alcance: Criterios de verificación: Supuestos y preguntas abiertas: Fuentes y códigos de tiempo: Quién aprobó y cuándo:
¿Se pueden verificar los requisitos sin el autor?
- Cada requisito explica qué problema resuelve.
- El resultado comprobable se distingue de la implementación.
- Los límites de la versión están definidos.
- Las preguntas abiertas están señaladas.
Veamos los detalles
¿Se puede redactar un PRD solo con los deseos del cliente?
Se puede preparar un borrador. Comprueba escenarios y restricciones reales. Un deseo describe una posible solución y quizá deje sin explicar el problema del futuro usuario.
¿Cuánto debe medir el documento?
Lo suficiente para entender el escenario, alcance, restricciones y verificación. Para una función pequeña suele ser más práctico un documento breve con ejemplos que un texto largo sobre objetivos generales.