El bloc de notas de un Agilista Jedi

Regresar Kanban

No todo el trabajo es siempre una urgencia

12 de septiembre de 2023

No todo el trabajo es siempre una urgencia

Debemos optimizar la capacidad: Kanban propone un enfoque para evaluar las prioridades de los elementos de trabajo. Esto se llama Clases de Servicio (CoS en inglés, Class of Service).

Imagen de: interhelpambulancia.com

.

Tenemos capacidad finita, se necesitan Clases de Servicio

Clases de Servicio (CoS), es una manera de clasificar el trabajo para proporcionar niveles de atención aceptables (y consecuentemente de satisfacción al cliente) a un costo económico óptimo, es decir, como no podemos atender todo porque la capacidad es finita, se define qué trabajo se va a atender primero en base a su impacto y prioridad o urgencia. Se basa en que podemos estar trabajando en una tarea y, si surge una que tiene mayor impacto o urgencia, necesitamos dejar de lado la tarea no urgente, para atender la de urgencia máxima, pero esto de manera ordenada: con transparencia y basados en políticas claras para todos.

Un punto importante es que estas clases de servicio deben de definirse en base a su impacto de negocio, y cada clase representa un determinado compromiso con el cliente.

David J. Anderson, creador del Método Kanban, propone 4 clases de servicio, pero aclara que son solo una guía y puedes definir las que consideres de acuerdo con el contexto de tu equipo.

Aquí te comparto las 4 clases de servicio que propone el Método Kanban:

.

Estándar (Standard)

Este es (o debería de ser) la mayoría del trabajo que un equipo realiza, tareas regulares. Deben atenderse en orden de llegada, primero en entrar primero en salir (FIFO, por sus siglas en inglés Fist Input First Ourput), o algún mecanismo acordado para ello. Este trabajo es importante y no es urgente.

.

Expedito (Expedite)

Tiene la máxima prioridad y debe de atenderse inmediatamente. Es una urgencia, y de manera normal solo debería de existir un elemento de esta clase a la vez (en progreso).
Por ser una emergencia, este tipo de clase debe moverse rápidamente a través del flujo de trabajo, y por lo tanto puede ser ingresado a un sistema Kanban (debe de ser atendido) incluso si se ha alcanzado el límite de WIP (es el único momento en que un límite de WIP puede violarse).

Ejemplos de elementos de trabajo expeditos:
• Defectos o bugs que surgen en producción (dependiendo de su impacto, claro está).
• Problemas que causen que una línea de producción se detenga.
• Elementos que impactan a un cliente o usuario final, y puede generar una experiencia negativa.
• Situaciones que detienen algún proceso de negocio.
• Cumplimientos regulatorios o normativos (aquí una nota, ya que depende de la fecha de este cumplimiento, como se menciona en el siguiente elemento de trabajo: Fecha Fija).
• Incidentes particulares, vulnerabilidades de seguridad, etc.

Es importante ver el contexto de cada equipo, por ejemplo: ¿Cuántas “urgencias” surgen que el equipo debe de atender? Si surge urgencia tras urgencia, si el equipo vive apagando incendio tras incendio, es importante levantar la pregunta de lo que es “verdaderamente-de-veras-de-veras-urgente”. Hay una cita que me hace mucho sentido para estos casos: “Cuando todo es urgente, entonces nada es urgente”, es decir, la naturaleza de una urgencia es que es algo atípica y especial, no todo el trabajo regular es una urgencia.

Me gusta esta analogía: Si pasa una ambulancia por la avenida en la que vamos manejando, entendemos que es una urgencia, y le cedemos el paso. Pero ¿Qué pasaría si todos los coches que van por la avenida trajeran una sirena de ambulancia?, ¿Podemos darles el paso a todos?
O una de dos: o ninguno es una urgencia real, o ha ocurrido algo verdaderamente atípico y catastrófico (por ejemplo, ha iniciado un apocalipsis zombi y por eso todos quieren huir).

Debemos de tomar en cuenta que el atender un elemento expedito realmente tiene un impacto, genera retraso en entregas de otras tareas (por ejemplo, puede llegar a suceder que un trabajo que se estaba realizando y se dejó de lado de hacer para atender una urgencia, se termine convirtiendo a su vez en una urgencia). Por lo tanto, no deben de tomarse a la ligera.

.

Fecha fija (Fixed Delivery Date)

