Kanban, cómo resolver sus inconvenientes.

14:23:00 Anónimo 1 Comments

Tras el uso de forma simple de la metodología de gestión de tareas Kanban, descubrimos otro concepto muy utilizado en entornos de gestión evolucionario basado en Lean, es Kaizen, que significa "mejora continua", pues bien, nosotros tuvimos Kaizen a ostias. 
Esta es nuestra experiencia de como resolvimos los incidentes, tras más de un año de ir adaptando el modelo a nuestras necesidades.





Problema #1 Gestión Repriorizaciones
El planteamiento Simple del tablero de Kanban comentado en el anterior post, pronto mostro serias limitaciones, como por ejemplo, como actuar sobre una repriorización (una tarea de última hora con caracter urgente). Al equipo de trabajo, le generaban tareas de diferentes orígenes o personas, dep. marketing, dep. ventas, dep. administración,... si sucedia (y sucede, vaya si sucede) una repriorización esta NUNCA podia afectar al trabajo en curso, solo a la columna Pendiente, pero si teníamos tareas comprometidas (aún no comenzadas, pero apalabradas y con fecha entrega estimada era una fuente de continuas discusiones y desencuentros.

Solución
La solución que adoptamos fue dividir la columna Pendiente, en dos subcolumnas. Pila (petición) y Seleccionado. Cuando llegaba una petición nueva, simplemente la anotábamos en una nota (junto con la fecha y la persona que originaba la petición) no entrábamos en el detalle. Era un recordatorio, tenemos que hacer esta tarea. 
La columna Petición no tenia limite WIP, la columna Seleccionado tenia un WIP por cada componente del equipo. Al hacer Pull y añadir una nota a la columna seleccionado, nos reuniamos con la persona propietaria de la petición y tratabamos todos los detalles y resolviamos nuestras dudas sobre cómo hibamos a realizar la tarea. Se entendia que empezariamos a trabajar esta peticion de manera inminente, normalmente se hace cuando el limite de WIP de la siguiente columna te lo permite. La tarea esta comprometida.
Ahora viene lo mejor. Si una persona queria que una tarea fuera más prioritaria (que pase inmediatamente a la columna seleccionado) hacia que otra tarea de esa columna retrocediera a la columna Pendiente de nuevo, entonces lo que hacíamos es notificar de esta situación  a los propietarios de las tareas afectadas, y entre ellos resolvían la situación y nos confirmaban o no la repriorización. Otras veces solo notificábamos de la repriorización y apuntábamos las causas (cuestión de cadena de mando, que le dicen ;). De una manera o de otra, el peso de la repriorización (ocasionada desde un punto de vista de valor de negocio) no caia sobre el equipo, y siempre que una repriorización afectava a una tarea comprometida las personas interesadas eran avisadas puntualmente y entre ellos se resolvían los posibles conflictos existentes.

Problema #2 Gestión Entregas
Ademas, no gestionábamos correctamente las entregas, en el modelo inicial no había un espacio especifico para realizar el aviso, formación o acciones derivadas de la finalización de una tarea. Y no siempre se avisaba puntualmente a la persona responsable de la petición, de que su tarea ya estaba acabada y funcionando.

Solución
Lo primero que hicimos fue dividir la columna Terminado en dos subcolumna. En entrega y Funcionando. La subcolumna En entrega, siguio con el limite WIP que tenia la columna Terminado y la subcolumna Funcionando, no tenia ningún limite WIP
De esta manera nos obligamos a realizar una operación más en el ciclo de vida de una tarea, que era la gestión de entrega. Esta operación podría ser sencilla, como un email al propietario de la tarea (con un asunto siempre con el mismo prefijo (nomenclatura), por ejemplo EntregaCRM: descripcion_de_la_tarea) o más complejo como realizar una sesión formativa para las personas que vayan a utilizar la nueva funcionalidad, esto requeria crear una presentación, preparar la sesión, etc. Pero de esta manera siempre realizábamos las entregas de manera correcta.
Esta reorganización, implico que muchas tareas acabadas, estuvieran en espera de la acción pull porque la columna En entrega estaba al limite del WIP, pero que no se trataba de embudos, sino de ciertas tareas de preparación de entrega requerían mucho tiempo. Nos encontrábamos que parte del equipo estaba libre para comenzar tareas, pero no podia por el limite de la columna Desarrollo. Al principio subimos el limite WIP, pero causo problemas de demasiadas tareas comenzadas y si que se creaba un embudo en la entrega. Finalmente decidimos dividir la columna Desarrollo en dos subcolumnas. En curso y terminado, las dos con un limite WIP de 1,5 puntos por miembro del equipo. Y esto funciono a las mil maravillas.

Problema #3 Gestión Historica
Periodicamente "limpiabamos" la sub columna Funcionando, asi que desde el principio padeciamos "ceguera historica" sobre lo que habiamos hecho a largo plazo. Podíamos analizar los mails enviados en la fase Entrega, pero era una forma muy manual y poco practica de tener un historico sobre tareas realizadas.

Solución
Lo que hicimos fue comenzar a guardar en una hoja de datos de google docs, todas las tareas que se habian terminado. Esto lo haciamos cada quince días y siguiendo varios formatos. El definitivo que seguimos usando es:
{label}{Inicio:date}{Fin}{description:single}{UNE}{TipoEvento}{Team}{url_Backlog}{ProductBacklog}

Esto ademas de servir como historico de tareas realizadas, nos permitia generar cualquier tipo de informe o infografia


O un timeline con el widget SMILE y archivo de tareas dinámico de forma visual y que todos los interesados pueden acceder y configurar a su gusto. Pero esto ya es otro post ;)


You Might Also Like

1 comentario:

  1. Hola!, podrías resubir las imágenes? Por otro lado, una tarea como ser correcciones de defectos, la agregan a la columna del backlog en puesto 1? Gracias!

    ResponderEliminar