El ciclo de mejora continua es un concepto que se puede aplicar a la vida y al ámbito empresarial. Las herramientas y recursos que propone nos dan la oportunidad de estar en procesos de constante mejora, y esto es muy útil en el área, precisamente, de IT.
Origen del método Kaizen
Mucha gente tiene asumido que las prácticas de mejora continua tienen su origen en Estados Unidos. Y, si bien este país ha influenciado en el desarrollo de muchas metodologías, su origen viene del mundo industrial japonés, precisamente cuando finalizó la 2ª Guerra Mundial, siguiendo los conceptos metodológicos de William Edwards Deming y J.M. Juran. Rápidamente se extendió por toda Asia Oriental.
Esto nos muestra que su origen no sucedió con las TI y que, de hecho, las excede: es en sí una filosofía de vida. Kaizen se puede traducir como mejora continua.
[Fuente imagen: Wikipedia]
Kai (Cambio, acción de enmendar) / Zen (bueno, beneficioso)
Este método trata de realizar pequeños cambios pero continuos orientados a mejorar, tanto a nivel personal como empresarial. En la práctica corporativa, se enfoca en adoptar una serie de procedimientos y herramientas para conseguir unos estándares de calidad óptimos y una significativa reducción de costes.
Cómo aplicar la mejora continua en el ámbito corporativo
Existen muchas formas de empezar con la mejora continua en una empresa. Hoy hablaremos del método de las 5S y del Ciclo Deming (PDCA).
Método de las 5S para mejora continua
[Fuente imagen: Wikipedia]
Resumidamente, podemos decir que estos conceptos aplicados al mundo de las TI ayudan a mejorar y simplificar el entorno de trabajo para focalizarnos en el objetivo. Veamos los componentes del método:
Seiri (Clasificación)
Esta instancia nos propone mantener únicamente lo esencial para realizar una tarea, es decir, descartar los elementos inútiles u obsoletos. Está muy alineado con el principio de desarrollo de software KISS (Keep It Simple, Stupid!). Un ejemplo sería tener un IDE configurado con los plugins justos y necesarios.
Seiton (Orden)
Este componente busca asegurar que todos los elementos están organizados de una forma lógica, facilitando así la consecución de las tareas. Todas las herramientas consideradas útiles y necesarias deben ser ordenadas para facilitar el acceso a cualquiera de las partes, como la correcta organización de los repositorios de código y/o artefactos, por ejemplo.
Seiso (Limpieza)
Debemos mantener el entorno de trabajo limpio, procurando anticiparnos a defectos o errores. En lo relativo a proyectos tecnológicos, podemos incluir muchos de los conceptos del libro Clean Code: A Handbook of Agile Software Craftsmanship, de Robert C. Martin y Dean Wampler.
Veamos los 9 puntos que definen a un código limpio:
- El código limpio está enfocado, y esto va muy en línea con el principio de desarrollo de software SRP (Principio de Responsabilidad Única), definido como: “Una unidad funcional en un nivel de abstracción dado debería ser responsable por un único aspecto de los requerimientos del sistema.”.
- El lenguaje con el que se escribió el código debería parecer que fue hecho para el problema. Como establece Robert C. Martin: “No es el lenguaje lo que hace parecer simple un problema, sino que el desarrollador hace que el lenguaje parezca simple.”. Esto quiere decir que, generalmente, si decimos que algo solo puede lograrse con un workaround, es que no hemos invertido el tiempo necesario para obtener una solución limpia y simple.
- No debe ser redundante: Está en línea con el principio de desarrollo de software DRY (No Te Repitas), que establece que, cambiar un elemento no implica modificar otros elementos sin relación lógica.
- Leer el código debe ser placentero: El código debe ser sencillo, fácil de seguir y entender, sin necesidad de investigar. Es importante tener siempre en cuenta los principios KISS y YAGNI (No lo Vas a Necesitar).
- Puede ser extendido fácilmente por cualquier otro desarrollador: Debemos codificar de forma que otras personas sean capaces de realizar cambios o extender la funcionalidad.
- Debe tener dependencias mínimas: Cuantas más dependencias tenga una solución, más difícil será de mantener y actualizar.
- Más pequeño, mejor: Es necesario que nuestras clases, objetos y/o funciones sean cortas. Cuanto menos código utilicemos, cuanto más desgranemos un problema a solventar, mejor.
- Debe tener pruebas unitarias y de aceptación: Si no existen pruebas, no podemos afirmar que hemos solventado el problema.
- Debe ser expresivo: En el código los nombres deben expresar la intención y, si es necesario, se deben incluir anotaciones explicando el cometido de la variable o función.
Seiketsu (Estandarización)
Busca mantener el orden y la limpieza obtenidos en los puntos anteriores a través de la estandarización de las tareas. En el mundo IT, se traduce como la necesidad de establecer convenciones de código, creación de comentarios y documentos con las definiciones necesarias y automatización de las pruebas, entre otros. Así se simplifica la tarea de identificar las distintas partes de un sistema complejo.
Shitsuke (Disciplina)
En este último componente buscamos convertir en hábito los puntos anteriores. Es la descripción más corta (pero la más difícil de aplicar). Entre todos los que colaboran en un proyecto, es importante buscar la forma de procurar la “disciplina” necesaria para dar continuidad a este modelo de trabajo.
Lo mejor del método de las 5S no es el resultado obtenido, sino que se puede empezar a aplicar sin necesidad de cumplir ningún requisito.
Ciclo Deming
También conocido como PDCA por sus siglas en inglés (Plan, Do, Check, Act), consiste en:
[Fuente imagen: Wikipedia]
Plan (Planificar)
Se establecen las actividades del proceso, lo que implica recopilar los datos necesarios para profundizar en el conocimiento de un proceso, detallar las especificaciones y los resultados esperados, definir la tareas necesarias para conseguir el requerimiento y cómo se verifica y establecer los objetivos y procesos necesarios.
Do (Hacer)
Aquí se debe desarrollar la tarea. Lo ideal es siempre empezar con la prueba, la verificación de que, efectivamente, funciona.
Check (Verificar)
Una vez finalizada la tarea, los datos de control y prueba se agrupan y analizan, comparándolos con los requisitos expuestos.
Act (Actuar)
Teniendo en cuenta los resultados obtenidos en el anterior punto, es posible que sea necesario volver al paso inicial de planificar para poder adaptarlo y conseguir un resultado mejor o más ajustado a lo requerido.
Como sucede con las 5S, siempre podemos empezar a aplicar esta metodología sin más, estando un proyecto en cualquier estado y grado de avance, aunque este método requerirá de mayor dedicación al principio.
Conclusión
Estas son solo algunas de las metodologías existentes, tales como la Mejora Continua, Grupos Kaizen, Kaizen Nissan, Karakuri Kaizen, Teian Kaizen, y más. No se trata de decir cuál es mejor que otra, de hecho, pueden utilizarse fusionadas, como la fusión de 5S, PDCA y Hansei.
El objetivo de todas, sin lugar a dudas, es conseguir una solución, proyecto o empresa de calidad y, sobre todo “foolproof” o, como dicen en Japón, cuna del Kaizen: Poka-yoke.
Desde Enzyme podemos acompañarte a implementar el método indicado para tu empresa y así perfeccionar sus procesos, reducir sus costes y aumentar sus resultados. Contáctanos para recibir una propuesta personalizada.
