Etiqueta: cuello de botella

Esteban, el «cuello de botella» (un caso real)

Con este post intento ayudar a Esteban, una persona real y concreta. Pero también creo que las ideas podrían ser útiles para otras personas en situaciones parecidas.

Esteban se dedica al desarrollo de software. Proyectos para distintos clientes, todos con sus peculiaridades, temas críticos y urgentes para resolver. Nada sorprendente para una persona del mundo TI. Lo interesante está en la situación en la que se encuentra Esteban:

  • Lleva 5 proyectos y participa en otros 8 como Responsable Técnico del diseño de las soluciones
  • Todos los proyectos utilizan tecnologías nuevas en el dominio TI y también nuevas para las personas de sus equipos
  • Además de hacer sus propias tareas, Esteban da formación en las nuevas tecnologías a las personas involucradas en los proyectos, les ayuda resolver las dudas en su trabajo, arregla los errores que ellos no pueden corregir, habla con los clientes para aclarar funcionalidades (tanto implementadas como nuevas o modificadas), etc.
  • En términos más concretos esto significa que cada día atiende a unos 20-25 compañeros, comentando asuntos muy diferentes, cuando surjan, sin ningún orden o agenda, y dedicando unos 10-15 min a cada uno esto le come unos 5-6 horas de su jornada laboral, … entre las conversaciones intenta re-tomar su trabajo…. hasta la próxima interrupción. El resultado es el siguiente:
    • el trabajo sin cerrar de Esteban se va acumulando
    • la cola de los quienes esperan sus respuestas está aumentando
    • el descontento por parte de los clientes está creciendo porque sus problemas se resuelven lentamente
    • el Jefe de Esteban está descontento también porque Esteban se ha convertido en un “cuello de botella” y no “compagina” bien las diversas tareas.

¿Te suena una situación como esta?

¿Qué harías tú para resolverla?

Yo veo tres opciones e intentaré explicarlas y demostrarlas aquí. Mira esta botella.

Bottle

Contiene el trabajo que debe pasar por el cuello de la botella, es decir el que Esteban tiene que hacer.

  1. La primera opción es “No hacer nada”, o sea dejar los compañeros se arreglen entre ellos, con o sin la ayuda del Jefe y simplemente empujando fuertemente para que trabajo pase lo más rápido posible por el cuello de botella.En este caso se ha tardado unos 11:07 segundos en vaciar la botella (terminar el trabajo). Se ven las burbujas de aire que entran y que facilitan la salida del agua, pero también hacen que el flujo pare para que entre el aire y luego vuelva a fluir.
  2. La segunda opción es de poner un poco de orden, por ejemplo, definir un periodo de tiempo en el día en el que Esteban se dedique a la resolución de las dudas de sus compañeros, establecer algunas reglas sobre qué tipos de preguntas se van a dirigir a Esteban y cómo tratar los asuntos verdaderamente urgentes que no pueden esperar hasta la hora de preguntas.Visualicemos esta opción:El agua circula dentro de la botella y esto representa el orden que ayuda que el trabajo pase más rápidamente por el cuello de botella.El cronometro también muestra una mejora. El agua tarda 7:93 segundos en salir de la botella. Unos 28% de reducción del tiempo de entrega comparando con el caso anterior.
  3. La tercera opción es la siguiente (la demostramos primero)

¡La misma cantidad de trabajo pasa por el mismo cuello de botella en sólo 5:60 segundos! Otros 29% de reducción del tiempo, o un 49% más rápido comparando con el primer caso.

¿Cómo es posible?

El aire que entra por la pajita hace que el flujo del agua es más suave y uniforme, sin paradas y re-arranques (causadas por las burbujas de aire, como en la primera opción).

En el caso de Esteban ¿qué sería equivalente al aire que entra por la pajita?

