Documentos de requisitos del producto (versión reducida)

A nadie le gusta escribir documentos con requisitos del producto extensos y ultradetallados.
Pero resulta que a nadie le gusta usarlos tampoco.

Dan Radigan Dan Radigan
Buscar temas

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.

Documentos de requisitos de productos ágiles | Orientador ágil de Atlassian

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.

Reunir requisitos en un mundo á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. 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!).

Crear un entendimiento común entre los equipos

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 revisión de backlogs. Estas son buenas oportunidades para asegurarse de que todo el equipo está en sintonía y entiende por qué el propietario del producto ha priorizado el trabajo de ese modo.

¿Quieres darle una oportunidad? Regístrate o inicia sesión en Confluence >>

Crea una plantilla de entrevistas de clientes para documentar tu conocimiento del cliente. Sigue nuestro tutorial para empezar a dirigir entrevistas de clientes importantes:

Antipatrones ante los que estar alerta
  • Ya hay especificaciones detalladas de todo el proyecto antes de que empiece el trabajo de ingeniería
  • Se requieren revisiones exhaustivas y aprobaciones rigurosas de todos los equipos antes de que empiece el trabajo
  • Los diseñadores y desarrolladores no saben cuándo se han actualizado los requisitos
  • Los requisitos nunca llegan a actualizarse (dado que todos los aprobaron, ¿verdad?)
  • El propietario del producto escribe requisitos sin la participación del equipo

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?

Mantener requisitos esbeltos con un cuadro de mandos de una página

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?
Requisitos ágiles | Orientador ágil de Atlassian

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?

Requisitos de productos ágiles | Orientador ágil de Atlassian

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.

Historias de requisitos ágiles | Orientador ágil de Atlassian

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.

Consejo de experto:

El manifiesto ágil nos recuerda que podemos ser flexibles al crear requisitos. Algunos equipos hacen ejercicios de asignación de historias de usuario para identificar problemas y soluciones. A veces, la tríada completa del producto (propietario del producto, desarrollador y diseñador) visita a un cliente y se pone a buscar soluciones de un problema concreto que el cliente haya mencionado.

Independientemente de cómo se generen los requisitos, lo importante es que el equipo los considere una de las muchas formas de definir y comunicar los problemas del cliente. Consulta nuestra sección sobre diseño ágil para saber cómo los propietarios de productos pueden utilizar Keynote y PowerPoint para simular experiencias reales como si fueran requisitos.

Ejemplo de PRD de una página

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.

Documento de ejemplo de requisitos de productos | Orientador ágil de Atlassian
Documento de requisitos de productos | Orientador ágil de Atlassian

¿Quieres probarlo? Regístrate o inicia sesión en Confluence >>

Una vez que estás metido en el tema, elige la plantilla de requisitos del producto y sigue el tutorial que se muestra a continuación para ayudarte con la configuración de los requisitos:

Aportes fundamentales del método de una página:

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 Software, las vinculamos a nuestra página (lo cual también crea, estratégicamente, un enlace desde las incidencias hasta la página). Con la sincronización bidireccional entre Confluence y Jira Software podemos ver automáticamente el estado actual de cada incidencia directamente 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.

Dificultades

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.

Ahora, ¡a trabajar!

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.

Consejo de experto:

No realices el seguimiento de las historias de usuario que en un sistema sean requisitos del proyecto y en otro sean un defecto. Gestionar trabajo en dos sistemas es innecesariamente complicado y una pérdida de tiempo.

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.