Crear un buen producto requiere mucha investigación y una planificación exhaustiva. ¿Por dónde empezar? Normalmente, los responsables 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 product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

¿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 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 de la metodología ágil también dependen de una comprensión compartida del cliente que comparten 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, una vez más, gracias a ese entendimiento compartido. (¡Toma ya!)

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.

¿Quieres darle una oportunidad? Regístrate o inicia sesión 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

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

Enumera las suposiciones técnicas, empresariales o del usuario que puedes estar haciendo.

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.

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

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

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 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. Captar "extras"

Los diagramas elaborados con herramientas como Visio, Gliffy o Balsamiq permiten comunicar 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 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.

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.

Recuerda, sé á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.