Bueno, la respuesta de esta pregunta se puede encontrar únicamente con las personas directamente involucradas en la situación. Lo que yo puedo sugerir es lo siguiente:

  • Que visualicen el trabajo en curso en los proyectos para que todos los involucrados puedan hablar, priorizar y llegar a acuerdos sobre qué hay que hacer para que haya un flujo constante de resultados. ¡No que cada uno esté ocupado, sino que se vayan desarrollando resultados que aporten valor a los clientes!
  • El cuello de botella es un recurso valioso y en el mismo tiempo limita el flujo del agua. Por eso lo tenemos que utilizar inteligentemente, no desperdiciarlo. Es decir, que Esteban se dedique siempre a las tareas que requieran sus conocimientos y no pierda tiempo en otras que solo ralentizan el flujo de trabajo.
  • Buscar formas de hacer el cuello de botella más ancho, poco a poco haciendo que otras personas ayuden en los trabajos específicos. (esto requiere más tiempo y esfurzo)

¿Qué tal lo ves tú?

Artículos relacionados:

La Ley del cuello de botella

La ley del cuello de botella tiene su origen en la Teoría de las Limitaciones, creada por Dr Eliyahu Goldratt y publicada en el año 1984 en su libro “La meta”.

La ley dice que cada sistema, independientemente de cuánto de bien funciona, tiene por lo menos una restricción (un cuello de botella) que limita su rendimiento.

La ley permite deducir el tiempo de respuesta y los límites de rendimiento de un proceso – una información imprescindible para los servicios TI y los proyectos de desarrollos de software.

Centrar los esfuerzos de mejora en resolver el cuello de botella es el camino más rápido y más eficaz para la mejora de la rentabilidad.

 

Los cuellos de botella pueden involucrar personas, información, herramientas, procedimientos y pueden ser internos o externos para la organización.

PuenteColgante_Queue

El cuello de botella es la fase en el proceso en forma de sub-procesos o actividades individuales que limitan o bloquean el flujo. En el cuello de botella el rendimiento es más bajo. O bien, es la fase en la que una unidad de trabajo tarda más tiempo entre entrar y salir de la fase – el Lead time de esta fase es más largo.

Por ejemplo, miremos el proceso de “lavar la ropa – secarla – doblarla”.

Washing-DryingProcess

El cuello de botella es la secadora porque en esta fase del proceso completo el Lead time es más grande.

Los procesos involucran distintas personas, actividades y herramientas y cada uno de estos tiene un rendimiento distinto. Por lo tanto, si las actividades de un proceso se deben ejecutar en un orden secuencial, por ejemplo
        lavar-secar-doblar
        registración para el vuelo – control de equipaje – embarque al avión
        tomar requisitos – análisis-diseño-implementación – pruebas – entrega,
siempre habrá un cuello de botella en el proceso completo, especialmente si las fronteras del sistema están establecidas relativamente ancho.

¿Cómo resolver un cuello de botella?

En el libro «Kanban: Successful Evolutionary Change for Your Technology» de David Anderson puedes leer en más detalles cómo resolver un cuello de botella en función de si está causado por una limitación en la capacidad o en la disponibilidad del recurso.

Aquí voy a resumir los métodos de resolución de un cuello de botella:

  • Utilizar lo máximo del recurso: hacer que el recurso se dedique sólo a las actividades propias de este y asignar el resto de las actividades a otros recursos
    Por ejemplo, disponemos de un especialista en integración de software y debido a su participación en varios proyectos se convierte en un cuello de botella. Una opción será dejarle que se dedique explícitamente a las tareas de integración y asignar sus tareas de otro tipo a otros miembros del equipo.
  • Aumentar la disponibilidad del recurso – la frecuencia con la que el recurso está disponible aunque sea para un tiempo más corto.
    Ejemplo: El especialista en integración puede dedicar un día a la semana a cada proyecto. Una solución más eficiente es que la persona dedique a cada proyecto media jornada dos veces a la semana, en lugar de una jornada completa sólo un día a la semana.
  • Automatizar parte de las actividades.
  • Aumentar el recurso – suele ser la solución más cara.
    Siguiendo el ejemplo de antes esto es equivalente a contratar a otra persona con los conocimientos y la experiencia necesaria en integración de software.

Artículos relacionados:

