¿Qué es el Documento de Requerimientos de Producto (Product Requirements Document) y cómo se escribe?
La creación de un gran producto es un proceso largo que implica una gran cantidad de planificación, investigación y múltiples partes interesadas. Mantener a todos en la misma página y asegurarse de que todos se muevan en la misma dirección no es fácil.
Los Documentos de Requerimientos de Producto o PRD a menudo se asocian con la metodología de desarrollo en cascada. Según esta metodología, los requisitos del producto deben definirse con anticipación y documentarse en detalle.
Sin embargo, los PRD también se utilizan comúnmente en el desarrollo ágil, que adopta un enfoque de planificación más adaptable y flexible. En este caso, el PRD generalmente sigue el mismo formato, cubriendo el objetivo del producto, sus características y la línea de tiempo de desarrollo, sin embargo, ya no es un documento estático. En ágil, un PRD es un documento vivo y en evolución, donde los requisitos se agregan y se priorizan continuamente a lo largo del proceso de desarrollo.
¿Por qué realizar un PRD?
El objetivo principal de un PRD es alinear a todas las partes interesadas y crear un entendimiento compartido.
La entrega exitosa de un producto o una función requiere la colaboración de varios equipos, incluidos los de ingeniería, diseño, ventas, soporte y marketing. Un PRD marca el rumbo del lanzamiento, manteniendo a todos los colaboradores sincronizados y asegurando que se entregue a tiempo lo que los clientes desean.
Un PRD es el punto de partida, en función del cual otros equipos planificarán sus propias acciones y crearán artefactos relevantes, incluidas especificaciones funcionales.
¿Cómo redactar un documento de requisitos?
Hay varios puntos a tener en cuenta al escribir un documento de requisitos de producto:
Un PRD no tiene por qué ser un documento extenso. En algunos casos, puede caber en una sola página.
Escribir un PRD es un proceso colaborativo. Para garantizar que todos permanezcan en sintonía, todas las partes interesadas deben contribuir continuamente.
Un PRD nunca está realmente completo. Evoluciona con el proyecto y debe actualizarse semanalmente o incluso diariamente.
Por todo esto, se debe elegir cuidadosamente la herramienta que va a utilizar para su PRD. En el pasado, la mayoría de los equipos usaban Microsoft Word para crear y administrar sus PRD. Esto inevitablemente llevó a PRD desactualizados e inexactos rebotando en las bandejas de entrada del equipo. Lo aconsejable es utilizar una herramienta en línea que facilite la colaboración y garantice que todos tengan siempre la última versión para evitar confusiones.
En cuanto a qué incluir en su documento, un PRD puede seguir diferentes formatos, pero normalmente se cubren varios temas específicos.
1. Definir el propósito del producto. Un PRD se inicia describiendo el propósito del producto o característica que está desarrollando. Todas las partes interesadas deben estar firmemente alineadas con él. Se puede resumir respondiendo a tres preguntas principales:
· ¿Qué problemas resuelve este producto?
· ¿Quién usará este producto?
· ¿Por qué es importante?
2. Resumir las características del producto. El siguiente paso es determinar los requisitos de las funciones. Cada característica que se incluye debe estar impulsada por el propósito que describió en la sección anterior. Para cada función, debe incluir una descripción, objetivo y caso de uso como mínimo.
Key point: explicar lo que debe crearse para que el equipo de desarrollo pueda determinar la mejor manera de implementarlo (por ejemplo ayudas visuales para comunicar exactamente lo que está visualizando).
3. Priorizar las funcionalidades dentro cada release. En este punto hay que incluir una lista de los requisitos previos que debe cumplir el producto para que esté listo para su lanzamiento público. Puede seguirse el criterio RICE que pondera los siguientes criterios:
R = Reach (Alcance): valorar cuántas personas serán afectadas por la funcionalidad en un periodo concreto.
I = Impact (Impacto): cómo de alineada está la funcionalidad con la estrategia del producto y su filosofía.
C = Confidence (Confianza): determinar el nivel de confianza que se tiene en que la funcionalidad será un éxito.
E = Effort (Esfuerzo): O el esfuerzo necesario para que se pueda añadir (y que funcione correctamente) la característica.
4. Establecer un Roadmap. En esta sección se describe qué se entregará y cuándo. Una estimación aproximada puede ayudar enormemente a las partes interesadas de su proyecto a planificar su trabajo. El foco debe estar en los hitos y dependencias clave para mantener a todos en el camino correcto y dejar espacio para cambios.
5. Definir las métricas de éxito. Es importante decidir por adelantado como se medirá el éxito del nuevo producto o función. Se puede realizar creando una hipótesis sobre el impacto previsto de una función y estableciendo objetivos medibles en base a:
Proporción de usuarios que interactúan con la función.
Con qué frecuencia los usuarios interactúan con la función.
Cuánto tiempo pasan los usuarios interactuando con la función.
Resumen: Un documento de requisitos de producto (PRD) define el valor y el propósito de un producto o feature. Está escrito por el Product Manager en armonia con el equipo y tiene como finalidad comunicar lo que se está creando, para quién es y cómo beneficia al usuario final. Debe seguir un enfoque de alto nivel que comience con la visión general de lo que quiere lograr. Por lo tanto,
deben vincular los objetivos e iniciativas del producto con las características necesarias para lograr esa visión
incluyen detalles sobre cómo el usuario final interactuará con la funcionalidad y cómo se verá.
no necesitan ser documentos extensos. La intención del documento es alinear a todos en torno a las capacidades clave que deben entregar los sprints
No hay dos documentos de requisitos de producto iguales. Sin embargo, una plantilla de PRD puede ser un buen punto de partida y puede utilizarse como base para la creación de futuros documentos.
