En una oportunidad trabajé como desarrollador para un proyecto que culminó fracasando estrepitosamente. No solo se entregó mucho después de la fecha pautada y con un notable desbordamiento de presupuesto, sino que, además, se entregó una aplicación que el cliente no había pedido. No supe sino hasta el final del proyecto, que la razón principal del fracaso fue la forma en que se priorizaron las actividades, o eso parecía.
Lo cierto es que si se analiza la historia en retrospectiva, parece lógico pensar que claramente podía advertirse el problema de priorización que sucedía. En la empresa donde trabajaba en aquel entonces, el equipo de desarrollo era responsable de llevar múltiples proyectos para múltiples clientes. Esto suponía, a priori, un problema de descontrol y desorganización que se hacía notar.
Diariamente, el uso de la jornada laboral obedecía si y solo sí, a las instrucciones del jefe de los proyectos. Esta persona, acudía a tu puesto de trabajo y era capaz de hacer detener todo lo que estabas haciendo y obligarte a cambiar de desarrollo. Esto porque era exageradamente importante para los intereses estratégicos de la empresa. No habían pasado ni diez minutos, mientras intentabas cambiar el switch y comenzar la nueva importante funcionalidad de extrema importancia, cuando ya volvía el jefe del proyecto con nuevas funcionalidades de mayor urgencia y prioridad estratégica. Era evidente, que de esta forma no se podía trabajar. Solo era cuestión de tiempo para que algo malo sucediera.
Paradójicamente, se alegaba que, como se trabajaba dentro de un marco ágil, se debía de responder rápidamente al cambio, pues los clientes necesitaban de funcionalidades «para ayer». Cuando finalmente, el proyecto fracasó y se intentó buscar las causas, estas fueron simples: El departamento comercial, en función de los ingresos que generase uno u otro cliente, priorizaba las funcionalidades a entregar. El jefe de los proyectos, sin voz ni voto, simplemente acudía desesperado a cambiar las ordenes de entrega. Palabra Santa.
Esta claro que, priorizar basado en los ingresos que pueden producir un cliente u otro, no es en lo absoluto una idea descabellada. Pero ¿Era esta la manera correcta?
¿Qué se puede aprender de esta experiencia?
- Colocar a un solo equipo a trabajar en múltiples proyectos puede ser contraproducente.
- El departamento Comercial y el departamento de Gestión de TI deben estar alineados estratégicamente y de forma bidireccional.
- Priorizar con base en los ingresos por cliente es una buena idea, pero las repriorizaciones deben tener un margen de tiempo razonable.
- En las filosofías ágiles se acepta el cambio. Pero este cambio tiene normas a seguir en torno a el momento en que deben considerarse.
- Priorizar debe ser una tarea que obedece a un análisis, no a un impulso.
