El problema de medir la productividad del equipo

Escenario

Algunos managers intentan medir la productividad del equipo para saber si lo están haciendo bien y si están mejorando. Cuando se habla de KPI, entonces se trata de hacer seguimiento de algunos valores y poder reaccionar. Jefes de proyectos tienen la necesidad de intervenir cuando las cosas no están andando bien, y sobre todo, quieren ser siempre más productivos. El problema es que esto no es tan fácil, o puede ser hasta imposible.

Podemos entender al desarrollo de software como un sistema que recibe información (entrada) y con un proceso en algun tiempo produce un resultado (salida). ¿Qué tan productivo es este sistema ? y sobre todo ¿Es mejor o peor comparado con que?

El problema es exactamente el de encontrar un KPI que sea adecuado y que traiga las respuestas al manager que está siguiendo el proyecto. No hay un KPI que pueda exactamente medir la productividad directamente. Veamos algunos ejemplos.

El problema de medir las variables de entrada

Algunos consideran que las horas trabajadas puede ser un indicador de productividad. Este KPI se deriva de pensar que un equipo que trabaja poco es poco productivo, mientras que un equipo que trabaja muchas horas es muy productivo. Por el contrario, es posible dar mucho valor al cliente, tras completar un task muy fácil, pero importante. Así, el equipo fue muy productivo trabajando poco. En realidad este es el peor KPI posible. De esta manera, las empresas se llenan de equipos que trabajan mucho y no producen nada. Las horas trabajadas son un indicador de costos, pero no de productividad. De hecho, productividad es hacer más, en menos tiempo.

De manera análoga, podríamos considerar la cantidad de task completados como indicador, ma como resultado, se conseguirian muchos task terminados de baja calidad, solo para llegar a una fecha deadline como objetivo. Resulta que aquí el objetivo de los programadores no es agregar valor al software, sino cerrar el task independientemente del estado. 

El problema de medir las variables de salida

Si entonces los indicadores de entrada no funcionan se podrían medir los indicadores de salida. Estos son la cantidad de líneas de código producidas o la cantidad de commits. De nuevo, estos no son KPI’s válidos puesto que no son comparables en el tiempo o entre un programador y otro. 

Evaluar a un programador por la cantidad de de commits, generará como resultado commits más frecuentes y más pequeños, con menos valor. Medir la cantidad de líneas de código producidas podría afectar al modo que un programador escribe su código en función de las líneas, pero no de su calidad.

El problema de todas estas métricas, es que hacen perder el foco sobre el verdadero objetivo, que es agregar valor al cliente y tenerlo satisfecho. Le estamos diciendo a los programadores que serán evaluado por las métricas y ellos responderán en función.

El efecto cobra

Agregar métricas para medir los resultados puede generar (y de hecho generan) el resultado opuesto. 

Las malas métricas hacen que el objetivo se concentre en la métrica misma y alejan al programador del objetivo real, que debería ser siempre el de añadir valor al cliente o al producto.

El nivel de la medición

Todas las métricas anteriores están definidas a nivel individual, sin tener en cuenta el grupo, la sinergia, factores humanos ni tampoco el contexto o factores externos. Las métricas anteriores, no tienen en cuenta que estamos hablando de personas que trabajan en grupo.

Si bien considero que escribir código está más cerca de la ingeniería que del arte, el proceso no es lineal o matemático. Muchas cosas emergen durante la escritura del código que pueden afectar los tiempos de desarrollo (como el débito técnico, dificultades no previstas, o simplemente un algoritmo que era más difícil de lo planeado).

Algunos frameworks de procesos de desarrollo como agile, sugiere medir los resultados en términos de grupo, preguntandose “Està el equipo entregando software de valor?”. Esta pregunta, desgraciadamente para quienes intentan medir la productividad, está orientada hacia la dirección que debe tomar el equipo y no sobre la eficiencia. Igualmente, “generar valor” no es algo discreto que se pueda medir directamente, sino que interviene la opinión, sentimientos y emociones del stakeholder que da el feedback.

Aquí se introduce el concepto de “Velocity” que intenta medir qué tan rápido se puede llegar a producir durante un sprint. Como consecuencia, se agregan reuniones para intentar medir (en puntos de fibonacci u otro método) el valor de cada task. Como contra respuesta, los programadores tienden a sobreestimar las tareas que tienen delante. Los puntos de velocity intentan ser algo objetivo, pero están basados en la definición de puntos de fibonacci que son subjetivos. Entonces, no puede ser considerado un KPI, visto que va en contra de la propia definición de KPI.

Conclusion

No existe una manera directa y objetiva de medir la productividad de un equipo. Agregar métricas, generalmente entorpece el cumplimiento del objetivo. Quizás deberíamos preguntarnos por qué queremos medir la productividad y qué haríamos si lo lográramos.

Producir software se trata de un negocio, y quizás sea mejor centrar los esfuerzos en entender si el cliente está contento, y recibir feedback para saber si ambas partes están alineadas.