Lean Manufacturing (fabricación ligera/ágil/sin grasa) es una filosofía de gestión enfocada a la reducción de despilfarro (waste) en los procesos de fabricación. Fue concebida en Japón, por Taiichi Ohno, para la empresa automovilística Toyota, con el objetivo de atajar ciertos problemas detectados en la cadena de producción: sobreproducción, tiempos de espera, inventario, ineficiencias de mano de obra, etc. Realmente estaba incluida en lo que se conoció como Sistema de Producción Toyota, que incluía otras filosofías de hacer las cosas como es el caso del Just-In-Time (Justo a Tiempo), y que en general incidían en cuestiones tan importantes como: calidad perfecta, mejora continua, eliminación de actividades sin valor (minimizando el despilfarro), orientación al cliente, desarrollo de relaciones duraderas con clientes y proveedores, y flexibilidad para mejorar la eficiencia.
Herramientas en el Lean Manufacturing
Sin profundizar excesivamente, comentar que Lean Manufacturing cuenta con algunas herramientas como las siguientes:
• Kanban. Se trata de un sistema de señalización que permite entregar el pedido correcto en el momento preciso, nivelando de esta forma la producción. Una forma de aplicar este sistema es por medio de los conocidos tableros kanban, que se basa en el uso de tarjetas.
• Seis Sigma Kaizen. Técnica consistente en el control de la variación de los procesos para conseguir una muy baja tasa de defectos. Es básica para contribuir a la mejora contínua.
• Pokayoke. Sistema a prueba de error que busca crear mecanismos para que las cosas se hagan a la primera de la forma correcta. Un ejemplo, es el de los cables del ordenador que sólo se pueden conectar de una determinada forma.
• Jidokas. Automatización con sentido humano, que busca crear mecanismos sonoros o visuales que nos avisen ante la aparición de problemas. Es el caso por ejemplo del aviso luminoso que emite una impresora cuando se queda sin papel.
Precursores del sistema Lean Manufacturing en el desarrollo de software
Tom y Mary Poppendieck han sido los principales precursores de la aplicación de esta filosofía al desarrollo de software, muy ligada a los “frameworks” o metodologías ágiles, como es el caso de Scrum. Además de varios libros sobre la materia, Mary Poppendieck es la autora de un artículo, cuyas ideas considero claves y revolucionarias para mejorar la forma en que desde el mundo IT desarrollamos los proyectos. Su título: «Lean Development & the Predictability Paradox». Se trata de un gran artículo, en todos los sentidos, tanto en extensión (39 páginas), como en las ideas que en él se transmiten. Ideas, sencillas, pero potentes a la vez, todas ellas extraídas de Lean Manufacturing y su práctica en la marca japonesa Toyota.
Todo el artículo gira alrededor de lo paradójico que puede resultar intentar alcanzar la máxima predictibilidad en un proyecto software. Como dice la autora: «La paradoja es que intentar con demasiado esfuerzo crear predictibilidad origina el efecto opuesto».
El camino propuesto comprende los siguientes principios: comenzar pronto, aprendizaje constante, comprometerse lo más tarde posible, y entregas rápidas. Y a su vez, estos principios se apoyan en cuatro focos adicionales: eliminar todo aquello que no aporta valor («waste»), fortalecer la autoridad del equipo de trabajo, integración completa del testeo dentro del propio desarrollo, evitar la sub-optimización descomponiendo el todo en partes más pequeñas.
Ideas principales de Lean Develpment & the Predictability Paradox
Algunas de las principales ideas con las que yo me quedo son las siguientes:
• Los usuarios tienen dificultad para articular claramente lo que ellos necesitan, y las necesidades de los usuarios cambiarán una vez que ellos vean el potencial del sistema y entiendan lo que pueden llegar a hacer con él. Por ello, de la importancia de comenzar a desarrollar lo antes posible.
• Si dividimos un problema complejo en partes más pequeñas, resultará mucho más difícil centrarnos en el campo de actuación en el cual dicho problema existe, porque el esfuerzo se estará dirigiendo hacia solucionar los sub-problemas. En ese aspecto el desarrollo Lean trabaja con un enfoque de «embudo»: se comienza explorando la amplitud del paisaje, para ir luego gradualmente estrechando el campo de visión.
• Los planes están basados en especulaciones, puesto que realmente no conocemos todo lo necesario cuando estamos creando el plan del proyecto. Puesto que hay que asumir los cambios como algo totalmente natural en un proyecto de software, debemos tener «feedback» constante en el proceso de desarrollo, puesto que en caso contrario estaremos desarrollando para situaciones que existieron al principio del plan, pero no cuando el software se vaya a entregar.
• Retrasar los compromisos, significa mantener abiertas las opciones posibles tanto tiempo como sea posible. Como se comentaba antes, las decisiones se deben basar en hechos, y no en proyecciones. Como comenta Mary Poppendieck en el artículo: «La decisiones se deberían hacer en el último momento responsable: el momento en el que un fallo en la toma de decisiones elimina una alternativa importante». Para ello, es crucial también tener una capacidad de respuesta muy rápida.
• Hay que proporcionar autoridad y poder decisión al propio equipo de trabajo, puesto que realmente una planificación que pueda cambiar de forma rápida es mejor implementada por ellos, que adoptando una planificación centralizada.
• En el pensamiento Lean, la eliminación de cualquier cosa que no añada valor («waste») es el punto clave para conseguir la excelencia. Y en este sentido, es necesario revisar aquellos puntos de la cadena donde el trabajo permanece parcialmente hecho.
• La creación de defectos es «waste» en proporción directa al tiempo que el defecto permanece en el sistema. Por eso es tan importante que los defectos creados, sean detectados y solucionados inmediatamente a través del testeo.
• Una gestión efectiva del equipo de trabajo pone el énfasis en que éstos definan y constantemente mejoren sus propios procesos. Esto debe marcar la diferencia entre rendimiento pésimo y resultados magníficos. Se asume que el equipo de trabajo conoce su trabajo y los problemas derivados mejor que nadie. Es muy importante tener un buen método para transferir conocimientos y experiencia entre todos los miembros del equipo, del tal forma que nadie sea indispensable.
• En cuanto al testeo, éste debe estar completamente integrado dentro del proceso de desarrollo. Se dice en el artículo que cualquier sistema de software que pueda sufrir cambios en el futuro debería tener un completo conjunto de tests automatizados, del tal forma que cuando se realicen cambios, sea imposible romper el resto del sistema. Es indispensable que el sistema sea testeado en las mismas condiciones en las que se encontrará en el entorno real de producción.
• La desagregación en tareas ignora el flujo de valor a través del conjunto completo de la cadena económica. Se centra en el coste y tiempo de hacer cosas, pero no considera el valor de no estar haciendo nada. La autora critica en este apartado, la creación de la Estructura de Desglose del Trabajo (“Work Breakdown Sctructure”, WBS) propuesta en la gestión de los proyectos convencionales, porque se centra en la gestión del coste y la planificación de cada parte de forma individual. En este sentido, también, se aconseja medir el rendimiento del equipo completo, más que tratar de medir el rendimiento individual de cada miembro.
• Mary Poppendieck defiende la idea de que cada proyecto debería tener su propio cuadro de mandos que reflejase los principales conductores de valor de negocio, en vez de medir los proyectos en coste, planificación y alcance. Esos indicadores son lo que realmente deberían dictar el éxito o no del proyecto.
• En cuanto a los contratos se defiende que hay que buscar en todo momento la maximización de beneficios proveedor-cliente, y en este sentido los «Targets Contracts» son un buen mecanismo para conseguir dicho objetivo. Se trata de un tema que me gustaría desarrollar en otro post, porque realmente hay materia para muchos ríos de tinta.
Hasta aquí un repaso de las ideas con las que yo me quedo de este gran artículo. Ideas con las que mayoritariamente estoy de acuerdo. No estoy de acuerdo en la visión que se proporciona en el artículo de la WBS, porque considero que el objetivo perseguido por su realización puede ser totalmente compatible con la visión a más bajo nivel (a nivel de implementación) perseguido por Lean. Y en general hay otras ideas propuestas en el artículo, que se tratan totalmente opuestas a la visión que, por ejemplo, el PMI traza de la gestión de proyectos, pero que bajo mi punto de vista son totalmente complementarias. Pero, efectivamente, sobre estos temas también hay mucha materia para escribir.