Referencias

  • Libro: David Anderson, «Kanban: Cambio Evolutivo Exitoso Para su Negocio de Tecnología»
  • Libro: Eliyahu Goldratt, «La meta: Un proceso de mejora contínua»
  • Wikipedia: Teoría de las Limitaciones

Los principios de la gestión de proyectos que (casi) nadie enseña

Me dedico a la gestión de proyectos desde hace ya diecisiete años. He llevado a cabo proyectos de desarrollo de software para banca, para ingenieros civiles y para gestión documental.

He aplicado las prácticas deProjectMgmt_Sp

  • Rational Unified Process (RUP)
  • Método de Valor Ganado
  • PMBoK
  • CMMI™
  • Gestión de proyecto ágil (basada en Scrum)

Aunque siempre estaba tratando de aplicar correctamente los métodos, identificar y abordar los riesgos adecuadamente, hablar con el equipo a diario (la comunicación nunca ha sido un problema en nuestros proyectos), comunicar con el cliente a menudo, he sufrido los problemas de:

  • Estimaciones inexactas
  • Tener que trabajar largas horas y los fines de semana para cumplir fechas
  • “Todo es urgente” y se tiene que implementar en la iteración en curso
  • Tener que parar todo el proyecto para corregir un error en el diseño de la arquitectura
  • Subir a producción sin haber hecho todas las pruebas por falta de tiempo.
  • No saber cómo exactamente actuar para eliminar una desviación de plazo o de presupuesto y volver el proyecto a lo estimado

Hasta que aprendí Kanban y asistí al curso Kanban Coaching Professional con David Anderson, ninguno de los métodos me había enseñado que para que fuese bien el trabajo en los proyectos tenía que enfocarme también en lo siguiente:

  • Asegurar un flujo de trabajo suave
  • Aplicar la Ley de Little para equilibrar la demanda de trabajo y la capacidad del equipo
  • Resolver los cuellos de botella para mejorar el flujo de trabajo
  • Conocer la variación de los procesos y los efectos de esta.
  • Hoy me pregunto ¿por qué nadie me enseñó esto antes?

Si tuviera estos conocimientos antes, mis proyectos hubieran ido mucho más suave…

En fin, la máquina del tiempo todavía existe sólo en las películas.

De todos modos, si eres Jefe de proyecto, Team leader o Scrum Master, cuando tengas un rato, échales un vistazo a estos temas. Te ahorrarán algún que otro fuego.

Artículos relacionados:

Diagrama de flujo acumulado. ¿Todavía no lo utilizas?

Si eres responsable de la entrega de resultados a tus clientes y todavía no utilizas un diagrama de flujo acumulado (DFA) para gestionar tus proyectos de desarrollo y / o servicios, abre los ojos para esta herramienta. La querrás consultar a diario.

El trabajo se considera terminado cuando está entregado al cliente, ¿verdad? Sólo entonces podemos cobrar por ello.

Por tanto los equipos ágiles miden el progreso de un proyecto mediante el número de historias / requisitos entregados al cliente. Al principio en Scrum se usaba el gráfico burn down que mostraba el número de horas (o story point) restantes para completar el backlog. Luego se empezó a usar el gráfico burn up. Este muestra el número de features/funcionalidades realizadas por el equipo cada día. Esta información, junto con la métrica de velocidad se utiliza para proyectar una terminación sprint / iteración.

BurnUpChart_Sp
Sin embargo, teniendo en cuenta sólo el trabajo terminado no es suficiente.

La Ley de Little nos dice que el tiempo de entrega depende del trabajo en curso (TEC; WIP). WIP es todo el trabajo que se ha iniciado y aún no ha terminado, es decir, todo el trabajo entre Análisis y Despliegue, suponiendo que la etapa antes de Análisis es Backlog y la después de Despliegue es Hecho.

CFD_LittleLaw_Sp

Así que hay que mantener un ojo sobre el WIP.

Si el WIP aumenta, la fecha de entrega está en riesgo.

