Limitar el Trabajo en Progreso

Por Víctor Reyna Vargas
June 20, 2022

Limitar WIP (trabajo en progreso) es un rasgo característico de Kanban: es de suma importancia de por qué el método funciona tan bien. Cuando lo piensas por primera vez, puede parecer contrario a la intuición. ¿Le estamos diciendo a la gente que trabajo menos? No, limitar el WIP no significa limitar el trabajo en sí, sino limitar la cantidad de tareas que se pueden iniciar a la vez.

¿Qué es “trabajo en progreso”?

Kanban provino del mundo de la fabricación. Por lo general, las empresas de fabricación mantienen un inventario de producción: una lista de niveles de materiales y suministros en stock para usar en el proceso. Normalmente hay tres tipos de inventario:

  • Materias primas: materiales de construcción, a los que aún no se les ha aplicado ningún trabajo.
  • Trabajo en progreso: materiales a los que se les ha realizado algún trabajo, también denominados productos semiacabados.
  • Productos terminados: materiales y trabajo que han sido completados y están listos para ser vendidos.

¿Por qué limitar WIP se considera algo bueno, y debería serlo?

La razón predominante por la que los límites WIP tiene una buena influencia en un flujo de trabajo es que acelera la finalización de la tarea: reduce tanto el plazo de entrega como los tiempos de ciclo, debido a varios factores. Pero una de las razones elementales tenía que ver con fines contables, como verás en el ejemplo a continuación.

Ejemplo

Consideremos los límites WIP en una pequeña casa de desarrollo de software: un equipo de 4 toma los requisitos del cliente/historias de usuario, conceptualiza y verifica el diseño, escribe el código, lo prueba y lo implementa para que lo use el cliente. Normalmente publican alrededor de 20 historias cada mes. Pero además de las 20 funciones implementadas, también quedan alrededor de 10 elementos parcialmente completados, en varios estados de progreso.

Si bien estos artículos sin terminar no se pueden entregar, los contadores de la empresa no pueden simplemente cancelarlos y no reconocerlos en absoluto, ya que esto no sería una representación precisa del trabajo realizado durante el mes. De ahí que los contadores acepten las partidas inconclusas como una forma de activo, y los bancos de la empresa que valoren como algo positivo. Podemos ver cómo ese puede tener sentido.

Los dueños de negocios a veces sienten que cuanto más WIP tengan, mejor. Confían en que es solo cuestión de tiempo antes de que los vendan, por lo que el trabajo inacabado se reconoce correctamente como un activo. Pero el problema es: ¿Qué sucede cuando el tiempo de trabajo en progreso se prolonga más y más? ¿Qué pasa si hay problemas con la operación de características específicas o la integración con el producto, y estos artículos WIP nunca se lanzan? ¿Sigue teniendo sentido verlos como activos? ¿Están aportando valor a la casa de software?

Probablemente hayas escuchado a la gente decir que “el efectivo es el rey”; esto tiendo a ser cierto. Las empresas a menudo se hundirán debido a un flujo de caja deficiente. No siempre es importante cuántos activos tiene una empresa si no puede convertirlos o generar el efectivo cuando sea necesario. Se arruinará y todos los activos se perderán o se venderán por mucho menos de lo que valen. Este es el problema con el trabajo en progreso. Una cosa es que una empresa reconozca el WIP como un activo, pero el hecho es que esos objetos no se pueden vender. Nadie quiere comprar una pieza de código que funciona a medias, y si alguien lo hace, entonces probablemente esté buscando comprarlo por mucho menos que el precio del producto terminado.

Eli Goldratt, un exitoso hombre de negocios y gurú de la administración, argumentó que el trabajo en progreso no debe considerarse como un activo, sino como un gasto. Argumentó que nadie entra en el negocio con la esperanza de “mantenerse ocupado”, las empresas necesitan obtener ganancias. La única forma de obtener ganancias es vendiendo su producto, y su costo de producción debe ser menos que sus ventas totales. Goldratt creó un concepto conocido como Contabilidad de Rendimiento (Throughput Accounting).

El concepto destaca del throughput (la velocidad con la que se puede construir y entregar un artículo), los inventarios y los gastos operativos como tres medidas principales de la restricción de la productividad. Formalizó su pensamiento en un libro “La Meta” y más tarde en un sistema conocido como la Teoría de Restricciones. Las empresas que implementaron este sistema experimentaron mejoras dramáticas en sus resultados.

¿Por qué debemos limitar el trabajo en progreso?

1. Fomentar una cultura de terminar el trabajo, reducir el tiempo de comercialización y minimizar el riesgo

Tu beneficio radica en los productos terminados, no en WIP. Y si tienes un negocio con poco efectivo, ¿quieres tener 30 artículos a la mitad de la venta, o más bien 10 artículos listos para usar? Siempre es mejor concentrarse en realizar completamente 10 elementos y liberarlos. Eso es lo que ayuda a lograr la limitación del trabajo en progreso. Si una empresa solo puede vender 10 artículos por mes, no tiene sentido trabajar en 30. Una limitación del WIP aquí sería centrarse en terminar esos 10 artículos. Por lo tanto, si limita el WIP, puedes concentrarte fácilmente en completar el trabajo iniciado y, cuando antes puedas terminar el trabajo, antes podrás entregarlo al cliente y monetizarlo.

