Resultados de búsqueda de enero 2016

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

La Ley de Little

El origen de la ley de Little es la Teoría de las Colas. Es quizás la ley más conocida en el modelado del rendimiento de los sistemas TI.

La ley demuestra las relaciones entre el Lead Time, el Trabajo en curso (WIP) y el Rendimiento (Throughput).

Little's Law

  • El Lead time: El período entre la entrada de un petición en el sistema (petición  solicitada) y la recepción de la petición. Se mide por el tiempo transcurrido (minutos, horas, etc). La petición puede ser un requisito, una historia de usuario, una incidencia, material, una solicitud de un usuario, etc.
  • Trabajo en curso (WIP – Work In Process): el número de peticiones (unidades de trabajo) que se están procesando, es decir las que han entrado en el sistema, pero todavía no han salido.
  • Rendimiento (Throughput): el número de unidades de trabajo que salen del sistema en un tiempo determinado, p.ej., 3 historias de usuario por día.

Las conclusiones de esta ley son igual de interesantes e importantes:

  • Cuanto más grande es el WIP, más largo es el Lead time, es decir más tardamos en terminar el trabajo empezado. Dicho de otra manera, para cumplir los plazos de desarrollo o de los servicios, hay que reducir el trabajo en curso, o sea procurar de cerrar trabajos antes de abrir nuevos.
    Sin embargo, en muchas ocasiones ocurre justo lo contrario: los equipos empiezan a trabajar sobre muchas tareas para que así el proyecto entero “avance” más rápidamente. Otra razón por la que se busca asegurar mucho trabajo en curso es conseguir una alta utilización de los recursos.
    Independientemente del motivo, suponiendo que el rendimiento no cambia, el aumento del trabajo en curso aumenta también el tiempo necesario para su realización.
    Aunque parezca contra intuitivo, recuerda que reducir el trabajo en curso ayuda a cumplir los ANS y reducir los tiempos de desarrollo.
  • Enfocándose en reducir el Lead time ayuda identificar las actividades obsoletas que se están llevando a cabo. Eliminándolas tiene dos efectos positivos: (1) se eliminan desperdicios en los procesos, (2) se reduce el trabajo el curso total que resulta en un ciclo de desarrollo más corto y más eficiente.
  • Cuanto mayor es el Rendimiento, tanto más corto es el Lead time.
    Existen diferentes formas de mejorar el rendimiento: automatizando las actividades de valor (automatizar actividades que no aportan valor es equivalente a automatizar la producción de desperdicios), mejorando los procesos o añadiendo más recursos. Si decides añadir más recursos, observa el Lead time porque en general los recursos adicionales  añaden más trabajo en curso.
  • Cada iniciativa Lean procura de minimizar los desperdicios y de reducir los ciclos de producción. Reduciendo el ciclo de producción es equivalente a reducir el Lead time. Minimizar los desperdicios incluye un análisis del inventario actual y los pasos para reducirlos. Esto es equivalente a la reducción del WIP.

¿Por qué esta ley es importante para los Jefes de proyectos?

La ley de Little es una herramienta de conocer el rendimiento real de un equipo de operaciones o de desarrollo de software

  • Proporciona previsibilidad en el proceso.
    P.ej., si tenemos que implementar 50 requisitos y la capacidad del equipo es de unos 5 requisitos por semana, el tiempo que necesitaremos es

50 requisitos/5 requisitos por semana = 10 semanas.

  • Demuestra que cuanto más grandes son los batches de trabajo, tanto más largo es el tiempo de su procesamiento, el Lead time.
  • Explica por qué las multi-tareas retrasan en lugar de acelerar la terminación de trabajo.
    Habitualmente las personas creen que trabajar sobre varias tareas en paralelo aumenta la productividad. Por eso asignar unas cuantas tareas a una persona es una práctica común en las empresas. Sin embargo, a diferencia de las máquinas, las personas no son tan buenas en la ejecución de procesos paralelos. Aumentando el Trabajo en curso aumenta también en tiempo de cambiar y re-tomar las tareas y por lo tanto reduce el Rendimiento. A consecuencia, el tiempo para ejecutar el proyecto resulta insuficiente, el trabajo empezado y no terminado empieza a acumularse.
    En breve, la ley de Little ayuda a encontrar el punto de equilibrio entre el Trabajo en curso y el Lead time.
  • Proporciona los fundamentos para llegar a los óptimos límites de WIP. Si los límites de WIP están por debajo del nivel óptimo, hay recursos infrautilizados y el rendimiento es bajo. Si los límites WIP superan el nivel óptimo, entonces las unidades de trabajo empiezan a montar colas y el rendimiento baja.
  • Ayuda entender qué efectos tendrá sobre los plazos del proyecto o el servicio el bloquear un trabajo o tener que corregir errores. En ambos casos baja el rendimiento y de ahí aumenta el Lead time.

