~ 6 min de lectura

📐 Métricas I: Introducción y opinión

¿De que manera podemos medir la productividad de un equipo de desarrollo? Por otro lado, ¿deberíamos hacerlo y para que?.

¿De que manera podemos medir la productividad de un equipo de desarrollo? Por otro lado, ¿deberíamos hacerlo y para que?.

Este es el primero de una serie de posts dedicados a las métricas o frameworks utilizados para solucionar una de las cosas que preocupa más a nivel tech: La productividad de un equipo. En los últimos años en los que muchas startups han escalado muy rápido, una de las principales preocupaciones siempre ha sido determinar como de bien están funcionando los equipos a nivel de delivery y desarollo.

En esta serie, escribiré sobre:

  • Que son las métricas y como deberíamos tenerlas en cuenta en los equipos.
  • DORA Metrics & Framework
  • SPACE Framework
  • DevEx Framework

⚔️ Métricas, un arma de doble filo

Cualquier métrica será útil o totalmente nociva en función de como se use y en que contexto. Concretamente toda métrica debe ir asociada a un contexto, su elección debe ir asociada a un motivo o un objetivo el cual se logra discernir gracias a esa métrica. Incluso las más aceptadas o usadas, por si solas como valor numérico no te van a permitir accionar nada sin un contexto sobre el que interpretarlas.

Por otro lado, creo que hay una obsesión por medir esa productividad y sinceramente, no creo que tengamos motivos e incluso me atrevería a decir que no tenemos derecho a medir la productividad de los equipos de desarrollo como tal. El concepto de métrica nace de un afán por medir la productividad en los entornos industriales. Una productividad fácilmente medible en entornos en los que producir algo consiste en seguir una serie de pasos hasta lograr un producto. En estos casos tiene sentido.

Sin embargo, en el desarrollo, nuestro trabajo es ciertamente creativo, no hay una fórmula mágica que apliques siguiendo unos pasos y tengas un producto exitoso, hay buenas prácticas, pero aplicarlas no es garantía de éxito en tu producto, es garantía que si tienes éxito, podrás escalar. En nuestro entorno, en el que tratamos de ser ágiles y adaptarnos a un mundo que cada minuto que pasa es distinto debemos ser creativos. Si me permitís, aunque suene atrevido, los desarrolladores somos artistas, creativos que generan soluciones a problemas que existen o incluso ni existen y vamos un paso más allá.

Dicho esto, ¿Por qué sentimos la necesidad de medir dicha productividad cuando no se hace lo mismo con un artista? ¿Como se mide la productividad de un pintor? ¿Tener una galería mayor de cuadros es garantía de éxito? Para mi es sencillo, esas medidas no son justas, muchas veces son utilizadas para justificar temas económicos o financieros, justificar recortes o inversions. En realidad, deberían utilizarse en beneficio de los equipos no en su contra. El establecimiento de estas métricas suele someter a una carga de estrés a los equipos, forzándose para lograr cumplir esos números o bien los equipos buscan la forma de batir la métrica, encontrar el vacío legal para romperla o superarla. En cualquiera de los dos casos, hay un problema. En algunas ocasiones se trata de una mala comunicación. En otras, es motivo de 🚩 red flag.

El tema de las métricas y el afán de medir la productivadad de los equipos de desarrollo se ha vuelto a poner en boca de todos desde la pandemia en la que todos los entornos empezaron a considerar como medir el cambio de paradigma, como afectarían todos los cambios que se estaban dando en el delivery de sus equipos debido al trabajo remoto, la situación socio-económica y sanitaria. Las tan conocidas DORA no eran suficiente y se comenzó a pensar en otras opciones.

👨‍🔬 Métricas vs frameworks

También quiero dejar claro en este primer post, que debemos diferenciar entre métricas concretas y frameworks. Las métricas no son más que conceptos que medimos, que sin contexto no son más que números sin sentido. Un framework es una guía de como una serie de métricas, las cuales no debes aplicar todas ellas, pueden establecerse y usarse bajo determinado contexto para entender como está un equipo y que accionar para llegar al punto que se quiere. Uno de los errores más comunes es coger un framework y aplicar todas las métricas. Un framework es un marco de trabajo, como su traducción indica, un simple resumen de ideas, conceptos y relaciones para que en base a tu contexto, tu entorno, tus equipos, puedas seleccionar un conjunto de métricas que puedas interpretar para saber si el equipo está donde debería estar.

Frameworks y métricas son herramientas para resolver un problema pero no son la solución.

🧰 Su utilidad

  • Gestión bottom-top: Ayudan a quien no está con el equipo a entender lo que está haciendo, como lo está haciendo y el impacto que tiene.
  • Gestionar el equipo: como funciona el equipo y donde actuar. Para mi la principal.
  • Gestionar tus stakeholders: Ayudan a demostrar en que se está focalizando el equipo y para quien o que: features, bugs, refactor, etc. Útiles para poder tener conversaciones en lugar de discusiones.
  • Gestionarte a ti mismo: tener visibilidad te ayuda a poder focalizarte en lo que realmente importa al equipo.

⚠️ Elige con cuidado

Las métricas crean incentivos. Los incentivos crean comportamientos. Los comportamientos crean cultura. Lena Reinhard

Las métricas provocan comportamientos en determinada dirección, te guste o no y esos comportamientos acaban impregnandose en la cultura del equipo u compañía. Aquello que midas es un reflejo de en lo que te vas a fijar como líder, remarcan lo que es importante para tí y por ende hace que los equipos miren en esa dirección. El equipo reaccionará a esa métrica con un comportamiento, ya que saben que se les está midiendo y por tanto se van a comportar de forma acorde para cumplir esa métrica. Si mides el número de líneas de código, el equipo producirá más, lo cual no significa de más calidad.

Finalmente, esos comportamientos acabarán impregnando la cultura del equipo y por ende de la compañía.

🤓 Consejos

Algunos consejos que he recopilado y me parecen útiles:

  • No te centres en una sola categoría. Mide eficacia y eficiencia.
  • Equilibra las métricas para evitar incentivos erroneos.
  • Se justo con la complejidad técnica, no trates de preguntarte porque un desarrollo está llevando más que otro. No tiene sentido. Cada desarrollo es un mundo.
  • Mezcla métricas sobre el resultado esperado y sobre el camino hasta lograrlo.
  • Empieza fácil, métricas fáciles de medir y con gran impacto. Ya te centrarás en las complejas más adelante.
  • Transparencia al equipo, el equipo debe conocer en que se le mide.
  • Pocas métricas, compartidas y constantemente en revisión.
  • Las métricas son señales, no son el objetivo.

🛑 Cuidado con sus límites

  • Las métricas miden produticividad individual.
  • Medir pero no actuar sobre lo que se mide es inútil.
  • Las métricas no son objetivas, reflejan sesgos y objetivos.
  • Las métricas sin contexto son inútiles.

🧠 Conclusión

Bien usadas, un conjunto de métricas pueden elevar a tu equipo, tu producto y cultura. Pero mal usadas pueden acabar con ellos también. A la hora de elegirlas, planteate el tipo de líder que quieres ser para tu equipo. Usa las métricas para saber donde actuar y como ayudar/guiar más al equipo en el trabajo del día a día, pero no te quedes ahí, usalas para hacerles crecer.

📖 Recursos

📚 Accelerate

📚 Team Topologies: Organizing Business and Technology Teams for Fast Flow

📚 The Phoenix Project

📑 How Uber is Measuring Engineering Productivity