Proceso Tipo
Expresión gráfica
Pensamiento Tipo
Expresión estructurada
Notas Tipo
Expresión eficiente
Mapa de árbol
Diagrama de soportes
Modo predeterminado
El trabajo de un gerente de producto es esencialmente un juego continuo de pasar del "caos" al "orden".
Con una montaña de comentarios de usuarios acumulándose en la base de datos de demanda, solicitudes urgentes de colegas de operaciones y desarrolladores que se preguntan "¿qué problema resuelve realmente esta función?"... bombardeados con todo tipo de información a diario, sin un método claro para organizarla y planificarla, es fácil caer en la situación de "parecer ocupados, pero la dirección del producto se vuelve cada vez más confusa".
Hoy hablaremos sobre cómo los gerentes de producto pueden usar tres diagramas clave para transformar requisitos caóticos en un plan de producto claro. Estos tres diagramas son: una lista de requisitos, un diagrama de la estructura de características del producto y una hoja de ruta del producto.
Cuando recibas un montón de requisitos, no te apresures a dibujar diagramas. El primer paso siempre es: categorizar, filtrar y priorizar.
Cuando se enfrentan docenas o incluso cientos de requisitos, cada requisito puede etiquetarse utilizando las siguientes dimensiones:
Dimensiones de la fuente: comentarios de los usuarios, análisis de datos, investigación de la competencia, necesidades de gestión, necesidades operativas y necesidades técnicas.
Dimensiones del tipo: Funcionalidad, Optimización, Experiencia del usuario, Rendimiento, Cumplimiento
Dimensiones de valor: valor central, valor auxiliar, pseudonecesidades
El objetivo principal de este paso es "tener una visión general". Una vez que se hayan categorizado todos los requisitos, se tendrá una comprensión macroscópica de la dirección a seguir para la mejora del producto.
El modelo Kano es una herramienta clásica para la selección de requisitos, que los clasifica en cinco tipos:
Requisitos básicos: Son elementos imprescindibles para cualquier producto. Si no los incluyes, los usuarios se quejarán. Si los incluyes, los usuarios los darán por sentados (como la función de pago de una aplicación de comercio electrónico).
Necesidades deseadas: Lo que los usuarios claramente quieren; cuanto mejor se haga, más satisfechos estarán los usuarios (por ejemplo, la precisión de los resultados de búsqueda).
Necesidades impulsadas por la emoción: Sorpresas inesperadas para los usuarios; su ausencia no afectará la experiencia del usuario, pero su presencia provocará emoción y entusiasmo.
Necesidades indiferenciadas: Los usuarios no notarán si está implementado o no.
Demanda inversa: Hacerlo podría, de hecho, provocar que a los usuarios les desagrade.
Al realizar la selección, primero puede eliminar los requisitos de "sin diferencia" y "inversos", y centrarse en mantener las tres primeras categorías.
El modelo RICE es una herramienta para cuantificar prioridades, con cuatro dimensiones:
Alcance (cobertura): ¿A cuántos usuarios afectará esta función?
Impacto: ¿Cuánta influencia tienes sobre un solo usuario? (Generalmente se califica en una escala de 3, 2, 1 o 0,5).
Confianza: ¿Qué tan seguro/a está de la valoración anterior? (Porcentaje)
Esfuerzo (Insumos): ¿Cuántos días-persona se requieren para el desarrollo?
Fórmula de cálculo: Puntuación RICE = (Alcance × Impacto × Confianza) / Esfuerzo. Cuanto mayor sea la puntuación, mayor será la prioridad.
Puedes usar tablas o mapas mentales para organizar la lista final de requisitos. Una lista de requisitos clara debe incluir: nombre del requisito, fuente, clasificación KANO, puntuación RICE y conclusiones preliminares.
Se han aclarado los requisitos, pero lo que el equipo necesita no es una lista de "20 funcionalidades a implementar", sino un diagrama de estructura que muestre "cómo organizar estas 20 funcionalidades juntas".
Un diagrama de estructura funcional del producto, también conocido como diagrama de arquitectura de información del producto, ilustra la relación jerárquica y la organización lógica de las funciones del producto. Con él, los desarrolladores comprenden los límites de los módulos, los diseñadores la navegación entre páginas y los evaluadores la cobertura de los casos de prueba.
Un diagrama de arquitectura funcional estándar suele contener tres niveles:
Módulos de primer nivel: La división funcional de nivel superior de un producto, que generalmente corresponde a la barra de navegación inferior o a las secciones comerciales principales (como el " módulo de usuario " , el módulo de producto y el módulo de transacción " en una aplicación de comercio electrónico).
Funciones secundarias: Funciones principales dentro de cada módulo principal (por ejemplo, " Módulo de producto " dentro de " Categoría de producto " , " Visualización de producto ", "Gestión de producto ").
Subfunciones de tercer nivel: Operaciones específicas o subpáginas dentro de las funciones de segundo nivel (como " Listado de productos " , " Edición de productos " y "Eliminación de productos " dentro de " Gestión de productos ").
Diagrama de estructura funcional de la aplicación de comercio electrónico
El principio MECE establece que las funciones del mismo nivel deben ser mutuamente excluyentes y estar enumeradas exhaustivamente, sin superposición ni omisión .
Perspectiva del usuario: La estructura organizativa debe basarse en los hábitos del usuario, no en la estructura organizativa de la empresa .
Escalabilidad: Deje espacio para futuras ampliaciones de funciones; no haga que el diseño sea demasiado rígido .
En ProcessOn , puede utilizar directamente las plantillas " Diagrama de flujo " o "Organigrama" para dibujar diagramas de estructura funcional .
El diagrama de arquitectura funcional está completo y el equipo sabe "qué tenemos que hacer". Pero una pregunta crucial sigue sin respuesta: "¿Cuándo hacerlo?".
Una hoja de ruta del producto es la herramienta para responder a esta pregunta. Muestra el plan de iteración del producto y el calendario de lanzamiento de funcionalidades en forma de cronograma durante un período de tiempo.
Cronograma: puede ser trimestral, bimensual o mensual, dependiendo del cronograma del producto .
Módulos funcionales: Las funciones principales que se lanzarán en cada momento .
Objetivos: ¿Qué problemas resolverá cada versión y qué objetivos comerciales logrará ?
Hoja de ruta interna: detallada, incluyendo características específicas y cronogramas de desarrollo, para uso interno del equipo .
Hoja de ruta externa: de grano grueso, que solo indica "en qué dirección vamos" para que los clientes y el mercado lo entiendan .
Hoja de ruta estratégica: Una perspectiva de alto nivel que muestra la visión del producto y la dirección estratégica anual .
Paso 1: Determinar la escala de tiempo
En primer lugar, aclare el plazo que abarca la hoja de ruta (por ejemplo, seis meses o un año) y la unidad de tiempo más pequeña (trimestre o mes).
Paso 2: Agrupación de funciones
Tras priorizar la lista de requisitos, asígnelos a diferentes periodos de tiempo. El principio básico es: aborde primero los requisitos básicos, luego los previstos e intercale los requisitos más interesantes como elementos sorpresa durante el proceso.
Paso 3: Nomenclatura de versiones
Asigne a cada versión un nombre significativo, como V2.0 «Edición Básica para Operaciones» y V2.1 «Edición Mejorada para Marketing». El nombre en sí resume los objetivos de la versión.
Paso 4: Marcar el objetivo
Debajo de cada punto temporal, resume el objetivo principal de esta versión en una sola frase. Por ejemplo: "Lanzar la función de compra grupal para aumentar la tasa de conversión de nuevos usuarios en un 20 %".
Paso 5: Presentación visual
Visualice la información anterior mediante un diagrama de Gantt o una línea de tiempo. El eje horizontal representa el tiempo, el eje vertical los módulos funcionales y los diferentes colores representan distintas prioridades o estados.
Hoja de ruta funcional del producto
No se comprometa con fechas específicas: especialmente para planes de desarrollo externos, usar "Q2" es más seguro que "15 de abril" .
Prevea un período de margen: Siempre habrá eventos inesperados durante el desarrollo, por lo que el cronograma debe tener cierto margen de maniobra .
Ajuste dinámico: La hoja de ruta no es inamovible; se revisa mensualmente y se ajusta según sea necesario .
Objetivos relacionados: Cada versión debe explicar claramente "por qué se hace", no solo "qué se hace" .
La esencia del trabajo de un gerente de producto radica en transformar lo "vago" en "claro". El análisis de requisitos puede convertir un cúmulo de opiniones confusas en una lista con prioridades claras; un diagrama de estructura funcional puede transformar los puntos funcionales de la lista en una arquitectura de producto lógicamente clara; y una hoja de ruta del producto puede convertir una arquitectura estática en un cronograma de implementación dinámico.
Una vez que estos tres diagramas estén claros, tendrás un lenguaje común para comunicarte con desarrolladores, diseñadores, evaluadores y el equipo de operaciones. El equipo sabrá adónde vamos, por qué vamos y cuándo llegaremos.
En ProcessOn , hemos preparado plantillas de funcionalidades específicas para gestores de producto: hojas de análisis de requisitos, plantillas de diagramas de estructura de funcionalidades y plantillas de hojas de ruta de producto. Puedes crearlas con un solo clic y comenzar rápidamente con la planificación de tu producto. ¡Pruébalo ahora!
Diagrama de flujo de mapas mentales colaborativos en línea gratuito