Condiciones importantes para que funcione la ley de Little

La ley de Little es muy útil, pero además de conocer la formula tienes que tener en cuenta las condiciones necesarias que se deben cumplir para que la ley de Little te sirva:

  • Se cogen valores medios de todos los parámetros: promedio del Lead time, promedio del trabajo en curso, y promedio del rendimiento
  • Las unidades deben ser coherentes, p.ej. si medimos el rendimiento en una semana, el lead time también tiene que ser en semana, así como el promedio del trabajo en curso
  • El sistema tiene que estar estable, es decir todo el trabajo que entra en el sistema, sale de este, el WIP total al inicio y al final del periodo es constante, la tasa media de llegada de trabajo es igual a la tasa media de salida de trabajo del sistema.
  • Para resumir, el uso correcto de la ley de Little ayuda conseguir un flujo de trabajo suave y estable, y a mejorar la previsibilidad de los proyectos y los servicios TI. El Trabajo en curso (WIP) es un factor clave para el rendimiento y el tiempo necesario para el desarrollo de software y/o la ejecución de los servicios. Limitar el trabajo en curso además de reducir el Lead time lleva a una reducción de los desperdicios en el flujo de trabajo.

Artículos relacionados:

Referencias

  1. Little’s Law on wikipedia
  2. Little’s Law – artículo en formato .pdf

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:

Analíticas Kanban: Gestión de proyectos pragmática

Los buenos viejos tiempos

Empecé a trabajar como jefe de proyectos de desarrollo de software en 1996. Éramos un equipo de 5 personas, jóvenes y motivados, y desarrollábamos un sistema de gestión de instalaciones (inglés: facility management) para un banco.

Sólo para darte una idea de aquel tiempo, teníamos acceso a Internet en un solo ordenador, por lo que comprobábamos el correo electrónico de todo el equipo (no el personal) dos o tres veces al día. Los teléfonos móviles eran como ves en la foto, es decir, no SMS, no WhatsApp, ni nada de este estilo.

Computer_Handy_1996

Este fue el único proyecto sobre que trabajábamos, no compartíamos recursos con otros proyectos y los otros desarrollos tampoco nos impactaban tanto.

¿Tu también te acuerdas de ese tiempo?  :-)

Como jefe de proyecto era responsable de planificar, dar seguimiento y reportar el progreso del proyecto.

El cliente esperaba un producto de alta calidad, sin embargo, fue lo suficientemente paciente para trabajar con nosotros en los requisitos y dejarnos el tiempo necesario para implementarlos y hacer las pruebas.

Está chupado, ¿verdad?

Aun así, antes de cada entrega teníamos que trabajar largas hora para asegurarnos que todo funcionaba bien. Es decir, las estimaciones no se ajustaban a los números reales.

Las estimaciones y los datos reales son diferentes valores del mismo parámetro.
No fuerces (manipules) los reales para que coincidan con las estimaciones.

La supervivencia y la sostenibilidad requieren pragmatismo

Menos de 20 años después, pocos jefes de proyectos, más bien ninguno, se puede imaginar llevar un único proyecto, con un equipo totalmente dedicado a este, sin interacciones con otros desarrollos, casi sin interrupciones, con algunos cambios de requisitos manejables, y problemas relacionados sobre todo con la tecnología.

Lo interesante es que la complejidad de los métodos de gestión de proyectos ha aumentado en paralelo con el aumento de la complejidad del desarrollo de software, mientras que el tiempo para hacer las decisiones correctas es cada vez más corto y las expectativas de los clientes cada vez superiores.