Con respecto a los límites WIP que tienen un impacto en la reducción de riesgos del proyecto, imagina que, si varios elementos están en progreso al mismo tiempo, será imposible probar su compatibilidad con el producto de trabajo, así como entre sí. Por lo tanto, existe un alto riesgo de que el equipo tenga que volver a trabajar con todos los componentes nuevos, en lugar de solo aprobar e integrar el recién terminado con el producto terminado.

Además, el WIP limitado también facilita mejor cualquier trabajo acelerado y potencialmente puede hacer que sea menos común. Cuando surge un problema, un equipo que trabaja en 3 funciones las pausará y abordará el problema. Así que solo 3 tareas se retrasarán un poco. Si hubieran tenido 20 elementos en curso, los 20 se habría detenido y retrasado. Y cuantos más elementos retrasados tenga una canalización, más probable es que la parte interesada acelere más trabajo, para terminar al menos un elemento rápidamente, en lugar de seguir esperando. Por lo tanto, es preferible concentrarse en mantener tiempos de ciclo cortos, entregar con frecuencia y rapidez, y agilizar menos tareas. Tal enfoque, verdaderamente ágil, harás que tu flujo de trabajo sea sostenible y receptivo a los cambios.

2. Para minimizar la multitarea, el caos, la ociosidad y las reuniones

Limitar el trabajo en progreso silencia el ruido y ayuda a gestionar el caos. Si te lanzara una pelota, la atraparías fácilmente. Entonces, si te tiro otro tiro, también lo atraparías. Si te tiro dos pelotas al mismo tiempo, bueno, posiblemente las atraparías a los dos, o las dejarías caer. Pero, ¿y si te tiro 10 pelotas al mismo tiempo? Es probable que los dejes caer a todas: caos. Por la misma razón, la multitarea en uno o dos elementos y hacerlo rápidamente o trabajar en 10 elementos y no tener nada que mostrar, o en otras palabras: atrapar 2 pelotas o dejar caer 10.

Al limitar el trabajo en progreso, harás que la multitarea sea más difícil de lograr, tanto a nivel individuales como a nivel de enfoque de equipo combinado. Y debería ser bastante fácil entender por qué mantener un enfoque uniforme en una tarea en lugar de cambiar entre 4 tareas general. La configuración de un tablero Kanban con límites WIP también tiende a reducir la inactividad de los empleados, siempre que haya suficientes elementos en el backlog para todos los miembros del equipo disponibles.

Otro aspecto de la limitación WIP es la posibilidad de abordar la cantidad de proyectos diferentes en los que está trabajando toda la empresa, aunque controlando cuántos proyectos puede tener cada equipo a la vez. A través de estas restricciones de varios niveles, puedes asegurarte de que los gerentes sepan cuánto trabajo se puede asumir y, si se agrega más trabajo, qué otros proyectos pueden sufrir un costo. Vinculado a la cantidad limitada de proyectos en cualquier momento, está el hecho de que cuantos menos pasteles tenga cada trabajador, menos reuniones deben asistir, ¡otra reducción de desperdicio para ti! Agrega a esto el hecho de que la naturaleza visual de los tableros Kanban disminuye la importancia de las reuniones de estado, ya que todo lo que necesitas saber sobre un proyecto ya están en el tablero, y es posible que pueda salirse con la suya con tan pocas reuniones mensuales como una o dos.

3. Para maximizar el rendimiento, ejerce un verdadero proceso de extracción y reduce el tamaño de los lotes

Gracias a que comienza a trabajar solo en lo que se puede terminar, estás asegurando que el proceso se ejecute con el mayor rendimiento de material posible. Eso significa menos desperdicio y más ventas. Además, al obligar al equipo a no comenzar a trabajar mientras los elementos anteriores aún están en progreso, estarías implementando un verdadero modelo de proceso de extracción: no empujar el trabajo al proceso, independientemente de si se puede manejar o no, pero dejando que el equipo saque trabajo nuevo cuando esté listo para ello.

Maximizar el rendimiento acortará visiblemente el tiempo del ciclo: el tiempo que tarda un elemento en pasar de “Iniciado” a “Terminado”, lo que, una vez más, te ayudará a entregar nuevos lanzamientos con regularidad.

Limitar el trabajo en progreso puede ser de gran ayuda para reducir el tamaño del lote/sprint del producto porque cuando los equipos se deciden a trabajar en no más de, digamos, 1 tarea por persona a la vez, esto lleva a que el gerente del proyecto no planee más de un número determinado de tareas por cada sprint o lote. Por supuesto, no siempre tiene que funcionar de esa manera, y los límites WIP por sí solos no garantizarán tamaños de lotes más pequeños, pero ayudan a mantenerlos bajos.