Por lo tanto, es mucho mejor trabajar con menor tamaño del sprint backlog / iteración que con los más grande. También, manteniendo el WIP menor, reduce el esfuerzo gastado en cambiar de tarea (task switching).

La reducción de tamaño del alcance (de una iteración o sprint)
aumenta la velocidad de entrega.

 

Como un buen gestor, además de conocer lo que se está desarrollando actualmente, tendrás que saber cuál es el estado del trabajo, cuáles de las unidades de trabajo están experimentando problemas, tienen defectos, o impiden la implementación de los demás. Es tu trabajo lo de resolver los obstáculos y asegurar un flujo de trabajo continuo.

Según la Teoría de las Limitaciones, cada sistema tiene al menos una restricción (cuello de botella). Así que hay que

  1. Identificar la restricción
  2. Decidir cómo explotar la restricción
  3. Subordinar todos los demás procesos de la decisión adoptada en el paso 2.
  4. Si después del paso 2 y 3, se necesita más capacidad, elevar la restricción.
  5. Ir al paso 1

¿Cómo detectar el cuello de botella en el flujo de trabajo?

De la Ley del cuello de botella, sabes que un cuello de botella es el lugar donde el rendimiento es más bajo. Por lo general, antes de este lugar hay una cola y después de él el rendimiento no es óptimo. Como ejemplo, piensa en un peaje en una autopista, un puente (ej. Puente Colgante de Bizkaia) en una hora pico, o un punto de control de seguridad en un aeropuerto.

Volviendo a nuestro flujo de trabajo de desarrollo de software, podemos visualizar la cantidad de elementos de trabajo en cada etapa diferente (análisis, implementación, prueba, despliegue, hecho) utilizando bandas de diferentes colores.

CFD_Sp

Ahora hay que observar si hay una banda que está cada vez más delgada, mientras que la correspondiente a la etapa anterior en el flujo de trabajo es cada vez más ancha (equivalente a una cola creciente).

CFD_CuelloDeBotella_Sp

Si ves este patrón, aplica los pasos mencionados arriba para resolver el cuello de botella.

Ten en cuenta que cuando vemos un cuello de botella, instintivamente pensamos que necesitamos más recursos. Sin embargo esta suele ser la solución más cara y no siempre la mejor. Ver el capítulo 17 Cuellos de botella y disponibilidad no instantánea en el libro «Kanban» de David Anderson para más detalles sobre cómo resolver los cuellos de botella. También te podría resultar interesante la historia de Esteban, el cuello de botella.

En Cumulative Flow Diagram Pawel Brodzinski muestra otros patrones de DFA que puedes ver si utilizas este gráfico.

Para resumir,

El Diagrama de Flujo Acumulado es una herramienta práctica que te ayuda a ver el estado del trabajo en curso, el ritmo del proyecto e identificar rápidamente los riesgos asociados al tiempo de entrega, así como los cuellos de botella.

Dibujar un DFA manualmente requiere concentración y buenas habilidades de representación numérica. Sin embargo, la mayoría de las herramientas de Kanban te proporcionan este gráfico automáticamente. Además, puedes elegir qué etapas del flujo de trabajo visualizar.

Para las organizaciones de gestión tradicional:

Si estás acostumbrado a monitorizar el progreso de un proyecto contra su plan y estimar la fecha fin en base al camino crítico del proyecto, utilizar el DFA también te resultará útil para lo siguiente:

  • Identificar los riesgos de retraso del proyecto antes de recibir el próximo informe del estado del proyecto
  • Detectar los obstáculos en el flujo de trabajo y eliminarlos antes de sufrir su impacto en el cumplimiento del calendario del proyecto
  • Obtener de un vistazo un imagen completa del estado del trabajo actual y el ritmo del proyecto.

Por otra parte, los datos que necesitas para hacer el DFA son sólo los estados de los elementos de trabajo (tareas, requisito, historia, boleto, incidente) y el tiempo que cada uno de ellos ha estado en el proceso (lead time). Las herramientas corporativas suelen tener estos datos. Lo que es crucial, por supuesto, es que los datos sean correctos, no manipulados.

Artículos relacionados: