Sugerencia para gerentes de productos: Vincule los trabajos pendientes del producto con la visión del producto

Uno de los desafíos constantes para un equipo de desarrollo ágil basado en productos es mapear lo que están haciendo 'ahora mismo' a lo que se supone que debe tener el producto, digamos, dentro de 2 o 3 años.

No se trata de que los equipos no sepan en qué están trabajando, sino más bien del hecho de que pueden permanecer demasiado concentrados en sus tareas diarias, lo que invariablemente socava la sensibilidad del impacto de su trabajo 'presente' en el panorama general . Las decisiones o elecciones realizadas hoy durante la ejecución pueden tener un gran impacto en el futuro, especialmente cuando el producto está evolucionando.

Tomemos un ejemplo de la vida real.

Formaba parte de un equipo ágil que intentaba introducir un servicio de traducción de texto para el contenido del sitio . Se tomó la decisión y se utilizó una herramienta de traducción automática de terceros. Sin embargo, la hoja de ruta del producto finalmente mencionó que, en el futuro, los usuarios deberían poder corregir y proporcionar su propia traducción contextual, lo que significaba que la capacidad de traducción debería tener inteligencia artificial para que pueda aprender por sí misma, en función de la retroalimentación.
Dado este desarrollo, la elección que se hizo no fue adecuada y, por lo tanto, requirió un grado considerable de reelaboración porque el panorama general no estaba vinculado con la tarea que se le encomendó al equipo ágil en el sprint.

Se puede argumentar que los equipos pueden hacer un esfuerzo consciente para obtener esta información, pero el punto es que ¿por qué no se pueden capturar estos objetivos a 'largo plazo' en las herramientas y paneles ágiles existentes?

Los equipos ágiles ejecutan tareas específicas y bien definidas en un ciclo de desarrollo, pero ¿eso significa que debe ser a costa de ser indiferentes a la evolución del producto? No, no lo creo.

Por lo que sé, no existe una herramienta o marco rápido que defienda o recomiende esta información al equipo ágil, en su funcionamiento diario, pero ¿se puede crear tal vista en la vista existente? ¿Vale la pena intentarlo? Veamos cómo podemos hacerlo.

Comenzaremos con el artefacto más común en Agile: la acumulación de productos.
Según el Instituto SCRUM, una cartera de productos es la lista de cosas que deben hacerse en un proyecto. Estas cosas pueden incluir mejoras y/o errores. Una lista numerada no es útil a menos que el equipo sepa cuál es la estructura de prioridad de los elementos. Aquí es donde entra el propietario del producto , que tiene la responsabilidad general de trabajar con las partes interesadas para obtener requisitos claros, resolver las interdependencias y obtener una lista de prioridades para los elementos de la cartera de productos.

Es posible que durante este proceso, un elemento de trabajo más grande y dependiente se divida en partes más pequeñas para que sea fácil de desarrollar para el equipo. Estos elementos de la cartera de productos se dividen en partes más pequeñas y se ejecutan en ciclos de sprint que van de dos a cuatro semanas, respondiendo al componente "cómo" del desarrollo del producto.

Por otro lado, los elementos de la cartera de pedidos del producto también se asignan al "norte verdadero" del producto, a menudo denominado visión del producto. Este es el estado deseado del producto que a menudo se logra a través de lanzamientos de múltiples versiones y se vincula estrechamente con lo que el público objetivo o los clientes quieren y el valor que les aporta.

Esta cadena de elementos que vincula al equipo ágil con los clientes (incluida la visión y la acumulación de productos) se puede representar como:

Vínculo distante entre un equipo ágil y lo que el cliente necesita…

Con la falta de una visión que vincule claramente los sprints con la visión del producto, los propietarios de productos a menudo corren el riesgo de centrarse demasiado en la parte del 'cómo' y perder de vista el objetivo más amplio e importante del 'qué', que puede conducir a una priorización equivocada.

El enfoque que discuto aquí es crear una vista simple pero poderosa que vincule ambos componentes. Esto se conoce como Product Vision Matrix (PVM). El objetivo es vincular la visión del producto a elementos granulares de desarrollo. Esta matriz se convierte en un factor clave para analizar el progreso del equipo con respecto al desarrollo del producto. También sirve como panel de productos para la alta dirección de la organización y los mantiene informados sobre la posibilidad de alcanzar los objetivos del producto.

Como sugiere el nombre, PVM es una matriz donde las columnas representan las dimensiones (de micro a macro) que se están capturando. Entendamos PVM con la ayuda de una aplicación de pedido de comida donde la visión es brindar una experiencia de comida a los usuarios, y el punto de partida es el pedido de comida. La matriz de muestra se ve así:

La Matriz de Visión de Producto puede tener los siguientes campos:

• Versión del producto: esta es la versión del producto que es el hito de lanzamiento oficial y, a menudo, es lo que recibe el cliente.
• Big Rock Item: esta es la categoría o el tema al que también pertenece una característica. Estos elementos también pueden ser las áreas de necesidad del producto a largo plazo de la visión del producto.
• Característica: Esta es la característica del producto que se está desarrollando. La función puede pertenecer a uno o varios temas (elementos de roca grande).
• Sprint ID: este es el número de sprint en el que se está desarrollando una función.
• Estado de desarrollo: este campo indica el progreso del desarrollo (planificado, diseño completo, desarrollo completo, probado y publicado).

Tenga en cuenta que la estructura de la matriz es indicativa aquí. Uno puede ser más creativo al identificar las columnas que pueden capturar la visión del producto.

La ventaja de este enfoque es la clara visibilidad que cada miembro del equipo tiene sobre los objetivos generales del producto. Para un producto en evolución, los miembros del equipo deben tener una mejor comprensión del panorama general. Esto no solo les permite contribuir de manera efectiva, sino que también les permite asumir una mayor responsabilidad. El resultado es un equipo más enfocado y adaptable que siempre tiene un dedo en el pulso de sus clientes y reconoce la diferencia que sus sprints pueden hacer para contribuir a la visión y al éxito final del producto.

Estudie cursos de gestión de productos en línea de las mejores universidades del mundo. Obtenga programas de maestría, PGP ejecutivo o certificado avanzado para acelerar su carrera.

Programa destacado para usted: Programa de certificación Design Thinking de Duke CE