Según el enfoque tradicional de gestión de proyectos, el éxito de estos se mide por el grado de cumplimiento de tres variables: alcance, tiempo y presupuesto. O sea, el proyecto tendrá éxito si el alcance deseado es entregado en el plazo y al coste previstos. El problema de este planteamiento es que ignora si ese alcance crea o no valor alguno para el cliente o usuario finales: hemos podido entregar toda la funcionalidad que nos pidieron, en fecha y dinero, pero puede que tal funcionalidad luego no sea utilizada por nadie.

Lo recomendable es adoptar una mentalidad de producto, orientada a la creación de valor a largo plazo. Esbozo a continuación las características asociadas a uno y otro enfoque.

Mentalidad de proyecto

– El éxito es medido de acuerdo con parámetros preestablecidos: entrega del alcance deseado en presupuesto y plazo.

– Orientación a la gestión de tareas y personas por parte del Project Manager.

– Trasvases de conocimiento entre departamentos o especialistas a medida que las fases del proyecto progresan.

– Uso de Waterfall o Water-Scrum-Fall.

Mentalidad de producto

– El éxito se mide de manera continua de acuerdo con métricas de negocio: tasa de uso o retención, ingresos, ahorro en costes, etc.

– Puestas en producción frecuentes, con objeto de obtener feedback de los clientes o usuarios lo antes posible.

– Énfasis en la visión y objetivos de producto en lugar de en la gestión de tareas, lo cual otorga mayor autonomía al Equipo de Desarrollo; mayor creatividad y menor despilfarro en actividades de reporte.

– Uso de Agile y Scrum. Las funciones del Proyect Manager tradicional son eliminadas u absorbidas en parte por el Product Owner, el Scrum Master y el Equipo de Desarrollo.

Podría parecer que estamos ante un debate más bien teórico. Sin embargo, son muchas las empresas que se enfrentan a esta dicotomía, que tiene carácter estratégico y gran trascendencia en cuanto a la propia cultura empresarial de nuestra organización.

– La situación arquetípica quizás sea la de la empresa que ha ido desarrollando un producto de software propio aunque a medida de ciertos clientes B2B o partners, puede que durante años, hasta que llega un punto en el que queda claro que escalar así es casi imposible. Todos esos pequeños proyectos de desarrollo que nos hicieron fuertes en su momento se van convirtiendo en deuda técnica, en vallas que nos impiden avanzar y tener el producto que queremos. Lo más doloroso es que puede que tengamos que decir “no” (mi deporte favorito como Product Owner) a muchos de esos proyectos, que nos traen rentabilidad en el corto plazo. O, peor aún, que tengamos que explicar a esos clientes que tienen que renunciar a determinadas funcionalidades por las que en su momento pagaron.

Recuerdo cuando en Liftshare (algo así como el Blablacar de Reino Unido, donde teníamos un parte muy importante de B2B) teníamos que hacer auténticos malabares para acomodar las peticiones más o menos pintorescas de grandes cuentas, y lo importante que era trabajar con los Account Managers para que no vendiéramos aquello que no pudiera tener encaje en nuestra estrategia como plataforma.

– Más difícil aún es gestionar esta tensión estratégica desde las consultoras de software, que suelen tratar a cada cliente como un nuevo proyecto. Lo importante es que la consultora sea capaz de ir más allá e integrarse dentro de la estrategia de producto del cliente… Pero, claro, a menos de que parte del contrato esté vinculado al éxito del producto, en términos de valor real, es decir, a menos de que el riesgo se comparta en cierto grado, esto va a ser harto complicado.

¿Se enfrenta tu empresa a esta tesitura entre proyecto y producto? ¿Cómo la estáis resolviendo?

Imagen: Vector de Negocios creado por katemangostar – www.freepik.es