Mejorar ligeramente cada día. ¿No sería estupendo? En Easy LMS, todos somos seguidores del método Kaizen. Este método japonés de productividad nos ayuda a hacer frente a las pérdidas de tiempo, para que el trabajo sea más agradable y ligero. Su aspecto clave es la mejora continua;
¿Por qué Kaizen?
Grandes procesos de mejora. Lo hemos intentado, créanme, pero nunca con el efecto deseado. Se paralizaban, porque no podíamos elegir entre todas las mejoras posibles, y nos perdíamos en las cuestiones cotidianas. Siempre surgía una pregunta del cliente entre medias, que era más urgente que poner en marcha todo un proceso;
Como nos gusta mucho mejorar, hemos apostado por el método Kaizen. Después de leer el libro Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results de Mike Rother, nos convencimos de su eficacia. Al fin y al cabo, el Kaizen no se centra en que todo sea perfecto de golpe, sino en dar pequeños pasos cada día. Los pequeños pasos son, de hecho, pasos muy pequeños. En total, estos pasos le llevarán lejos. A fin de cuentas, también se corre un maratón paso a paso;
La traducción literal de Kaizen es "cambiar para mejorar".
Visión general de los métodos Kaizen en Easy LMS
Kaizen cuenta con una amplia gama de métodos y procesos, tanto grandes como pequeños, para realizar mejoras. Kaizen en Easy LMS se basa en las siguientes partes:
Determinar la dirección utilizando las condiciones objetivo.
Pequeñas mejoras continuas.
Análisis de la causa raíz: preguntarse por qué cinco veces.
El conocimiento es poder.
Kaizen es responsabilidad de todos.
Centrémonos en las partes dos a cinco, ilustradas con un ejemplo de cómo ejecutamos Kaizen. La primera parte necesita un artículo entero para explicarla ?;
Parte 2: Pequeñas mejoras continuas
Algunas mejoras parecen demasiado pequeñas y precisamente entonces es importante hacerlas.
¿Cómo de pequeño es? En nuestro caso, muy pequeño. Aprender atajos, o incluso trasladar una impresora a un lugar más conveniente, es una mejora. Por eso, hacer pequeñas mejoras es quizá el paso más difícil. Algunas mejoras parecen demasiado inútiles, demasiado pequeñas o tener muy poco impacto. Por eso a menudo no se hacen, y precisamente entonces es importante hacerlas. El otro peligro es que cuanto más espere, mayor será el problema, lo que significa que tendrá que incluirlo en la planificación, con todos los peligros que ello conlleva. Puedes empezar inmediatamente a hacer pequeñas mejoras. Incluso sin la aprobación de la dirección. Cada paso adelante genera beneficios;
Nos dimos cuenta de ello cuando examinamos más de cerca nuestro ciclo de publicación. Antes, creábamos nuevas funcionalidades o solucionábamos errores en línea ("liberábamos") una vez cada pocas semanas. Ahora lo hacemos al menos dos veces por semana, y muy pronto será cada vez que hayamos completado algo.
El camino hacia esto consiste en docenas de pequeños (mini) pasos. Nos gustaría destacar cuatro:
Primero probamos todo antes de que salga al mercado. Para probar una versión, los desarrolladores inicialmente tenían que hacerla disponible en nuestro entorno de pruebas. Los desarrolladores a veces se olvidaban de esto, o estaban enfermos. Al fin y al cabo, somos humanos. Esto nos dio muchas razones para asegurarnos de que nuestra probadora, Caroline, pueda poner la versión en el entorno de prueba ella misma.
La generación automática de una versión tarda 45 minutos, lo cual es un tiempo de espera bastante largo. Como tarda tanto, ahora lo hacemos a horas fijas: Lunes y jueves a las 6 de la mañana. Cuando llega Caroline, puede empezar inmediatamente. Pero primero, por supuesto, una taza de café ?.
Al principio también se requería que un desarrollador pusiera una versión en vivo en el entorno en vivo. Ahora ya no es así. Ahora lo hace la propia Caroline. La puesta en marcha sólo es posible si todo ha sido aprobado.
Siempre realizamos pruebas de aceptación y eso lleva mucho tiempo. Sobre todo si son 25, como es nuestro caso. Por eso, empezamos a automatizar estas pruebas una a una. La primera prueba nos ahorró un poco de tiempo. Ahora ya están todas automatizadas y eso nos ahorra 12 horas a la semana.
La primera prueba nos ahorró un poco de tiempo.
Parte 3: Análisis de la causa raíz, preguntarse cinco veces por qué
Cuando se aplica el Kaizen, no basta con poner parches.
Cuando se aplica el Kaizen, no basta con poner parches. Se aborda la raíz del problema para resolverlo una sola vez. Siempre tan eficaz. Se puede encontrar la raíz del problema preguntando "por qué" cinco veces;
Cada vez que no cumplimos un determinado objetivo, realizamos un análisis de la causa raíz. Esto nos da un límite de tres historias de usuario que pueden estar en desarrollo. Lo hemos determinado entre todos. Esto nos obliga a completar las historias por orden de prioridad. Si alguien coge una cuarta historia, detenemos el trabajo y empezamos a analizar.
Hace poco, tuvimos que poner algo en directo mientras ya se estaban desarrollando tres historias. Poner algo en vivo, significa la historia número cuatro. Llegamos al siguiente análisis:
¿Por qué hemos abierto una nueva historia?
Tenemos que hacer un lanzamiento y el lanzamiento requiere una historia que indique lo que hay que hacer.
¿Por qué necesitamos esta historia?
Pondremos varias funcionalidades nuevas y solicitadas en vivo.
¿Por qué vamos a lanzar varias funcionalidades?<
Nunca lanzamos una sola funcionalidad.
¿Por qué no lo hacemos?
Crear una versión lleva demasiado tiempo. Los costes superan los beneficios.
¿Por qué lleva tanto tiempo?
Las pruebas son el cuello de botella.
¿Por qué las pruebas son el cuello de botella?Las pruebas automatizadas no son lo suficientemente fiables, así que hay muchas pruebas manuales.
¿Por qué las pruebas automatizadas no son fiables?
Porque utilizamos un marco antiguo en el que ejecutamos las pruebas.
Por qué las pruebas automatizadas no son fiables?
Porque utilizamos un marco antiguo en el que ejecutamos las pruebas.
Hay múltiples soluciones a varios niveles para resolver este problema. Juntos decidimos cuál es la mejor solución por el momento. La solución para esta causa raíz es actualizar el marco de ejecución de las pruebas;
Parte 4: Saber es poder
¿Cómo saber si un cambio ha tenido éxito? El conocimiento es poder. Cree una línea de base y vuelva a medirla después del ajuste. Intentamos que todo sea medible en la medida de lo posible, pero a veces también tenemos la corazonada de que algo puede hacerse más rápido o mejor. Una vez más, somos humanos;
Un proceso que hemos hecho totalmente mensurable es el de una historia de usuario. Antes de que una historia pueda ponerse en marcha, pasa por toda una serie de pasos. ¿Cuánto tiempo llevaban estos pasos? No teníamos ni idea hasta que empezamos a medir el tiempo. Entonces quedó claro dónde estaba el cuello de botella: Caroline tardaba demasiado en hacer pruebas. Hicimos un análisis de la causa y pusimos en marcha inmediatamente una mejora basada en él. Otra mejora que surgió: el proceso de gestión de las traducciones. Pero eso es algo para otro artículo;
Parte 5: Kaizen es responsabilidad de todos
El kaizen sólo funciona si todos en la empresa contribuyen a él asumiendo la responsabilidad y dedicándole tiempo y atención. En Easy LMS, todo el mundo tiene espacio para proponer mejoras y tiempo para dedicarles. Porque sabemos que nos beneficiaremos a largo plazo
Ahora que ha leído este artículo, ¿le gustaría dar un paso en el camino hacia el Kaizen?
