En un post anterior hablamos largo y tendido sobre Scrum. A la hora de aplicar Scrum se puede complementar con otras técnicas de Desarrollo Ágil como pueden ser TDD (Desarrollo Dirigido por Pruebas), XP (Programación Extrema), el método Jidoka, etc. En este post vamos a tratar en concreto el método Jidoka.
La palabra «Jidoka» significa verificación del proceso. Se utilizan parámetros óptimos de calidad en la producción. Si surge un problema, el proceso se detiene alertando a todo el equipo y éste se centra en resolverlo, y cuando se resuelve se da por supuesto que dicho error no volverá a producirse. Una vez resuelto se reactiva el proceso de producción. Así, objetivo de este método es obtener un 100% de calidad siempre.
Además, el método Jidoka se puede explicar mediante una historia o anécdota sucedida en una empresa japonesa, así me lo explicó por primera vez José Manuel y me encantó el ejemplo.
La historia del método Jidoka
Un día los dirigentes de una prestigiosa marca de coches americanos hicieron una visita a otra prestigiosa marca de Japón. Una vez allí y después de varios días observando la cadena de montaje quedaron impresionados con la sincronización de los procesos.
Sucedió que una vez un coche salió con una raya en la chapa de la puerta izquierda, y rápidamente el director de la cadena de montaje tocó una campana y todos pararon de producir, se reunieron y debatieron qué podía ser el causante de aquella catástrofe. Iban proponiendo ideas y descartando opciones entre todos, recorriendo la fábrica todos juntos, hasta que encontraron el problema: cuando pasaban 15 días sin cambiar el esprite de pintura, le entreba una mota de polvo y rayaba un coche.
Una vez localizado el problema acordaron el encargado de cambiar 2 días antes el esprite, volvieron cada uno a sus puestos de trabajo y el director volvió a tocar la campana. Como un reloj la cadena de montaje comenzó de nuevo a producir.
Los americanos no salían de su asombro, ¡HABíAN PARADO LA CADENA DE MONTAJE! Al ver la reacción generada el director japonés les preguntó:
– ¿Cómo lo hacéis vosotros?
– Apartamos rápidamente el coche y un equipo de mantenimiento lo repara. Pero no dejamos de fabricar ni un sólo minuto, no podemos permitir bajar el rendimiento de producción. – contestó sonriente el americano
– ¿Entonces? ¿No localizáis el problema? ¿Tenéis un coche fallido cada 15 días?
– Ejemmmm… esto… si, pero no perdemos tiempo.
– Entonces, A la larga vuestra pérdida de tiempo es mayor e infinita.
En definitiva, el método Jidoka desarrolla los proyectos en equipo, todos a una y tras resolver el problema, se confía que no volverá a dar dolores de cabeza 😉
Creo que puede venir muy bien en desarrollo del software. ¿Qué opináis?
Me parece una buena práctica, pero veo díficil el poder seguirla en según que equipos.
Nosotros aquí porque somos cuatro gatos y tenemos el buen rollo necesario como para ayudarnos entre nosotros, pero en equipos más numerosos seguro que hay problemas, básicamente por el cruce de competéncias.
En el ejemplo todos van a una en una cadena de montaje, pero en según que empresas cada uno hace la guerra por su lado.
Un abrazo tio!!
Ya ves, y en las PYMES muchas veces es así al tener «varios coches a la vez» y cada uno se encarga de uno. Cada uno se encarga de un proyecto entero y claro carece de sentido parar la cadena de montaje…
Pero si lo enfocamos para el desarrollo de productos si nos podría valer y puede ser útil, no crees?
un abrazo!
En definitiva suena muy bonito y se que es alcanzable, pero en la practica la cantidad de recursos humanos y tecnicos disponibles para que en el momento que se toque la campana todo un grupo baje a diagnisticar y encontrar la causa raiz resulta dificil por la comprension del «yo opero tu reparas, yo reparo tu diseñas y yo dioseño y tu operas» la disivison del trabajo, este costo muy dificilmente lo quieren absorber las compañias ya que el beneficio no es imediato. y no hablemos de la estadistica y registro que se debe de llevar sobre el metodo jidoka
Exactamente… actualmente en las empresas americanas, mexicanas han trabajando por muchos años asi…. teniendo solo equipos de respuesta para solucionar los problemas dentro de producción. Tecnicos de procesos, fallas, pruebas, etc., que solo se preocupan por sacar lo ya producido para no generar un alto stock de los materiales producidos sin ser entregados al cliente externo, creo que esta técnica es muy buena pero tengamos en cuenta que la cultura de las personas las separa un abismo con Japón y América. Y siempre y cuando este abismo nos separe jamaz se podra lograr implementas una herramienta de calidad.
Qué es esprite?