Toyota introdujo el término "kaizen", y se ha escrito mucho sobre él en los gruesos libros de la serie Toyota Tao.
Kaizen también se llama el "proceso de mejora continua". Por lo general, se asocia con la producción industrial de automóviles y transportadores, bien, o al menos con el control del proceso. Dicen poco sobre el desarrollo, pero Kaizen es muy adecuado para el desarrollo de software.
Además, aprenderá sobre varios casos que gradualmente llevaron al autor a comprender el kaizen en el desarrollo.
Una serie de problemas
El primer caso ocurrió justo en Año Nuevo, a las 20:00. El disco duro se estrelló en el servidor y por eso fue necesario separarse de la preparación de ensaladas e ir urgentemente a Moscú al sitio de intercambio de tráfico para cambiar el dispositivo roto.
Después del disco duro, la placa base se quemó. Lo cambiaron todo, pero luego decidieron averiguar por qué sucede esto.
Los administradores familiares dejaron en claro que debe tener mucho cuidado con el hardware del servidor, no comprar en ningún lugar y reservar todo y en todos los niveles.
Se decidió cambiar el servidor y tener mucho cuidado al elegir un proveedor. Examinamos el hardware del servidor, solicitamos recomendaciones y elegimos un servidor que luego funcionó sin parar y sin interrupción durante 7 años. Él continúa trabajando ahora, aunque han pasado 5 años desde que el autor dejó ese trabajo.
Pasó más tiempo y se produjo un incendio en el sitio. El servidor sobrevivió milagrosamente. Entonces todos temblaron bien, porque existía el riesgo de destrucción total del negocio.
Después de eso, se hizo un espejo del sitio y la base de datos en un sitio separado, completamente independiente en el otro extremo de la ciudad. Y una vez que ella incluso fue utilizada.
También hubo un caso en que el tráfico comenzó en el sitio que se acaba de lanzar, y de repente se detuvo por completo, simplemente no pudo soportar la carga.
Después del estudio, quedó claro que la compañía de outsourcing que creó el sitio lo hizo para que no tuviera más de 200 personas por día. Gracioso y triste
Después de eso, se decidió abandonar el outsourcing y formar su propio equipo de desarrollo.
Una vez creado el equipo, tenemos un problema más: la corrección de cualquier error provocó una avalancha de nuevos errores. Cualquier cambio casi abrumado todo el sitio.
Cada solución conllevaba muchos, muchos problemas. Cuando analizamos la situación, nos dimos cuenta de que necesitamos cambiar fundamentalmente todo en general, todo el interior. Y luego todo el sitio fue refactorizado por completo, toda su arquitectura fue al revés. Y solo después de eso, la situación cambió radicalmente y los problemas desaparecieron por completo.
Eliminar la causa raíz
Todas estas soluciones estaban unidas por una cosa: todas estaban destinadas a garantizar que el problema raíz que las subyace nunca vuelva a surgir, para que se elimine por completo. De la palabra en absoluto. Y para que el mismo problema nunca más se repita.
¿Entiendes?
Elemental: la computadora se estrelló; nos dimos cuenta de que debemos elegir el hardware adecuado, que nunca fallará.
El sitio se incendió: hicieron una copia para excluir la ocurrencia de una situación similar en el futuro.
Entonces las palabras no sabían tal cosa - kaizen.
5 por qué
No siempre la raíz del problema radica en la superficie, a veces hay que profundizar en ella.
Un buen ejemplo se dio en uno de los libros Tao de Toyota. En la fábrica, se descubrió que una de las máquinas estaba inactiva durante una gran cantidad de tiempo durante el día.
¿Por qué tiene descansos en el trabajo? Resultó que la máquina se detiene para limpiarla.
Alrededor de la máquina hay virutas y suciedad. Naturalmente, si hay virutas alrededor, entonces debe eliminarse, de lo contrario es imposible trabajar. ¿Eso está bien?
Pero Kaizen dice: tienes que cavar a la causa raíz.
¿Por qué se cae el chip? La respuesta llega de inmediato: los chips se apilan porque no van a ninguna parte: la máquina no tiene un dispositivo que permita retirarla y recogerla. Si existiera dicho dispositivo, entonces la máquina no tenía que detenerse.
Bueno, entonces, encontremos una solución que permita que este chip se elimine de la máquina y que no se detenga para la limpieza. Esta solución ya es puramente técnica y bastante simple.
Hay una técnica muy simple para determinar la causa raíz: el conocido método "5 por qué".
Kaizen recomienda usarlo para llegar al fondo de las causas raíz.
Considere constantemente las causas del problema, una tras otra:
- ¿Por qué se detiene la máquina? Porque la limpieza está hecha.
- ¿Por qué se realiza la limpieza? Porque las virutas y la suciedad salen volando de la máquina.
- ¿Por qué vuelan las astillas y la suciedad? Porque no se alejan de la máquina.
Con la ayuda de “5 por qué” encontramos la causa raíz, encontramos una solución para eliminarla, asignamos una persona responsable y los plazos, y verificamos semanalmente el logro del resultado.
Solo tenga en cuenta que cualquier problema puede resolverse de manera costosa y barata.
Kaizen dice: primero elige la forma más barata. Suele ser el más simple y el mejor.
Kaizen en desarrollo de software
Y ahora algunos ejemplos recientes de la vida de un equipo de desarrollo de software.
Feil Jobs
El equipo está implementando sus mejores prácticas en Prod lanzando Jenkins. De hecho, Jenkins es un programador como crontab que puede ejecutar trabajos programados. Y el equipo tenía ese trabajo.
Una vez que se descubrió que Prod-Jobs cayó 5 veces seguidas con estado de falla. Y nadie les prestó atención, a pesar de que, de hecho, cada archivo en el Prod debería ser una alarma universal.
Luego comenzaron a descubrir la razón usando el método "5 por qué":
- ¿Por qué los compañeros de trabajo voltearon 5 veces y nadie prestó atención? Debido a que todos reciben constantemente notificaciones de trabajos deficientes, hay muchos de ellos y se familiarizan
- ¿Por qué se están familiarizando? Porque casi todos los días recibimos algún tipo de notificaciones, falla y no falla. No vemos la diferencia. Simplemente no les prestaron atención.
- ¿Por qué las notificaciones llegan todos los días? Debido a que uno de los desarrolladores está probando un nuevo trabajo que está cayendo, y las notificaciones al respecto van a todos. El trabajo no es importante en este momento, por lo que todos dejaron de prestar atención a las notificaciones de ella y, al mismo tiempo, de todos los demás trabajos.
La decisión fue transparente: para los trabajos de prueba, las notificaciones sobre los archivos no se enviarán a nadie, excepto al propietario del trabajo, e incluso si lo necesita.
Además, se registró oficialmente que cualquier notificación del trabajo es una emergencia excepcional, a la que todos deberían responder.
Guión caído
El segundo ejemplo es un problema con la aplicación QlikView.
Una vez que se le dijo al equipo que sus informes QlikView eran de alguna manera diferentes. Todo parece funcionar, pero los datos no son los mismos. Comenzaron a entender el problema.
Resultó que el script de descarga no funcionó hasta el final. ¿Por qué no funcionó hasta el final? Debido a que había una gran cantidad de código en el script y en algún lugar en el medio estaba el operador de depuración Exit Script: simplemente olvidaron eliminarlo, no lo notaron. La situación resultó cuando la secuencia de comandos de descarga se cayó y los datos se usaron de forma antigua.
¿Por qué no te diste cuenta de esto? Porque las pruebas no mostraron esto debido a la arquitectura. La aplicación se dividió en dos partes independientes (back / download script y front), y así sucesivamente. había muchos datos, intentaron no reiniciarlos nuevamente, para no perder mucho tiempo en esto.
Fue hecho especialmente para que el frente no estuviera conectado con el script de carga. Simplemente tomó un cierto archivo de datos y lo mostró. No estaba claro que este archivo de datos sea antiguo, es decir, era imposible determinar la presencia de un error en él.
¿Qué se inventó para evitar una situación similar en el futuro?
El equipo se hizo la pregunta: ¿cómo asegurarse de notar tal situación en el futuro? ¿Cómo dejar en claro que el script de descarga no funcionó hasta el final?
Se decidió registrar la etiqueta al comienzo del guión y, al final, eliminarla. Es decir Si la etiqueta no se elimina, esto significa que el script no completó la descarga hasta el final. El frente verificó que, si hubiera una etiqueta, mostraría una pancarta roja en el piso de la página con una notificación sobre el problema.
Por lo tanto, aunque la posibilidad de la aparición de tales problemas no se descartó por completo, al menos se supo de inmediato sobre ellos. Solución simple y barata.
Pérdida de datos en reinicios
El servicio de monitoreo web recibió datos de stands industriales. Periódicamente, tenía que finalizarse y corregirse, y cada corrección requería un reinicio. Aunque el reinicio duró un par de segundos, en ese momento los datos industriales y el abismo podrían estar garantizados. Era imposible perderlos, por lo que el equipo decidió analizar el problema más profundamente.
Las preguntas "5 por qué" dejaron en claro que la causa raíz del problema es la arquitectura: era lo que no permitía hacer de otra manera. No importa cuán estricto sea el servicio, no importa lo que hicieron con él, de todos modos, todo se redujo a un reinicio.
La nueva arquitectura resolvió el problema de una vez por todas: el servicio se dividió en dos partes independientes, recepción y procesamiento de datos. Estas partes estaban físicamente separadas, es decir puede desactivar el controlador de forma segura y, mientras recibe los datos, continúa funcionando y guardando todo lo que se obtiene. Y lo más importante, el receptor de datos se hizo para que nunca requiriera un reinicio. Los controladores se pueden apagar, modificar y sobrecargar de forma segura sin preocuparse por el hecho de que se puedan perder datos.
DevOps parece estar allí, pero no parece estar
DevOps es una cosa mágica. Parece estar allí, pero al mismo tiempo también sucede que no existe.
Uno de los desarrolladores publicó sus mejores prácticas en el banco de pruebas. A pesar de que usaba DevOps, "de repente" resultó que el banco de pruebas estaba conectado a la base de datos de combate. Parte de los datos se perdieron irremediablemente.
Empezamos a descubrirlo. Resultó que el desarrollador no se dio cuenta de que estaba usando la cadena de batalla de conexión.
La razón raíz fue que el desarrollador tuvo que cambiar manualmente la cadena de conexión para diferentes soportes y servidores.
¿Qué dice kaizen? Derecho! Debemos encontrar una solución para eliminar completamente el problema, es decir elimine la necesidad de cambiar manualmente la línea.
Y se implementó la solución: la cadena de conexión comenzó a seleccionarse automáticamente según el servidor en el que se ejecutaba. El problema se resolvió de una vez por todas.
Creo que usted mismo ya entendió de los ejemplos anteriores que la esencia de la mejora continua se puede expresar en una frase simple: eliminar por completo la recurrencia del problema.
Resultados clave: una parte integral de kaizen
El resultado de kaizen es la realización, no una idea.
Encontrar una solución no es tan difícil, es mucho más difícil implementarla.
Para cada decisión tomada, es importante entregar resultados clave, es decir, comprender quién debe hacer qué y en qué fecha.
¿Cómo entiendes que has logrado un resultado exitoso?
Tomemos un ejemplo con una cadena de conexión. ¿Qué resultado
material se considerará un éxito aquí? El éxito se logrará cuando:
- se creará una biblioteca para seleccionar automáticamente la cadena de conexión,
- el desarrollador construirá una biblioteca para sí mismo y lanzará con éxito su software con ella.
Ambos pasos deben ser tomados en cierta fecha por ciertas personas. Solo con ambos pasos podemos suponer que se ha logrado el éxito.
Los resultados clave son criterios de éxito; Kaizen no funciona sin ellos. El éxito es la implementación.
Solo una solución implementada le permitirá eliminar el problema en el futuro, por lo tanto, cuando se habla de kaizen, siempre significa que debe implementar todo lo que se inventa.
¿Dónde más se puede aplicar esto?
Como probablemente haya visto en los ejemplos, Kaizen puede y debe usarse en el análisis de incidentes. En realidad, fue creado para esto.
Los incidentes en grupos de soporte técnico, infraestructura y desarrollo de productos son perfectos.
En cuanto a la codificación, aquí puede analizar su código y ver cómo se puede cambiar para eliminar permanentemente los problemas encontrados.
Sí, y el muy famoso Agile retro también es kaizen, porque en estas reuniones se analizan los problemas para el sprint, se hacen preguntas "5 por qué", y se están tomando medidas para evitar problemas. ¡El kaizen más natural!
La técnica kaizen en sí misma funciona bien en el desarrollo de software, es muy fácil de usar y muy adecuada para su uso en asuntos personales.
El secreto del éxito es simple: elimine los problemas uno por uno y luego no se resolverán en absoluto. Esta es una mejora continua.
Toyota mismo usa kaizen en producción con un éxito abrumador. Sus resultados hablan por sí mismos: los defectos de producción son solo 3 defectos por cada 1,000,000 de partes.
¿Por qué no aplicarlo por ti mismo?
Ahora estás oficialmente bombeado. Si escuchas ese término, sabrás de qué se trata.
Y éxito en tu trabajo.