¿Qué es un documento de requisitos del producto?
Un buen documento de requisitos del producto identifica los objetivos de cualquier nuevo producto, servicio o función; describe con precisión el producto que construirá su equipo.
Un documento de requisitos del producto eficiente y conciso debe describir claramente los objetivos del producto, los usuarios objetivo y el uso esperado.
It is the foundation that any agile product team needs to ensure all stakeholders involved are aligned and the roadmap for the product team is clear. The PRD will be the most referenced resource throughout your product build.
¿Qué hace que un documento de requisitos del producto sea eficaz?
Los documentos de requisitos del producto no necesitan tener páginas y páginas de extensión. Seamos francos, la gente lee por encima, selecciona palabras clave y capta la esencia de las cosas. Para crear un documento de requisitos del producto sencillo, es esencial que mantenga las cosas lo más breves posible, concisas y agradables a la vista; no tenga miedo de utilizar elementos visuales como apoyo.
→ Por ejemplo, en Slite, utilizamos bocetos para definir funciones e interacciones.
Even if you manage to create an outstanding product requirements document, it doesn’t guarantee that your product build will be a success, but it will certainly give it the best possible starting blocks.
Una guía completa del documento de requisitos del producto
Cómo un DRP puede ayudar a un equipo de desarrollo de productos
Los equipos de desarrollo de productos son, con diferencia, el equipo más afectado por un documento de requisitos del producto. Son los que consultarán los planes del proyecto con mayor frecuencia y necesitarán conocer el documento como la palma de su mano para asegurarse de que están trabajando de forma colaborativa y eficiente.
El DRP desempeñará un papel más pequeño en la estrategia, la visión y la hoja de ruta del producto más amplias. Es uno de los recursos principales, además del talento, que permite una excelente gestión de productos.
Sin embargo, no se detiene con el equipo de desarrollo. Los equipos de marketing, ventas, desarrollo empresarial, soporte y más deberán consultar la plantilla para comprender completamente lo que está por venir y el cronograma. Si todos los equipos están de acuerdo con el documento, planificarán mejor dentro de sus áreas para poder apoyar el nuevo producto lo mejor posible cuando esté listo.
Lo que el DRP significa para un Product Manager
Como gerente de producto (PM), usted debe ser el principal contribuyente a cualquier documentación técnica como una plantilla de especificaciones del producto o DRP, pero eso no significa que deba hacerlo solo. Depende de usted, como PM, encontrar los mejores recursos en su equipo para ayudarlo a crear diferentes partes del DRP:
- Utilice un diseñador para wireframes y maquetas
- Contrate a un especialista en marketing para personas y historias de usuarios
- El Product Manager es responsable de gestionar todo el proceso de definición de requisitos del producto.
Si este proceso se gestiona bien, los gerentes de producto deben utilizar este documento como un recurso para sí mismos durante todo el proceso y como un recurso para que otras partes interesadas lo consulten continuamente.
¿Cuál es la diferencia entre un DRP y un MRD?
La gente a menudo se confunde entre lo que es un DRP y lo que es un MRD. Son diferentes, pero tienden a ir de la mano. Se debe crear un documento de requisitos del mercado antes del documento de requisitos del producto.
En resumen, un MRD es una investigación que identifica las necesidades y oportunidades del mercado con un producto de su empresa. El DRP identifica el producto que se puede construir para aprovechar la oportunidad.
¿Qué debe incluirse en un DRP?
Una buena plantilla de inicio de DRP será diferente según su negocio y equipo. Sin embargo, la mayoría de los documentos de requisitos del producto deben incluir:
- Metas y objetivos
- Partes interesadas clave
- Personas de usuario & Historias
- Detalles de la versión
- Diseño y Wireframes
- Riesgos
- Hoja de ruta e interacciones futuras
Nuevamente, esta es solo una descripción general amplia de cómo puede aparecer un DRP. Es posible que le resulte necesario incluir todo lo anterior en su documento, o es posible que solo necesite tomar aquellas cosas que considere relevantes para su proceso de desarrollo de productos.
1. Metas y objetivos
Esta parte es el “por qué” para construir este documento de producto en primer lugar. Proporciona el contexto en torno al ciclo de vida del producto y cómo se alinea con la misión y visión más amplias de su empresa/producto.
Intente aclarar los problemas que este producto está diseñado para abordar. Esto garantizará que su equipo de desarrollo cree un producto que resuelva su propósito y lo haga de una manera que sea agradable para el usuario final.
2. Partes interesadas clave
Una parte simple pero a menudo pasada por alto del DRP es la identificación de las partes interesadas clave en el proceso de la hoja de ruta del producto. Esto debe incluir, entre otros, al gerente de producto, los diseñadores internos o externos, los desarrolladores de productos, el propietario del documento y cualquier informe directo o puesto de liderazgo que esté involucrado.
Todos los que esperan su proyecto deben saber a quién recurrir y para qué. La propiedad clara es crucial.
3. Personas e historias de usuarios
Estas personas son tan esenciales en el proceso y el resultado del desarrollo de un producto. Cada persona que cree debe actuar como una entrada en la experiencia del producto y debe tener un propósito o desafío particular para ayudar a su producto a alcanzar su objetivo final. Ayudan a proporcionar los casos de uso del producto.
Muchos proyectos de nuevos productos tienden a salir mal aquí; giran en torno a personas construidas demasiado similares entre sí, simplemente cambiando el género o la edad. Concéntrese en sus personajes de usuario. ¿Quiénes son? ¿Cuántos años tienen? ¿Con qué género se identifican? ¿Cuál es su ocupación? ¿De dónde son? ¿Cuál es su nombre? Y lo más importante, ¿qué necesidad específica resuelve su producto?
Asegúrese de que todos estos factores sean diferentes pero precisos según los datos que tenga disponibles. Utilice Google Analytics, las redes sociales y otros datos de audiencia para ayudarlo a desarrollarlos.
¿Qué es un ejemplo de persona DRP?
Nombrar a las personas ayudará a un equipo de desarrollo de productos a poder diseñar para alguien, no para algo. Construya lo suficiente de una persona para que el equipo pueda identificarse y comprender, al hacerlo, crearán un producto final que se ajuste a las necesidades identificadas de alguien y, por lo tanto, del mercado.
Apoye a estas personas con historias de usuarios. Aquí hay un ejemplo de documento de requisitos de persona, “Como Cindy, alguien que hace XYZ, necesito este producto para XYZ”. Al utilizar estas necesidades del cliente como apoyo al diseñar un nuevo producto, su equipo de diseño creará algo que se mantenga fiel al propósito y al ajuste al mercado.
Estas historias deben centrarse principalmente en una característica particular del producto. En lugar de parecer una propuesta de proyecto, la persona debe responder a un punto débil, identificado en el MRD, y al valor que proporcionará la característica.
4. Notas de la versión
Estos son tan importantes, no solo para ayudar a un equipo de producto a garantizar que la hoja de ruta del producto se mantenga en el camino, sino también para otros equipos involucrados. Ayudará a las personas a administrar su carga de trabajo para que puedan apoyar el producto cuando y cuando lo necesiten.
Las notas de la versión del producto deben incluir nombres de hitos, características, correcciones y mejoras futuras.
5. Diseño y Wireframes
Los diseños visuales y los wireframes son imprescindibles para cualquier documento de requisitos del producto exitoso. Ayudan a los ingenieros a comprender la visión del diseño y a responder a los puntos débiles de las personas usuarias.
Al introducir wireframes en esta etapa, puede identificar problemas y encontrar soluciones que no habrían sido evidentes sin una ayuda visual. No piense en el diseño en esta etapa como diseño gráfico. Su wireframe debe funcionar como un plano o mapa básico de dónde encajarán sus características principales dentro de una página y qué deben ser esas páginas en primer lugar.
Los wireframes no necesitan ser algo hermoso, pero deben brindar a sus ingenieros y otras partes interesadas una visión clara de cómo se utilizará el producto y cómo un usuario fluirá a través del producto.
6. Riesgos
El don de la retrospectiva es algo tan poderoso. No sabemos si un producto tendrá éxito o fracasará, ni todos los obstáculos que podemos encontrar a lo largo del proceso de desarrollo. Lo que podemos hacer es tratar de identificar tantos riesgos como podamos encontrar en el camino.
Un riesgo puede ser cualquier cosa, desde un cronograma inestable hasta un nuevo código o talento, una integración particular o un recurso externo necesario. Al identificar los riesgos al principio del documento del producto, el equipo del producto puede superar cualquiera de los desafíos más importantes que se presenten lo antes posible y preparar un plan B para cualquier situación.
7. Hoja de ruta e iteraciones futuras
Un producto nunca es realmente una pieza de trabajo terminada. Debe estar en un estado constante de flujo, aprendiendo de su uso, adaptándose y creciendo a nuevas tecnologías o necesidades del consumidor. La primera iteración de su producto debe ser exactamente eso, un primer borrador.
Como propietario o gerente de producto, pregúntese qué requisitos funcionales son esenciales para el MVP y qué puede esperar para la segunda o tercera iteración. Tal vez incluso considere qué es mejor dejar para una segunda o tercera iteración, y podría defenderse con algunos datos de usuario en el cinturón.
Intente planificar la hoja de ruta futura de su producto para que los miembros del equipo de diseño e ingeniería comprendan qué bases deben sentarse ahora para hacer posibles estas versiones. Considere el propósito de todo su trabajo futuro, el plazo en el que espera que se entregue y su prioridad junto con otras características.
Ejemplo de una plantilla de documento de requisitos del producto
Cómo escribir un documento de requisitos del producto puede ser una tarea desalentadora, y es difícil comprender por dónde empezar. Es una buena idea comenzar con una plantilla de documento de requisitos del producto para ayudar a poner en marcha su proceso.
A continuación, le proporcionamos un ejemplo de DRP que puede utilizar y adaptar a sus propias necesidades.
¿Cómo escribir un documento de requisitos del producto?
Paso 1: Estudie
Un DRP (que significa "documento de requisitos del producto") debe centrarse en el problema que resuelve su producto. Investigue las necesidades y los deseos de los clientes, y lo que pagan actualmente por productos similares.
¿Cómo abordan el problema los competidores? ¿Cómo puedes satisfacer mejor las necesidades de los clientes?
Talk to your marketing, sales, and technical experts about the advantages and disadvantages of available technologies. All this research will help you lead your product development team confidently and effectively.
Paso 2: Define los valores fundamentales del producto
Tu plantilla de Documento de Requisitos del Producto debe explicar claramente cómo el producto se alinea con los objetivos generales y la estrategia del producto de tu empresa. Presenta la propuesta de valor de tu empresa como un discurso de ascensor. Asegúrate de que todo el mundo sepa lo que una implementación exitosa del producto debe ofrecer durante el proceso de diseño e implementación.
Paso 3: Crea una filosofía de producto
Defining product principles helps your team develop it. Some PRD examples include:
- Seguro
- Reliable
- Intuitivo
Este ejercicio de propuesta de valor ayuda a refinar los principios de tu producto y guía a tu equipo a medida que definen las tareas del usuario y las características del producto.
Step 4: Identify user profiles, goals, and tasks
Un ejercicio centrado en el perfil, los objetivos y las tareas de tu usuario te ayuda a construir tu producto de forma eficaz. Por ejemplo, los PRD deben indicar para quién es, cuáles son sus objetivos de producto y cómo lo utilizarán.
Crea un perfil de usuario
Tu documento de producto debe identificar al usuario principal del producto que es más importante para tu negocio en términos de ventas. Al considerar nuevas características, pregunta a tu equipo cómo reaccionaría y usaría esa característica ese usuario. Céntrate en las necesidades, los deseos, los hábitos y las actitudes de la mayoría de tus usuarios principales en lugar de intentar complacer a todos los clientes potenciales.
Define los objetivos del usuario
A product requirement document should identify what users want to accomplish. Users often have trouble explaining exactly what they want. Identify the user's needs and obstacles so designers and engineers can find the best solution.
Define las tareas del usuario
When putting together your PRD, create user-friendly tasks with your team. Explore ways you can accomplish the user's goals quickly and easily. Then, evaluate the best alternatives.
Paso 5: Enumera las características de tu producto
La mayor parte de tu PRD describirá la funcionalidad de las características y las restricciones impuestas al diseño del producto. La funcionalidad del producto se describe en los requisitos funcionales. Los requisitos no funcionales describen las limitaciones del diseño del producto.
Paso 6: Prueba tu concepto
Los gerentes de producto y los desarrolladores a menudo se toman demasiado en serio su borrador de PRD. Es demasiado tarde para hacer cambios importantes cuando llega la retroalimentación Beta. Las herramientas modernas de creación de prototipos facilitan las pruebas de validación de prototipos de productos para obtener retroalimentación. Los tres tipos de pruebas de validación de productos son:
- viabilidad
- usabilidad
- concept testing
Paso 7: Criterios de lanzamiento
Your requirement document should prioritize and rank requirements and release goals as "must haves," "high wants," and "nice to haves." This helps you bring the product to market and track evolving requirements.
Establece métricas de éxito cuantificables como:
- Rendimiento
- Fiabilidad
- Usability
- Seguridad
- Capacidad de soporte
- Escalabilidad
- Localizability
- Other relevant product factors
Step 8: Revise your PRD draft
Make sure the developer understands the PRD problem and QA has enough information to build a test plan. Address any issues your stakeholders raise while drafting your PRD.
Paso 9: Gestiona el desarrollo del producto
When a problem over requirements arises, refer to the PRD. If there isn't an answer, resolve and record the decision. Throughout development and product launch, your PRD gives your whole team a clear understanding of what you're aiming for.
Los escollos al crear un documento de requisitos del producto
The testing process
In your first usability test, you will see what issues they have and how to fix them.For effective usability testing:
- Prueba la usabilidad antes de la implementación, no después
- Make multiple iterations
- Mantén involucradas a otras partes interesadas
- Focus on user actions, not words
- Observe user interactions with the product
If you don't have usability engineers on staff, hire a firm that specializes in usability testing and add their input to your requirements document.
Mantenerlo centrado en el cliente
Customers are rarely as tech-savvy as product creators. For example, product requirements documents that seem intuitive to your designers may be obtuse to potential users. A poor first impression can sour your product on a customer. This is why customer feedback during development is an invaluable part of the process.
Don't start from solutions
Your product requirement document should specify the problem to solve, not how the product will solve it. A solution-based approach may lead to your engineers making incorrect assumptions and leave your development team confused and frustrated.
Not enough details
Your product document should give engineers and designers lots of leeway. Team members will fill in PRD gaps. Plan for problems popping up during development, Schedule time to address them quickly, and update the PRD as needed.
Overly detailed
Demasiados detalles pueden llevar a que los miembros del equipo no lean el PRD. Los productos complejos pueden necesitar documentos de nivel inferior para cada subsistema. La plantilla de PRD de Slite tiene en cuenta los proyectos complicados.
Too many features
While trying to meet all customer needs is tempting, it can be counterproductive for high-tech products. Added features bloat the product, leading to user confusion and increased maintenance costs. Be disciplined when adding features to your product requirement document.
Impulsado por la ingeniería
Puedes sobrecargar al gerente de producto si tu equipo de ingeniería está enamorado de una nueva tecnología. Las reglas de gestión de proyectos requieren que escuche a los ingenieros, pero que se centre en el valor y dé ejemplos de requisitos que los clientes comprarán y que su empresa puede construir.
Impulsado por el marketing
One marketing-driven example of a requirements document problem is "specials," special features, or additional purchases in exchange for additional payments. Specials can lead to customer confusion and frustration. They also require building, testing, maintaining, and supporting multiple product versions. And customers may discover that new features don't meet their needs. Evaluate each proposed feature and know when to walk away.
Requirement traceability
Your PRD must support requirement traceability and track issues, test cases, bugs, and problem resolutions to each requirement. An integrated requirements management tool, such as SLITE, can clarify your PRD meaning and greatly simplify requirements traceability.
Easily Handle a PRD and Product Processes with Slite
Just because you’ve managed to create an efficient Product Requirements Document, doesn’t necessarily mean your team will use it as a reference point, or even know where to find it.Slite is here to help you handle new product processes by keeping your team connected with the awesome resources you create:
- Share your PRD and other documentación de software en tiempo real, con aquellos de su equipo que lo necesiten.
- Centralize your team’s knowledge, no more jumping from person to person to get information.
- Get instant access to a wealth of templates that can help your product processes excel.
