Plantilla y guía del documento de requisitos del producto

Share on X (Twitter)Share on FacebookShare on LinkedInShare on Email

Es el año 1982, IBM es una de las empresas más innovadoras del mundo y un ingeniero escribe un documento de requisitos del producto (PRD) antes de iniciar el proyecto en cascada que lanzaría una nueva característica para una IBM PC.

40 años después, Amazon es una de las empresas más innovadoras del mundo y un gerente de producto escribe un PRD durante el descubrimiento para que un equipo ágil lance una nueva iteración de producto en AWS.

¿No es extraño que haya cambiado tanto, pero que la gente siga usando los PRD prácticamente con la misma frecuencia? Junto con las hojas de ruta, esta reliquia del pasado sobrevivió a la mayoría de las prácticas obsoletas de los proyectos de software por una razón, y eso es lo que explorarás aquí.

Los PRD son tan poderosos e importantes que constituyen uno de los pocos denominadores comunes entre las fábricas de características y las empresas líderes en productos, las que se posicionan en la parte baja del mercado y los gigantes tecnológicos de primer nivel. Si bien no existe un modelo estándar de cómo debería ser un PRD, su uso tan común permite identificar sus puntos en común y reflexionar sobre qué hace que un PRD sea tan efectivo en la industria del software.

¿Qué es un PRD?

Un documento de requisitos del producto (PRD) tiene un título que se explica por sí solo. En esencia, un PRD es un registro del concepto de un producto en términos de alcance y objetivos. Generalmente es responsabilidad del gerente de producto, pero no se limita exclusivamente al equipo de producto. Un PRD debe poder distribuirse sin problemas entre ingeniería, diseño, control de calidad, marketing, ventas y altos ejecutivos.

A pesar de mi reflexión inicial, los PRD han cambiado sustancialmente en cuanto a su aplicabilidad. Si antes eran un documento de referencia inamovible para la gestión de proyectos, hoy son documentos dinámicos y en constante evolución que ofrecen guías y conocimiento acumulado para los equipos técnicos.

Para escribir este artículo, investigué decenas de plantillas de PRD de varias empresas diferentes (algunas consideradas como muy maduras en cuanto a productos, otras no tanto) y determiné cuál sería la mejor plantilla de documento de requisitos de producto posible, o al menos la más común.

¿Por qué necesita un documento de requisitos del producto?

Cada organización tiene razones ligeramente diferentes para impulsar un PRD, pero casi todas son válidas. Como regla general, un PRD es documentación que puede utilizarse durante las conversaciones de diseño, la gestión de las partes interesadas o la referenciación del desarrollo. Debe cambiar a medida que evolucionan el descubrimiento y la entrega del producto, adaptándose a la realidad en lugar de mantenerse fiel a una concepción original que puede quedar obsoleta con bastante rapidez.

Muchas críticas sobre los documentos de requisitos de producto se deben a que requieren mucho tiempo para desarrollarse, son demasiado largos para que los lea cualquier parte interesada o desarrollador, y por ello suelen quedar archivados durante el desarrollo. Puede parecer una pérdida de tiempo, pero no tiene por qué serlo. De hecho, los documentos de requisitos de producto son la columna vertebral de algunas de las mejores empresas de productos, y así es como los utilizan.

¿Cómo escribir un PRD?

Para ayudarle a comenzar a escribir su propio PRD, puede seguir estos cinco pasos:

1. Comienza con el porqué

Para deleite de Simon Sinek , su famoso mantra empresarial también se aplica a la redacción de PRD. Google, Microsoft, Amazon, Figma; es muy común entre las grandes empresas crear documentos de requisitos que comiencen explicando por qué se requiere ese producto en primer lugar.

Podemos obsesionarnos fácilmente con toda la escritura y documentación que implica definir la solución, pero los documentos de requisitos del producto también son excelentes para el seguimiento estratégico. Cinco meses después del desarrollo, tras la cuarta iteración, no es raro que el trabajo se desvíe de su objetivo original. El hecho de haber captado el porqué del inicio de un producto garantiza que se puedan reevaluar adecuadamente las prioridades cuando las estrategias exijan cambios, o que no se pierda el valor que se pretendía ofrecer inicialmente.

No dude en cambiar esto a medida que el producto evoluciona. A medida que surgen las limitaciones comerciales y técnicas, no solo puede, sino que debe, actualizar la motivación detrás de un producto. Es perfectamente razonable que una idea de producto fracase incluso antes de comenzar el desarrollo si el descubrimiento invalida su caso de uso.

2. Prepárese para el éxito

Una vez documentado el motivo de tu creación, debes establecer cómo garantizar que cumpla con ese objetivo. Con demasiada frecuencia, los equipos entregan algo en producción solo para descubrir posteriormente que carecen de los medios para medir el alcance total de su impacto.

