Muchos equipos de desarrollo han sufrido los intentos de medir la productividad de sus programadores. Ya sea con cualquier métrica que el manager responsable haya decidido o con algún plugin instalado en el gestor de tareas que arroje números sin ningún contexto. Todo ello, con la buena intención de saber la velocidad del equipo, aunque a veces se desvia hacia dónde pierden el tiempo los desarrolladores.

Pocos programadores acaban confiando en esas métricas, incluso son el principal foco de frustración, donde se valora la cantidad en lugar de la calidad o el impacto del producto que se está desarrollando.

En Genbeta

12 cosas que destruyen la productividad del desarrollador

¿Qué pasa si implantamos una métrica donde premiamos el número de tareas cerradas?

Lo más habitual es que el equipo se enfoque en resolver los tickets más fáciles, contestando y resolviendo los bugs que menos tiempo le llevan con la única motivación de engañar a las estadísticas. Es como cuando nos dan un tirón de orejas y de repente estamos super atentos y serviciales para todo.

Aunque las métricas indican que el equipo está trabajando en la línea acordada, la calidad del producto o el alcance de los nuevos desarrollos empeora. La realidad es totalmente distinta a los números.

Obviamente, esto conlleva que los programadores no confíen en esas métricas, mientras se incrementa la deuda técnica: reutilización de código con la intención de aumentar el número de líneas, …