Cultura Lean en una fábrica

Cultura Lean aplicada a la fabricación de objetos tangibles:

La filosofía de este tipo es que Lean es fácil y lean se trata de eliminar el desperdicio, punto. Si fuera dificil, no serviría.

Pequeñas estaciones de trabajo para hacer batches pequeños. mantener todo limpio y ordenado. Se mejora pero a la gente no le gusta, porque no se sienten dueños del proceso.

Los 8 desperdicios mortales:

  1. Inventario.
  2. Movimientos (transporte).
  3. Overproduction.

En vez de hacerlo así lo empezaron a hacer “just in time”.

Hacer experimentos e ir aprendiendo, no se necesita permiso para experimentar, cualquiera puede hacerlo.

Todos quieren lean, ¿cómo se mide? ¿Hacen lean en su casa? Eso es todo.

¿Cómo contratan? Contratan por la actitud y enseñan las habilidades.

Evitar los pedidos gigantes: hablar con la persona que va a usar el producto final, si no, la orden no se realiza, porque si se fabrica algo sin hablar con quien lo va a usar, entonces se está fabricando el producto equivocado.

2 Me gusta

empecé a ver el video super escéptico, y se profundizó mi escepticismo a medida el gringo hacía su charla estilo americano como vendedor de feria, pero antes de un tercio del video, empieza el valor.

Creo que el tipo este comunica lean mejor que cualquiera que haya visto:

  • Lean es simple
  • Aprende a detectar el desperdicio
  • Enseña a detectar el desperdicio a tus colegas, esto es prioridad.
  • Documenta y comparte cada mejora para inspirar y contagiar.
  • Haz cada proceso auto documentado con radiadores de información para asegurar colaboración

Especialmente me encantaron los videos de mejoras muestra. Me metí a su página y saqué este video que es de la empresa del tipo.

Con un poco más de tiempo voy a seguir viendo (voy como a la mitad) pero quedé enganchado

Yo destaco que la gente deja de trabajar cuando quiere.

Si quieren pueden ponerse a mejorar cosas, no sólo las que tocan ellos, sino cualquiera, lo pueden hacer cuando quieren, porque todo está entregado, no hay temas pendientes, está todo entregado, el tiempo que sobra sirve para hacer cosas como esas.

No hay proyectos donde sobre el tiempo, ¿no? Siempre estás tapado de pega… Entonces no eres lean. Cuando no te sobra el tiempo, te apuesto que hay alguien haciendo copy and paste como loco, y ese tipo se niega a hacer revisiones de código, a escribir tests, a crear prototipos, a reutilizar el código escrito, porque hay gente que ama hacer copy and paste y que le paguen por mover los dedos en vez de usar el cerebro.

En mi experiencia eso es fundamental es 100% contrapuesto a Scrum, en Lean hay mejora continua, eres dueño del proceso de verdad, mientras que en Scrum esa parte es lip service. En Scrum tienes que hacer un reporte todas las mañanas de lo que hiciste, lo que vas a hacer y los impedimentos.

Lo que hiciste significa ¿cumpliste?

Lo que va a hacer significa “comprométete”.

Los impedimentos significa “cuéntame las malas noticias”.

Eso es como entrometerse en lo que las personas hacen, y eso siempre significa “trabaja, trabaja, trabaja” y no te pongas arreglar cosas porque para eso no te pago.

En los proyectos que he tenido éxito dedico al menos el 10% del tiempo y a veces hasta un mes completo de corrido en arreglar algo que hace que el proyecto ande lento, por ejemplo el mapeo Hibernate automatizado. Si sabes que se pierden 4 horas en promedio arreglando a mano los mapeos de Hibernate, no tiene sentido no invertir un 10% del proyecto en corregir ese problema. No necesitas permiso para hacerlo.

Creo que ahí hay un desfase entre Agile y Lean que no alcanza a entenderse. En el método Toyota los empleados tienen derecho a parar la fábrica para resolver un problema. En Scrum al parecer es al revés, se trata de controlar a los empleados y se aplican reglas donde aunque nominalmente se les da el control para autodirigirse, existen todos los controles para que no puedan tomar decisiones por sí mismos.

