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

Crear un buen producto requiere un montón de 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

When writing a requirements document, it's helpful to use a consistent template across the team so everyone can follow along and give feedback. At Atlassian, we use Confluence to create product requirements with the product requirements document template. We've found that the section below provides "just enough" context to understand a project's requirements and its impact on users:

1. Define los detalles específicos 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. Objetivos del equipo y empresariales 
Ve al grano. Informa, pero no aburras.

3. Contexto y encaje 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
Enumera las suposiciones técnicas, empresariales o de usuario que se estén haciendo.

5. Historias de usuario
Enumera o vincula historias de usuario. Incluye también vínculos a entrevistas de 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 el usuario
Después de que el equipo desarrolle la solución de cada historia de usuario, incluye un vínculo 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 no hacemos 
Mantén al equipo centrado en el trabajo que hay que realizar señalando claramente las tareas que no vas a llevar cabo. Indica todo aquello que no forma parte del alcance actual, pero que puede serlo en el futuro.

Pro Tip:

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.

 

Da igual 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 con todo lujo de detalles que hemos creamos 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 tampoco 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 darle una oportunidad? 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 una épica concreta. 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 extra
Lo increíble de utilizar una sola página para colaborar (en lugar de una herramienta de gestión de requisitos específica) es que puedes manejar la documentación con una 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. Contexto y detalles suficientes
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 vivas
Veo a muchos clientes que también lo hacen. Cuando las historias están más o menos pensadas e introducidas como tiques en Jira Software, las vinculamos a nuestra página (lo cual también crea, estratégicamente, un enlace desde los tiques hasta la página). Con la sincronización bidireccional entre Confluence y Jira Software, podemos ver automáticamente el estado actual de cada tique directamente desde la página de requisitos.

5. Sabiduría colectiva
Captar requisitos del producto con Confluence facilita que las personas de otros equipos 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 tú solo; 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 feedback 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 compensaciones 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 animarlos para que escriban más especificaciones e historias en nuestra intranet?". Es un hueso duro de roer y se reduce a varias técnicas de adopción de wikis en la organización. Hay montones de recursos que te pueden ayudar. Puede que haya en juego otros problemas de espíritu 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.