Como escribir un Documento de Requerimientos de Producto?
Product Management en Español
Hola, soy Charly! en esta serie de artículos iré contando el día de día como Product Manager, con sus aciertos y errores, los aprendizajes y el hands-on. Suscríbete gratis para recibir los nuevos posts y apoyar esta iniciativa.
En el día a día, planificar el trabajo y tener una visión clara de lo que se quiere lograr es fundamental para avanzar. Los equipos ágiles están descubriendo que agregar este tipo de documentos agrega valor en sus procesos.
Verdad incomoda: el 70% de los proyectos fallan debido a la falta de levantamiento de requerimientos.
De esta manera, para la creación de cualquier producto, documentar la visión, bases, características y más, es una buena práctica y se encuentra en lo que denominamos “Documento de Requerimientos de Producto - DRP”, o en ingles “Product Requirement Document - PRD”.
¿Que es un documento de requerimiento de producto?
El documento de requerimiento de producto, define lo que un producto debe llegar a ser. El DRP se concentra en el QUE vamos a construir. Así mismo nos sirve como una herramienta de comunicación entre stakeholders, incluyendo product managers, diseñadores, desarrolladores y otros miembros del equipo. Asegura que todos estén en la misma pagina, independientemente de las características/funcionalidades individuales. Pensemos como si fuera el roadmap que guía el desarrollo desde la concepción de la idea hasta que se completa el producto.
Como escribir el Documento de Requerimiento de Producto (DRP)
Definir la visión del producto
Debemos definir la vision y los objetivos de producto a alto nivel, ¿que problema resuelve?, ¿a que audiencia esta dirigido?, ¿que lo hace único?, miembros del equipo, fecha de lanzamiento, etc.
Esta sección define el tono para el resto del documento, así también ayuda a la alineación de los miembros del equipo en torno al desarrollo del producto.
Identificar funcionalidades clave
Debemos listar las funcionalidades principales que debe tener el producto. Debemos ser específicos y priorizar basados en la importancia. Debemos diferenciar entre funcionalidades/componentes “must-have” y “nice to have”, a fin de concentrar nuestros esfuerzos de manera efectiva.
Historias de usuario
Debemos crear historias de usuario para ejemplificar como diferentes usuarios interactuaran con el producto. Las historias de usuario ayudan a comprender las necesidades, los comportamientos y los escenarios de los usuarios finales.
Requerimientos funcionales
Debemos detallar los requerimientos funcionales del producto, como que acciones el usuario debe ser capaz de realizar, que funcionalidades deben estar incluidas, y como estas funcionalidades deben de trabajar. Esta sección provee una perspectiva técnica en como el producto debe operar.
Requerimientos no funcionales
Los requerimientos no funcionales se centran en las cualidades que debe tener el producto, tales como el rendimiento, escalabilidad, seguridad y usabilidad. Estos requerimientos aseguran que el producto no solo trabaje bien, pero que también cumpla con los estándares de calidad.
Restricciones
Debemos definir cualquier restricción que pueda impactar en el desarrollo o funcionalidad del producto. Esto incluye limitaciones en tecnología, tiempo, presupuesto u otro factor externo que necesite ser considerado.
Wireframes y Mockups
Debemos incluir wireframes o mockups que representen como el producto debería lucir y funcionar. Las ayudas visuales ayudan a los stakeholders a comprender mejor el diseño y la experiencia de usuario que se busca.
Criterios de aceptación
Debemos definir claramente los criterios de aceptación, los mismos determinan las condiciones que deben cumplirse para que cada requerimiento sea considerado como terminado (o completado). Esto ayuda a determinar cuando una funcionalidad (feature) esta lista para su liberación (release).
Compartir con stakeholders e iterar
Finalmente, compartir el DRP es una gran oportunidad para tener una retroalimentación temprana y que los stakeholders compren la idea del desarrollo del producto. Con la respuesta que se obtenga se deben hacer los cambios necesarios.
El desarrollo de producto es un procesos iterativo, así que debemos estar conscientes de que este documento se irá transformando y refinando a lo largo del ciclo de vida del producto.
El delicado arte de documentar en equipos ágiles
Documentar puede sentirse como una perdida de tiempo cuando estas en un equipo ágil que constantemente cambia y se adapta. Sin embargo tener un cierto nivel de planificación puede ayudarnos a prevenir el caos cuando las circunstancias, los objetivos de la empresa y otras cambien.
Un DRP es un documento guía para equipos ágiles y tradicionales. Utilízalo para:
Mapear el lanzamiento ideal
Pensar acerca del producto desde el punto de vista del usuario y
Apropiarte junto a tu equipo de lo que están construyendo.
Para cualquier comentario o sugerencia, puedes contactarme en mis redes sociales: