Midiendo la productividad sin renunciar a la calidad

Desde hace un tiempo, me viene rondando un tema que se anda solicitando en las empresas de software: la medición de la productividad.

Cuando hablamos de software y de código es tremendamente complicado sacar esta medición, y como bien dice Javier Garzas, muchos métodos que parecen típicos (como puntos función), no son del todo fiables en este ámbito.



La productividad, tiene que entenderse como eficiencia y efectividad en el trabajo. Entendiendo esto, tenemos dos grandes ramas donde apoyarnos.

La medición de la eficiencia se puede trasladar a eficiencia de recursos o de flujo.
A nivel de recursos, queremos mirar como maximizar la utilización de las personas, por lo tanto, lo ideal es observar las horas consumidas de esa persona, en concreto, en una tarea. Esto, tarea por tarea, nos dará el resultado de la eficiencia de ella, en el proyecto.

Si esta suma, la contrastamos con la estimación que se dio en la hoja de carga, nos encontraremos con una medición realmente eficaz de si estamos acertando o no. El resultado, nos proporciona un kpi de desvío, que es exactamente: diferencia de horas estimadas contra las horas consumidas, dividido por las horas estimadas.

Por ejemplo, si Pedro estima 5 horas una tarea, y consume 10, según este kpi, tendremos que Pedro cuenta con un -1, por lo tanto tiene una desviación importante sobre la estimación inicial.

Esta medida, a priori, puede parecer muy sencilla, pero si la asociamos al tiempo que tardamos en completar una historia de usuario, la cosa cambia. Para ello, usaremos Cycle Time, que es el tiempo desde que se empieza una tarea hasta que se termina.

Conseguir una mejora de este método cuya repercusión en los resultados sea mayor que la inversión económica realizada y, sobre todo, sin pérdida de calidad en el resultado final, debe ser el objetivo de cualquier empresa.

El punto más importante, es que no se debe de supeditar, bajo ningún concepto la calidad del software. De nada vale entregar antes y que el resultado sea peor, costándonos una inversión posterior y un esfuerzo, para solucionar los defectos y ajustar aspectos funcionales que hemos hecho a medias.

En relación a la eficacia, es el punto más complicado de medir. Para ello, necesitamos conocer en valor que estamos aportando a cliente y esto, en muchas ocasiones suele ser subjetivo y relativo.

Lo que si podemos medir es la cantidad de veces que los usuarios utilizan la funcionalidad, tanto a nivel de mapas de calor, con los clicks generados o investigando los logs o base de datos con las llamadas realizadas. A esto, si le sumamos formularios de feedback y petición de mejoras que se puedan añadir al backlog, nos darán información muy útil para medir este dato.


Estos valores, siempre se deben de medir a nivel de equipo de trabajo y no por persona y resulta una potencialidad de la mejora continua y de la cultura de calidad de las empresas que nos aportará positividad en los equipos y en las personas de nuestra organización.

No hay comentarios:

Publicar un comentario