Cambio de mentalidad: de proyectos a productos
Cambio de mentalidad: de proyectos a productos
La diferencia entre un proyecto y un producto puede marcar la diferencia entre éxito y fracaso.
Imaginemos que un ejecutivo c-level escucha que el carrito de compras del sitio ecommerce de la empresa está generando descontento por alguna razón. El ejecutivo entra a una sala con todos los desarrolladores de la empresa y dice: "¿Quién es dueño del carrito de compras? Tengo algunas mejoras críticas para implementarse de inmediato".
En una organización enfocada en proyectos, nadie es dueño del carrito de compras. En su lugar, puede haber un grupo de operaciones que acepte todo tipo de solicitudes de mejora y trabaje en ellas, obteniendo ayuda de desarrollo cuando sea necesario.
La solicitud del ejecutivo se iría a ese backlog, compitiendo con muchos de otros temas por priorizar. Y si el cambio es grande, se tendría que escribir business case y un equipo se armaría para ello, quienes tendrían que aprender sobre el producto y el requerimiento. El equipo constuiría una solución, la implementaría y luego se disolvería. Todo esto suena a que tomaría mucho tiempo.
En una organización enfocada en productos, un equipo consistente y de largo tiempo (y probablemente con un nombre de equipo autodenominado, como Barracudas o Cactus) es el dueño del carrito.
Cuando una empresa pasa de proyectos a productos, está cambiando el enfoque de cada persona en la organización, de una perspectiva a corto plazo de "hagamos este proyecto y pasemos al siguiente" a una perspectiva de responsabilidad y accountability de largo plazo.
En este escenario centrado en productos, los equipos no trabajan en un proyecto; son dueños de un producto desde el concepto inicial hasta que se le da de baja por obsolesencia. ¿Podemos imaginar la diferencia en la calidad y compromiso cuando los equipos son dueños de los productos en lugar de ser tratados como recursos a asignar según las necesidades del “negocio”?
Objetivos de un proyecto vs un producto
En un proyecto uno de los objetivos es cumplir con la fecha para entregar un alcance acordado con un costo previsto y una calidad definida.
En estos casos, es común reducir la calidad (con el consiguiente aumento en los costos de mantenimiento) con tal de llegar a la fecha definida.
El producto, sin embargo, va más allá de cumplir con una fecha, busca generar valor para la organización (ya sea dinero u otro bien intangible como imagen de marca). El producto puede tener fechas, ¡por supuesto!, pero su éxito no se mide en el cumplimiento, sino en el valor que genere. ¿Qué organización pagaría por un software que nadie quiere o se vuelve obsoleto luego de que terminó el proyecto?
¿Cómo la gestión de productos afecta el delivery?
Como Agile y DevOps, la gestión de productos promete incrementar el flujo de valor hacia los usuarios:
El equipo ya está operando. No necesitamos dedicar tiempo a formar un equipo para implementar un proyecto, lo que suele tomar meses en algunas organizaciones. No tener que formar un equipo disminuye el tiempo de generación de valor.
Los nuevos equipos de proyecto incurren en una curva de aprendizaje de la iniciativa y cohesión como equipo, lo cual impacta la productividad de corto plazo antes de que se conviertan en un equipo de alto rendimiento (si es que alguna vez llegan a serlo). Esto puede llevar de días a meses. Equipos de producto usualmente ya tienen tiempo trabajando juntos en el mismo producto, por lo que no tienen estas curvas de aprendizaje y cohesión. Tener un equipo de producto establecido, reduce el tiempo hacia la generación de valor.
Los equipos de producto no se centran en el alcance de un proyecto a completarse. Estos equipos tienden a operar casi en automático y en sintonía, por lo que que ponen en producción pequeñas unidades de funcionalidad con la mayor frecuencia posible. Si a este equipo le llevamos el reto de mejorar el carrito de compras, podrán descomponer ese reto en partes valiosas y comenzarán a fluir hacia la producción lo más rápido que puedan. Pasar a producción pequeñas partes con mayor frecuencia también reduce el tiempo hacia la generación de valor.
Entonces, ¿esto es lo mismo que Agile? Agile siempre pide equipos dedicados, pero eso rara vez ocurre y se termina ejecutando sprints dentro de un proyecto. Muchas casas de desarrollo operan en Agile, pero terminan formando equipos para un “proyecto” de un cliente, y cuando éste termina, el equipo se desbanda.
Organizarse alrededor de productos permite que la organización pueda formar estos equipos ágiles consistentes que se necesitan.
¿Cómo la gestión de productos afecta el funding?
En un entorno de proyectos, el business case se escribe para justificar el presupuesto y éste se asigna por adelantado. Luego se forma el equipo y les entregan los fondos para completar el proyecto.
Si el proyecto se alarga, se necesitan nuevas negociaciones. Si el proyecto termina antes de fecha, el equipo a menudo usa los fondos extras en otras tareas buenas pero no críticas. Esto aumenta el tiempo de creación de valor y puede conducir al “embellecimiento” de una solución; en otras palabras, agregar funciones que suenan emocionantes, pero que no otorgan un valor comercial claro.
En un entorno de productos, todo este tiempo se elimina. El trabajo nuevo se descompone en tareas y se prioriza frente a los elementos pendientes del backlog. Si el trabajo es crítico, el equipo puede comenzar a inyectar este trabajo en la siguiente ronda (por ejemplo, un sprint de dos semanas) o incluso antes, en una situación de emergencia, e intercambiar por otra tarea en curso. En este contexto podemos empezar a ver frutos de la inversión mucho más rápido.
Financiar equipos puede ser problemático en un mundo de finanzas capex/opex, donde un equipo no es un producto. Financiar productos es más preciso, pero también presenta algunos desafíos de governance, como por ejemplo, que los ejecutivos necesitan ver claramente el valor creado por el presupuesto invertido a medida que se va consumiendo. La importancia de informar sobre la entrega de valor aumenta cuando las empresas optan por financiar productos en lugar de proyectos. Y aquí el modelo de gobierno es clave.
Seguimiento por % de avance vs seguimiento por valor
Una diferencia radical al momento de ejecutar una iniciativa como proyecto es el % de avance. El % de avance nos indica cómo vamos respecto al objetivo final.
Es común hacer el cálculo de “si tengo 10 meses y llevo 9 estamos al 90%”, pero esto no es más que engañarse a si mismo. La teoría funciona si no fuera porque el alcance suele variar durante el proyecto.
En los productos es diferente. No hay un % de avance porque no hay un fin a alcanzar sobre el que compararnos.
Dependiendo del contexto y del objetivo del producto necesitamos definir qué métrica usaremos para medir el valor que aporta: ingresos, retención, eficiencia, etc. En los productos digitales definimos una métrica de valor y hacemos que éste aumente con el paso del tiempo.
¿Cómo la gestión de productos afecta la transformación digital?
Cuando se necesita cambiar el foco de una idea a otra, lo llamamos un pivot. En un pivot relacionado a un producto, es necesario entender qué producto o productos serán afectados para llevar la idea o estrategia al equipo apropiado y éste puede pivotar en el siguiente sprint o inmediatmente, según el grado de urgencia.
Las empresas que tienen que armar equipos para pivotar o aprovechar nuevas oportunidades siempre se quedarán atrás de las empresas que utilizan equipos de alto rendimiento existentes. Las organizaciones que adoptan un enfoque de proyecto perderán tiempo buscando personas para formar un equipo.
En ese contexto, las personas asignadas al nuevo proyecto causarán la interrupción de muchos otros proyectos en los que cada uno estaba anteriormente. Perderán tiempo en la curva aprendizaje y cohesión de equipo, y mientras definen cómo trasladarán su solución a producción.
Por el contrario, en las empresas orientadas a producto, un equipo de alto rendimiento existente tomará la iniciativa y se pondrá a trabajar de inmediato. En este equipo, los miembros ya saben cómo trabajar juntos y ya tienen una metodología que les funciona desde el diseño hasta el pase a producción. Descompondrán la solución en MVPs (Productos Mínimos Viables) para validar las hipótesis de la solución e irán iterando de manera contínua y recogiendo la voz del usuario en el camino, hasta encontrar la solución que genere real valor, más allá de una buena idea.
Generar valor = demostrar que una métrica relevante es impactada de manera positiva
Un equipo de producto suele ser multifuncional, con habilidades de diseño, negocio y tecnología, trabajando juntos para asegurar la entrega de valor.
La clave está en delegar la responsabilidad y dar el espacio que el equipo necesita para construir, medir e iterar, con un modelo de gobierno que mantenga a los ejecutivos informados en cada etapa de progreso.
Entonces, ¿quién es el dueño del carrito de compras? ¡Eres tú!
Como comentamos al inicio del artículo:
Cuando una empresa pasa de proyectos a productos, está cambiando el enfoque de cada persona en la organización, de una perspectiva a corto plazo de "hagamos este proyecto y pasemos al siguiente" a una perspectiva de responsabilidad y accountability de largo plazo.
El contenido de esté artículo fue traducido y adaptado en base a dos artículos que puedes leer aquí:
Projects to products: What it means, why it matters, por Anthony Crain
Cambio de mentalidad: proyecto vs producto., por Javier Martín de Agar
Ayúdame con feedback
Si te gustó, dale “like” al post y compártelo
Suscríbete para que te llegue mi siguiente post a tu correo
¡Deja un comentario!
¡Gracias!
Juan Pablo