Producto no camina solo
El proceso de discovery todavía no está claro.
Sin rodeos, esta vez quiero ir al grano desde el primer párrafo, el proceso de descubrimiento de los requerimientos no es cosa de producto. Se que suena rotundo y puede que genere mucho rechazo de primeras, pero déjame que te explique qué es lo que está pasando aquí de verdad.
Sabemos que producto representa ese rol que se encarga de dialogar con los stakeholders y que traduce en requerimientos funcionales sus deseos para que el equipo de desarrollo los comprenda desde el punto de vista del usuario y ejecute los cambios necesarios para satisfacer esa demanda. Voy a partir de la idea de que todos trabajamos con marcos de trabajos ágiles que nos permiten iterar con el cliente con cierta cadencia y verificar que lo que construimos es lo que desea y además lo adaptamos a los cambios que sucedan. Entonces, ¿por qué nos olvidamos de esta precepto? Proporciono una correlación de ideas rápidas y la explico a continuación: producto tiene dificultades para conocer el máximo porcentaje de esos requerimientos en primera instancia, pero como quiere darle el máximo al equipo de desarrollo para que proporcionen una estimación a alto nivel lo más precisa posible, atrasa el momento de interacción con el mismo hasta el momento en el que de verdad cree que lo conoce todo. (Spoiler: no es verdad) Así, cuando llega al equipo de desarrollo es tarde, hay poco margen de maniobra y los detalles que no encajan en esos requerimientos atrasan la entrega y forman un cuello de botella en el estadio final comprometiendo la calidad y la atmósfera laboral. Resultado: el equipo de desarrollo trabaja sin visión de producto, objetivos difusos o reducidos a “hay que tener esto este día sí o sí”; responde a una demanda sin valor, además del incremento de arreglos ad hoc envueltos en épicas contenedores que generan la absoluta desconexión del Product Owner con su entrega.
Resultado: el equipo de desarrollo trabaja sin visión de producto, objetivos difusos.
Esto es una realidad que me confunde en muchos aspectos, sin embargo, evidencia una absoluta desconexión entre desarrollo y producto, emergiendo por consiguiente como dos silos que trabajan de forma independiente con determinados hitos de interacción insuficientes.
Producto y desarrollo son uno.
¿Cuál es el detonante de esta desconexión? Si hay algo que tengo claro es el inicio de todo esto. Es ese momento en el que producto piensa que debe llevar todo lo posible a desarrollo y así todo irá mejor, menos preguntas, menos dudas, menos interacciones, más entrega. Meh! Producto y desarrollo son uno, ambos están sentados con el cliente, cada uno con sus responsabilidades, pero siempre juntos. Y así comienza el proceso de descubrimiento, uno de mis favoritos si se me permite. Cuando los roles conversan y descubren juntos cuáles son los requerimientos, paso a paso manejan los posibles riesgos, futuros bloqueos y la carga de la pesada losa de la incertidumbre. “No conocer” siempre será un estadio difícil, poblado por la sensación de que todo se puede ir al traste rápidamente o de que no se alcanzarán los estándares esperados. Si esta losa se sostiene en conjunto, pesa menos; y si además la desgranamos juntos, ¿Qué puede ir mal? Todas las contingencias nos pillarán a todos con el mismo grado de conocimiento y por tanto la aportación de las partes para superarlas será igualitaria, nadie estará sorprendido.
A esto lo llamo “la teoría de los vasos comunicantes del producto”. Si la comunicación fluye entre producto y desarrollo con la misma cadencia, ambos estarán siempre al mismo nivel. De este modo producto no deja de ser el enlace con negocio, no es eso en lo que se centra este proceso, aún recoge los requerimientos en primera instancia pero los comparte con su equipo tras conocerlos y se colocan en la misma plataforma del hoyo de la incertidumbre. De ella salen juntos, fuertes y con confianza. Puedo garantizar que un equipo con una relación constante e igualitaria con producto recibirá con menor grado de rechazo el cambio y viajarán en paralelo a la estrategia de negocio de la compañía.
Caminar juntos en el proceso de Discovery del producto es poner a trabajar nuestras funciones a la vez para alcanzar la excelencia.
Hablamos, pues, de objetivo de producto, de objetivo de sprint, de visión de negocio. No hemos cambiado el lenguaje en ningún momento de este viaje, pero parece que se han radicalizado las tareas propias de cada rol de forma que para no salirse de ellas, se han encerrado en un clima opaco y poco permeable. Caminar juntos en el proceso de Discovery del producto no es olvidar nuestras funciones, es ponerlas a trabajar a la vez para alcanzar la excelencia.