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.