Revisé mis apuntes de los últimos años. Los jefes de proyecto comparten los siguiente acerca de su trabajo:

  • Es difícil manejar la variedad de factores que influyen en un proyecto: la claridad de los requisitos, la estabilidad de las tecnologías, el nivel de conocimientos y habilidades de los miembros del equipo, los riesgos, las dependencias de otros proyectos, etc
  • Cuanto más sofisticado sea el método de estimación, más esfuerzo (y tiempo) se necesita para hacer un buen plan de proyecto. De todos modos este tiene una vida muy corta hasta que cambie de nuevo
  • Estimación, planificación, seguimiento y re-planificación es una carga administrativa muy alta, difícil de vender a los clientes, y por lo tanto sostener
  • Hay mucha presión para dar estimaciones rápidamente y después cumplirlas
  • Difícil coordinación de los proyectos.

En una situación como esta, ¿no deberíamos de revisar las prácticas de gestión de proyectos bien establecidas y buscar algunas más pragmáticas?

Aplicar métodos complejos a situaciones
complejas las complica aún más.

 

Enfoque Kanban de gestión de proyectos

¿Cuál es el propósito de gestión de proyectos? – Asegurarse que el proyecto se ajusta a los criterios de sus interesados (clientes y organización). ¿Correcto?

Aquí los tienes:

Aptitud del trabajo: Perspectivas
Cliente

  • Entregar rápidamente (tiempo)
  • Entregar a tiempo (previsibilidad)
  • Precio competitivo
  • Calidad (obtener el producto/servicio correcto)

 

 

 

 

 Organización

a. Nivel de proyecto

  • Estimaciones (tiempo, coste)
  • Previsibilidad
  • Calidad
  • Coordinación de los proyectos

b. Nivel de negocio *

  • Sostenibilidad
  • Orientación a servicio
  • Supervivencia

* Ver la charla de David J Anderson sobre las 3 agendas de Kanban.

Entonces, las dimensiones de la aptitud de un proyecto y las herramientas analíticas correspondientes se pueden resumir de la siguiente manera:

Aptitud del trabajo: Dimensiones
Tiempo de entrega

  • Tiempo de entrega (inglés: Lead time)
  • Rendimiento (inglés: throughput)

Coste

  • Coste de las actividades de valor añadido, transaccionales y de coordinación>
  • Coste de los desperdicios (corrección de defectos, re-trabajo, espera)
  • Requisitos/historias descartados
  • Eficiencia

 

 Previsibilidad

  • Cumplimiento de ANS
  • Cumplimiento de fecha fin

Calidad

  • Número de defectos
  • Esfuerzo y duración de re-trabajo

Negocio

  • Eficiencia
  • Perseverancia del flujo de trabajo (Diagrama de flujo acumulado, DFA)
  • Cumplimiento de ANS (historgrama, gráfico de control)

Pincha en los enlaces para ver cómo se utiliza cada una de las herramientas y la valiosa información que aporta a tu proyecto.

Si te fijas en las herramientas que necesitas para gestionar la aptitud del trabajo de tu proyecto con respecto a cualquier criterio, cliente o organización, te darás cuenta que lo que necesitas fundamentalmente es suficiente y, por supuesto, buenos datos reales. (En cuanto a los datos, siempre tenemos que recordar que si entra basura – sale basura).

El poder de los datos reales, no las estimaciones especulativas, te da confianza
en tus compromisos y te permite dormir tranquilo, porque
reduce los riesgos de no cumplir tus promesas.

 

Además, ahorras todo el esfuerzo para inventar y actualizar un método de estimación formal y tratar de adaptarlo a las características únicas de cada proyecto.

Para las empresas CMMI:

  • El tiempo de entrega se recoge principalmente en proyectos orientados a los servicios (por las necesidades de la gestión los ANS). Sin embargo este es un dato valioso para los proyectos de desarrollo de software también.
  • En los proyectos de desarrollo de software por lo general se registra el esfuerzo de realización de la tarea, pero no el tiempo de entrega (el Lead time) de un requisito o historia. Esfuerzo y duración no es lo mismo. Conocer la distribución del Lead time para los tipos de trabajo o las clases de servicios ayuda a conseguir una planificación más realista.
  • Conociendo el Rendimiento permite (a través de la ley de Little) dar una estimación rápida y fiable del tiempo de entrega necesario para implementar un conjunto de historias / requisitos.
  • La visualización del trabajo en curso facilitan enormemente la coordinación de los proyectos.
  • El DFA es quizás el mejor indicador en tiempo real del ritmo del trabajo (proyecto) y los riesgos.

