Pages Menu
Categories Menu

Posted by on Mar 13, 2015 in General | 5 comments

El peligro de malinterpretar las métricas o KPIs en una empresa software.

Voy a empezar este post reconociendo algo. A mí, Ana, me encantan las métricas. Y no es irónico.

Aviso a navegantes, definición de métrica (tipo Wikipedia): “Una métrica es una medida cuantitativa del grado en el que un sistema, un componente o un proceso cumple con un determinado atributo. “

Y un “KPI es una métrica que la organización o el departamento ha identificado que de alguna forma predice el rendimiento en la empresa.”

Me gustan todo tipo de métricas. Soy una gran fan de establecer metas a conseguir, sacar acciones para lograr esas metas y obtener métricas útiles que puedan ayudar a visualizar si vamos progresando en nuestros objetivos o no.

Sé que obtener métricas, mantenerlas actualizadas e interpretarlas cuesta esfuerzo y tiempo, pero el esfuerzo invertido en las métricas que me gusta obtener (pensadas para ayudar a cumplir ciertos objetivos de la empresa, del equipo) facilita mucho las cosas después.

Estas métricas van desde mediciones de calidad de código, avance del equipo, errores detectados, etc. Lo importante para mí es primero, establecer un objetivo concreto a conseguir y segundo, pensar qué métricas pueden ayudarme a visualizar el progreso para mejorar en el caso de que vayamos mal.

Aquí me gustaría recalcar las palabras más importantes de esta última frase: objetivo, pensar, ayudarme y mejorar.

Me parece inútil y NO soy partidaria de sacar una métrica o un montón de métricas porque sí, sin tener en cuenta esas palabras.

Existe una línea muy delgada entre que una métrica sea verdaderamente útil y que se malinterprete y el equipo piense que sea un acto de control por parte de la gestión.

Por lo que he vivido, si un equipo piensa que con una métrica les estás controlando…mal asunto. Eso es que alguien en algún momento las ha utilizado para ese fin, o se le ha dado algún motivo al equipo para pensar así.

Y es que algo peor que sacar muchísimas métricas y que no sirvan para nada, es sacar métricas, KPIs, etc. y que se malinterpreten a nivel de gestión. O mucho peor: malinterpretar métricas teniendo implantada una política de miedo y recriminación en la empresa.

Para mí, esto es muchísimo más perjudicial en el mundo del software que en cualquier otra disciplina, porque es complicado llegar a entender que el desarrollo de software es diferente del resto de disciplinas.

Hoy me gustaría ponerte algunos ejemplos de malas interpretaciones de métricas, con las típicas respuestas de managers que están a favor de la política del miedo (recriminar errores, desmotivar) y en su lugar, cuál creo que debería ser la actitud ante ese resultado, en una cultura de empresa más sana.

– Cuanto más líneas de código haga un desarrollador, más productivo es.

ERROR. No tiene por qué, incluso podría darse el caso de que esa funcionalidad que el programador está desarrollando pueda hacerse en menos líneas, con un mejor diseño y calidad. Puede también que simplemente el desarrollador en ese momento no tenga la experiencia ni el conocimiento necesario para desarrollar esa funcionalidad mejor, porque acaba de empezar a trabajar con esa tecnología hace muy poco tiempo. Sin contexto, no puedes saber nada.

POLÍTICA DEL MIEDO: Establezco un mínimo de líneas al día y quien no desarrolle ese mínimo no es productivo, pudiendo llegar a echarle por mal rendimiento.

MEJOR ENFOQUE: Muchas gracias, amigo política del miedo, te estás cargando la calidad del software, fomentando que los desarrolladores implementen más líneas de código de las que necesitan realmente. Como he dicho antes, en este caso, necesitas más contexto.

– Si tenemos 1000 casos de prueba definidos para un software y ejecutamos el 100%, podemos asegurar que el software no va a fallar.

ERROR. No te bases solamente en el número de casos de prueba ejecutados para saber las garantías de una subida a producción. ¿Se ha definido un buen plan de pruebas? ¿Tenemos detectados los riesgos? ¿Se han probado los componentes afectados por los cambios en el código y los componentes dependientes de ellos? Solo por ponerte algunas más preguntas a plantearte.

POLÍTICA DEL MIEDO: Si hemos ejecutado un 90% o cerca de un 100% y falla algo en producción, es culpa de los testers, que no han hecho bien su trabajo.

