Ya han pasado más de 20 años de la firma del Manifiesto Ágil. Un hito que se transformó en un punto de inflexión de toda una industria y han sucedido muchos cambios e innovaciones a lo largo de estas décadas. Hoy reflexionaremos acerca de un camino tangencial que aporta el Product Management a la agilidad.
Para entender mejor esta relación, nos remontaremos en la historia a un ejemplo que comenzó a mediados de 2003 y duró hasta finales de 2006.
Un ejemplo con metaSAP (ViaWise)
El producto en cuestión se llamaba metaSAP y posteriormente ViaWise. Era una solución web que se integraba a SAP y creaba copias de las pantallas y reglas de negocio para ejecutar los procesos desde un navegador (en ese momento Internet Explorer y Netscape) o una handheld con Windows ME.
Gracias a ese producto se podía experimentar la diferencia entre un equipo de delivery, un equipo de features y un equipo de producto.
Se trataba de un equipo de seis personas. Podríamos separar el desarrollo de metaSAP, y su sucesor ViaWise, en tres grandes momentos donde la atención se había puesto en diferentes aspectos:
Atención al delivery
Atención a las funcionalidades
Atención a los resultados de producto
A continuación veremos las particularidades de esos tres momentos.
Gestión de proyectos y cumplimiento de tareas (foco en el delivery)
En una compañía en 2003 se inició el desarrollo de metaSAP. Con la gestión de proyectos tan presente en la cabeza, el desarrollo se basó en las propuestas del Project Management Institute (PMI) y Rational Unified Process (RUP).
El trabajo se organizaba alrededor de un Work Breakdown Structure (WBS), planes y Gantt charts, donde la principal preocupación era concluir las entregas en tiempo y forma. El equipo recibía una lista de entregables y sus deadlines. Algunos ejemplos de entregables eran del estilo Artefactos de RUP, como Stakeholders Requests, Business Case, Software Requirement Specification, Deployment Plan, etc. Podríamos llamar "documentación exhaustiva" a todo este grupo de entregables.
Como te imaginarás, entre estos documentos y el software construido había un divorcio significativo. Nada se correspondía con nada, ya que las soluciones propuestas cambiaban luego de haberse diseñado y los diseños nunca se actualizaban. Adicionalmente, la integración y el testing de estos desarrollos se hacían en fases. En ningún momento durante la construcción de metaSAP el equipo se detuvo a evaluar los resultados ni beneficios que obtenían los potenciales clientes.
Fue un desarrollo de meses que se hizo puertas adentro siguiendo las "mejores prácticas" del momento. El producto tenía una calidad técnica y un nivel de innovación enorme para el estándar de esos años.
El error cometido fue no involucrar a ningún cliente directo en el día a día. En su lugar se hicieron una serie de entrevistas a potenciales clientes y luego se diseño la solución y su desarrollo. Obviamente, ya entrado el 2004, no se había vendido a nadie. El producto se puso en el freezer y a otra cosa.
Involucramiento de los stakeholders (atención a los features y outputs)
A mediados de 2005 se decide darle otra oportunidad a metaSAP. La idea fue renovar su tecnología pasando de ASP.NET a Java, hacer un renaming de metaSAP a ViaWise y redefinir por completo su identidad de marca.
Como ya se habían tenido buenas experiencias con Scrum durante 2004 y principios de 2005, se decidió utilizar ese marco de trabajo para esta iniciativa.
El objetivo principal era no volver a cometer el error de enfocarse en el delivery. Entonces, el Product Owner se reunía periódicamente con los directores de la empresa (stakeholders) quienes le hacían llegar sus requerimientos priorizados y luego los discutía junto al resto del equipo de desarrollo para que les dieran detalle al feature, estimarlo y finalmente sean desarrollados.
Entonces, podríamos decir que el flujo de las ideas era el siguiente:
- Idea de feature: stakeholders
2. Priorización de historia de usuario: Product Owner
3. Refinamiento de historia de usuario: Product Owner y Developers
4. Desarrollo de historia de usuario: Developers
ViaWise comenzó a tener un poco de tracción, pero seguía sin terminar de convencer al mercado. Había más interés, había más reuniones, pero no necesariamente se transformaban en una gran cantidad de ventas. Podríamos decir que era un producto moderadamente valorado.
Involucramiento del cliente (atención a los resultados del producto o outcomes)
Hacia 2006 había una oportunidad más de hacer despegar ViaWise de una vez por todas.
La diferencia con las veces anteriores es que en esta ocasión acompañaría Expofrut, un cliente cercano a la empresa en cuestión y dispuesto a colaborar en el desarrollo de ViaWise. Aquí se sentía la gran diferencia entre lo que era el equipo antes (un equipo de delivery o features enfocados en el output) y lo que lograría ser en ese momento, un equipo de producto orientado a outcomes.
La priorización de estos problemas estaba determinada por la estrategia de producto donde sí tenían influencia los directores de la empresa.
Una vez recibido cada problema, los encargados de validarlo era el equipo de producto el equipo de producto, y lo hacía interactuando directamente con las personas que utilizaban ViaWise en Expofrut.
Habían entrevistas, se hacían prototipos en papel (confesado también en Pphotoshop), y junto a los clientes se definían los features. Los resultados que los usuarios obtenían a partir de los nuevos features eran medidos en términos de uso del producto y optimización operativa. Por ejemplo: tiempo total de escaneo de pallets de un camión con doble acoplado, demora entre el cambio de turno y el primer pallet despachado, disminución de errores por escaneos defectuosos, etc.
Todo este trabajo se hacía sin intervención de los directores de la empresa (stakeholders), a quienes sí se los mantenía informados sobre la evolución del producto y con quienes sí se medía el impacto en términos financieros: cantidad de ventas, rentabilidad, etc.
Esto es lo que fue crucial en las oportunidades que se abrieron para ViaWise luego de este trabajo junto a Expofrut.
Productos digitales y equipos ágiles
Hoy podríamos decir que hay noticias muy buenas y noticias prometedoras
Las muy buenas son que ya hemos superado en muchas empresas el mindset de delivery. Ese mindset que está orientado a proyectos, entregables intermedios y trabajo en silos. Si bien sigue habiendo muchas organizaciones que aún están buscando salirse de ese esquema, es un escenario que, por gracias al gran trabajo hecho por la comunidad ágil global, mucho ya se puede identificar a un solo golpe de vista. Esto permite que al verlo podamos hacer algo al respecto.
Las noticias prometedoras son que hay muchos equipos de features que están comenzando a ver el valor del mover su atención de la entrega de historias de usuario hacia los outcomes del producto.
Para poder identificar estos movimientos de equipos de features a equipos de producto podemos listar los cambios más significativos en ciertos atributos:
* Las features les llegaban como pedidos de stakeholders, en su lugar ahora los stakeholders les presentan problemas priorizados.
* El Product Owner se encontraba limitado a la gestión del backlog y en muchas ocasiones ni siquiera tenía autonomía para determinar las prioridades. Ahora el Product Owner está empoderado y realiza muchas otras acciones de Product Management como la definición de la estrategia y la coordinación del discovery.
* Los Developers sólo tenían influencia sobre la forma de construir el producto pero no con respecto a qué construir. Ahora los Devs. suman la capacidad de diseño de producto y se involucran de lleno en el Discovery, decidiendo no sólo cómo construir sino también cuáles son los features con los cuales experimentar soluciones.
* Las Sprint Reviews eran reuniones en donde se evaluaba si el incremento construido cumple con las especificaciones de las historias de usuario, pero no indagaban acerca de resultados de producto (outcomes). Ahora son reuniones donde se tiene en cuenta múltiples factores de éxito del producto, incluyendo los outcomes y, en algunas ocasiones, los impactos también.
De todas formas, aún queda mucho camino por delante para evolucionar las culturas ágiles y orientarlas hacia mindset de producto en lugar de outcomes. Pero definitivamente es un paso más allá de lo muchísimo que se ha logrado a lo largo de estas décadas.