Este debe ser entregado antes de una determinada fecha. Puede que no sea urgente al momento de realizarse, pero tiene un costo o impacto alto en caso de que no sea completado antes de la fecha determinada (por eso en la gráfica se ve que el impacto se incrementa, se vuelve una línea vertical, esto es cuando la fecha de compromiso ha llegado y no se ha realizado o completado esta tarea).

Algunos ejemplos de este tipo de elementos podrían ser:
• Cumplimientos regulatorios o normativos: Pago de impuestos, renovación de licencias, pago de nóminas y/o proveedores, entre otros.
• Fechas especiales de lanzamiento de productos: Un producto o cierta promoción que debe de salir al mercado en una fecha específica, como navidad, día de acción de gracias, día de Star Wars (sí existe, millones de fans alrededor de la galaxia lo celebramos el 4 de mayo. True story!), día del amor y de la amistad, entre otros.
• Hitos o milestones importantes de un proyecto.
• Etcétera.

Si el trabajo no se completa en la fecha y forma indicada, este elemento puede convertirse en uno de la mayor urgencia (expedito).

.

Intangible

Es trabajo que es importante realizarse pues aporta un beneficio o mejora para el equipo u organización, pero por lo general no tiene un costo de retraso o impacto visible o “tangible”. La realidad es que, aunque es importante, por lo general se pospone su realización porque en el día a día surgen elementos con mayor “urgencia”.

Ejemplos de esta clase de servicio pueden ser:
• Realizar automatizaciones para hacer más rápido y eficiente algún proceso manual.
• Refactorización / resolver Deuda técnica.
• Rediseño de algún proceso o forma de trabajo.
• Ciertos tipos de mantenimientos preventivos.
• Implementar mejoras de cualquier tipo (investigar, hacer experimentos, pruebas de concepto, etc.)

¿Te ha sucedido que existe alguna tarea que periódicamente requiere mucho de tu tiempo, sabes que es necesario darte un espacio para analizar y automatizar o mejorar la forma en que se realiza, precisamente para que te tome menos tiempo y sea realizado de manera más eficiente… pero sencillamente no tienes tiempo para hacerlo? (Si es así, no estás solo o sola, a millones nos pasa de repente en la vorágine del mundo actual ☹). Este es precisamente un elemento de trabajo Intangible.

.

Transparencia: No nos olvidemos de las Políticas

Ahora, como mencionaba anteriormente, estas clases de servicio son solo una guía que propone Kanban, el primer paso es siempre identificar las clases de servicio de acuerdo al equipo/organización y su contexto. Lo siguiente es definir políticas para cada clase de servicio (esto continúa fomentando esta transparencia que hemos venido mencionando, así como la autogestión para que los equipos puedan decidir cómo atender cada elemento de trabajo).

Y parar no hacer este artículo tan largo, aquí algunas ideas de políticas para clases de servicio, que puedes ajustar al contexto de tu equipo:

  1. Clase Expedito: Utilizará tarjetas rojas.
  2. Clase Intangible: Utilizará tarjetas verdes.
  3. Solo puede haber un elemento Expedito a la vez.
  4. Los elementos Estándar se atenderán conforme vayan llegando, primero en entrar – primero en salir (FIFO).
  5. Acuerdos de niveles de servicio para cada tipo de elemento de trabajo.
  6. Entre otras.

.

Conclusiones

Las clases de servicio ofrecen una manera transparente para optimizar la capacidad y, consecuentemente, la satisfacción del cliente. El impacto desde la perspectiva de negocio debe de ser siempre tomado en cuenta al momento de definir las clases de servicio en el contexto de tu equipo. Finalmente, recordemos que nada está escrito en piedra (o en adamantium), las clases de servicio y las políticas pueden evolucionar a lo largo del tiempo. En este sentido, el enfoque experimental es súper poderoso: Siempre inspeccionemos cómo nos está funcionando en el contexto de nuestros equipos, y adaptemos en consecuencia.

¿Qué opinas de las clases de servicio? ¿identificaste alguna o algunas que con las que ya trabajan en tu equipo, pero que les llaman de otra manera?

.
Referencia:
Kanban: Successful evolutionary change for your technology business.
David J. Anderson
.


autor

Leonel Zapien
Apasionado de la Agilidad: Consultor & Facilitador.

Conoce más sobre mí

Comparte este articulo

Seguir leyendo sobre Kanban