Muchos directivos están de acuerdo en que indagar en los datos del flujo de trabajo de ingeniería puede parecer invasivo. Al mismo tiempo, muchos ingenieros se muestran naturalmente escépticos ante las métricas, malinterpretándolas como una forma de controlar o microgestionar la producción. En la mayoría de los casos, suele deberse a que los propios datos se interpretan o manejan mal, o a que el tipo de datos simplemente no arroja luz sobre la verdad en su conjunto. La clave para mantener la confianza de tu equipo y fomentar una mayor sensación de autonomía no reside en si tienes acceso a los datos, sino en cómo los utilizas.
Medir un proceso humano complejo no es fácil, ni sistemáticamente preciso. Aun así, con una aplicación meditada y las herramientas adecuadas, los líderes de ingeniería pueden utilizar las métricas de ingeniería para mejorar la eficacia, crear una cultura de trabajo positiva y establecer prioridades claras. Estos datos pueden proporcionar una base concreta para conversaciones productivas, y ayudar a los equipos de ingeniería a maximizar su impacto.
He aquí algunas de las mejores prácticas para utilizar los datos de forma transparente y constructiva.
1. Una mejor métrica es sólo el principio
Las buenas métricas se basan en mediciones objetivas. Pueden evaluar con precisión la línea de base de tu equipo, medir el progreso entre equipos y proyectos, y realizar un seguimiento del estado del proceso a lo largo del tiempo. También te permiten establecer objetivos procesables para los desarrolladores de software e impulsar el alto rendimiento de tu equipo.
Sin embargo, “objetivo” no es lo mismo que “bueno”. Las líneas de código (LOC) son una métrica objetiva. También es una forma horrible de cuantificar las contribuciones de los desarrolladores, ya que mide el volumen en lugar de la calidad o el impacto.
Además, no todas las métricas objetivas son igual de útiles para todos los equipos y situaciones. Los líderes que buscan aumentar la eficiencia pueden querer hacer un seguimiento de una métrica de velocidad como el Tiempo de Ciclo. En cambio, los que buscan optimizar la colaboración podrían fijarse en métricas de revisión de código como la Velocidad de Revisión o los Ciclos de Revisión.
También puede ser útil examinar conjuntamente métricas complementarias: medidas de velocidad y calidad, por ejemplo, para asegurarte de que una no se resiente mientras intentas mejorar la otra.
2. Utiliza los datos con responsabilidad
Al aprovechar los datos, es importante ser transparente, abierto y constructivo. Tu equipo debe entender qué estás midiendo y por qué, así como quién puede ver qué datos. Debes implicar a tu equipo en los debates sobre qué medir y a qué objetivos aspirar.
Si los datos no cumplen las expectativas o suscitan algún tipo de preocupación, es importante que trabajes con tu equipo para comprender los puntos débiles, abordarlos y crear resultados positivos.
Los datos nunca deben utilizarse como base para tomar medidas punitivas. Es esencial que los miembros del equipo se sientan seguros diseccionando y aprendiendo de los problemas, en lugar de preocuparse de que se les castigue si no alcanzan una cifra arbitraria.
3. Añade siempre contexto
Las mediciones sólo cuentan una parte de la historia, y todos los datos deben situarse siempre en su contexto. Si una métrica determinada tiende en una dirección preocupante, es fundamental hablar con tu equipo y determinar exactamente por qué. Puede haber una buena razón y, si no la hay, comprender la causa raíz facilitará la resolución del problema.
Por ejemplo, uno de nuestros jefes de equipo se dio cuenta de que sus desarrolladores remotos tenían un tiempo de ciclo mucho mayor que sus compañeros presenciales.
Si nos fijamos sólo en esa métrica, sería fácil suponer que los desarrolladores remotos tenían que ponerse al día o mejorar. Sin embargo, con más contexto, surgió una verdad muy distinta.
Durante las sesiones de coaching 1:1, se enteró de que el verdadero problema eran las pull requests inusualmente grandes. Los desarrolladores remotos no estaban atascados ni trabajaban menos: simplemente se habían desalineado con las mejores prácticas del equipo sobre el tamaño de las relaciones públicas.
4. Deja atrás la culpa
Las métricas te dan una visión del trabajo, no de los propios desarrolladores. Un ingeniero que avanza lentamente en un proyecto podría estar teniendo dificultades, pero también podría estar trabajando en un problema complicado que requiere una cuidadosa consideración.
Los indicadores adelantados son una señal de alarma: hacen saber a los líderes de ingeniería cuándo hay un riesgo o algo que merece ser investigado. Este tipo de datos puede utilizarse para impulsar las conversaciones y las decisiones, permitiendo a los líderes dar una retroalimentación significativa y procesable con una comprensión basada en hechos de lo que está sucediendo.
Los datos importan
Los datos de ingeniería pueden revelar mucho sobre la salud y la eficacia de tus procesos de desarrollo de software. Pueden ayudarte a entrenar a tu equipo, evaluar los progresos e intervenir antes de que los pequeños problemas se conviertan en grandes trastornos.
Pero para aprovechar los beneficios de los datos de ingeniería, debes utilizarlos con responsabilidad. Como líder, tu éxito no se mide por tu rendimiento individual, sino por la salud de tu equipo y su colaboración. Los datos ganan cuando pueden aumentar o satisfacer las necesidades del equipo. Elige utilizar los datos para potenciar, motivar e inspirar el crecimiento profesional.