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

PRINCIPALES CONCLUSIONES

• En un documento de requisitos del producto (PRD) se define la finalidad, las funciones y el comportamiento de un producto, lo que alinea a las partes interesadas y el desarrollo guía.

• Los PRD ágiles se centran en la comprensión compartida, las necesidades de los clientes y la flexibilidad, y se evitan las especificaciones demasiado detalladas.

• Los PRD eficaces incluyen metas, suposiciones, historias de usuario, diseños y elementos claros que están fuera de alcance, lo que fomenta la colaboración y la adaptabilidad.

• Colabora con tu equipo para crear y actualizar periódicamente un PRD conciso y así garantizarás la claridad y la alineación a lo largo del proyecto.

Crear un producto de éxito comienza con una dirección y una alineación claras. Ahí es donde entra en juego el documento de requisitos del producto (PRD, por sus siglas en inglés).

Un PRD describe las características esenciales, metas y funciones de un producto, que sirve como hoja de ruta del producto para que los equipos conviertan las ideas en realidad. Este es un paso crucial para cualquier gestor de productos que necesite adaptar equipos, partes interesadas y las metas generales.

En este artículo, desglosaremos qué es un documento de requisitos del producto, por qué es importante y cómo sienta las bases para un desarrollo de producto eficaz.

¿Qué es un documento de requisitos de producto (PRD)?

Un documento de requisitos del producto (PRD) define el producto que se va a crear al describir el propósito, las características, las funciones y el comportamiento del producto.

Define el propósito del producto, sus características clave, las necesidades de los usuarios y los criterios de éxito, lo que lo convierte en una única fuente de información para los equipos multifuncionales.

Al documentar claramente los requisitos y las expectativas, un PRD ayuda a garantizar que todas las personas (desde diseñadores y desarrolladores hasta partes interesadas) se mantengan alineadas durante todo el proceso de desarrollo del producto.

Documento de requisitos del producto para la actividad ágil

¿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. Los requisitos de la metodología ágil son los mejores amigos del propietario de un producto.

Los propietarios de productos que no utilizan requisitos de la metodología ágil se ven envueltos en especificar cada detalle para entregar el software adecuado (y luego cruzan los dedos esperando haber especificado las cosas correctas). Por otro lado, los requisitos ágiles también dependen de un entendimiento compartido del cliente.

Esto se comparte entre el propietario del producto, el diseñador y el equipo de desarrollo. Esa comprensión y empatía compartidas por el cliente objetivo desbloquea un ancho de banda oculto para los propietarios de los productos.

Pueden centrarse en los requisitos de nivel superior y dejar los detalles de la implementación al equipo de desarrollo, que está totalmente equipado para hacerlo gracias al entendimiento compartido.

Consejos para crear un documento de requisitos del producto eficaz

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 evaluación de actividades 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.

¿Quieres probarlo? Regístrate en 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

Has hablado de un conjunto de historias de usuario con tu ingeniero y diseñador. Has ido y venido, has tenido algunas sesiones de pizarra y has concluido que hay algunas dimensiones más que necesitas considerar para esta función en la que estás trabajando.

Debes desarrollar algunas suposiciones que estás haciendo, reflexionar sobre cómo esto encaja en el esquema general de las cosas y realizar un seguimiento de todas las preguntas abiertas que tienes que responder. ¿Y ahora qué?

¿Qué debe incluir una gestión del ciclo de vida de los productos?

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. Define 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 al grano. Informa, no aburras. Tener el software adecuado para detallar estas metas, en una vista fácil de leer, es útil para todos los involucrados.

Los objetivos empresariales deben ser claros y directos, pero también lo suficientemente informativos para adaptarse a las partes interesadas. No dejes que los demás hagan suposiciones.

3. Contexto y encaje estratégico

La sección de fondo explica la motivación que hay detrás del producto o función y cómo se adapta a las metas más amplias de la empresa. Proporciona contexto sobre por qué el proyecto es importante y qué problemas pretende resolver.

Detallar el ajuste estratégico garantiza que todo el mundo entienda cómo esta actividad respalda la visión y las prioridades de la organización. Esta claridad ayuda a los equipos a mantenerse centrados en entregar valor que importa.

4. Suposiciones

Esta sección describe las suposiciones que el equipo hace sobre la tecnología, las necesidades empresariales o el comportamiento del usuario. Establecer claramente las suposiciones ayuda a identificar riesgos potenciales y áreas que pueden necesitar validación.

Además, garantiza que todas las personas estén al tanto de los factores que influyen en las decisiones y la planificación. Revisar estas suposiciones a lo largo del proyecto puede ayudar a los equipos a adaptarse a medida que surge nueva información.

5. Historias de usuario

Enumera o proporciona enlaces a las historias de usuario implicadas. 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 va entendiendo los problemas que hay que resolver, es frecuente que surjan preguntas. Crea una tabla de lo que hay que decidir o investigar para hacer un seguimiento de estos asuntos.

8. Lo que no estamos haciendo

Mantén al equipo centrado en el trabajo que hay que sacar adelante señalando con claridad las tareas que no hay que hacer. Indica todo aquello que no forma parte del alcance actual, pero que puede serlo en el futuro.

Ventajas de un documento de requisitos del producto bien redactado

Si vas a llevarte algo de este blog, entiende el “por qué”, no el “qué”, porque el “por qué” te ayudará a explorar qué es lo mejor para tu equipo.

Estos son las ventajas y los desafíos que hemos observado con el enfoque de panel de una página:

1. Una página, una fuente

Apuesta por la sencillez. 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 ahorra tiempo a los miembros del equipo a la hora de 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 aplicando la 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 de ellos en los documentos de requisitos del producto, puesto que ayudan a sintetizar la complejidad y a revelar paulatinamente la información al lector cuando proceda.

Entre los recursos detallados enlazados se pueden incluir:

• 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

Cuando las historias están más o menos pensadas e introducidas como actividades en Jira, las vinculamos a nuestra página (lo cual también crea cómodamente un enlace de las actividades a la página).

Con la sincronización bidireccional entre Confluence y Jira, podemos ver automáticamente el estado actual de cada actividad desde la página de requisitos.

5. Sabiduría colectiva

Captar requisitos del producto con Confluence permite que las personas de otros equipos contribuyan y hagan sugerencias sin problemas. Me sorprende la de veces que alguien de otro equipo se ha metido en la conversación para enviar un comentario positivo, sugerencias o lecciones aprendidas en proyectos similares.

Así se consigue que una gran organización parezca un equipo pequeño.

6. “Extras” atractivos

Los diagramas creados con herramientas como pizarras de Confluence comunican mejor los problemas a tu equipo. También puedes insertar imágenes, vídeos y contenido dinámico externos.

7. Colaboración

Lo más importante de esto es que todo el mundo participe. No redactes 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.

Desafíos de los documentos de requisitos del producto

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 escriba 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.

Ponte a trabajar en tu PRD con Jira y Confluence

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 trabajo 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.

Recuerda ser ágil en la evolución de los requisitos de un proyecto. Está bien cambiar las historias de usuario a medida que el equipo crea, lanza y recibe comentarios. Mantén siempre un bar de alta calidad y una cultura de ingeniería sana, aunque eso signifique lanzar menos funciones.