Límites WIP e identificación de cuellos de botella

Aunque limitar WIP es bueno, si aplicamos límites WIP en todo el proceso, pueden surgir otros problemas. Aplicar un límite en el lugar equivocado puede generar desperdicios por todas partes. Si un gerente limita el trabajo en curso de manera incorrecta, podría llevar a la empresa a producir menos artículos de los que es capaz de producir. Esto también sería un desperdicio y no algo que Taichi Ono aprobaría. Entonces, ¿cómo identificamos en qué parte del proceso se debe limitar el trabajo en curso?

Decidir el límite WIP correcto, a través de encontrar el verdadero cuello de botella

Ejemplo

Hay cuatro personas en un equipo de desarrollo de software:

  • John finaliza las historias de usuario de los clientes y las conceptualiza en funciones.
  • Anton y Alice escriben el código.
  • Peter prueba el código y lo firma completo.

John selecciona y entrega 10 historias de usuario cada semana. Anton y Alice normalmente pueden codificar 8 historias a la semana, y Peter puede probar alrededor de 6 elementos a la semana. Esto muestra que el equipo puede lanzar 6 funciones por semana, ese es su rendimiento.

Pero si se le dijera al equipo que trabajara a su máxima capacidad, ¿cuál sería la situación al final de la semana? Supongamos que cada miembro del equipo tiene suficiente trabajo para comenzar a trabajar desde el principio. Veamos cómo podría funcionar esto:

Recuerda, que WIP es un artículo de inventario. Notamos grandes pilas de tarjetas de historias de usuario en la etapa Historias de usuario verificadas y en Codificación. Pero, ¿por qué los artículos se acumulan allí? Porque el probador es el cuello de botella, la restricción del proceso, capaz de completar solo 6 versiones verificadas por semana.

Los que un gerente Ágil debería hacer aquí es limitar el equipo de codificación para producir no más de 6 elementos por semana, ya que cualquier cosa más será un desperdicio, el probador no podría manejar el ritmo. Potencialmente, lo que podría suceder es que John, Anton y Alice participen y ayuden a Peter con las pruebas, una vez que hayan terminado con sus tareas. Esto debería mejorar el rendimiento del sistema. De repente, la empresa puede estar lanzando más de 6 artículos a la semana, y el compromiso de los empleados está mejorando junto con el rendimiento.

¿Cómo aplicar un límite WIP?

En resumen, para aplicar un límite WIP adecuado a tu proceso, debes analizarlo y encontrar el engranaje más lento de la máquina.

Paso 1: Mira tu proceso e identifica los cuellos de botella

Para empezar, simplemente camina por tu oficina o planta de producción. Busca miembros del equipo que estén sobrecargados y tengan mucho inventario en sus escritorios o tableros visuales. ¡Así es como encontrarás tu cuello de botella!

Paso 2: Haz coincidir el límite WIP con la capacidad de proceso más lento

¡Ve a hablar con el equipo que trabaja en el paso del cuello de botella y ve cómo puedes limitar el trabajo a ellos, ayudara a que toda tu empresa trabaje más rápido y tus empleados te amarán por ello!

Paso 3: Analiza el flujo con los límites WIP aplicados periódicamente

A medida que tu proceso cambia, el equipo crece, se reduce o cambia: es posible que sea necesario ajustar el límite WIP aplicado. Vigílalo para mantener tus niveles óptimos de rendimiento.

Resumiendo

Limitar el trabajo en curso es un concepto tan simple como eficiente. Considera probarlo con tu equipo, o simplemente para un flujo de trabajo personal, y lo verás de primera mano. En resumen, al restringir la cantidad de cosas en las que estás trabajando en cualquier momento, verás potencialmente los siguientes beneficios:

  • Finalización de tareas más rápida: tiempos de entrega y de ciclo reducidos, rendimiento maximizado.
  • Tasas de entrega de productos más rápidas y sostenibles.
  • Reducción del riesgo del proyecto e identificación más rápida de cuellos de botella.
  • Menos multitarea, menos ociosidad de los empleados.
  • Tamaños de lote más pequeños, menos reuniones y mejor control sobre todos los proyectos de la organización.

Este artículo se basó en el Blog de kanban tool en su artículo “Limiting Work in Progress”.

Por favor déjanos tus opiniones y preguntas acerca de esta publicación en los comentarios al final de la página.

Acerca del autor 

Víctor Reyna Vargas

Ingeniero de Sistemas por la Universidad Nacional de Ingeniería de Lima (Perú).
Apasionado por la Innovación y la Transformación Ágil, el Gobierno de la Información y la Tecnología y el Gobierno Digital.
Es asesor, consultor, mentor y capacitador en los temas de su especialidad.
Actualmente se desempeña como especialista en Innovación y Transformación Ágil del Negocio.
Es titular gerente de DOBLERRE & ASOCIADOS.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Suscríbete y recibe nuestros Últimos Artículos

Obtén las últimas novedades de nuestros artículos directamente en tu email.

>