¿Un buen proyecto implica un buen producto?

Podemos llegar a un producto a través de un proyecto o a
través de la gestión de entregas de producto que hace Scrum

En una conversación con Alexandre Magno, un apasionado por la gestión de productos, dió como ejemplo al Titanic para entender la diferencia entre proyecto y producto.

Pensemos en el Titanic como barco: fue un excelente proyecto, se construyó en tiempo y costes y cumplió perfectamente con todas las normativas de la época, pero fue un producto mediocre, se hundió en el primer viaje en una ruta que iba a ser habitual y solo tenía un tercio de botes salvavidas para poder cubrir el pasaje, con lo que murieron más de 1.300 pasajeros.

Ahora pensemos en la película Titanic: fue un proyecto nefasto, sus costes de producción se multiplicaron por 17 y James Cameron tuvo que hipotecar su patrimonio, ahora como producto fue superior y produjo beneficios mucho más allá de lo que cabía esperar, en su momento fue la película mas taquillera de todos los tiempos, se recaudaron más de 1.800 millones de dólares.

Quiero invitaros a leer el post de Alejandro Pérez ¿Proyecto o Producto? ¿Sabes diferenciar correctamente sus ciclos de vida? en el que trata la diferencia de ambos. Las definiciones oficiales y los ciclos de vida de ambos según el estándar internacional de gestión de proyectos, el PMBOK, son:

• Proyecto: Esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.
• El ciclo de vida del proyecto son todas las fases necesarias para llevar a cabo este objetivo, que el PMBOK describe en 5: Inicio, Planificación, Ejecución, Monitorización/Control y Cierre.
• Producto: Es un artículo producido, cuantificable y que puede ser un elemento terminado o un componente.
• A diferencia del proyecto, el ciclo de vida del producto, está centrado en el entregable, el producto en si mismo, siendo sus fases diferentes: Introducción, Crecimiento, Madurez y Retiro.

Podemos construir un producto a base de uno o varios proyectos, cada uno de ellos tiene un inicio y finaliza a una fecha de entrega. Los ciclos de vida son totalmente independientes, el producto subsistirá mientras no quede desfasado u obsoleto. De hecho un producto exitoso es aquel que está en constante evolución, adaptándose una y otra vez a los cambios y oportunidades del mercado. Pensemos en Amazon por ejemplo, tanto software como los productos que ofrecen están en continua evolución, el día que la tienda no evolucione probablemente se estará acercando al final de su existencia. Un producto basado en software suele estar obsoleto en el momento en el que deja de evolucionar.

Project manager versus Product Owner

Profundicemos en la gestión de proyectos; esta se basa en montar lineas de tiempo (planes) atadas a un alcance inicial y en dotar a la linea de tiempo de los recursos necesarios para cumplir con esa linea, y lo hace en el primer momento sin tener en cuenta capacidades ni dependencias.

Se basa en traer a la gente al trabajo, en equipos asociados al proyecto que por diseño no tienen continuidad. Con cada proyecto se crea un equipo nuevo del que no se sabe su capacidad hasta que esté rodado, y sabemos que los equipos suelen tardar de 3 a 6 meses en estar integrados, haber adquirido el conocimiento sobre el producto y entorno tecnológico y a establecer conexiones con otros equipos y otros interesados clave. Por tanto la dotación de recursos al plan no deja de ser una intención o deseo.

Durante el proyecto el jefe de proyecto o project manager, que está comprometido con el alcance y una construcción óptima del mismo, tiene su foco en cumplir con el triángulo de hierro protegiendo al proyecto de todo cambio, y por tanto está indefenso para lidiar con la turbulencia del cambio del mundo actual y la divergencia diaria de las metas de proyecto y producto.

Scrum proporciona una forma distinta para construir y hacer evolucionar un producto, una forma centrada en el producto y no en proyectos. Se basa en medir la capacidad de flujo del sistema y sus equipos, equipos maduros y estables y con continuidad, ajustar el trabajo inyectado a la capacidad y poner el foco en mejorar el flujo de forma continua, alineando, sincronizando y planificar teniendo en cuenta las dependencias. Trae el trabajo a la gente y en forma de incrementos de valor para el producto. Un Propietario del Producto o Product Owner está comprometido con los problemas del cliente y su foco principal es conseguir el mejor producto del mundo.

Ambas son formas para construir y mantener un producto. En mi experiencia, en especial en el desarrollo de software y aquellas áreas que tratan directamente con clientes y usuarios, cuando lo hacemos a través de proyectos pasaremos por varias crisis de ajuste a la realidad, ya que el foco está en las actividades del proyecto y no en los incrementos de valor del producto. Cuanto más corto sea el proyecto menos incertidumbre le rodea y más posibilidades tiene de incorporar las divergencias y por tanto tener éxito. Si construimos con Scrum, focalizados en incrementos de valor, garantizamos el mejor producto posible para el presupuesto y tiempo dado, solo hemos de liberarnos del anclaje a un alcance inicial y entender que al principio de un proyecto es imposible saber como va a ser el detalle de ese mejor producto posible.

Quiero dedicar este post a Dani, el autor del dibujo del Titanic, con el que he disfrutado impulsando a algunos jefes de proyecto en su trayectoria ágil