Artículos relacionados:

Escucha los defectos para limitar los riesgos eficazmente

«Si no atacas los riesgos activamente, ellos te atacarán activamente»
– Tom Gilb

Lo que suelo ver en las tablas de riesgos de los planes de proyecto o servicio es «retraso de la entrega», «sobrepasar el presupuesto», o «problemas en la aceptación del cliente debido a requisitos poco claros».

Al mismo tiempo, los equipos más a menudo se quejan de no poder cumplir los plazos, y superar los presupuestos.

Obviamente estamos más atacados que atacando los riesgos. (más…)

Se trata de hacer el trabajo fluir, «tontito»

En 1992 Bill Clinton eligió un lema interesante para su campaña política: 

Bill Clinton Economy

Por supuesto, había muchos otros temas importantes para el país y una gran cantidad de factores que estaban influyendo su resolución. Sin embargo el mensaje clave de Bill Clinton se centró en el punto central para el país, la economía.

Yo me encuentro frecuentemente con empresas que se enfrentan con la necesidad de reducir el tiempo de entrega de sus proyectos y servicios, ofrecer precios más competitivos, y adaptarse mejor a las necesidades cambiantes de sus clientes.

Es difícil introducir cambios drásticos en las organizaciones donde las estructuras y responsabilidades jerárquicas llevan establecidas largos años y cualquier interrupción asusta a la gente y la hace resistir. Para estas organizaciones, la necesidad de cambio es, sin duda, reconocida. Cómo enfocar y llevarlo a cabo, sin embargo, no está bien claro.

Aunque yo personalmente no llamaría a nadie «estúpido», si tengo que resumir al estilo de Bill Clinton lo que he visto que las empresas hacen para estar en forma, diría:

Se trata de hacer el trabajo fluir, estúpido.

¿Cómo? – A través de unos pasos sencillos:

  • Visualizar y centrarse en una cantidad limitada de trabajo en curso
  • Hacer lo que aporta valor para el cliente. No hacerlo que no es necesario.
  • Aprender a ver y eliminar los desperdicios de los procesos. Simplificar los procesos.
  • Gestionar el flujo de trabajo, no el plan
  • Hacer que las personas  resuelvan los problemas en colaboración, dentro y entre los equipos

Visualización

La visualización te ahorra esfuerzo esencial para:

  • entender la situación actual del trabajo – lo ves directamente en el tablero, no tienes que deducirlo de los números
  • tomar decisiones efectivas sobre los impedimentos en el flujo de trabajo y los riesgos – los detectas en cuanto aparezcan, no tienes que esperar  ningún informe, y tienes de  inmediato la imagen de la situación real que se tiene que resolver (otro trabajo afectado, personas que pueden estar involucradas)
  • decidir cómo adaptar el proceso estándar; lo defines con tu equipo teniendo en cuenta el proyecto real  o la situación de servicio
  • comunicar información y llegar a una visión y comprensión compartida del trabajo – todo está en el tablero y hablar de los detalles delante de la imagen completa del trabajo que se tiene que realizar, es la manera más eficaz de comunicación

Tablero Proyecto

Visualizar los defectos y re-trabajo fortalece la conciencia de los miembros del equipo acerca de la necesidad de buenos procesos y les ayuda a identificar cómo mejorar las prácticas actuales. Recuerda que

«El tipo de desperdicio más peligroso es el desperdicio que no reconocemos.»
Shigeo Shingo

Limitar el trabajo en curso

Limitar el trabajo en curso en un sistema kanban hace el trabajo fluir (segunda práctica de Kanban). Centrarse en el valor y tiempo de entrega provoca naturalmente preguntas como «¿por qué hacemos esto?», «¿El cliente lo necesita?», «¿Cómo podemos obtener el mismo resultado más rápidamente?». Estas dudas a su vez llevan a simplificar y aligerar los procesos.
Además, la necesidad de auditorías y controles por el departamento de calidad se reduce porque el equipo las realiza en los momentos adecuados. Esto permite a los responsables de calidad concentrarse en resolver los problemas que afectan a varios procesos y proyectos / servicios, trabajo que corresponde a su perfil y que realmente les gusta.

