Cómo crear un documento de requisitos de productos (PRD)

Resumen: un documento de requisitos del producto (PRD) define los requisitos de un producto concreto, incluidos el propósito, las funciones, la funcionalidad y el comportamiento de este. Actúa como guía para los equipos empresariales y técnicos para ayudar en la compilación, el lanzamiento o la comercialización del producto.

Crear un buen producto requiere mucha investigación y una planificación exhaustiva. ¿Por dónde empezar? Normalmente, los gestores de productos empiezan con un documento de requisitos del producto (PRD).

Con un documento de requisitos del producto, puedes definir el producto que vayas a crear: describir el objetivo del producto, sus funcionalidades, características y comportamiento.

A continuación, puedes compartir el PRD con las partes interesadas y pedirles su opinión: equipos empresariales y ténicos, que ayudarán a crear, lanzar o vender el producto.

Cuando todas las partes interesadas estén de acuerdo, el PRD sirve de brújula, indicando la dirección exacta del objetivo del producto y asegurando un entendimiento común entre los equipos empresariales y técnicos.

¿Qué aspecto tiene el proceso de recopilación de requisitos en un mundo ágil? Puede parecer complicado y lo es. Pero no te preocupes. En Atlassian, lo sabemos todo sobre la creación de PRD en un entorno ágil. A continuación, presentamos algunos puntos a tener en cuenta:

Los requisitos ágiles son el mejor amigo del propietario del producto. Los propietarios de productos que no utilizan requisitos ágiles se ven atrapados en las especificaciones de cada detalle para entregar el software adecuado (y cruzan los dedos a la espera de haber especificado lo correcto). Los requisitos ágiles, por otro lado, dependen de un entendimiento común del cliente, compartido entre el propietario del producto, el diseñador y el equipo de desarrollo. Ese entendimiento común y esa empatía con el cliente potencial desbloquean el ancho de banda oculto de los propietarios de productos. Se pueden concentrar en los requisitos de nivel superior y dejar los detalles de la implementación en manos del equipo de desarrollo, que está totalmente equipado para ello (de nuevo, gracias a ese entendimiento común). (¡Toma!).

Si te entusiasma la idea del entendimiento común, pero no tienes ni idea de cómo crearlo, sigue estos consejos:

• Al llevar a cabo entrevistas a clientes, incluye a un miembro de los equipos de desarrollo y diseño para que tengan un contacto de primera mano con el cliente en lugar de depender de las notas del propietario del producto. También les dará la oportunidad de profundizar en el tema mientras todavía se encuentre fresco en la mente del cliente.
• Haz que el desarrollo y uso de perfiles segmentados de clientes sea un trabajo en equipo. Cada miembro del equipo tiene una perspectiva y conocimientos únicos, y necesita entender cómo los perfiles segmentados influyen en el desarrollo del producto.
• También deberías trabajar en equipo en la priorización de incidencias y la limpieza del backlog. Son buenas oportunidades para asegurarse de que todo el mundo esté en sintonía y entender por qué el propietario del producto ha priorizado el trabajo de ese modo.

Want to give it a try? Sign up or log into Confluence >>

Crea una plantilla de entrevistas de clientes para documentar los datos relevantes sobre los clientes. Sigue nuestro tutorial para empezar a dirigir entrevistas de clientes importantes:

• Crear páginas de entrevistas de clientes con preguntas perspicaces
• Convertir la información en conocimiento con la pirámide de entrevistas del cliente

Vale: has hablado de una serie de historias de usuario con el ingeniero y el diseñador. Tras darle varias vueltas y algunas sesiones de ideas, has concluido que hay que tener en cuenta algunas dimensiones más de la funcionalidad en la que estáis trabajando. Tienes que concretar algunas hipótesis que tienes, reflexionar sobre cómo encajarlo en el plan general de las cosas y realizar el seguimiento de todas las cuestiones pendientes que necesitan respuesta. ¿Y después?

Al escribir un documento de requisitos, ayuda utilizar una plantilla uniforme en el equipo, de modo que todos puedan seguirla y dar feedback. En Atlassian, usamos Confluence para crear requisitos del producto con la plantilla de documento de requisitos de productos. Hemos descubierto que esta sección proporciona el contexto "suficiente" para comprender los requisitos de un proyecto y su repercusión en los usuarios:

1. Definición de las especificaciones del proyecto
Recomendamos incluir instrucciones de alto nivel en la parte superior de la página de esta forma:

• Participantes: ¿Quién participa? Incluye el propietario del producto, el equipo, las partes interesadas
• Estado: ¿Cuál es el estado actual del programa? Cumple plazos, en peligro, retrasado, aplazado, etc.
• Objetivo de publicación: ¿Cuándo está planificado su lanzamiento?

2. Metas del equipo y objetivos empresariales
Ve directamente al grano. Informa, no aburras.

3. Contexto y enfoque estratégico
¿Por qué hacemos esto? ¿Cómo encaja en los objetivos generales de la empresa?

4. Suposiciones
Lista de suposiciones técnicas, empresariales o del usuario que puedes estar haciendo.

5. Historias de usuario
Especifica o proporciona enlaces a las historias de usuario relevantes. Incluye también enlaces a entrevistas a los clientes y capturas de pantalla de lo que hayas visto. Proporciona detalles suficientes para crear una historia completa y aporta métricas del éxito.

6. Diseño e interacción con los usuarios
Después de que el equipo desarrolle la solución de cada historia de usuario, incluye un enlace a los estudios de diseño y esquemas de la página.