En mi experiencia, cuando eres el jefe de un equipo, primero les enseñas y luego les dices “avísenme cuando no se puedan poner de acuerdo”. Y listo. La gente se chequea entre ellos mismos porque se necesitan para sacar cualquier parte del producto adelante.

Lo difícil es convencerlos de hacer mejoras profundas, de crear bibliotecas que reduzcan el tiempo de desarrollo x 10. No sé porqué pasa eso, supongo que la educación que reciben es muy de libro “esto se hace así”. Cualquier desviación les da miedo y temen que su intento fracase, pero la actitud correcta debería ser “bueno si esto falla, siempre podemos volver a lo que teníamos antes, fracasar es imposible”.

Se me olvidó mencionar que los tipos se reunen en la mañana para presentar las mejoras que han hecho (cosas hechas en vez de cosas por hacer = kanban)…

Esto porque a nadie le importa que tenga un pendiente… les importa de qué manera ellos pueden hacer las cosas mejor y más rápido…

En una parte del video, hasta donde alcancé a ver en la mañana, hizo un comentario muy por encima que al principio se me pasó por alto pero luego lo recordé. En respuesta a una pregunta del público dice que les pide que cada día, hagan al menos una mejora, por muy pequeña que sea, y luego se da a entender que es mediante esta práctica y a las reuniones diarias en donde se comparten estas mejoras, que el equipo aprende a experimentar y a mejorar.

Lo encuentro genial. Quiero aplicarlo en mi vida, onda, cada día, hacer al menos un mini hack en algún aspecto de mi vida.

Sí, yo también quiero aplicarlo.

otro video que estoy viendo que es la expicación pseudo-científica:

Esto me gustó más:

Básicamente es lo mismo, pero creo que está mejor explicado en el sentido de que la jefatura sólo debe preocuparse de los principios Lean, mientras que es el equipo quien es responsable del resultado. De esta manera se logra que el equipo esté y se sienta empoderado.

Esto es importante porque lograr que el equipo se vuelva autónomo a mí me toma al menos 3 o 4 meses, sino 6, e incluso me ha pasado que el equipo no se siente autónomo, por que se reusan a hacer tests. Sin los tests se pierde la visión del feedback inmediato, entonces se vuelven dependientes de lo que diga el jefe o lo que digan los clientes y se vuelven como niños: irresponsables, no se sienten en control de escenario.

Lean se trata de que la gente se sienta en control, y hasta donde he podido leer, ese es el secreto para hacer que la gente se sienta contenta en su trabajo, que se sienta en control.

Pongo un ejemplo: terminé un proyecto con un equipo de programadores y se tomó la decisión que alguien completamente fuera del equipo de proyecto, una analista/jefe de proyecto iba a hacer la migración con uno de mis programadores… Eso ya suena mal, ¿porqué lo va a tomar otra persona? ¿porqué no ha recibido entrenamiento? ¿porqué no es parte del equipo?

Ok, nada que discutir, pero obviamente me entran sospechas de fracaso…

Ella va instruye a este programador a hacer parte de la migración a mano… casualmente voy pasando por el pasillo y escucho eso… obviamente entro en la conversación y digo: “no puede ser a mano” porque va contra la filosofía de lo que estamos haciendo, todo lo hacemos programando, de manera automatizada, de manera que queda un registro de la data que se entregó y del resultado (a lo CMMI), tanto los datos de entrada como los de salida y los datos rechazados porque están malos. Esto porque típicamente las migraciones fallan y te vuelven a entregrar los datos al otro día, de modo que te pueden mantener todo el día ocupado, pero si haces un programa, te demoras una semana, pero luego las migraciones diarias toman 5 minutos y te queda el resto del día para mejorar el proceso o hacer cualquier otra cosa que se necesite.