Gestionar el trabajo, no las personas

Watch The Baton

Gestionar el trabajo en lugar de las personas o el plan es la clave para lograr buenos resultados. ¡Esta es la parte difícil! Puedes encontrar las métricas y técnicas más importantes en la serie de artículos sobre Analíticas Kanban. Gestión centrada en los clientes, de tiempo real y compartida por todos los miembros del equipo, disminuye la carga del director de proyecto y le proporciona más tiempo para hacer mejor su trabajo.

Todos los modelos y estándares sugieren colaboración. Pocos proporcionan medios para realmente conseguirla. Un grupo de personas con unas tareas asignadas en un proyecto común no es un equipo y no necesariamente colabora. La colaboración se produce cuando las personas se reúnen regularmente y hablan acerca de cómo lograr objetivos comunes, resolver problemas juntos, y ayudarse uno a otro cuando sea necesario. La visibilidad tiene un papel importante en la creación de un equipo y hacerle avanzar hacia una meta.

Para resumir, el entorno de negocio está cambiando constantemente y las organizaciones tienen que aprender a adaptarse y responder rápidamente a esto. Hay muchas prácticas que ayudan a las empresas satisfacer mejor las necesidades de sus clientes, pero la vital es hacer el trabajo fluir. La visualización, la gestión centrada en la entrega de valor al cliente de forma rápida, y la involucración de las personas en simplificar y aligerar los procesos son muy importantes para hacer que esto suceda.

 

Teodora Bozheva
Accredited Kanban Trainer & Consultant
Co-autora del Kanban Maturity Model
www.berriprocess.com

Artículos relacionados:

La comunicación y la visibilidad – las vitaminas para las empresas TIC

Este mes tuve un servicio interesante para el departamento TI de un banco. Digo interesante porque me contactaron para visitarles,ver cómo llevaban a cabo y gestionaban sus proyectos y decirles cómo les veía. Nada de problemas que quieren resolver, objetivos que están buscando, mejoras que les gustaría introducir o método que aplicar. Simplemente venir – ver – y darnos tu opinión.

Fui con una buena dosis de curiosidad y también con algo de preocupación porque no sabía con qué me iba a encontrar ahí.

El contexto

Para entender el contexto les pedí tanto al equipo de desarrollo de software como al de los usuarios que me describiesen su flujo de trabajo asó como todas las dificultades que tenían en su día a día (un problema por post-it).

En resumen la situación actual se puede dibujar así:

WorkflowAndPains Sp

Los dolores que necesitan una cura urgente según la priorización de ambos equipos son los siguientes:

  1. Pobres requisitos de los usuarios (definidos a nivel de idea)
  2. Insuficiente análisis de negocio
  3. Problemas con las estimaciones de las tareas – los usuarios no entienden qué hacen los desarrolladores tanto tiempo; existe presión por reducir las estimaciones; luego aparecen los problemas de no cumplirlas
  4. Frecuentes cambios de prioridades
  5. Alta carga de trabajo e incapacidad por parte del equipo de desarrollo de responder rápidamente a las peticiones de los usuarios.
  6. Falta de gestión de riesgos

El análisis de los problemas se puede resumir así, leyendo el árbol desde abajo hacia arriba.

Pains Analysis

Se buscan “quick wins”, es decir soluciones que lleven a resultados positivos en corto plazo.

¿Qué vitaminas les receto para que noten mejoría en poco tiempo?

Definir un método de estimación vendría bien,  establecer criterios y reglas de gestión de los cambios a los requisitos y de los riesgos también, pero todo esto requiere su tiempo y esfuerzo. Además, después hay que asegurarse que se acepte bien por las personas en ambos equipos – los usuarios y los desarrolladores.

Escuchando a los dolores y los miedos de los dos lados la siguiente imagen apareció en mi mente:

CommunicationProblems Sp

En el fondo de todo está el problema del mapeo (el encaje) entre los requisitos de los usuarios, en su idioma de negocio, y  el trabajo del equipo de desarrollo, con todos sus aspectos creativos y técnicos.

