Repitamos juntos: No bañaré en oro mis proyectos.

"Bañar en oro" los proyectos es una importante fuente de problemas y sin embargo dicha práctica se viene repitiendo y repitiendo como piedra en la que caemos continuamente. Está en nuestra naturaleza, lo de caer varias veces en la misma piedra, por tanto tal vez sea conveniente repetirlo como un mantra todas las mañanas.

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Rita Mulcahy, experta en dirección de proyectos reconocida internacionalmente, que a su vez fue contribuyente y revisora de la Guía del PMBOK del Project Management Institute identificaba "bañar en oro" los proyectos como una mala práctica y lo definía como dar componentes de mayor calidad, alcance extra o mejor rendimiento del pactado con el cliente al comienzo del proyecto. En ocasiones no está incluido en la planificación, sino que en la ejecución diaria del proyecto alguien incorpora "mejoras" no solicitadas que supone valorará el cliente.

Mary Poppendieck en Implementing Lean Software Development identifica la "Funcionalidad Extra" como el peor, con diferencia, de los siete desperdicios (Wastes) del proceso de desarrollo de software. Si eliminar desperdicios es probablemente la piedra angular de los principios Lean y la "Funcionalidad Extra" es el desperdicio "estrella"...

Desde Silicon Valley -tierra sagrada para los emprendedores de todo el mundo- Eric Ries en su libro Lean Startup se aproxima al mismo concepto desde la perspectiva de empresas innovadoras de alta tecnología. Eric va más allá y propone un nuevo modelo de management cuyo núcleo es el Producto Mínimo Viable (MVP, por sus siglas en inglés) que nos permita conducir nuestro esfuerzo de desarrollo a través de lo que denomina el aprendizaje validado haciendo incapie en evitar los indicadores vanidosos, esos que nos hacen creer que vamos por el buen camino (para nuestra propia satisfacción) hasta que nos encontremos con el fin de la vía... y un precipicio. El método Lean Startup pretende evitar la implementación de características en los productos que los usuarios no han pedido, no quieren y no utilizarán...

Desde la comunidad de Google +FebMeeting, capitaneada por Gojko Adzic, se trabaja en encontrar un mínimo común en las técnicas actuales de definición de producto que permita sintetizar las prácticas que nos llevan a construir el producto adecuado. La siguiente imagen resume las primeras conclusiones.

"Bañar en oro", "Funcionalidad extra" o "como quieras llamarlo" ha hecho y seguirá haciendo mucho daño. Por más que mejores tu proceso de desarrollo, por más que utilices las mejores y validadas prácticas ágiles del momento y todo tu equipo funcione como un reloj suizo... si circulas por la vía equivocada... todo, y digo "absolutamente todo" lo que hagas durante tu jornada laboral es puro desperdicio. Desde una perspectiva más tradicional, después de meses/años de esfuerzo mejorando (madurando) tu proceso para conseguir una mejora significativa de productividad (digamos un 20%, que ya está bien), si igualmente circulas por la vía equivocada... el 100% es desperdicio.

Lo peor es que esta práctica ocurre en todos los niveles de la jerarquía, aunque obviamente cuanto más arriba más doloroso (en cuanto al costo del desperdicio). Pongamos algunos ejemplos, a ver si te resultan conocidas las escenas :

El desarrollador que decide incluir en la interfaz unos efectos chulísimos que, aunque no lo había pedido nadie, quedaban de lujo y que finalmente dieron ciertos "problemillas" que retrasó la entrega del proyecto.

El Arquitecto software que decide que prácticamente la totalidad del sistema que está diseñando estará sujeto a cambios y lo sobrecarga de patrones de diseño consiguiendo el efecto opuesto al deseado: un sistema más complicado de implementar y mantener.

El Jefe de Proyecto o Product Owner que después de hablar con sus clientes/usuarios decide "desviarse" de las especificaciones... porque en realidad no saben lo que quieren, y está seguro que cuando termine el producto y se lo entregue estarán encantados... Que no digo yo que no se pueda ser innovador y visionario, pero con mesura, que no todos somos Steve Jobs ni todas las organizaciones tienen por visión cambiar el mundo.

Alta dirección (como decía a más altura, más desperdicio...). En este caso no es que perdamos el trabajo de una iteración (o dos) de un equipo de desarrollo, o de construir la mitad de un producto equivocadamente... aquí el "baño en oro" puede afectar al proyecto completo. El resultado es tristemente conocido: aeropuertos sin aviones, líneas de alta velocidad sin viajeros... y aunque no se vean tanto porque los podemos esconder mejor... sistemas de información sin usuarios... poco ayuda aquí que lo implemente una factoría de la India nivel 5 de CMMI o la mejor empresa del planeta usando Scrum, si no hay usuarios el desperdicio es "el todo".

Por eso, estés donde estés en la jerarquía, repitamos todas las mañanas antes de iniciar nuestra jornada laboral... "no bañaré en oro mis proyectos", no sé... tal vez la sugestión funcione.