How to Achieve ARP4754A Development Assurance in Aerospace Programs
Check out the importance of ARP4754A, the ARP4754A development cycle,...
¿Cómo crear el documento de requisitos del producto (PRD) perfecto?
Desarrollar sin tener las ideas claras es la forma más rápida de retrasar un producto.
A menudo, los equipos comienzan a desarrollar el producto con información incompleta o comentarios dispersos. Dan por sentado que las notas de las reuniones y los chats son suficientes para empezar. Pero no lo son. Esto da lugar a confusión, a que se pasen por alto casos de uso y a un sinfín de idas y venidas durante el desarrollo.
El documento de requisitos del producto (PRD) se elabora para aportar claridad antes de que comience el desarrollo. En él se describen las funcionalidades que se van a desarrollar, los problemas que pretenden resolver y qué es lo que debe entregarse en el producto final.
Tanto si eres gestor de producto como parte interesada del negocio, esta guía te ayudará a comprender qué es un PRD, cuáles son sus componentes clave y a seguir un proceso paso a paso para elaborar un PRD eficaz.
¿Qué es un documento de requisitos del producto (PRD)?
Un PRD, o documento de requisitos del producto, define claramente qué producto hay que desarrollar y por qué, antes de que comience el desarrollo propiamente dicho.
Un PRD bien redactado no es una mera formalidad, sino que está diseñado para que el trabajo avance sin confusiones.
Algunos de los aspectos fundamentales que suelen incluirse en un PRD:
- Objetivos empresariales
- ¿Qué funciones forman parte del alcance actual?
- Detalles sobre la experiencia del usuario
- ¿Qué se debe evitar o dejar de lado por ahora?
Posteriormente, los analistas de negocios y otros miembros del equipo utilizan el PRD para elaborar un documento de especificaciones de requisitos del sistema, en el que se definen en detalle los requisitos funcionales y no funcionales del sistema.
¿Sabías que... A menudo se dice que «un PRD es el amigo silencioso del gestor de producto»?
En qué se diferencia un PRD de un documento de requisitos empresariales (BRD)
Elemento diferenciador | PRD (Documento de requisitos del producto) | BRD (Documento de requisitos de negocio) |
|---|---|---|
Objetivo | En él se detallan los aspectos relativos al funcionamiento del producto desde el punto de vista del usuario final.
| Explica los objetivos empresariales, las necesidades y las expectativas que subyacen al proyecto.
|
Tipo de contenido | Necesidades funcionales, historias de usuario, alcance de las funcionalidades y flujos básicos. | Problemas empresariales, expectativas de retorno de la inversión, riesgos y justificaciones de costes. |
Nivel de detalle | Nivel medio, centrado en las funciones y las necesidades de los usuarios | De alto nivel, centrado en los objetivos empresariales y en el valor |
Titularidad | Normalmente redactadas por los responsables de producto | A menudo los elaboran analistas de negocios o jefes de proyecto |
Público | Responsables de producto, diseñadores, desarrolladores, evaluadores | Las partes interesadas de la empresa, los patrocinadores de los proyectos, los clientes y, en ocasiones, los equipos de producto |
Momento oportuno | Se utiliza antes y durante el diseño y el desarrollo del producto | Normalmente se elaboran antes de que un proyecto obtenga la aprobación del presupuesto o el visto bueno |
Enfoque en los resultados | Qué desarrollar y por qué es importante para los usuarios | Por qué es importante el proyecto para la empresa y qué resultados se esperan |
Elementos clave de un documento de requisitos del producto
No hay elementos fijos que debas incluir en el documento de requisitos del producto.
En la imagen siguiente, puedes ver las listas de componentes que utiliza un jefe de proyectos sénior:
A continuación, enumeramos algunos elementos que se suelen utilizar para elaborar un PRD:
- Objetivo: Definir por qué se está desarrollando el producto, quién lo utilizará, qué problema resuelve y cómo encaja con el objetivo de la empresa.
- Características: Describe las características principales del producto. Además, detalla los requisitos.
- Alcance: Enumera lo que se incluirá en la versión. En algunos casos, también se menciona aquí lo que no se incluye.
- Calendario del proyecto: Indique el calendario estimado para cada hito.
- Cuestiones pendientes: aspectos que aún no se han decidido. Mantenerlos a la vista ayuda a los equipos a evitar confusiones más adelante.
Cómo redactar un documento de requisitos del producto (paso a paso)
El objetivo principal de redactar el PRD es alinear al equipo de producto y desarrollo en torno a un objetivo común. Los equipos pueden seguir el proceso paso a paso que se indica a continuación para redactar un documento PRD sólido:
1. Empieza por el problema, no por la solución
Al principio, resume el problema y explica por qué estás desarrollando el producto.
- Ejemplo: «Los usuarios abandonan el proceso de pago porque no pueden iniciar sesión como invitados».
Una frase como esta define el objetivo de la función. Si el problema no queda claro, es probable que la función no dé en el blanco.
2. Enumera los objetivos en un lenguaje sencillo
Evita las florituras. Explica con claridad qué es lo que el producto o la función debe lograr. Basta con una o dos líneas.
- Ejemplo: «Permite a los usuarios realizar compras sin necesidad de crear una cuenta».
Esto ayuda al equipo a centrarse. Si más adelante se añaden elementos adicionales, se pueden sopesar en relación con el objetivo original.
3. Definir qué entra dentro del alcance y qué no
Además, define qué está incluido y qué queda excluido del producto. De este modo, los equipos sabrán qué funcionalidades se incluirán y cuáles se excluirán en la próxima versión.
- Por ejemplo:
- En el alcance: añadir inicio de sesión para invitados, enviar correo electrónico de confirmación.
- Fuera del alcance: Guardar los datos del usuario para futuras visitas.
Pequeñas notas como estas evitan malentendidos más adelante.
4. Características de la lista
Ahora escribe lo que debe hacer el sistema. Utiliza puntos breves y claros. Escribe con un lenguaje sencillo y conciso.
Ejemplo:
- Si el usuario selecciona «Finalizar compra como invitado», omite la creación de la cuenta
- Es necesario registrar la dirección de correo electrónico antes de realizar el pago
- La confirmación del pedido debe enviarse en un plazo de 5 minutos
Además, asegúrate de definir claramente los requisitos funcionales y no funcionales de alto nivel.
5. Añadir el calendario de lanzamiento del producto
Nadie puede determinar el plazo exacto para terminar el producto. Sin embargo, sí se puede establecer el plazo estimado para completar cada función de la versión. A partir de los plazos fijados, los equipos de desarrollo pueden priorizar el desarrollo de las funciones.
Ejemplo:
- El inicio de sesión a través de redes sociales debería implementarse en los primeros cinco días hábiles.
- Se prevén cambios en la API de pagos el próximo mes
Si se tiene esto en cuenta desde el principio, se pueden evitar sorpresas más adelante.
6. Definir los criterios de éxito
En esta sección, define los criterios que ayudarán a los equipos a determinar si el producto está terminado y listo para el cliente.
Por ejemplo:
- El 100 % de las transacciones válidas de los usuarios (alta/baja) se procesaron sin errores.
- No se han producido incidencias de seguridad relacionadas con el acceso no autorizado a cuentas.
7. Revisión por parte de las partes interesadas
Una vez creado el documento, asegúrate de que todas las partes interesadas lo revisen de forma conjunta. De este modo, los equipos pueden asegurarse de que no falte ninguna característica y de que todos los miembros del equipo estén en sintonía.
Un PRD no es algo que se redacta una vez y luego se olvida. Los equipos deben ir actualizándolo a medida que cambian los requisitos.
Descarga el documento PRD de demostración desde aquí.
Creación de documentos de requisitos de producto (PRD) utilizando Modern Requirements
Escribir los PRD en Microsoft Word puede parecer cómodo al principio, pero a menudo se convierte en un caos cuando los equipos crecen o los cambios se acumulan. No hay control de versiones. Las revisiones se realizan por correo electrónico. Las plantillas se copian y se editan manualmente, lo que aumenta el riesgo de que se pase algo por alto.
Es aquí donde conviene plantearse el uso de una herramienta adecuada de gestión de requisitos .
Con Modern Requirements4DevOps, los equipos pueden utilizar los Smart Docs para redactar PRD directamente en Azure DevOps. Para crear un PRD, puedes utilizar las plantillas meta predefinidas o crear una nueva, tal y como se muestra en el vídeo a continuación.
Esta metaplantilla se puede reutilizar una y otra vez.
Además, cuenta con un editor similar al de Microsoft Word, lo que facilita la edición del documento. Los vídeos que se muestran a continuación explican cómo crear un documento e incorporar elementos de trabajo de Azure en tu PRD.
Además, ofrece un sistema de control de versiones para realizar un seguimiento de las distintas versiones del documento y un sistema de gestión de revisiones que permite revisar el documento de forma colaborativa.
Con el tiempo, el uso de Smart Docs ayuda a los equipos a redactar más rápido, revisar mejor y mantenerse sincronizados sin tener que cambiar de herramienta.
Índice
Artículos recientes
NIST RMF Requirements Traceability
Learn more about the importance of NIST RMF, what the...
NERC CIP Compliance Traceability for Energy & Utility Organizations
Learn more about the NERC IP compliance, which industries is...