La comunicación y la visibilidad compartida en el trabajo son
las vitaminas para las empresas TIC.

Ninguna tecnología o método formal dará resultados positivos en corto tiempo, si falla la comunicación entre las personas y falta visibilidad en el trabajo que se está llevando a cabo.

Verifiqué esta idea con el equipo y juntos llegamos a los siguientes dos elementos de la solución “quick win”:

  • Trabajar en equipos multidisciplinares

MultidisciplinaryTeam Sp

  • Usar a un tablero kanban compartido para tener visibilidad en el trabajo en curso y facilitar su entendimiento y gestión.

Draft Kanban Board

Ahora volvamos a los dolores que necesitan una cura urgente. Todos estarán positivamente afectados de esta solución sencilla ¿verdad?

Por lo menos en esto estamos convencidos el equipo de la organización y yo.

¿Qué tal lo ves tú?

Si crees que esta experiencia puede servir a algún amigo tuyo, re-envíale el mensaje. Te devolverá el gesto en otro momento importante para tí.

Artículos relacionados:

Los dos enemigos mortales del cumplimiento de plazos

De los últimos proyectos o servicios que hayas terminado, ¿cuántos entregaste completos y en el plazo esperado? Por supuesto, sin la necesidad de trabajar horas extra o los fines de semana.

Hace 4 años empecé a coleccionar fotos de los problemas de las organizaciones de desarrollo de software, independientemente del método de trabajo que utilizan. El año pasado comencé a ampliar mi colección con fotos de empresas industriales.

¿Sabes cuál es dolor más recurrente?

– Los retrasos de los proyectos / servicios. Que a su vez llevan a sobrecostes.

ProjectPainPoints

Lo que aumenta la amargura de la persona responsable para un retraso es que ha hecho todo lo posible para evitarlo: ha intentado de desglosar bien el trabajo, de evaluar los riesgos, ha añadido colchón a las estimaciones, etc, etc.

Aun así se ha cumplido la ley de Murphy, “todo lo que pudo perjudicar al proyecto ocurrió en los peores mementos posibles”, como p.ej:

  • Uno de los compañeros se puso malo y su trabajo se tuvo que distribuir entre las otras personas del equipo
  • Surgieron dos proyectos nuevos, importantes, que se tenían que compaginar con el resto del trabajo
  • Algunas de las tareas resultaron más complejas que lo esperado. Por tanto se tardó más en hacerlas y esto afectó a otros trabajos.
  • La aprobación del cliente / la entrega del proveedor llegó fuera del plazo previsto
  • Hubo un día loco cuando todo el mundo llamaba por teléfono para pedir algo, y se terminó la jornada sin prácticamente avanzar el trabajo planificado
  • Etc, etc.

¿Te suenan estos motivos para los retrasos?

¿Te imaginas una semana en la que te dedicas a lo que tienes pensado, disponiendo de toda la información que necesitas, ordenando tus tareas sin la presión de terminar alguna antes que otra, sin interrupciones, completando todo bien y profesionalmente como a ti te gusta?

¡5 días volviendo a casa satisfecho con el trabajo cumplido y teniendo tiempo y ánimo para disfrutar la tarde-noche con los tuyos!

Sunset Vieux Boucau

¿Qué causa los retrasos?

La primera razón que se nos ocurre son las estimaciones.

Las estimaciones ¿de qué?

Los métodos tradicionales como CMMI y PMBoK incluyen prácticas acerca de la elaboración del calendario de un proyecto / servicio.

Para poder definir el calendario estos métodos sugieren lo siguiente:

  • Desglosar y definir el trabajo en suficiente detalle
  • Secuenciar las tareas
  • Estimar el tamaño de las tareas y de ahí el esfuerzo para su ejecución
  • Tener en cuenta la disponibilidad de los recursos para el trabajo
  • Tener en consideración los niveles de experiencia y capacitación de los recursos
  • Identificar y evaluar el impacto de los riesgos para el proyecto

Los métodos tradicionales estiman el tamaño y el esfuerzo, pero no estiman el tiempo de los trabajos (el hecho se estima que una tarea requiere 5 horas de trabajo no significa que se va a terminar en un tiempo de 5 horas).

