• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

flow

El mito de la eficiencia

Hace unos meses, en un esfuerzo por reducir mi altísima carga de trabajo, contraté a una empresa de Granada para llevar la gestión del Marketing Online de los cursos públicos. Nada muy sofisticado, apenas consistía en llevar campañas de Google Adwords, Facebook, la gestión de las publicaciones en redes sociales y un rediseño del material y la web. Mi principal problema era de tiempo, no de conocimiento. Para mi, es mejor externalizar todo lo que no añade directamente valor a las formaciones y centrarme en mejorar su calidad.

Saqué dos horas de mi agenda para sentarme a hablar con ellos y explicarles cuales eran los detalles y la problemática que tengo. Sabía que tocaba hacer muchos deberes y podía aprovechar las dos semanas siguientes para trabajar en lo que hiciera falta. Tres semanas después, contactaron por primera vez conmigo después de nuestra reunión para enviarme un presupuesto. Había perdido mi ventana de oportunidad.

A pesar de todo, intenté darle salida y buscar tiempos antes de las 8 de la mañana para hacer reuniones telefónicas y darles lo que necesitaran. Todo se encasquilló en torno al diseño de unos banners, que en un principio estaban presupuestados pero luego no lo estaban. Les dije que si, que necesitaba avanzar, pero la discusión siguió en torno a si serían 90€ o 120€ más por hacer los banners. Me da igual, les dije. Necesito sacar esto adelante.

Siete semanas después de sentarme por primera vez, por fin pudimos darle salida a la primera campaña en Adwords. No había banners y del resto de cosas que quería hacer ni siquiera tenía un presupuesto. La gota que colmó el vaso fue cuando descubrí que pretendían cobrarme sus servicios por adelantado. Unos servicios que, por lo que había visto hasta ahora, eran increíblemente ineficientes. Desde el punto de vista del flujo.

Cuando les comuniqué que no pagaría por adelantado más que lo que estaba estipulado en el contrato, la persona del departamento de Publicidad me remitió al departamento de Administración, que a su vez me dijo que tendría que remitirme al departamento de gerencia. ¿Sabes cuantos empleados tiene esta empresa, incluidos los socios? 11. Entre solo 11 personas habían creado un entramado de departamentos y de colas de espera que serían el deleite de cualquier ejecutivo de un call-center de Telefónica.

Eficiencia de recursos y eficiencia de flujo

Desde el punto de vista de esta pequeña compañía, probablemente tienen un entramado eficiente. Alguien que se encarga de comercial, algunas personas lo hacen de publicidad, hay un departamento de administración. Todos funcionan como silos perfectos que se comunican entre ellos. Están equivocados. La eficiencia matará su compañía.

Es la manera perfecta de maximizar el número de horas que una persona está ocupada. De identificar si hay una sobrecarga de trabajo en un área determinada. No contratan más gente hasta que el sistema está al borde del colapso.

Es eficiencia de recursos.

Los recursos son limitados y el objetivo es maximizar su eficiencia introduciendo nuevos recursos sólamente cuando es completamente necesario.

El problema reside en que esta eficiencia de recursos no tiene en cuenta la satisfacción del cliente. Yo, como cliente que planea invertir miles de euros al mes en sus servicios, espero una atención rápida y deliciosa.

Cualquier compañía digital entiende que lo importante no es cuan eficientes seamos, sino la velocidad de adaptarnos a las necesidades del cliente. En otra compañía de similar tamaño, me reuní directamente con la persona que se encarga de la publicidad, que además es el único punto de contacto para mi, como prospecto o como cliente. En un par de horas tenía un presupuesto y el tiempo para tener la campaña online era de un par de días.

Este enfoque se llama eficiencia del flujo.

Aquí, lo importante no es utilizar todas nuestras horas de forma óptima, sino que el tiempo de espera sea el mínimo, mientras que la densidad del valor añadido sea máxima.

Si contamos con que el tiempo de creación de valor añadido: Reunión, definición, alta de campañas, facturación y cobro son 15 horas en ambos casos, la eficiencia de la primera compañía es de apenas un 1.2%, mientras que en la segunda compañía es del 20.8%.

Como se puede ver, lo importante no es optimizar la eficiencia de los subprocesos, sino la experiencia global.

Cada vez que introducimos una optimización en uno de esos subprocesos, reducimos la eficiencia de flujo del total de la experiencia de cliente.