Obviamente ella se opone porque quiere entregar todo rápido. Dado que no me han asignado autoridad sobre la migración, no hay nada que hacer. El programador se siente sin autoridad. El resultado es que 2 semanas después el programador está hastiado de hacer algo que no le corresponde (lo contrataron para programar y está todo el día jugando con los datos ya sea en Excel o en un editor). Cada vez llegan más datos y más correcciones, ¿cómo vuelves la migración atrás si estás subiendo los archivos directamente a la BD? En vez de demorarse un día se empiezan a demorar una semana por migración, y cada vez que se reporta algo malo, no hay como volver atrás. El cliente se rehúsa a entregar el conjunto completo de datos corregido, sino que envía sólo las diferencias, pero no hay cómo eliminar lo que viene corregido, excepto si se detecta, se saca, pero es un trabajo de mono y se vuelve imposible de hacer.

Es lo contrario de Lean porque estás usando el tiempo de la gente en trabajo inútil.

Obviamente dado el fracaso rotundo me lo asignan a mí. Tomo al programador y le doy un espacio para limpiar su alma de toda la negatividad, que se tome 2 o 3 días sin hacer nada.

A la vuelta: calma. No empecemos a hacer cosas como estúpidos. Primero: control de versiones. Tomamos algunas de las entregas que tenemos claras. Las subimos al control de versiones. Creamos un programa para convertir de un formato al formato esperado. Creamos un ant db-migrate que borra la BD, la crea de nuevo con el formato correcto y corre el programa de migración a partir de los archivos que están en un directorio y que corresponden a sólo una entrega.

Las siguientes entregas se van pisando los archivos Supongamos que cambia el formato de algún archivo, note avisan, sólo lo cambian, entonces lees el archivo, si lo entiendes, cambias el programa, sino, reclamas al cliente que lo explique, eso queda anotado en un archivo de log de formato, también dentro del control de versiones. Como ha pasado mucho tiempo, descartamos simplemente esa entrega y seguimos con la otra, si el cambio es permanente (se mantiene hasta el día de hoy, lo que raramente ocurre, llamamos al cliente y preguntamos), etc. Imposible fallar.

Esa frase “imposible fallar” es la clave. Si te demoras más de una semana en escribir el programa, no importa, luego la migración se puede ejecutar en minutos.

La sensación es que tu ambiente de trabajo es limpio.

Bueno y ésta es genial:

Enseña a la gente a ir más lento para hacer mejoras. Yo ocupo prototipos para hacer mejoras, acá hablan de tarjetas PDCA que son aún más metodológicas para hacer experimentos.

En vez de tener ocupado al 100% al programador, lo que debes hacer es hacer experimentos para que el programador tenga tiempo para hacer experimentos. ¿Se entiende?

El mayor costo de los proyectos es el tiempo del programador. Si mantienes al programador ocupado, no hay experimentos, si no hay experimentos no hay mejoras. Mantener al programador ocupado es la mejor manera de asegurarse de que el proyecto vaya lento y que el cerebro del tipo se seque.

Una vez que el cerebro se seca, no aprende, no es capaz de inventar nada.

el primer video lo vi entero y me engancho altiro!

El video de kata waks tiene cosas bastante controversiales y por lo tanto interesantes:

  1. Todos sabemos que Lean es anterior a Agile, ellos todavía están aprendiendo y desde ese punto de vista Lean se sigue modificando.

  2. Katas: Hasta donde sé inventado por Uncle Bob, dentro de programming craftmanship. Que a su vez viene de Agile…

  3. Gemba walks es un concepto inventado por los japoneses aplicando Lean and Kanban en particular, para eliminar waste…

  4. Este tipo dice que Gemba walks está mal, porque si le preguntas a 5 empleados vas a tener 6 respuestas, mejor usa Kata walks y no mejores todo, sino que mejora lo que te lleva a un objetivo gerencial, para que los esfuerzos se alinien con los objetivos gerenciales, para que los esfuerzos tengan sentido,

  5. Gemba walks se trata de que el gerente aprenda. Pero lo que dice el speaker es que también se está enseñando a los empleados en lo que deben fijarse. What the heck should we do on a gemba walk? He tenido la misma experiencia, haces una pregunta y la gente cambia todo lo que hizo, porque la pregunta lo toman como “esto es lo importante” y no son capaces de darse cuenta que lo que hicieron está super bien por otras razones y no te escuchan y lo cambian rapidísimo, desafortunadamente. Alguien que no ha sido jefe se preocupará “que hago si no me escuchan”… eso es fácil… el problema es cómo hago para que se sienten a pensar en vez de cambiar todo por una pregunta que hice… se aceleran porque… me gustaría saber la respuesta, para decirles, relájate, no actúes tan rápido, pensemos una solución… y esa solución que sea un prototipo… guardémoslo en el control de versiones… vamos lento.

