Una gran cantidad de artículos y libros sobre el trabajo del gerente de producto, consideran temas de pensamiento estratégico e innovación. Por supuesto, esta es la base. Me gusta prestar atención a las tareas diarias de rutina. Uno de esos trabajos es con las solicitudes de los usuarios y los requisitos del producto.
El axioma es que las solicitudes de funcionalidad de los usuarios no son requisitos del producto. Una solicitud se puede dividir fácilmente en varios requisitos, y viceversa, un requisito consiste en varias solicitudes de los usuarios.
Veamos un ejemplo simple: la aplicación Calculadora. Recibió una solicitud: agregue soporte para el sistema de números binarios. Puede dar lugar a varios requisitos del producto.
- Soporte para operaciones aritméticas.
- Soporte de conversión. Esto incidentalmente afectará el sistema decimal existente. Será necesario, al menos, hacer botones en la interfaz.
- Soporte para operaciones lógicas.
Como puede ver, inicialmente el usuario no solicitó soporte, por ejemplo, solo operaciones lógicas. La solicitud del sistema de números en su conjunto, pero contiene varios requisitos.
Quizás todo esto sea obvio. Pero el proceso de trabajar con solicitudes, si no le da importancia, puede agregar problemas. El primer escollo es mantener registros en el rastreador.
Obviamente, tener un sistema único para las solicitudes de los usuarios y los requisitos del producto es mejor que dos. Bueno, al menos solo tendrás una ventana abierta. Es importante tener diferentes tipos de objetos para los registros. Un ejemplo de mi experiencia. En promedio, recibo entre dos y cuatro solicitudes de usuarios cada día hábil. Puedes imaginar el volumen. La lista en la cartera de productos es simplemente enorme. Tener dos tipos de entradas "requisito" y "solicitud de funcionalidad" le permite configurar filtros, recopilar una acumulación de una versión específica y hacer enlaces entre requisitos y solicitudes para realizar un seguimiento del historial. Además, después de considerar la solicitud, se puede cerrar con las notas "planificado para su lanzamiento" o "no se implementará".
El segundo aspecto del trabajo es la recolección directa de requisitos. Una forma es obtenerlos a través del soporte técnico. Este es un buen proceso, como resultado de lo cual se obtiene una solicitud filtrada que contiene la esencia. Por otro lado, es opaco para sus usuarios. Muchos pueden no ver que tal solicitud fue y se accede repetidamente.
Por lo tanto, los proveedores, especialmente aquellos que hacen soluciones en la nube, pueden usar portales para recibir comentarios.
Foro de comentarios de ZendeskEste método mejora la visibilidad. Separa las solicitudes de los requisitos, ya que los sistemas son diferentes. Sin embargo, ahora su trabajo se ha duplicado. Necesita ver rápidamente nuevas publicaciones, comentar, responder preguntas. El silencio, especialmente en la comunicación pública, es inaceptable.
Pero lo más difícil es que ahora tiene que rastrear y marcar las solicitudes de alguna manera para marcar las que están planificadas para la implementación, o viceversa. Volviendo al ejemplo con una calculadora. Al igual que en el portal, debe marcar la solicitud de soporte binario, si planea implementar solo operaciones aritméticas y conversión, sin operaciones lógicas.
Cada gerente de producto elige su propia solución. No hay un enfoque universal. Sin embargo, siempre debe recordar que incluso un proceso tan pequeño como recopilar y procesar solicitudes de usuarios puede contener muchos temas ocultos, y es fácil duplicar el trabajo.