La base de Lean

Esta diferencia entre  eficiencia de recursos y eficiencia de flujo es la base de Lean, un proceso que situó a la Toyota de la posguerra como el mayor fabricante de automóviles del mundo, por encima de compañías americanas y europeas con un porcentaje de optimización de recursos mucho mayor.

Esta es también la base de la transformación digital, en la que prima la velocidad de respuesta al consumidor que la capacidad de optimizarnos internamente.

Cómo la eficiencia hundió tu empresa

Hace unos días di un curso para una compañía muy conocida. Casi al final del segundo día, uno de los asistentes, Manager, me dijo: ¿Entonces cómo mido la eficiencia de la gente? ¿La eficiencia de la gente? Sí, claro… si trabajan o si no.

Estaba anonadado. Casi no sabía qué decir.

Justo en ese momento de la clase hablábamos de medir la productividad a través del throughput (ritmo de entrega) y la variabilidad de cada uno de los ítems entregados. Una alternativa mucho mejor al uso de Story Points. Tan distinta como comparar la homeopatía con un tratamiento médico de doble ciego.

Un ejemplo: Si un equipo entrega de media 10 Product Backlog Items y otro entrega cinco, eso no nos da mucha información. Los PBIs pueden ser más grandes o más pequeños, o el equipo tener distintas capacidades técnicas, el stack puede ser más o menos complicado y un sinfín de situaciones.

Pero si además de decir si un equipo entrega 10 o 5, lo acompaño con el número -medio- de días que tardan en entregar, entonces si tengo una métrica realista. Dos equipos, uno entregando 10 PBIs y otro entregando 5, que entregue en 20 y 10 días respectivamente, tendrán una productividad similar.

Pero esto no era suficiente.

La preocupación de este alumno era distinta. No le preocupaba el valor. No le preocupaba lo que se entregaba. Le preocupaba que su cliente viera a la gente -gente por la que paga- ocupada todo el día. Y claro, enfocándose en generar valor, es difícil que eso pase. Veamos por qué.

Eficiencia vs Valor

Hoy en día, las compañías deciden enfocarse en la eficiencia, y encuentran que los frameworks como Scrum o los métodos de Management como Kanban requieren de un salto de fe desde la eficiencia, entendida como todo el mundo debería de estar trabajando a toda velocidad, hacia el enfoque de valor.

Sin embargo, ¿qué es valor? Hace unas semanas, estuve con todos los Product Owners de una conocida startup en Barcelona. Juntos, llegamos a la conclusión de que su trabajo los había convertido en meros gestores de horas. Su misión era que los desarrolladores estén ocupados. Si la gente no trabaja ocho horas, entonces no son eficientes. Error.

Valor, en el negocio del desarrollo de Software, es llegar antes que los demás al mercado. Validar y seguir. Fallar y rectificar. Eso es la agilidad. Mientras no hacemos una release de Software al cliente, el valor que generamos es cero.

Cuando nos enfocamos en que todo el mundo esté ocupado, entonces tendemos a crear colas. Como en el desarrollo de Software por naturaleza las distintas tareas que podemos hacer tienen una alta variabilidad, entonces las colas tienden a crecer hasta el infinito. Que todo el mundo esté ocupado significa, inequívocamente, que nuestro ritmo de entrega tenderá a cero.

Conseguir una release supone ineficiencia. Sólo podríamos alcanzar un estado de alta ocupación y alta entrega si todas las tareas tuvieran exactamente la misma carga de trabajo. Lamentablemente, en el Software, debido a su naturaleza de crear siempre cosas nuevas, las cargas varían mucho.

La ley de los retornos disminuidos

Un 95% de las empresas trabajan totalmente ciegas a sus economías internas. Ni las entienden, ni saben que existen. Ni pueden ni saben cuantificar cuál es el coste de decidir hacer una nueva feature en lugar de invertir en mejorar la calidad técnica del producto.

Algunos desarrolladores de producto comprenden “algunas variables”, y por ejemplo te dirán que lo más importante es reducir el tiempo de desarrollo -cycle time-, pero no tienen ni idea de cuánto va a afectar al total del ciclo de vida del desarrollo de producto o a su beneficio.

¿Qué sentido tiene reducir el tiempo de proceso si al final estoy limitado por otras variables?