MEJOR ENFOQUE: Echa el freno. ¿Ese fallo encontrado estaba cubierto en el plan de pruebas? Si es que no, ¿por qué no estaba cubierto? ¿Era un caso muy concreto, donde es difícil recrear las condiciones adecuadas de testeo? ¿No se incluyó ese riesgo en el plan de pruebas porque no se notificó que se modificaría código que afectara a esa sección? ¿Durante el testing el entorno era inestable? ¿Cómo podemos evitar que vuelva a pasar eso?…

– El proyecto va con retraso. Si queremos ir más rápido necesitamos más gente, y ya mismo, en menos de 1 semana tienen que estar trabajando.

ERROR. Está demostrado que esa actitud en un proyecto software incluso puede llegar a retrasarlo aún más (Recuerda el post de Las bases de la gestión de proyectos software y los mitos del «hombre-mes»).

POLÍTICA DEL MIEDO:

Dependiendo de la situación y del número de personas incorporadas al proyecto, pueden pasar dos cosas:

– Que el proyecto se retrase más -> “Esta gente son unos vagos”.

– Vaya, parece que la cosa no va tan mal -> “La solución a cualquier problema es añadir más gente.”

MEJOR ENFOQUE:

Analicemos la situación detenidamente.

– Que el proyecto se retrase más -> ¿Los nuevos han retrasado a la gente del proyecto, porque han tenido que formarlos? ¿Han generado fallos por ser nuevos y no conocer bien el proyecto? ¿No tenemos una buena política de incorporación de personal (me refiero a formación, mentoring por parte algún perfil senior, etc.)? ¿Por qué hemos tenido que llegar a la situación de retraso? ¿Cómo hacemos para evitarlo la próxima vez?

– Vaya, parece que la cosa no va tan mal ->¿Realmente la cosa ha ido bien, o tu equipo ha tenido que estar echando más horas extra de las que tiene el día, fines de semana incluidos? No, trabajar todos los fin de semana no es sano, ni productivo. Merma la motivación del equipo, y más si por ejemplo nadie se lo agradece personalmente ni cobran adecuadamente por ello. Recuerda que la gente tiene vida personal además del trabajo.

– Antes desarrollaban a un ritmo de X funcionalidades por semana y el ritmo está empezando a decaer.

POLÍTICA DEL MIEDO: Como está decayendo el ritmo de desarrollo, significa que los desarrolladores no tienen suficiente presión de trabajo, están ociosos y relajados. Démosles más trabajo.

MEJOR ENFOQUE: ¿Realmente los desarrolladores son tan vagos como parece? ¿Por qué decae su productividad? ¿Hay algo que les desmotive? ¿Han tenido muchas reuniones esa semana, con lo que no han podido desarrollar? ¿Muchos bugs críticos que solucionar? ¿O es que la deuda técnica acumulada en el software es tan grande que ya está empezando a frenar la productividad del equipo?

Terminando…

Las métricas pueden ser muy buenas y ayudar muchísimo a mejorar una empresa.

Algunas organizaciones con una cultura sana son capaces de obtener muchísimas métricas, pero no utilizan los resultados para tomar medidas de vigilancia, ni de imposición. Ese no es el objetivo.

El objetivo de las métricas es detectar problemas, darles visibilidad y solucionarlos.

No te olvides de que una métrica sin contexto cuando tratamos con personas y software, en muchas ocasiones, no es más que un número.

Ana M. del Carmen García Oterino

Ana M. del Carmen García Oterino

Ingeniera Software QA at BQ
https://www.linkedin.com/in/amgarciao

Apasionada por la calidad del software (procesos, producto y equipos) y buenas prácticas en general.

Especializada en testing, automatización de pruebas e integración continua.
Ana M. del Carmen García Oterino

5 Comments

  1. Muy buen post, soy estudiante de Ingenieria de Sistemas en Ecuador, y siempre estoy atento a sus publicaciones, le queria pedir un favor, a breve sintesis, si podria ayudar a entender la metodología del SRUM, y por que es muy recomendada en algunas empresas de desarrollo

  2. «¿Realmente los desarrolladores son tan vagos como parece? ¿Por qué decae su productividad? ¿Hay algo que les desmotive? ¿Han tenido muchas reuniones esa semana, con lo que no han podido desarrollar? ¿Muchos bugs críticos que solucionar? ¿O es que la deuda técnica acumulada en el software es tan grande que ya está empezando a frenar la productividad del equipo?»

    –> Muy muy muy muy muy buena.

  3. Excelente post. Ahora me surge la pregunta, Cuales serian buenas metricas o KPI para un departamento de Programacion??

  4. Me ha recordado un artículo que leí hace unos años (y con cuya opinión he estado más o menos alineado):

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This