7. Preguntas
A medida que el equipo vaya entendiendo los problemas que hay que resolver, es frecuente que surjan preguntas. Crea una tabla de lo que hay que decidir o investigar para realizar un seguimiento de estos asuntos.

8. Lo que queda fuera
Mantén al equipo centrado en el trabajo que hay que realizar señalando claramente las tareas que no hay que hacer. Indica todo aquello que no forma parte del alcance actual, pero que puede serlo en el futuro.

He aquí un documento de requisitos totalmente desarrollado que hemos creado con Confluence. No olvides que no puede haber dos requisitos del producto idénticos. Usa este ejemplo para comprender los distintos elementos que se deben incluir en el PRD, pero ten en cuenta que no es la única forma de hacerlo.

Si quieres sacar algo de este blog, entiende el "porqué", no el "qué", pues el "porqué" te ayudará a averiguar qué es lo mejor para tu equipo. Estas son las ventajas y las dificultades que hemos observado con el método del cuadro de mandos de una página:

1. Una página, una fuente
Sin complicaciones. El documento de requisitos del producto se convierte en la "página de destino" de todo lo relacionado con el conjunto de problemas de un epic concreto. Tener algo que sea un lugar central de rigor les ahorra tiempo a los miembros del equipo al acceder a esta información y les ofrece una perspectiva global.

2. Agilidad adicional
Lo increíble de utilizar una simple página para colaborar (en lugar de una herramienta de gestión de requisitos específica) es que puedes manejar la documentación mediante metodología ágil. No hace falta que sigas siempre el mismo formato: haz lo que necesites cuando lo necesites, y hazlo de forma ágil. Cambia todo lo que haga falta.

3. El contexto y los detalles justos
Muchas veces nos olvidamos del poder que tiene un simple enlace. Insertamos muchos enlaces en los documentos de requisitos del producto. Ayudan a sintetizar la complejidad y a revelar paulatinamente la información al lector cuando proceda. Los recursos detallados enlazados pueden incluir cosas como:

• Entrevistas a clientes para antecedentes, validación o un contexto amplio de la funcionalidad
• Páginas o blogs con propuestas de ideas similares
• Debates anteriores o documentación técnica y diagramas
• Vídeos de demostraciones de producto u otros contenidos relacionados de fuentes externas

4. Historias reales
Veo a muchos clientes que también lo hacen. Cuando las historias están más o menos pensadas e introducidas como incidencias en Jira, las vinculamos a nuestra página (lo cual también crea cómodamente un enlace desde las incidencias hasta la página). Con la sincronización bidireccional entre Confluence y Jira, podemos ver automáticamente el estado actual de cada incidencia desde la página de requisitos.

5. Sabiduría colectiva
Captar requisitos del producto con Confluence facilita las personas de otros equipos diferentes contribuyan y hagan sugerencias. Me sorprende la de veces que alguien de otro equipo se ha metido en la conversación para aportar un feedback positivo, sugerencias o lecciones aprendidas en proyectos similares. Así se consigue que una gran organización parezca un equipo pequeño.

6. Captar "extras"
Los diagramas realizados con herramientas como Visio, Gliffy o Balsamiq comunican mejor los problemas al equipo. También puedes insertar imágenes, vídeos y contenido dinámico externos.

7. ¡Colaboración!
Lo más importante de todo esto es que todo el mundo participe. No escribas nunca un documento de requisitos por tu cuenta; ten siempre un desarrollador al lado y escribidlo juntos. Comparte la página con tu equipo y pídeles feedback. Haz comentarios y preguntas, y anima al resto a contribuir con pensamientos e ideas. Esto es de especial importancia para los equipos distribuidos que no suelen tener la oportunidad de hablar sobre los proyectos en persona.

Todo método tiene un lado negativo. Estos son los dos obstáculos principales de los clientes que hemos observado y combatido:

1. La documentación se puede quedar obsoleta
¿Qué pasa si implementas una historia, recibes comentarios y modificas la solución? ¿Hay alguien que vaya y actualice la página de requisitos con la última implementación? Esta dificultad se presenta en cualquier tipo de documentación, y siempre cabe preguntarse si esas correcciones merecen la pena. Habla con tu equipo sobre qué haríais en una situación así.

2. Falta de participación
"¿Qué puedo hacer para alentar los comentarios?", "¿Cómo puedo animar a la gente a que escriban más especificaciones e historias en nuestra intranet?". Esta es una situación peliaguda que pasa por la adopción de las wikis en la organización. Hay montones de recursos que te pueden ayudar. Puede que también entren en juego otros problemas de cultura empresarial más profundos.

Si los requisitos son concisos, el propietario del producto tiene más tiempo para entender el mercado y mantener su ritmo. Además, las explicaciones breves ayudan al equipo de desarrollo a utilizar la implementación que se ajuste mejor a su estructura y recursos tecnológicos.

Una vez que los requisitos del proyecto estén desarrollados razonablemente bien, recomendamos vincular las historias de usuario de la sección 5 a sus historias correspondientes en el gestor de tiques del equipo de desarrollo. De este modo, el desarrollo es más transparente: resulta sencillo ver el estado de cada elemento de trabajo, lo cual permite una mejor toma de decisiones por parte del propietario del producto, así como de los equipos que intervienen más adelante, como los de marketing y asistencia técnica.

No olvides ser ágil en tu evolución de los requisitos de un proyecto. Está bien cambiar historias de usuario a medida que el equipo compila, lanza y recibe feedback. Mantén siempre un gran nivel de calidad y un espíritu técnico sano, aunque eso implique lanzar menos funcionalidades.