Siempre puede contar las habilidades estratégicas del gerente de producto, como el pensamiento innovador, el enfoque del océano azul y otros. Pero a diario utilizamos herramientas y enfoques más prácticos. Este artículo trata sobre cómo trabajar con solicitudes de características y requisitos de productos.
El axioma principal de la gestión de solicitudes es que las solicitudes de características de clientes, socios y equipos internos no son requisitos para el producto. Esto se debe a que cada solicitud se puede dividir en varios requisitos o, de lo contrario, se pueden combinar varias solicitudes en un solo requisito.
Usemos un ejemplo: una aplicación de calculadora. Recibió una solicitud para agregar un sistema numérico binario a la aplicación. Esta característica única en particular plantea los siguientes temas, cada uno de ellos se puede convertir a requerimiento.
- Apoyo a operaciones aritméticas.
- Apoyando la conversión de / a. Esto afectará la funcionalidad del sistema decimal. Por ejemplo, debe admitir la conversión de decimal.
- Apoyo a operaciones lógicas.
Verá que nadie solicita operaciones lógicas para binario si no tiene soporte de dicho sistema. La solicitud de función trata sobre un sistema numérico particular, pero tiene varios requisitos subyacentes.
Probablemente esto es tan obvio. Hay un par de trampas ocultas. El primero de ellos es gestionar las solicitudes de funciones y los requisitos del producto en un rastreador.
Definitivamente, tener un sistema único para el seguimiento y la planificación es mejor que tener dos. Al menos solo necesita abrir una pestaña o ventana de aplicación. Considere utilizar tipos de registros separados para gestionar solicitudes y requisitos en lugar de uno solo. Un ejemplo de mi experiencia. Recibo de dos a cuatro solicitudes de funciones nuevas cada día laborable, enviadas por el equipo de soporte. Puede imaginar fácilmente una cantidad de elementos registrados. La lista de proyectos del producto parece una lista extremadamente larga. Tener un tipo de registro "requisito" y "solicitud de función" facilita la revisión y la planificación. Si varias solicitudes son el origen de un único requisito, hago un enlace de referencia. Y después de revisar, puedo cerrar la solicitud de función con las etiquetas "planificado" o "rechazado"
La segunda trampa puede estar en la recolección de solicitudes. Una forma es obtenerlos a través del canal de soporte. Esta es una buena manera, cuando recibe elementos filtrados y limpiados. Por otro lado, este no es un proceso visible para sus clientes.
Por lo tanto, los proveedores, especialmente para el software en la nube, pueden usar portales para obtener comentarios.
Portal de comentarios de ZendeskEste método agrega visibilidad, separa las solicitudes de los requisitos. Sin embargo, ahora su trabajo se duplica. Debe revisarlos y comentarlos rápidamente: a los clientes no les gusta el silencio y se está comunicando públicamente.
Y lo peor es rastrear y marcar elementos en la lista como planificado, no planificado, completado. Recuerde que las solicitudes de funciones no son requisitos que debe tener en cuenta para las dependencias. Volviendo a un caso de soporte binario en la aplicación de calculadora. Cómo debe rastrear esta solicitud en el portal público si implementa solo aritmética y conversión sin operaciones lógicas.
Cada gerente de producto elige su propia solución, no existe un enfoque universal. Sin embargo, siempre debemos recordar que muchos detalles importantes pueden estar ocultos en un tema simple.