Hoy toca otro artículo protesta/queja/sugerencia. Si la semana pasada hablaba sobre la muerte del tipo de sistemas y de lo ineficiente que es dividir equipos en departamentos, hoy toca hablar sobre la imputación de horas.
Seguro que habéis estado en alguna empresa, en la que había que imputar las horas. Más o menos funciona así. Un desarrollador está asignado a uno o varios proyectos. De forma periódica, debe rellenar un parte de horas, definiendo por cada día, a qué tareas ha estado dedicado y cuánto tiempo ha utilizado en ellas. Dependiendo de la empresa, la frecuencia puede variar. Las hay que prefieren que el parte de horas esté al día, aunque no suela revisarse con esa frecuencia; otras prefieren que el parte de horas este terminado todas las semanas, para empezar la semana siguiente con una visión clara de los proyectos en marcha; o lo más típico, imputar las horas una vez al mes.
La verdad es que no es mala idea. Con este sistema podemos controlar las tareas, las desviaciones de tiempos, aprender para proyectos futuros o utilizarlo para facturar a un cliente.
El problema está en que generalmente todo el parte de horas es una mentira.
La mentira de las 8 horas
Si obligamos a la gente a imputar horas al minuto, ya estamos cayendo en la primera mentira. Si una jornada tiene 8 horas, es imposible que se trabajen completas. Nadie trabaja todas las horas de su jornada laboral. O al menos yo no conozco a nadie. La gente toma café, va al baño, se echa un cigarrito, o recibe llamadas personales. Es algo muy normal.
A veces “perdemos” tiempo ayudando a compañeros en tareas que no son nuestras. O el jefe nos hace una consulta, que nos hace despistarnos de lo que estamos haciendo. O si estamos en varios proyectos, perdemos tiempo cambiando de contexto, cuándo pasamos de un proyecto a otro.
Por tanto, ¿por qué obligamos a que cada día cuadren las 8 horas? Lo único que hacemos es falsear los datos.
La mentira de las horas estimadas
Los desarrolladores somos malos estimando horas. Hay que reconocerlo. O nos pasamos o no llegamos. Pero una vez las tareas están estimadas, se mira mucho en el parte de horas que no haya desviaciones.
Eso es algo lógico. Si detectamos una desviación, podemos buscar las causas de la misma. Quizá fuimos demasiado optimistas estimando. Es bueno registrarlo y aprender del fallo para la próxima vez que encontremos una tarea similar.
El problema es que los jefes tienden a usar el parte de horas para echar la culpa a alguien. Y ese alguien no tiene siempre la culpa.
Lo más gracioso sucede cuando se sigues trabajando en una tarea, pero te dicen que no imputes esas horas “para que el proyecto no se desvíe”. ¿Perdón? Que no imputes las horas, no quiere decir que el proyecto no este desviado. Solo es una forma de autoengaño.
La mentira de las horas estimadas RELOADED
Cuando la imputación de horas no se usa para aprender, si no para controlar, se da una situación curiosa: los desarrolladores alargamos las tareas para cuadrarlas con la estimación.
En el punto anterior hablaba de cuándo una tarea nos lleva más tiempo de lo previsto. ¿Pero qué pasa si nos lleva menos tiempo? Lo lógico sería reflejarlo en el parte y aprender de esa tarea para mejorar las estimaciones. Pero esto no es lo que sucede. Lo que hacemos es utilizar esa tarea para imputar horas de otra tarea.
Vamos, que si tengo una tarea en la que me voy a pasar por 4 horas, y otra en la que me sobran 8, está claro dónde voy a imputar el exceso. Al final las horas se compensan.
Y otra vez que estamos falseando los datos.
La mentira de las horas extra
Por desgracia en el mundo del desarrollo se lleva mucho lo de echar horas extra. Parece que la cosa empieza a cambiar con el desarrollo ágil, pero en general se tiende a estimar en una fase del proyecto demasiado temprana. Si a eso le unimos la necesidad de que la empresa gane proyectos -cosa que se consigue con precios bajos-, nos encontramos con que las horas estimadas son insuficientes.
Como es lógico, al final los desarrolladores acaban palmando muchas horas de su vida para sacar el proyecto adelante. Y a la hora de imputarlo, eso no puede quedar reflejado. Si el proyecto se estimó en 40 jornadas, se imputan 40 jornadas. Y no más. Y supongo que como las horas no se imputan, tampoco se cobran.
Una vez más, volvemos a falsear los datos.
Conclusión
Leyendo esto, podría parecer que imputar horas es inútil. Nada más lejos de la realidad. Lo que hay que hacer es cambiar el objetivo de imputar horas. Debería ser algo didáctico. Servir para mejorar nuestras estimaciones. O para saber cuál es el mejor desarrollador que tenemos para una determinada tarea. En definitiva, debería servir para mejorar. Y si no, mejor no imputar horas.
¿Quiéres que te avisemos cuando se publiquen nuevas entradas en el blog?
Suscríbete por correo electrónico o por RSS