Bueno no sé si se entiende que el enredo acá es que Lean ahora al parece tiene Katas… ¿quién se lo copió a quién?

Ahora bien si han ido a un Dojo de programación, es muy parecido a un Dojo de Judo, es experimentar y cada practicante lo hace en frente de todo el mundo, todos aprenden al mismo tiempo, uno practicando, el resto mirando. El Kata se trata de mirar y aprender.

Pero acá el Kata se trata de ir al lugar de trabajo y hacer prototipos, pruebas de concepto, utilizando estos documentos PDCA (Plan-Do-Check-Act) y con una lista de obstáculos… por lo que veo el Kata wallk es innecesario, porque en realidad siguiendo el papelito el empleado puede hacer todo sólo… y más encima queda registrado uno por uno los experimentos.

Algo interesante es que cada entrevistado sabe que está agregando valor para el negocio (reducir head count), pero en ningún caso valor para el cliente, están usando Lean para auto eliminarse.Sigan así y eventualmente la empresa se vuelve tiesa. Si no me creen lean Tom de Marco.

La persona que hace las preguntas tiene que ser un “practicioner”, en nuestro caso, un programador con experiencia, o puede ser un gerente cualquiera??? Por ejemplo un ingeniero comercial o ingeniero industrial??? La respuesta es que tiene que ser alguien que sepa, para que haga las preguntas correctas. Porque un coach es un entrenador, con las preguntas provee entrenamiento… acá parece haber una desconexión entre lo que dicen y lo que hacen:

  1. What is the challenge?
  2. What is your target condition?
  3. What is the actual condition now?
  4. What do you think are the obstacles that prevent you from achieving your target condition?
  5. Which one obstacle are you addressing right now?
  6. What is your next step? (What do you expect? When can we see what you have learned form that step?)

No eran 5 preguntas? Anoté 6…

Me gustaría decir que esto más parece una restrospectiva que algo que se va a hacer de manera random una vez a la semana… ¿cuál es el objetivo de hacer un cata walk si el empleado ya está haciendo bien todo sólo?

Gemba walk se refiere a mirar casualmente lo que están haciendo. Debo decir que hacia esto, pero mirando el issue tracker porque los acostumbré a usar el issue tracker y lo más simpático de todo es que al principio, en los 3 primeros checkines tienes que corregirlos, pero de ahí en adelante nunca más, porque entre ellos se corrigen sólos.

Creo que felipe tiene razón, el primer video está bien, esto está mal, porque los empleados no se sienten motivados, al contrario, respuestas automáticas, se aprenden las preguntas, las respuestas no tienen emoción, parece que estuvieran leyendo el periódico, el Kata walk no aporta valor… ¿para qué hacerlo si ya está todo bien?

Además si yo fuera el empleado diría que el cata walk es sólo una distracción de mi verdadero trabajo. Algo así como un standup meeting entre 2 y que se quiere convertir en una retrospectiva, pero no hay información nueva para mí, es como un reporte de status gigante para un micromanager.

Creo que esto es lo que pasa cuando alguien que lee muchos papers trata de colaborar en el trabajo real: lo que se imagina no es lo que realmente está pasando en el trabajo. Por cierto la forma de trabajar que tenemos hoy en día viene directamente de los gringos: las formas de las palas, los tamaños, etc. vienen de los estudios que hizo Frederick Taylor directamente en ambientes de trabajo, y estos no están diseñados para agotar a las personas, como hubiera hecho un chileno cualquiera (todos hemos escuchado eso de “tenemos que mantenerlos ocupados”), sino que se trata de obtener la mayor eficiencia haciéndolos trabajar lo menos posible… ¿porqué lo menos posible? Porque de esa manera el empleado queda desocupado para hacer otra cosa.

Acá leyendo el papelito respondes las 5 preguntas, de modo que el cata walk es inútil.

Aplicandolo en la casa como dice Felipe:

1 me gusta