Cuándo Ágil experimentó por primera vez una adopción a gran escala a principios de la década de 2000, revolucionó el desarrollo de software program y las formas tradicionales de trabajar. Como resultado, muchos elementos básicos del enfoque Waterfall se consideraron obsoletos. Uno de ellos fue el documento de requisitos del producto (PRD).
El PRD fue alguna vez descrito como el “documento más importante el gerente de producto sostiene” por los tecnólogos Ben Horowitz y David Weiden, pero su relevancia y valor en desarrollo de productos ha sido objeto de acalorados debates durante las últimas dos décadas. Hay defensores apasionados, expertos que creen que ya no existe (ver esta publicación de weblog de 2006 del líder de pensamiento de productos Marty Cagan), y muchos otros sentados en la cerca.
Todos ellos tienen puntos válidos. Mi creencia, sin embargo, es que el problema no es ya sea utilizar un PRD, sino más bien cómo.
Organizaciones, productos y mercados todos crean un contexto único para el que no existe un PRD único para todos, pero al implementar estos consejos y sugerencias cuando corresponda, y al usar la plantilla gratuita que se proporciona a continuación, puede revivir el PRD y convertirlo en un componente valioso de su digital proceso de desarrollo de productos.
Documento de requisitos del valor de un buen producto
En mis muchos años trabajando como gerente de producto con varios clientes y equipos, he encontrado que el PRD es una herramienta extremadamente útil, pero su valor depende de cómo lo utilice y de lo que contenga. Cuando un PRD se diseña cuidadosamente y se usa con cuidado, estos son algunos de los beneficios de alto nivel que puede esperar:
Alineación interna: Un PRD es una gran herramienta para lograr la alineación del equipo, particularmente en remoto o configuraciones asincrónicas. Actúa como un documento guía, asegurando que el equipo comprenda lo que están construyendo, lo que no están construyendo, por qué lo están construyendo, cuáles son las prioridades y cómo se medirá el éxito.
Alineación externa: Un PRD puede tener los mismos resultados para otras partes interesadas y clientes, ayudando a los equipos a administrar el alcance y los resultados de su proyecto de manera transparente y comunicar los cambios de manera proactiva.
Colaboración: No existe un PRD para habilitar la autocracia del gerente de producto o de cualquier individuo. Más bien, es una herramienta de y para colaboración continua. Es un lugar donde ingenieros, diseñadores y gerentes de producto pueden reunirse para trabajar en la definición de historias de usuarios, por ejemplo, o crear un diálogo continuo con los clientes sobre objetivos y prioridades a medida que los contextos evolucionan y surgen nuevos aprendizajes.
Para crear un PRD habilitado para Agile y cosechar estos beneficios, hay varias trampas comunes que usted y su equipo deben evitar.
Cómo evitar trampas comunes
Antes del dominio de Agile, el PRD estaba en el centro de desarrollo de software program, capturando la esencia misma del producto. Debido a sus orígenes pre-ágiles, un PRD tradicional es más adecuado para un sistema Waterfall con pasos secuenciales claramente definidos (es decir, definición, diseño, entrega). Pero un PRD también puede y debe usarse como elemento principal en entornos ágiles. Simplemente necesitamos adaptar el formato y el contenido del PRD para un contexto moderno. Aquí están mis mejores prácticas:
1. Equilibre la rigidez con la flexibilidad
Hay dos formas de pensar sobre la rigidez: la rigidez del propio PRD y la rigidez en la forma en que se ve dentro de la organización. Ambos tipos ocurren comúnmente al crear y usar un PRD, pero abordaremos el primero primero.
Un documento rígido tiene un remaining cerrado y no deja espacio para que el equipo investigue o implemente otras soluciones durante el desarrollo. Pero debe hacer un esfuerzo consciente para equilibrar la claridad sobre el resultado deseado de un proyecto con la flexibilidad para hacer ajustes a medida que aprende nueva información. Él Método ShapeUpdesarrollado por el exjefe de producto de Basecamp, Ryan Singer, se puede utilizar para ayudarlo a encontrar la armonía entre proporcionar la dirección fija prometida por un PRD cerrado y dar a los equipos espacio para crear productos de manera ágil.
Otra opción para evitar la rigidez de un PRD tradicional es usarlo para describir criterios de éxito medibles. En el contexto de una aplicación de juego, por ejemplo, el objetivo sería un aumento del 10 % en el número de usuarios que comparten sus puntuaciones en las redes sociales con una pantalla remaining rediseñada y una experiencia de uso compartido más fluida. Esta opción no especifica la mejor solución para lograr esto, lo que permite una mayor granularidad investigación y descubrimiento.
2. Trátelo como un documento vivo
la forma en que PRD se ve dentro de la organización es primordial para su valor. ¿Cómo puedes esperar ser un equipo ágil cuando se trabaja desde un documento fijo? Del mismo modo, ¿cómo puede esperar que el documento funcione para usted si no lo usa en un ágil ¿manera? Cuando un PRD se usa de manera rígida, al cumplirse o aplicarse estrictamente, puede impedir las discusiones creativas y el descubrimiento de productos, fomentando una mentalidad de cascada y obstaculizando la agilidad common.
Seguir incondicionalmente un plan establecido es una receta para el desastre en el desarrollo de software program: considerar que su PRD está “terminado” es un enfoque común pero contraproducente, ya que el documento quedará obsoleto rápidamente.
Esforzarse por perfeccionar continuamente el PRD y tratarlo como un documento vivo. Evite tener una cadena de revisión o aprobación cada vez que un miembro del equipo hace un ajuste. Lo que es más importante, asegúrese de que su equipo esté bien versado en un marco como Melé, Kanbano Programación extrema, para que puedan responder a los comentarios, incorporar nuevos aprendizajes y reevaluar constantemente. Si el equipo está trabajando de manera ágil, es más possible que también usen el PRD de manera ágil.
3. Mantenga breves las descripciones
Otro escollo común es atiborrar el PRD con demasiados detalles, lo que resulta en un documento extenso y detallado que es difícil de entender y mantener. Esto suele ocurrir cuando se incluye demasiada información en la descripción de la función: cada elemento de la función, especificaciones de diseño exhaustivas o instrucciones de implementación.
Sin embargo, ser breve no significa sacrificar la claridad. Un PRD claro aún incluirá los fundamentos: el objetivo de cada característica, los elementos esenciales y las pautas para la entrega. Estos son ejemplos de diferentes descripciones de funciones para una aplicación de citas:
|
POCO CLARO |
BREVE Y CLARO |
VERBOSO |
|---|---|---|
|
Pantalla de éxito cuando hay una coincidencia entre dos usuarios, con una forma de conectarse. |
Necesitamos una pantalla de éxito para cada coincidencia que entusiasme al usuario y lo empuje hacia el siguiente paso (es decir, intercambiar mensajes). El estilo debe coincidir con los estándares de marca y accesibilidad. Elementos imprescindibles:
Además, nos gustaría ver la personalización, por ejemplo, fotos de perfil y/o apodos. Según corresponda, también se deben utilizar comentarios o vibraciones hápticas, animaciones, and many others. |
Cuando hay una coincidencia, debe aparecer una página en la pantalla completa que mostrará el mensaje “¡Es una coincidencia!” La pantalla debe incluir imágenes de perfil de ambos usuarios, en círculos grandes que ocupen una cuarta parte de la pantalla cada uno (con la imagen del usuario en el lado izquierdo), y el mensaje debe estar encima de estas imágenes. Debajo de las imágenes, debe haber dos botones grandes, de extremo a extremo, uno con el texto “Mensaje ahora” y otro con “Continuar deslizando”. En los botones a la izquierda del texto, también debe haber íconos: una burbuja de chat para enviar un mensaje al partido y un pequeño corazón para continuar deslizando. Todo el texto debe estar en coloration #003366, excepto los botones, que deben tener texto en blanco. La pantalla debería aparecer con un efecto de vuelo desde abajo, con pequeños fuegos artificiales, caras sonrientes y emojis de corazón volando (siete fuegos artificiales, tres caras sonrientes y cuatro corazones). |
Incluso en el ejemplo “Breve y claro”, hay información potencialmente superflua: por ejemplo, la guía sobre estándares de marca y accesibilidad, y también en la retroalimentación háptica, pueden no ser necesarios si se aplica a cada función y, en explicit, cuando las organizaciones tienen equipos de diseño que están familiarizados con estos estándares. Si este es el caso, puede ajustar aún más la descripción de la función.
En lugar de describir detalladamente lo que se incluye, puede ser más eficiente en algunos casos usar una lista de “lo que no se puede hacer”, tal vez en una sección fuera del alcance o usando el Método de Moscú. La lista solo debe abordar elementos exclusivos del contexto o donde pueda haber incertidumbre, como elementos eliminados del alcance que normalmente se incluirían, elementos que no están alineados con las regulaciones o casos límite.
Un issue importante en el nivel de detalle que elija incluir también será la experiencia del equipo y la madurez del producto. Si su equipo está compuesto por profesionales de alto nivel que han trabajado juntos antes, o si está creando un producto que tiene estándares y pautas establecidas, una breve documentación será suficiente.
La famosa cita “No tuve tiempo de escribirte una carta corta, así que te escribí una larga” es aplicable aquí. Requerirá mucho esfuerzo mantener el PRD breve mientras comunica toda la información necesaria, pero es una inversión que vale la pena.
Use esta plantilla de documento de requisitos de productos para maximizar el éxito
Para que pueda comenzar, he canalizado todos mis aprendizajes y orientación en la última plantilla gratuita de PRD, disponible para descarga. Si, en su forma precise, no se adapta a su contexto único, experimente eliminando o incorporando diferentes elementos para que funcione para usted.
Un PRD habilitado para Agile es una herramienta enormemente valiosa. Manteniéndolo breve, versatile y vivo, su PRD puede fomentar una mayor alineación, claridad y colaboración, todo lo cual es esencial en la creación de productos innovadores y útiles.
Notas Plantilla PRD
La plantilla se divide en dos partes: elementos obligatorios y opcionales. Usar solo el primero dará como resultado un documento ligero, suficiente para obtener los beneficios clave. Se recomienda incluir algunos de los elementos opcionales para brindar detalles adicionales según sea necesario. Aquí se explica cómo usar la plantilla de manera efectiva:
1. Objeto del documento
Esta sección es important para definir para qué se utilizará el PRD. Escriba una breve declaración o tal vez tres o cuatro viñetas que describan su propósito. Por ejemplo:
- Descubrimiento de documentos y colaboración con el cliente
- Esquema del alcance de MVP
- Resumir diferentes tecnologías y posibilidades de desarrollo.
- Detallar las necesidades del equipo a medida que surjan
2. Resumen ejecutivo
Brinde una descripción common de alto nivel del proyecto, sus metas y objetivos, el contexto organizacional y de mercado, y las recomendaciones.
Consejo profesional: full esta sección al remaining, una vez que tenga los demás elementos en su lugar.
3. Quién, por qué, qué y qué no
¿Para quién estamos construyendo este producto? Enumere los principales grupos de usuarios del producto, sus necesidades y puntos débiles.
¿Por qué estamos construyendo este producto? Enumere las principales oportunidades, hipótesis y razonamientos.
¿Qué estamos construyendo? Escriba una breve descripción del producto, su alcance aproximado o sus principales características/componentes.
¿Qué no estamos construyendo? Escriba una breve descripción de las funcionalidades que no se incluirán y las razones por las cuales.
