Cuando hablamos de Kanban, uno de los conceptos más complicados de explicar es ¨”limitar el trabajo en progreso”. Limitar el trabajo en progreso consiste en decir que no, en parar de hacer cosas nuevas hasta que hayamos acabado las actuales, en poner foco en acabar lo que estamos haciendo… El trabajo en progreso está muy relacionado con el tiempo que tardamos en hacer las cosas, cuantas más cosas hacemos a la vez, más tardamos en terminar cada una de ellas.
Vamos a analizar cómo, en los equipos software, nos enfocamos en que el equipo saque más trabajo, en vez de regular la “entrada de trabajo”. Estos días con la Crisis del Coronavirus hemos visto cómo se enfocan los diferentes países… ¡Lo analizamos!
Ley de Little
Antes de nada, vamos a explicar la famosa Ley de Little, que se utiliza en Kanban para explicar varias conceptos. La Ley de Little dice lo siguiente:
“En un sistema de flujo que no está en tendencia (y en el que todos los elementos que se seleccionan se entregan), hay una relación simple entre los promedios de las siguientes métricas durante un período específico”
Donde, la tasa de entrega es la cantidad de unidades de trabajo terminadas por periodo de tiempo, el WIP es la cantidad de tareas que hacemos a la vez y el cycle time es el tiempo que transcurre desde que nos solicitan un trabajo hasta que lo terminamos (tiempo que pasa nuestra tarea en nuestro sistema).
Nuestra tasa de entrega y nuestro lead time no podemos modificarlos. Podemos tratar de mejorar nuestros tiempos, pero llega un momento en el que las tareas tardan lo que tardan, nueve mujeres no hacen un niño en un mes. De la Ley de Little deducimos que, si queremos reducir el tiempo que las tareas pasan en nuestro sistema, debemos reducir la cantidad de elementos que hacemos. Que las tareas estén poco tiempo en nuestro sistema es muy beneficioso: recibimos feedback antes, reducimos coste por unidad de trabajo, y evitamos cambios de foco entre muchas tareas. De esta manera, somos capaces de dar un mejor servicio y, por tanto, tener un mejor impacto en nuestros clientes.
Cómo aplicar Kanban a la crisis del Coronavirus
Podemos hacer una analogía entre el sistema hospitalario para poder analizarlo. Las personas que enferman son las que entran en nuestro sistema para ser curadas, pasan un tiempo en los hospitales para superar el virus y, después, salen del sistema.
Hay varias ideas que tenemos claras. El tiempo de recuperación medio es el que es, de hecho lo estamos descubriendo ahora. Podemos ampliar el WIP, porque no queremos decirle que no a ningún paciente, por tanto, creamos hospitales como el de IFEMA o utilizamos otras plantas del hospital. El problema de ampliar el WIP, es que, es la solución más cara, debes contratar personas y no siempre das el mejor servicio. De hecho, ese es el gran miedo, que no podamos atender a las personas y haya que seleccionar. ¿Qué opción nos queda entonces?
La única manera de poder hacer fluir nuestro sistema y que resista es reducir la entrada de enfermos. ¿Cómo? Pues con medidas como el confinamiento, reducción de movimientos etc. Todas estas medidas buscan reducir la entrada para que no tengamos que superar el WIP y hacer fluir por nuestro sistemas a los pacientes.
¿Cómo aplicamos esto a equipos Software?
En el mundo software, es donde nació el método Kanban (a partir de los sistemas kanban de Toyota). En general, en el mundo software, vivimos una situación similar a la del coronavirus. Tenemos una demanda de tareas proveniente de nuestros clientes o de otra área, un equipo de trabajo que se encarga de resolverlas. El tiempo de resolución medio es el que es, y, realmente, no podemos presionar para tardar menos. Podemos introducir personas, pero eso es costoso y hará que tardemos tiempo en estabilizar el sistema, lo que nos impide conocer nuestros números reales para ser predecibles.
El problema en el sector software es que muchos managers que gestionan equipos se centran en la eficiencia del mismo. Tratan de presionar a los equipos para que saquen el trabajo en menos tiempo, en vez de centrarse en la demanda. El equipo siempre tardará lo que tarde y, si por correr, cometen más errores, esto generará retrabajo lo que impacta negativamente. Si a un paciente que no ha terminado de curarse lo mandamos a casa, contagia a su familia y genera nuevos ingresos hospitalarios (retrabajo).
Si queremos que nuestro sistema funcione mejor, la única alternativa es focalizarnosen la demanda, organizar todas las peticiones para entregar el máximo valor. Es mejor aplazar una entrega a un cliente que retrasar la de todos los clientes.
Es el mismo concepto que podemos estudiar en un taller. Llevamos el coche porque se ha roto, y el mecánico nos dice: “en tres días, me pongo”. Nosotros no podemos esperar tanto, y replicamos: “¿pero no puedes ponerte antes?” y nos responde “tengo otros coches”. A nosotros los demás coche nos dan igual, solo queremos el nuestro. Queremos que lo arreglen hoy, ¡qué digo hoy!, queremos que lo arreglen ya. Sin embargo, hay una cosa que nos cabrea mucho más que el hecho de que tarden y es que nos arreglen el coche y se rompa al salir del taller. Eso nos mosquea muchísimo. Podemos amenazar al mecánico con llevar el coche a otro taller, pero eso no suele funcionar, el mecánico quiere dar un buen servicio y no puede colarte porque se expone a fallar a otros clientes. Por eso, controlar nuestra demanda nos puede ayudar a dar un mejor servicio que nos permita ser efectivos.
Los buenos gestores de equipos saben cuándo tienen que decir que “no”. Si siempre decimos que sí, acabaremos dando un servicio muy malo y, a la larga, perderemos clientes.
Y tú, ¿regulas la demanda de tus equipos o dices a todo que sí?