Esto es algo habitual en la gran corporación. Por ejemplo, los bancos están invirtiendo cantidades ingentes de dinero en mejorar sus procesos de desarrollo usando Scrum, Kanban, SAFe o Nexus. Sin embargo, para poder lanzar una aplicación a producción, siguen necesitando a un comité de cambios que apruebe la subida a producción. Este comité se reúne una vez cada tres meses, limitando toda la mejora obtenida mediante Scrum a cero. ¿Qué sentido tiene desarrollar de manera ágil si al final vamos a llegar al mercado al mismo tiempo que lo hacíamos antes?

Por otro lado, la única manera de comprender la importancia económica de las colas que creamos cuando nos enfocamos en que todo el mundo esté ocupado -eficiencia-, es cuantificar el coste de retraso -cost of delay- en los proyectos de desarrollo de producto. A pesar de eso, sólamente el 15% de los desarrolladores de producto conocen el cost of delay asociado con sus proyectos y productos.

Cost of Delay

El cost of delay tiene una fórmula simple: ¿Cuánto me cuesta si no entrego a tiempo? A tiempo no es la línea temporal que me he marcado en mi plan de proyecto, sino el momento en el que el mercado me lo demanda. ¿O acaso lanzarías una campaña de Navidad en Febrero?

Un detalle: Cuando me refiero a desarrolladores de producto, no me refiero a ingenieros de software, ni programadores. Me refiero a todos aquellos implicados en el desarrollo de producto, desde el Product Manager hacia abajo, todos deben ser conscientes de estos elementos.

Prosigamos.

Así, estos tipos de Producto, se enfocan en variables proxy como la utilización (¿Trabajamos al 80% o al 90%?; ¿Está todo el mundo ocupado?) o la reducción del cycle time (Tenemos que tardar menos en desarrollar esta nueva feature) que en llegar antes el mercado con un MVP. Pero que todo el mundo siga muy ocupado.

Este vídeo lo explica muy bien:

Al final, esto se llama trabajo por lotes. ¿Te suena? Sí, esta es la base de PMBOK o Prince2. Trabaja por lotes que así serás más eficiente. Sin tener en cuenta que los lotes retrasan exponencialmente la salida al mercado y nos suponen una pérdida económica.

Métricas circunstanciales vs Métricas directas

El peligro de enfocarse en estas variables circunstanciales es que éstas interactúan unas con otras.

Mejorar la utilización de la capacidad de trabajo disponible tiene el efecto beneficioso de mejorar la eficiencia y el efecto negativo de incrementar el cycle time.

Para entender el impacto neto, hay que comprobar ambos efectos. Para hacerlo, hay que expresar los cambios de todas las variables proxy en la misma unidad. Esta unidad es life-cycle profit impact, que es la última medida de éxito en el desarrollo de productos. Si quieres leer más sobre esto, puedes hacerlo en el libro Lean Product Development Flow de Don Reinertsen.

¿Cuándo debemos mover un ticket en Kanban?

Una pregunta común en torno a Kanban es: ¿Qué hago con un ticket que está en la columna testing pero necesita trabajo de desarrollo porque he encontrado un bug?

La respuesta es muy sencilla. En el método Kanban, los tickets están en la columna que mejor refleja el estado dominante en el que se encuentra. En el caso anterior, el ticket se quedaría en la columna de testing hasta que el desarrollo esté resuelto.

Es importante recordar que en el método Kanban organizamos el trabajo y permitimos que las personas se autoorganicen alrededor del mismo. De esa manera, los desarrolladores no trabajan exclusivamente en la columna desarrollo y los testers en la columna testing.

Lo que ocurre es que el equipo, durante el Daily Meeting de Kanban, analiza el tablero que visualiza el trabajo en curso e identifica cuáles son los impedimentos que impiden que el trabajo fluya y deciden cuál va a ser su plan durante 24 horas para hacer avanzar el trabajo.

¿Y cómo se toman estas decisiones? Pues en base a dos criterios:

  1. El primero es el valor de los elementos que pueblan nuestro tablero, que estarán reflejados en una clase de servicio. La clase de servio indica el cost of delay, que actúa como indicador económico del valor del ticket.
  2. El Segundo es el lead time. Trabajando con la asunción de que cuanto más tiempo tardemos en entregar, menos retorno obtenemos, buscamos siempre elementos de alto valor y a la vez reducir el Lead Time.

De esta manera, el sistema Kanban es un espacio de autoorganización que permite la mejora de los procesos de una manera muy eficiente.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad