Estoy seguro que si has completado varios proyectos desarrollando una app o plataforma, vas a notar el fluctuante valor de las métricas. Si hablamos de un gestor de proyecto, puede ser el número de tickets finalizados, los puntos entregados en un sprint o la frecuencia en el lanzamiento del software.

Para el developer, puede ser el número de PRs que revisó o creó o el número de líneas de código que escribió. La meritocracia desciende si es que nos ponemos a analizar la performance de alguien. Es usual que en algunas empresas se definan metas profesionales a largo plazo, que se revisan una vez cada año y que impactan en compensación salarial.

Las métricas son un buen punto para partir y en especial si quieres tener una expectativa comparado a competidores u otros equipos. El problema comienza cuando se vuelven una adicción y un indicador de éxito para el equipo, lo cual no solo trae frustración y ansiedad, si no que últimamente puede crear un efecto “olla a presión” que termina decepcionando a líderes y managers.

Hablemos un poco hoy de la dependencia excesiva de las métricas y sus limitaciones.

🥇 Los frameworks y métricas actuales

Vivimos en una sociedad que mide las cosas. Indicadores de como avanzamos en nuestra vida, trabajo y finalmente, de nuestro nivel de éxito.

En equipos de software que son competitivos, las métricas son un must. Imposible que falten. Esto en particular se vio acrecentado en la pandemia donde las empresas, y al no interacción en oficina, tenían que tener algo de donde basarse para medir como los equipos estaban trabajando.

En la historia del desarrollo de software se han escrito “en piedra” varias métricas que hoy tomamos por sentado y que son difíciles de cuestionar. La velocidad del equipo (usualmente medido por puntos entregados en un sprint), la cantidad de código escrito, el número de releases y la cantidad de crashes que se reportaron en un tiempo determinado.

Varios estamos familiarizados con el concepto de agilidad en el desarrollo, de donde también se expanden técnicas como Scrum, Extreme Programming o Scaled Agile. Es común que si tienes un gestor de proyecto, utilice una variante de lo anterior. Lo común de estas es que debemos crear tareas o tickets a partir de un proyecto grande. Posteriormente puntuarlas y moverlas a través de estados.

Otro modelo que ha tomado fuerza es el llamado "DORA” (del inglés “DevOps Research and Assessment”). Este fue desarrollado por 7 años y posteriormente implementado por Google. Mide el desempeño de un equipo en base a 4 métricas: la frecuencia de release, el tiempo de recuperación después de un fallo, el tiempo de release de un cambio y la frecuencia de cambio con errores.

Como puedes notar, la diferencia entre “DORA” y por ejemplo Scrum, es que el primero asciende a variables que involucran otras áreas del desarrollo, y se acercan más a la calidad del software y felicidad del usuario final.

Estas métricas y frameworks sin duda entregan confianza a los equipos y otorgan dirección al momento de lanzar nuevo software, especialmente si este último se quiere que sea de calidad.

Pero, ¿qué limites se pueden encontrar al solo usar estas métricas?

✋🏻 La limitación de las métricas

El problema de contar con solo métricas es que estamos ciegos a otra situaciones que afectan la productividad y felicidad de un equipo. Déjame listarte algunas de ellas que tengo frescas en mi memoria:

• Peticiones o tareas informales para resolver tickets, que no están documentadas o no pasan por procesos establecidos
• Despidos o renuncias de miembros del equipo
• Estimación de tareas errónea o muy optimista. Se realiza trabajo extra sin que este “cuente” en un sprint.
• Falta o no existencia de investigación previa en tareas complicadas.
• Cambio de contexto en otras tareas (como cursos que el dev debe tomar) y exceso de reuniones.
• Situaciones de índole personal o profesional que afectan la salud del equipo.

Además de la lista anterior, una trampa que algunos líderes fallan es cuando aplican métricas destinadas a un equipo, pero a una persona específica. Es un error evaluar con las mismas métricas a un equipo y una persona.

Sinceramente, me produce un poco de cringe cuando escucho al gestor de proyectos felicitar al equipo porque entregó más puntos que el sprint anterior. No soy fan de la ilusión de productividad, ni tampoco de desvalorar el trabajo de un dev a 5 puntos cuando realmente invirtió 4 veces más de ese tiempo.

En mi experiencia, hay una desconexión entre el gestor de proyectos con métricas más duras, y el manager/líder que maneja otras dimensiones más blandas.

Lo cual me lleva a la siguiente pregunta…

📏 ¿Podemos contar con métricas más holísticas?

No todo está perdido, y si creo que podemos contar con un enfoque más holístico.

Obtener conclusiones de métricas es una tarea fundamental del líder. Y la pregunta que estos se deben hacer acá, junto a su equipo de liderazgo, es cuanta importancia y prioridad le dan a aspectos que no están relacionados necesariamente con métricas duras.

¿Por qué digo eso? Un equipo puede tener cientos de retros donde deja feedback. O reuniones 1:1 exponiendo situaciones que están bloqueando el avance del trabajo. Pero hasta que no se tome en serio y se añada a la cultura de esa empresa de forma permanente, esas métricas van a seguir determinado el futuro y progreso del software.

Un ejemplo interesante de un framework que presenta métricas más holísticas, es el modelo SPACE que se desarrolló en una universidad cercana a donde vivo (Universidad de Victoria). Es modelo propone que la productividad de un desarrollador se puede medir en 5 dimensiones extras: sanidad mental, performance, actividad, comunicación/colaboración y eficiencia.

Las métricas nunca van a decir la verdad al 100%, pero un líder puede ser pro activo e ir un paso más allá. Por ejemplo, pidiendo feedback a personas específicas, reconocer favoritismos entre miembros del equipo, despojarse de prejuicios respecto a sus creencias y estar abierto a re-evaluar métricas dependiendo de las metas a largo del equipo.

Por último, es importante poder visualizar las métricas duras y blandas. Usar una plataforma para crear reportes que entreguen transparencia al equipo sobre como lo está haciendo. Y al momento de encontrar una anomalía, ser honestos y resueltos en resolver la situación.

Te quiero dejar con algunas preguntas:

• ¿Cuál es una métrica que en tu experiencia no añade valor en el desarrollo de software?
• ¿Qué puedes hacer hoy para exponer más una métrica que no se está tomando tanto en cuenta?

🎧 Podcast

Me encanta tener conversaciones con personas empáticas y que les gusta ayudar al resto. Tadashi es eso y más.

Si te interesa la innovación, startups y el ambiente emprendedor, en este episodio vas a poder escuchar varias lecciones sobre la carrera y experiencia del invitado.

Tadashi ha estado constantemente observando los cambios de su ecosistema y explorando distintas facetas que saquen lo mejor de el. También, al detectar una falta de oportunidades para educarse sobre innovación y metodologías, fue que creó su canal de Instagram y LinkedIn, donde comparte tips y pequeñas cápsulas de conocimiento.

Nerd From Chile Podcast #26: Tadashi Takaoka

May 30, 2023

Listen now (66 min) | 🚨🚨 ALERTA DE CONCURSO 🚨🚨 Estoy muy interesando en conocer tu opinión sobre el contenido que estoy generando y los desafíos que tienes actualmente en tu vida laboral. Por ello, entiendo que tu tiempo es de mucho valor. Lo que tienes que hacer no te tomará más de 5 minutos.

Read full story →

💬 Quote de la semana

Esto alguna vez fue mi “talón de Aquiles”. Mi naturaleza prefiere decir que si y dejar contento a todo el mundo.

Rápidamente me fui dando cuenta de lo caótico que es eso. Por ejemplo y antes de entrar en una reunión, pensar en los pros / contras, rezar por un output específico para así no tener otra reunión con otro equipo, y explicar el porque de una decisión.

Mucho de ser auténtico tiene que ver con aceptar y estar tranquilo con lo que eres bueno y en donde no lo eres tanto. Para lo último, pensar en mejorar o simplemente delegar.

📰 Otras noticias y recomendaciones

• Ayer estaba leyendo el newsletter de una de mis autoras favoritas, Louise Penny, y hacía referencia al podcast de una de mis comediantes favoritas. Julia Louis Dreyfus (Elaine en Seinfeld). En ese episodio del podcast, Julia entrevistaba a Gina McCarthy, experta en todo lo relacionado al cambio climático y que actualmente trabaja en la Casa Blanca. Lo que me llamó la atención es la respuesta al a pregunta: ¿Cómo es posible que trabajes con republicanos y demócratas? (personas con intereses en el poder y algunas veces con opiniones y extremos opuestos). Spoiler: “Aceptar que es su show y siempre mantener el respeto”. Es una buena lección para aplicarla en el trabajo. Te recomiendo escuchar el episodio entero.
• Sigo activamente buscando feedback para el contenido que estoy creando. Si tienes 3 minutos ayúdame a responser esta pequeña encuesta. Tendrás mi eterna gratitud.

Disfruta lo que queda de jueves.

Yo me tomaré unos días de vacaciones y descanso, pero si o si nos hablamos la otra semana. 🏝️

Felipe

Cuéntame que te pareció esta edición:

• 👍 Motivador e interesante. Sigue así Felipe.
• 😐 Estuvo más o menos
• 👎 No me interesó para nada.