Productividad y programadores


Llevo observando desde hace tiempo, exactamente desde el año 2010,  cierto descontrol o desconocimiento en cuanto a cómo conocer si un programador/a es productivo cuando esta trabajando dentro del seno de una empresa.

En sí, es un  aspecto bastante difícil de medir debido a cómo se utilizan las herramientas dentro de las empresas de nuestro sector, el informático. Lo normal es usar los controles de versiones como git, team foundation server o plastic scm, solamente cuando la tarea que estamos desarrollando esta terminada, es decir, los pasos habituales suelen ser:

  1. Bajarse el código completo o la parte que vamos a modificar
  2. Modificar o crear nuevo código y probarlo
  3. Cuando todo esta listo, subir la versión al control de versiones correspondiente.



De la manera anterior suelen pasar semanas enteras resumidas en una sola tarea dentro de nuestro control de versiones, entonces, cómo podríamos medir la evolución o la forma de trabajar de nuestros programadores. Esa es una cuestión que me llega rondando la  cabeza desde el año pasado y ante la cual se me ocurrió  una sencilla solución que poco a poco iremos desarrollando en Mi Alejandría.

Básicamente si pudiésemos registrar diariamente  como codifican nuestros programadores, podríamos llegar a saber sus hábitos de programación, sabiendo que días de la semana son mas productivos podríamos programar nuestras reuniones para los días de menor producción. 
Podríamos conocer si un programador/a codifica todos los días o es productivo de forma cíclica, me explico, existen programadores que en un día codifican 500 lineas de código que no deben ser corregidas en meses y otros que para hacer lo mismo codifican y lo modifican durante una semana para llegar a ese grado de calidad, pero por desgracia pensaremos que el primero es un vago y el segundo es super-productivo.

Otro elemento importante es la calidad del código, a este respecto, debe preguntarse cuanto tiempo gastan sus programadores arreglando código ya escrito antes, lo ideal es codificar fragmentos o métodos que perduren en el tiempo lo máximo posible, porque eso indicara que nuestros gastos en mantenimiento y pruebas serán menores.

Desde hace tiempo la solución ronda por mi cabeza y a raíz de ello también los posibles problemas generados al guardar toda la información adicional (hacer guardados de versiones diarios por cada programador/a). También para el tema del almacenamiento se ha generado una solución que estamos desarrollando.

Comentarios