No se puede iterar sobre lo que no se puede medir. Si no se tienen en cuenta los datos, cualquier cambio es prácticamente una suposición y se puede desviar del objetivo original. Definir cómo se puede medir el impacto del producto también es una forma de conectar la posible entrega con el objetivo original.

De manera similar al “por qué”, el descubrimiento puede (y probablemente lo hará) cambiar la mejor manera de medir el impacto de su producto.

3. Vaya al grano

Aquí es donde la mayoría de las plantillas de PRD difieren. Algunos esperan que esta sección sea lo más exhaustiva posible, mientras que otros solo piden una descripción general de las características. Algunos incluso van un poco más allá y se vuelven lúdicos, simulando una carta de relaciones públicas o una sección de preguntas frecuentes (te estoy hablando, Amazon).

El uso de una u otra plantilla depende principalmente de la cultura de su organización o de las prácticas preferidas del equipo. En cualquier caso, la descripción de su solución debe ser adecuada y completa para ofrecer una visión de cómo se verá el producto una vez finalizado. El PRD también está diseñado para compartir información con toda la organización, por lo que es importante asegurarse de cubrir todos los posibles intereses de las partes interesadas.

Redactar una descripción del producto para ingenieros es completamente diferente a hacerlo para el equipo de marketing, diseñadores u otros gerentes de producto. Identifique a su público objetivo principal y adapte la descripción del producto a sus intereses. Algunas plantillas incluso sugieren redactarla con diferentes niveles de detalle, ofreciendo una descripción exhaustiva y general del producto.

4. Sea conciso

La mayoría de la gente detesta leer, sobre todo documentación poco interesante. Asegúrate de transmitir tu mensaje sin gastar demasiadas palabras. Un PRD debe ser leído; no hay razón para que esta experiencia sea desagradable.

Una idea interesante que incorporan algunas plantillas, y que personalmente me gusta usar, es usar imágenes en tu PRD: impresiones, simulacros, flujos de trabajo, diagramas… las imágenes te ayudan a dedicar menos tiempo a describir detalles y te dan tiempo para cubrir los conocimientos más importantes que quieras registrar. Lo mismo puede decirse de los enlaces URL a recursos externos, como documentación técnica o PRD anteriores.

Asegúrate de mantener las imágenes y los enlaces actualizados. Puede que te suponga más trabajo mantener las imágenes, las URL y el texto actualizados, pero te aseguro que la mejora en la eficiencia y la eficacia de la lectura lo compensará.

5. No te preocupes tanto por el formato

Dejando de lado las plantillas, no dediques tanto tiempo a encontrar el formato ideal. Siempre que te asegures de que se cumplan los puntos anteriores y de que quien lea tus documentos quede satisfecho, los resultados hablan por sí solos y no pierdes mucho al usar el modelo A o B del PRD.

Algunos equipos redactan los PRD como epopeyas de proyecto, otros mantienen una página de Confluence o Notion con toda la información relevante, y algunos utilizan el clásico sistema de carpetas y documentos de Office 360 ​​o Google Drive. El formato no es tan importante como el contenido, y no existe una única forma ideal de crear PRD.

Lo mejor de los PRD es que son una de las pocas herramientas de una cultura orientada al producto que se pueden implementar sin la ayuda de la alta dirección. Incluso si eres el único que los usa en toda la organización, podrás sacarles provecho. En el peor de los casos, tendrás un documento claro al que recurrir siempre que necesites validar preguntas y suposiciones.

Plantillas de documentos de requisitos de productos del mundo real

Ahora que ya conoce las mejores prácticas para los PRD, veamos cómo algunas empresas abordan la creación de uno. Probablemente conozca bien estas empresas, pero cada una adopta un enfoque ligeramente diferente:

Google utiliza un PRD basado en esta plantilla aquí .

Por otro lado, Microsoft utiliza una versión con la que se puede comparar la anterior:

Reflexiones finales

Los documentos de requisitos de producto han sido un elemento básico en la industria tecnológica durante décadas, resistiendo el paso del tiempo y demostrando su potencial como herramienta. Desde una fábrica de características obsoleta hasta una empresa líder en productos, los PRD son una forma muy eficaz de conectar los conceptos iniciales con el producto final. El innegable valor que aporta un PRD bien elaborado reside en establecer una base común para toda la organización, ayudando a todos, desde ingenieros hasta profesionales del marketing, a mantenerse alineados con los objetivos del producto.

A pesar de las diferencias entre la gran cantidad de plantillas disponibles, la conclusión clave es que los PRD no son documentos estáticos. Deben ser elementos centrales del desarrollo del producto y evolucionar a medida que se desarrollan el descubrimiento y la entrega. Un PRD bien redactado, ya sea un documento, una página de Confluence o una épica de Jira, es una de las maneras más concretas de cristalizar su trabajo y aportar valor a su equipo.

Fuente de la imagen destacada: IconScout

Si quieres conocer otros artículos parecidos a Plantilla y guía del documento de requisitos del producto puedes visitar la categoría Guias.