¿Consideras a los programadores cuando mides la productividad de tu proyecto software? Deberías.
Hoy en día existe una gran brecha entre la demanda de software y la cantidad de software producido, al pasar el tiempo la demanda de
productos software crece mucho más en comparación a años anteriores, esta realidad debe ser debidamente afrontada, sin embargo es casi imposible disminuir el interés hacia los productos software por parte de la sociedad, por ende, el estudio se centra en aumentar la producción de software mediante el aumento de la productividad de los programadores.
En la actualidad existen muchos estudios sobre los criterios que deben considerarse para una correcta medición de productividad, aun así no existe un valor único para realizar dicha medida. Muchos autores han mencionado que dicha productividad se encuentra fuertemente relacionada con los programadores que realizan el proyecto, sin embargo son pocos los estudios que se realizan acerca de dicho tema.
Con el fin de encontrar una forma eficiente de medir la productividad en cada uno de los programadores, es necesario conocer el punto de vista de los mismos y con esto poder responder dos preguntas importantes:
- ¿Cuando un programador siente que ha sido productivo?
- ¿Que criterios utiliza un programador para evaluar su propia productividad?
Se han realizados estudios acerca de la opinión de los desarrolladores de proyectos software acerca de este tema (para conocer con más profundidad como se realizaron estos estudios puede acceder al artículo de la referencia [1]), en dicho trabajo se ve reflejado que no existe una única métrica para medir la productividad de un programador, por lo cual podríamos afirmar que la productividad de los mismos debe realizarse de forma personalizada, sin embargo, existe una tendencia en las respuestas obtenidas por medio de una encuesta y un estudio de observación realizado.
En estos momentos responderemos las dos preguntas descritas anteriormente:
1- ¿Cuando un programador siente que ha sido productivo?
En la mayoría de los casos (según el estudio realizado mediante la encuesta), los desarrolladores indicaban que su día ha sido productivo si a lo largo de dicho día ellos han podido terminar una gran cantidad de trabajo (en el caso de trabajos pequeños), o han adelantado o terminado un trabajo grande.
Desde otro punto de vista, gran parte de los desarrolladores de software se sienten productivos cuando entran en un flujo de trabajo constante sin interruptores de contexto. Las interrupciones de contexto se refieren a los cambios de modo de pensar del desarrollador, por ejemplo, si un programador cambia de un código principal a otro que no se encuentran relacionados en su objetivo final y sin haber terminado el primero. Muchos cambios de tareas en un día de trabajo es productivo siempre y cuando no se cambie el contexto de los mismos o el cambio sea por poco tiempo. Cuanto más tiempo se pase en una tarea específica más caro sale dicho cambio de contexto.
Cuando ocurren interrupciones por las cuales los programadores deben esperar un tiempo para continuar avanzando en el código (ya que es imposible avanzar en ese momento), los desarrolladores indican que tareas pequeñas como mandar correo electrónicos, revisión de código entre otros, aumentan la productividad, ya que esto implica el aumento de tareas finalizadas.
2- ¿Que criterios utiliza un programador para evaluar su propia productividad?
Uno de los criterios más resaltados es la cantidad de elementos de trabajo o tareas finalizadas (dependiendo de la dificultad de los mismos) incluyendo corrección de código. De manera negativa, las interrupciones presentes a lo largo del día pueden afectar a la productividad, cuan perjudiciales son estas interrupciones varía mucho con respecto a la opinión de cada uno de los programadores.
También indican que para medir la productividad es necesario conocer algunos aspectos importantes como, la cantidad de tiempo que se dedica en código comparado con el tiempo que se dedica en reuniones o tareas personales en el trabajo, por otra parte, reconocen que es necesario saber cuan útil e importante es el trabajo que debe realizar el programador, indicando que cuanto más útil sea dicho trabajo para el equipo, más productivo es el programador.
Ya sabiendo todo esto, continuaremos explicando como algunas interrupciones afectan a la productividad de un programador.
- Reuniones formales: si las reuniones no tienen enfoque claro y objetivo, si lo participantes no están debidamente preparados o si dichas reuniones se realizan más de dos veces diarias, esta practica se considera improductiva, de lo contrario son productivas.
Concluyendo, responderemos a la siguientes preguntas:
1- ¿La medición de la productividad se está realizando de la forma correcta?
Considero que esto es difícil de reconocer, la medición de la productividad siempre incluirá aspectos muy subjetivos, por lo cual realmente dudo que en algún momento todos los investigadores del tema lleguen a un acuerdo con respecto a esto.
2- ¿Se toma en consideración aquellos factores que alteran la productividad del programador?
En la mayoría de los casos estos aspectos no son tomados en cuenta en su totalidad, sin embargo existen métodos de medición donde se considera la cantidad de trabajos realizado, clasificándolos en tareas grandes y pequeñas, lo cual incluiría uno de los aspectos que según los mismo desarrolladores es de mayor importancia para la medición de productividad.
3- ¿La productividad de cada programador en particular es proporcional a la productividad del proyecto?
Desde mi punto de vista, no necesariamente el aumento de productividad de un programador en particular indica un aumento en la productividad del proyecto completo, siempre debe tomarse decisiones observando de forma general aún cuando se hagan cambios a niveles más específicos, por ejemplo, si consideramos que las interrupciones por parte de los compañeros hacia un programador afectan negativamente a la productividad de dicho programador, entonces tendríamos que evitar por completo la interrupción entre compañeros, sin embargo, también es cierto, que dicha interrupción puede solucionar una duda que tenía el compañero permitiéndole avanzar en sus tareas, y posiblemente aumentando la productividad general del proyecto.
REFERENCIA
[1] A. Meyer, T. Fritz, G. Murphy and T. Zimmermann “Software Developers’ Perceptions of Productivity”
Roxana Rodríguez