Los métodos ágiles utilizan sprints (iteraciones) de una duración fija (de dos semanas habitualmente) y estiman el alcance (las historias de usuario) que se puede implementar en este time-box en base a la velocidad del equipo. Es decir, los métodos ágiles no estiman el tiempo de ejecución de los trabajos.

Si tenemos problemas con la desviación en plazo, ¿por qué estimamos esfuerzo y no tiempo?

El primer enemigo al cumplimiento de los plazos es confundir tiempo y esfuerzo

Desde que empecé a estudiar a fondo el problema de los retrasos, los datos de las diferentes empresas donde hemos medido estos dos parámetros muestran que el esfuerzo ronda entre 7% y 20% del tiempo de ejecución de un trabajo. Por ejemplo, si el tiempo que pasa entre empezar y cerrar una tarea es 10 días naturales, el esfuerzo que se imputa a esta es menos de 2 días. El resto del tiempo la tarea está parada por diferentes motivos: espera a información adicional, otra tarea más urgente, etc.

En Lean Kanban France-2012 Zholt Fabok presentó datos aún más preocupantes: 95% del tiempo de ejecución pasa en espera. Ver Measure and Manage Flow in Practice para más detalles.

Tiempo y esfuerzo son dos medidas diferentes.
Separa sus estimaciones, si quieres reducir los retrasos.

 

Cuando dejamos una tarea para [volver a] empezar otra, a veces tenemos la sensación que están avanzando las dos.
¡MENTIRA!

Las multi-tareas solo ralentizan la terminación de los trabajos y reducen la productividad un 40%. (Samsung Business)

Productivity Infographic

El segundo enemigo al cumplimiento de los plazos es el volumen de trabajo en curso

Consulta la Ley de Little para que entiendas que cuánto más trabajo tenemos entre manos, tanto más tardamos en terminar cada uno de ellos.

Un ejemplo: en abril Ander fue padre por primera vez. ¡Un momento feliz en su vida! Antes de salir de baja de paternidad se concentró en terminar lo máximo trabajo posible para que los dos compañeros de su equipo no se quedasen parados mientras él disfrutaba de la llegada de su hijo. Dejó una pila de diseños empezados y no terminadas (faltaba completar lo que correspondía a las otras dos personas). Consecuencia: el tiempo promedio de terminación de un trabajo por el equipo aumento de 13 a 21 días (un 60% de aumento).

Ya sé que esto es contra-intuitivo. Por eso te invito a experimentarlo tú mismo haciendo el ejercicio que te dejo abajo.

Resumen

No distinguir tiempo y esfuerzo y el volumen del trabajo en curso son dos enemigos ocultos que siempre atacan el cumplimiento de los plazos.

 

Si queremos reducir los retrasos, tenemos que controlar el tiempo de ejecución de los trabajos.

Para que reflejes y sientes el placer de entregar a tiempo sin estrés, haz el siguiente ejercicio:

  1. Durante una semana recoge los siguientes datos por cada tarea que haces: fecha inicio, fecha cierre, esfuerzo dedicado
  2. Por cada tarea calcula el Lead time = Fecha cierre – Fecha inicio +1
  3. Refleja sobre lo siguiente:
    • Ratio entre Esfuerzo dedicado y Lead time
    • Relación entre el promedio(Lead time) y el promedio(Trabajo en curso) (el número de tareas abiertas) por día
  4. Cuéntame tus conclusiones.

Artículos relacionados

Analíticas Kanban: Rendimiento

La métrica rendimiento (tasa de entrega) es relativamente poco conocida en las empresas de gestión de proyectos tradicional (basadas en PMBOK, PRINCE2, CMMI). Sin embargo, con la difusión de los conceptos Lean, creo que empezará a ganar más respeto en el futuro próximo.

El rendimiento es la cantidad de elementos de trabajo entregados en un período determinado de tiempo (p.ej. semana, mes, trimestre).

Cuando decimos ‘entregado’ nos referimos realmente a trabajo terminado y, posiblemente, entregado al cliente. Es decir, al final del proceso se cobra.

Para entender el concepto de rendimiento, vamos a suponer que durante las últimas cinco semanas un equipo ha entregado respectivamente 4, 6, 4, 2, y 3 historias de usuario (requisitos) por semana. Si hay historias empezadas, pero no terminadas, estas no forman parte de los cálculos.

