Documentos de requisitos del producto (versión reducida)

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

Dan Radigan Dan Radigan
Browse topics

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

En un documento de requisitos del producto puedes definir el producto que vas a crear: el objetivo del producto, sus funciones, sus características y su 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; nos referimos a los equipos empresariales y técnicos que ayudarán a crear, lanzar o vender el producto.

Cuando todas las partes interesadas estén de acuerdo, el PRD actuará como una brújula, indicando la dirección exacta del objetivo del producto y garantizando 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 el 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 abren un mundo nuevo de posibilidades para 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 capacitado para ello, de nuevo, gracias a ese entendimiento común. ¡Toma ya! 

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:

  • Cuando se lleven a cabo entrevistas con los clientes, que participen también un miembro del equipo de diseño y otro del de desarrollo, de forma que obtengan la información directamente del cliente en lugar de depender de las notas del propietario del producto. Esto también les proporcionará la oportunidad de indagar aún más cuando el cliente siga teniendo el tema reciente.
  • Haz que el desarrollo y el uso de perfiles de clientes sea un esfuerzo de equipo. Cada miembro del equipo tiene unas perspectivas y unos puntos de vista únicos y deben comprender cómo los perfiles afectan al desarrollo del producto.
  • Asimismo, transforma la evaluación de incidencias y la limpieza del backlog en un deporte de equipo. Estos aspectos constituyen grandes oportunidades para garantizar que todo el mundo está en sintonía y para comprender por qué el propietario del producto ha establecido las prioridades de trabajo como lo ha hecho.

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

Crea una plantilla de entrevista de clientes para reflejar las perspectivas del cliente. Sigue los pasos de nuestro tutorial para aprender a realizar entrevistas a los clientes que resulten valiosas:

Antipatrones ante los que estar alerta
  • Todo el proyecto tiene las especificaciones definidas en gran detalle antes de que comience el trabajo de ingeniería
  • Se exige que todos los equipos realicen una revisión profunda y una aprobación definitiva de las especificaciones antes incluso de que comience el trabajo
  • Los diseñadores y los desarrolladores no saben cuándo se actualizan los requisitos
  • En realidad, los requisitos no se actualizan nunca (porque todo el mundo ya los ha aprobado, ¿recuerdas?)
  • El propietario del producto redacta los requisitos sin que participe el equipo 

Vale: has hablado de una serie de historias de usuario con el ingeniero y el diseñador. Tras darle varias vueltas y celebrar algunas sesiones de ideas, has concluido que hay que tener en cuenta algunas dimensiones más de la función 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 redactar un documento de requisitos, resulta útil establecer una plantilla uniforme para todo el equipo, de forma que todo el mundo pueda seguirla y proporcionar comentarios. En Atlassian, usamos Confluence para crear requisitos del producto con la plantilla del documento de requisitos del producto. Creemos que la siguiente sección proporciona el contexto justo para entender los requisitos del proyecto y su impacto sobre 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énes están involucrados? Incluye al propietario del producto, el equipo y 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á previsto el 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 en la creación de requisitos. Algunos equipos realizan asignaciones de historias de usuario para identificar problemas y soluciones. En ocasiones, la tríada completa del producto (propietario del producto, desarrollador y diseñador) visita a un cliente y realiza una lluvia de ideas para encontrar soluciones a un problema concreto que haya mencionado el cliente.

 

Da igual cómo se generen los requisitos, lo verdaderamente importante es que el equipo los considere como una de las muchas formas con las que pueden definir y comunicar problemas del cliente. Consulta nuestra sección sobre diseño ágil para aprender cómo los propietarios del producto pueden usar Keynote y PowerPoint para realizar modelos de experiencias reales a modo de 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 intentarlo? Regístrate o inicia sesión en Confluence >>

Una vez que estés dentro, elige el plano de requisitos del producto y sigue este tutorial para empezar a definir los requisitos:

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

La idea principal con la que debes quedarte de este post es que debes entender 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 panel 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 referencia para todo lo relacionado con el conjunto de problemas de un epic concreto. Disponer de una ubicación central de referencia les 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 sola 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, ya que ayudan a sintetizar la complejidad y a revelar paulatinamente la información al lector cuando proceda. Los recursos detallados enlazados pueden incluir elementos como:

  • Entrevistas con los clientes para proporcionar contexto, validación o más contenido de la función
  • Páginas o blogs en los que se desarrollan ideas similares
  • Documentación de debates o documentación técnica y diagramas anteriores
  • Vídeos de demos de productos u otro contenido relacionado 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 la contribución y las sugerencias de personas de otros equipos diferentes. Me sorprende la cantidad de veces que alguien de otro equipo se ha metido en la conversación para aportar comentarios positivos, 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 redactes 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 comentarios. Habla, haz 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 que hemos experimentado y que hemos observado también en los clientes:

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 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 animar a la gente 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 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 incidencias 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 vienes de los requisitos del proyecto en un sistema y se desvían a otro. 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. No pasa nada por cambiar historias de usuario a medida que el equipo compila, lanza y recibe comentarios. Mantén siempre un gran nivel de calidad y un espíritu técnico sanoincluso si eso implica lanzar menos funciones.