Ahora que he terminado el sprint de CProject, he publicado su página web y he tenido tiempo para responder unos cuantos emails, voy a hablaros de un tema que tarde o temprano sale en la empresa: la productividad.
Este es un tema muy complejo, no hay más que ver los más de cuatro millones de resultados de búsqueda que salen en Google. Y es que medir la productividad no es tarea fácil.
Planning Poker - Poker face
Os voy a contar una historia verídica que me sucedió en un proyecto:
Hace un tiempo, teníamos que entregar un proyecto y para calcular el tiempo en el que se realizaban las tareas usábamos cartas scrum o planning poker. Para el que no lo conozca este método consiste en que cada miembro del equipo elige una carta que simboliza el tiempo que cree que va a tardar en realizar la tarea. Cuando todo el mundo tiene elegida su carta hay que darle la vuelta a la vez. Si los programadores tienen experiencia los valores normalmente son muy parecidos. El problema surge cuando los valores de las cartas varían de forma significativa.
En mi caso el equipo estaba formado por tres personas, de las cuales dos evaluamos la tarea en unas 8 ó 13 horas y uno la evaluó en 2 horas. Según mi experiencia esto es un problema, ya que la magia no existe. Desde mi punto de vista esto significa que el programador tiene un as en la manga o hay algo que se nos escapa a los demás. Así se lo hice ver al jefe de proyecto en una reunión posterior.
Evidentemente esa tarea fue asignada al programador de 2 horas, y para mi sorpresa la acabó en dicho tiempo.
Cuántos de vosotros os habéis sentado delante del monitor nada más llegar al trabajo y os habéis puesto a leer el periódico, twittear, leer blogs, etc. Cuando estaba en Viavansi un compañero me enseño el método Getting Things Done (GTD). Al principio me costó establecer mi rutina, ya que es fácil distraerse, pero una vez acostumbrado es una manera genial de establecer los objetivos del día. No hace falta una aplicación compleja para seguir el método. Mi amigo usaba OpenOffice con unas plantillas que se había hecho. Yo posteriormente conocí wunderlist y doit.im, fantásticas herramientas de organización. Desde que me acostumbré me di cuenta de que esos 5 ó 10 minutillos que se perdían en leer el periódico eran los mejores para organizar el día.
En muchos de los resultados de google aparece una formula de productividad del empleado tal como:
Productividad = (Productos o servicios producidos) / (Recursos Utilizados)
Esa a simple vista parece una buena forma de medir la productividad.
Developer troll
Cuando mi compañero entregó la tarea, no puedo negar que me quedé perplejo. Evidentemente fue felicitado por los jefes y a los demás se nos puso como ejemplo de empleado productivo. Incluso llegué a plantearme mi forma de hacer las cosas, ya que había fallado por muchas horas, casi en una jornada laboral. Y esto cuando un proyecto va muy justo de tiempo es importante.
El tiempo pasó, el proyecto avanzó tres o cuatro meses y próximo a una entrega me tocó integrar la parte de mi compañero con una que había realizado yo y optimizar un “problemilla” (así lo llamó mi jefe) ya que la aplicación se bloqueaba aleatoriamente. En ese momento encontré la trampa.
Resulta que tanto mi compañero como yo cuando evaluamos la tarea lo que hicimos fue pensar en la futura integración, las clases que hacían falta, el patrón de diseño a seguir, etc., planteando el desarrollo para no tener futuros problemas. Pero la persona que había hecho la tarea en dos horas, directamente “se había pasado todo esto por el forro”. No solamente esto, sino que me encontré con que muchos de los problemas que estaban ocurriendo eran debidos a ese código, ya que la aplicación tenía concurrencia y esto era lo que producía los bloqueos. Por no mencionar las malas prácticas de programación, ausencia de VO y pojos, todo devuelto en maps con maps en su interior, que a su vez tenían maps en su interior, y un etcétera para ahorrar tiempo.
Genius boss
Cuando hablé con mi jefe el cabreo fue enorme, pero para mi sorpresa cayó sobre mí, ya que él sigue la filosofía de El último que lo toca es el que lo ha roto. Con lo que hubo que hacer muchas horas extras con malas caras.
Volviendo al tema del post, en mi opinión medir la productividad del trabajo de otro es muy complicado. Con técnicas como GTD medir si el día de uno mismo ha sido productivo es fácil, pero medir el del compañero es muy complicado si el proyecto tiene una duración de meses. Si un proyecto sale bien se sabe que ha sido productivo, pero si un proyecto sale mal, o no ha sido tan bueno como se pensaba en un principio que iba a ser es una tarea complicadísima saber quien fue productivo y quien no (obviamente dentro de un entorno en el que todos son profesionales).
Y es que en mi opinión la productividad no se debe medir por tareas concretas, sino que haría falta añadir una variable más a la fórmula de manera que se midiera la productividad a lo largo del tiempo. O lo que es lo mismo, que el trabajo entregado no deje de funcionar a los X meses.
Hay que ser conscientes de que en programación no todo vale. Los patrones de diseño están para algo, no se debe abusar de ciertos tipos de datos, y una serie de normas que cualquier persona con sentido común y experiencia no debe olvidar.
Un amigo decía: Si empleo más de 20 minutos en leer un código propio que escribí hace meses y no lo entiendo, es que el código no era bueno. Creo que no hay que ser tan drástico, pero en términos generales estoy de acuerdo.
Saludos.
