Los indicadores para medir el flujo son el Lead Time, el tiempo (promedio) que un ítem tarda en ser procesado y recorrer el tablero kanban desde que fué introducido en él hasta llegar a DONE en su extremo derecho, y el Cycle Time, que es similar, pero contando como comienzo el momento en el cual el ítem se comienza a procesar (este punto correspondería a una columna específica del tablero kanban que depende del contexto de trabajo), y el Throughput, el número de ítems terminados por unidad de tiempo. Lo deseable es mantener los valores de Lead Time y Cycle Time en su nivel mínimo, y aumentar todo lo posible el Throughtput. La monitorización del flujo se visualiza en un Cumulative Flow Diagram (CFD), una gráfica de áreas acumuladas que se construye con los contadores de ítems en cada actividad, día a día, ilustrando por áreas de colores la evolución de la cantidad de ítems en cada actividad. A continuación se muestra una gráfica CFD indicando los conceptos básicos para su interpretación.
El siguiente ejemplo muestra un período de 24 días y las contabilizaciones de ítems en cada una de las actividades del tablero kanban (indicadas según la leyenda del recuadro).
Hasta aquí todo parece bastante claro e intuitivo. La mayoría de las herramientas que ofrecen soporte para un tablero kanban tienen funcionalidad asociada a limitar el WIP de las columnas. Dicho límite se puede definir para una columna y posteriormente se utiliza como una restricción para advertir cuando se podría superar o directamente para impedir que se supere.
A continuación mencionaré los "detalles" con los cuales nos hemos enfrentado intentando dar cabida a las ideas anteriores en el marco de nuestra metodología y herramienta TUNE-UP Process.
- Considero que es más importante supervisar el WIP que tiene cada actividad del proceso en cada momento que el encontrar un límite para el WIP de las actividades. Llevamos años trabajando con tableros kanban en nuestra herramienta (y aplicándola a proyectos de diverso tamaño y ámbito), el cual tiene una vista resumida en la cual se muestran los WIP del momento en cada actividad, es decir, contadores de ítems en TO DO o DOING en cada actividad. Cualquier seguimiento del trabajo en curso comienza examinando dicho kanban resumido y de allí acceder al detalle de los ítems. Sin embargo, el determinar un límite para dicho WIP en muy pocas ocasiones nos ha surgido como una necesidad. Cuando se detecta cierta acumulación de trabajo en una actividad es obvio que no tiene sentido que la o las actividades previas mantengan su ritmo de trabajo pues no harán más que aumentar dicha acumulación. Esta es la idea clave aportada por la Teoría de Restricciones de Goldratt, centrarse en mejorar la actividad que constituye la mayor limitación del sistema pues es ella la que impone el ritmo a todo el sistema. Entre las posibles acciones de mejora estaría el concentrar (momentáneamente) recursos en la actividad que presenta el cuello de bottella, probablemente cogiéndolos desde las actividades que no presentan acumulación (las cuales podrían incluso detenerse). Sólo en el caso que una actividad presente repetidamente está anomalía podría ser recomendable indagar más en su causa y aplicar otras medidas (como se comenta en el siguiente punto). Por otra parte, sobrepasar el límite de WIP no es el único factor a considerar, a veces actividades que tienen un WIP bajo pero son del inicio del workflow, deben hacerse prioritarias cuando sus ítem no son atendidos y van sufriendo cierta postergación (lo cual perjudicaría su Lead Time y Cycle Time). La siguiente imagen muestra el kanban de TUNE-UP Process, a la izquierda la vista resumida con los contadores de WIP en cada actividad y en cada sub-estado (TO DO, DOING o DONE), a la derecha la lista de ítems en la celda seleccionada (en este caso los ítems de la actividad Diseño e Implementación en el estado TO DO). Nuestro kanban puede sintetizar el trabajo de todos los participantes, de todos los productos/servicios y de todas los Sprints. En el ejemplo de la figura, se muestra un kanban filtrado para mostrar solo la información del producto TUNE-UP en su versión 1.3.6 y para todos los agentes participantes.
- El propósito que hay detrás de la idea de limitar el WIP conlleva una actitud y atención hacia la mejora del flujo, es decir, remover los impedimentos o actitudes que no favorezcan dichos indicadores de flujo. Importantes mejoras pueden detectarse observando la forma cómo se llevan a cabo las actividades para, por ejemplo: eliminar los desperdicios (waste), es decir, quitar de todo aquello que no sea imprescindible, o mejorar la productividad automatizando ciertas tareas, etc. Otra fuente para la degradación del rendimiento en una actividad se produce cuando quien la debe realizar interrumpe su trabajo por atender otras tareas. Por otro lado, existe la "actitud pulpo", es decir, cuando un miembro del equipo que tiende a coger nuevos ítems de trabajo sin terminar los que ya tiene asignados. Esta actitud llevada a un extremo obviamente puede reducir el desempeño de dicha persona pues los cambios de un ítem a otro generan pérdidas de tiempo por cambio de contexto, es decir, estos cambios deberían ser los mínimos, ojalá sólo para pasar desde termino a comienzo de actividades, evitando interrupciones que mantengan actividades sin completar. Pero no todas las interrupciones son malas, aquellas propuestas por la Técnica Pomodoro repercuten positivamente en el desempeño. Lo importante es, que en lo posible, los miembros del equipo puedan dedicarse a una actividad hasta finalizarla (recomiendo leer "La magia de hacer una sola cosa a la vez").
- La cantidad de ítems en una actividad no es determinante respecto a que siempre constituya una anomalía. Si tenemos, por ejemplo, solo un miembro del equipo que realiza una cierta actividad y en ella tenemos en cierto momento muchos ítems, probablemente se trate de una situación anómala. Pero si, por ejemplo en el extremo opuesto, si una actividad puede realizarla cualquier miembro del equipo, el tener muchos ítems en ella puede que no represente un problema cuando se trata de trabajo en paralelo de muchos miembros. En el caso de equipos cuyos miembros NO tienen roles específicos y fijos será difícil establecer un límite preciso al WIP de una actividad. Por otra parte, no hay que olvidar que el tablero kanban se originó en un contexto de producción de bienes físicos, en el cual las cuando un ítem está en una actividad el esfuerzo asociado es bastante predecible y similar para todos los ítems del mismo tipo. Además, la demanda de ítems puede ser en muchos casos prevista de antemano. En contextos como el de desarrollo de software o el de atención de incidencias no se dan dichas características. Aún si clasificáramos los ítems en términos de correcciones de fallos, mejoras o nuevos requisitos, en cualquiera de dichas categorías podríamos tener mucha variabilidad en cuanto a esfuerzo requerido y también suele ser difícil anticipar la demanda.
- Según el punto anterior, para determinar algún límite parece más preciso considerar la capacidad del equipo en una actividad y el esfuerzo asociado a los ítems que llegan a la actividad, y no solo basarse en la mera contabilización de ellos, sin considerar sus particularidades. Sin embargo, en el método Kanban la estimación para los ítems es opcional. Además, el cálculo de la capacidad siempre está asociado a un rango temporal, por ejemplo "horas ideales de programación por semana", pero el método Kanban no prescribe el uso de Sprints, pues lo importante es el flujo continuo, aunque paradógicamente, para analizar el flujo se necesita estudiar su comportamiento entre fechas y también las tendencias de dicho comportamiento a lo largo del tiempo.
- Finalmente, si en el proceso puede existir re-trabajo, es decir, que actividades aparentemente terminadas para un ítem tengan que volver a realizarse de forma total o parcial. El ejemplo más frecuente es cuando en pruebas se detecta un fallo en el ítem, que debe ser resuelto en programación (que previamente se había dado por finalizada para el ítem). Así, cuando al ítem se le tenga que aplicar de nuevo una actividad por la cual ya ha pasado ¿se le aplicaría también la restricción de no superar el límite de WIP en dicha actividad? Precisamente lo deseable en un caso de re-trabajo es que en dicha actividad sea prioritario el completar los ítems que han sido devueltos. El ítem podría NO devolverse a la columna previa, pero esto restaría legibilidad al tablero aunque se añadan decoraciones al ítem. Lo más claro sería que el ítem esté en la actividad en la cual se está trabajando en él. Pero un ítem puede estar en más de una actividad a la vez ya sea porque se hace re-trabajo mientras se mantiene en una actividad posterior o porque está en una actividad previa y se comienza a adelantar trabajo asociado a una actividad posterior.
Limitar el WIP es una idea interesante pero su implantación tiene matices y alternativas para sacarle provecho, eso sí, prescindiendo de una interpretación radical o purista de dicho concepto :-).
En TUNE-UP Process se ofrece funcionalidad para limitar el WIP de una actividad, tanto en su cola de entrada (la columna TO DO que tiene por defecto cada actividad) como en la actividad en sí misma (la columna DOING de la actividad). Además, respecto del efecto cuando se establece dicho límite, se puede configurar para cada actividad y columna (TO DO o DOING) que se impida superar el límite o que solo se advierta. Por otra parte, para analizar el flujo y detectar posibles anomalías tales como cuellos de botella, TUNE-UP ofrece Diagramas de Flujo Acumulado con diversos filtros. Estas gráficas se generan automáticamente mediante la generación de snapshots diarias del tablero kanban.
En TUNE-UP Process se ofrece funcionalidad para limitar el WIP de una actividad, tanto en su cola de entrada (la columna TO DO que tiene por defecto cada actividad) como en la actividad en sí misma (la columna DOING de la actividad). Además, respecto del efecto cuando se establece dicho límite, se puede configurar para cada actividad y columna (TO DO o DOING) que se impida superar el límite o que solo se advierta. Por otra parte, para analizar el flujo y detectar posibles anomalías tales como cuellos de botella, TUNE-UP ofrece Diagramas de Flujo Acumulado con diversos filtros. Estas gráficas se generan automáticamente mediante la generación de snapshots diarias del tablero kanban.
Patricio Letelier
No hay comentarios:
Publicar un comentario