El rendimiento promedio del equipo durante estas cinco semanas es (4 +6 +4 +2 +3) / 5 = 4 historias / semana (redondeado). La desviación estándar se redondea a 1 historia / semana.

El rendimiento se basa en datos reales de la capacidad del equipo de terminar/entregar trabajos. La variabilidad del rendimiento refleja el impacto de factores como el tamaño de las historias, su complejidad, urgencia, así como las habilidades de la personas.

El rendimiento se puede utilizar para planificar un proyecto. Por ejemplo, siguiendo con el ejemplo anterior, el equipo puede estimar que su rendimiento (capacidad de la entrega) será de 4 ± 1 historias por semana sin hacer ninguna estimación detallada de los requisitos individuales.

En Kanban, sin embargo, el rendimiento se utiliza principalmente para dar seguimiento al ritmo de producción (entrega) del equipo. Lógicamente, el objetivo es mejorar continuamente.

El rendimiento es una medida del número de elementos de trabajo que el equipo es
capaz de producir en un determinado período de tiempo (por ejemplo, semanas,
meses), siempre y cuando se mantenga una carga de trabajo uniforme.

Rendimiento y velocidad

El rendimiento es similar a la métrica ágil velocidad, sin embargo, se utiliza de manera diferente.

La velocidad se utiliza en eXtreme Programming y Scrum. Muestra la cantidad de trabajo que un equipo puede completar en una iteración o sprint. El trabajo se mide en puntos de la historia (story points).

Volviendo al ejemplo del equipo anterior, supongamos que los cinco casos de uso completados durante las últimas dos semanas, son de 3, 4, 1, 5 y 3 puntos de historia respectivamente.

Entonces, el número total de puntos de la historia que el quipo puede completar en un sprint de 2 semanas es 3 +4 +1 +5 +3 = 16. Es decir, la velocidad del equipo es de 16 puntos de la historia por sprint.

La velocidad también varía debido a factores como la complejidad de las historias, su tamaño, los cambios, el nivel de habilidades de equipo, etc.

Los equipos ágiles utilizan la velocidad promedia para estimar cuántas historias serán capaces de implementar en los sprints futuros. A pesar de todo, tienen que estimar los casos de usuario individuales con el fin de definir el backlog (el alcance) de un sprint.

Así que, aunque la métrica velocidad se asocia con rapidez, de hecho se trata de la carga, (medida habitualmente en puntos de historia) que un equipo puede llevar a cabo durante un período de tiempo determinado (iteración, sprint).

Rendimiento y estimación de los recursos

El rendimiento se puede utilizar para estimar los recursos necesarios para realizar un desarrollo o servicio.

Según la Ley de Little:

ThroughputFormulae_Sp

Si un equipo mantiene a un ritmo constante de trabajo, el tiempo promedio de entrega (lead time) para un determinado tipo de trabajo o una clase de servicio puede considerarse como una constante.

El rendimiento (throughput) es el objetivo que debe lograrse con el fin de cumplir la fecha fin definida por el cliente.

Aplicando la ley de Little calculamos el número de elementos de trabajo que hay que procesar en el tiempo determino.

Ejemplo: supongamos que el tiempo de entrega de una historia es de 0,25 semana. El rendimiento objetivo es de 20 historias/semana.

Entonces, El trabajo en curso (WIP) = 20*0,25 = 5 historias.

Asumiendo que una persona sólo puede trabajar sobre un único requisito, deducimos que necesitamos un mínimo de 5 personas para la implementación de todo el trabajo a tiempo. Por si acaso (no hay fórmulas precisas para esto), estaría mejor contar con un equipo de 6 personas. :-)

La ley de Little y el rendimiento permiten estimar los recursos necesarios
para llevar a cabo un trabajo.

En resumen, el rendimiento es fácil de recoger. Es una medida valiosa, ya que mantiene el foco centrado en la capacidad productiva del equipo. Asimismo, conociendo el rendimiento del equipo disminuye el esfuerzo para la estimación de las historias (requisitos), siempre y cuando estas se desglosan a trozos relativamente pequeños. Además, a través de la ley de Little, el rendimiento permite estimar los recursos necesarios para completar un trabajo determinado en el tiempo esperado por el cliente.

Artículos relacionados

Página anterior Página siguiente