El enfoque tradicional de gestión de proyectos mide el éxito de un proyecto por cumplir 3 variables: alcance, tiempo y coste.
Es decir si entregamos el alcance deseado por el cliente en el plazo acordado y coste deseado entonces el proyecto ha sido un éxito.
El problema de este planteamiento es que no se tiene en cuenta si ese alcance entregado crea o no valor al cliente.
En definitiva que puede que se entregue la funcionalidad que quiere el cliente pero le es útil? alguien la está utilizando?.
Lo ideal es adoptar una mentalidad de producto donde se este entregando valor en cada sprint o en cada entrega.
Voy a describir cada uno de los enfoques para que se entienda un poco mejor.
Enfoque de proyecto
El éxito de un proyecto viene dado porque se entregue el alcance deseado en el prepuesto y tiempo acordado.
-El Gestor de proyecto gestiona las tareas y personas del proyecto.
-El conocimiento se comparte a medida que avanzan las fases del proyecto.
-Se usa Waterfall generalmente.
Enfoque de producto
-El éxito se mide fijándonos en las métricas del negocio: tasa de retención, ingresos, ahorro de coste. Esta integramente asociado a que el producto genere ingresos y guste al usuario
-Despliegues a producción frecuentes con el objetivo de recibir feedback de los usuarios que utilizan la aplicación. Amazon al día hace varios despliegues con pequeñas nuevas funciones.
-Énfasis en la visión y objetivos del producto ,con lo que conseguimos mas creatividad y gastar menos tiempo en informes de reporte.
-Uso de Scrum y la mentalidad agile ,de hecho las funciones que solía hacer el Product Manager en el enfoque de producto son absorbidas por tres roles :Scrum Master, Product Owner y el Equipo de desarrollo.
Muchas empresas se encuentran ante este dilema, utilizar un enfoque al proyecto o al producto pero la realidad de hoy en día es que si es un producto para el mercado es mejor el enfoque a producto.
Si es un proyecto interno de la empresa o para la administración publica lo mejor es comenzar con enfoque al proyecto y en mantenimiento enfoque al producto.
Una situación común puede ser aquella empresa que ha desarrollado un software propio pero que da servicio a partners y le ha ido bien pero cuando a querido escalar se ha dado cuenta que es imposible.
Todas esas funcionalidades que sus clientes B2B les iba bien cuando han querido crear un producto más global se han encontrado con una gran deuda técnica.
En definitiva algunas veces tenemos que eliminar funcionalidades que gustan a nuestros socios para que el producto sea viable y escalable a medio plazo.
Otro problema que he visto es en las consultoras de software ,son meras fabricas de software donde realizan el producto que quiere el cliente, utilizan Scrum y practicas agile, pero en el fondo no entregan valor solo entregan un software .
Estas empresas utilizan Scrum pero tienen enfoque de proyecto no de producto pero en los contratos solo se pide la entrega del producto con unas funciones ,en un tiempo y coste y como mucho el mantenimiento pero en ningún momento se habla del éxito del producto en el contrato, la consultora cobra tenga éxito o no.
Las consultoras deberían aportar valor realmente y que en el contrato una parte de los ingresos esté vinculado al éxito del producto ,para que realmente no se haga lo que diga el cliente sino lo que realmente aporte valor al cliente en su nicho con su producto.
Si te ha gustado este artículo ayúdame compartiéndolo en alguna red o suscríbete a mi Newsletter.
