El overtime se compensa con undertime

Muchos jefes se consideran mejores cuanto más "exprimen" a los programadores. Siendo el desarrollo de software un trabajo intelectual, pensar así es claramente un error. 

Ciertos estudios demuestran que trabajar más de 80 horas semanales no aumenta la productividad neta. 

Cuando se trabaja más de 120 horas a la semana, la productividad llega a ser incluso negativa (el trabajo es inferior al retrabajo). Hay una franja de productividad óptima entre 60-80 horas a la semana, pero nadie puede trabajar continuamente mucho más de 40 horas, no al ritmo e intensidad que requiere el trabajo creativo. ¡La gente bajo presión no piensa más deprisa! La presión enérgica ocasional y las horas extra pueden ser tácticas útiles porque mantienen a la gente enfocada e incrementan el sentido de que el trabajo es importante, pero la presión prolongada es siempre un error.

Se ha comprobado que las horas extra (overtime en inglés), se compensan con menos horas productivas, "undertime" (e.g. a un domingo de trabajo le sigue un lunes relajado, si por la noche se trabaja, la mañana es improductiva con reuniones inacabables, etc.). Como estas horas extra no se pagan, el overtime no aparece en los registros de incurridos. Igual de invisible resulta el “undertime”, pero es razonable asumir una correspondencia de 1 hora de “undertime” por cada hora de overtime.

Muchos autores comparan el overtime con esprintar en una carrera. Esprintar tiene sentido los últimos 100 metros de la maratón (para aquellos que les queden fuerzas), pero no se recomienda comenzar esprintando el primer kilómetro. Obligar a las personas a esprintar tanto sólo conduce a que le pierdan el respeto al jefe. Los buenos programadores ya han pasado por ello, saben lo suficiente para guardar silencio mientras el jefe despotrica sobre que el trabajo hay que terminarlo en una fecha límite imposible de cumplir. Ya se tomarán su “undertime” compensatorio cuando puedan y así el balance final será de 40 horas de trabajo efectivo a la semana. 

Tom Demarco, en su novela The Deadline representa gráficamente el efecto de la presión en las personas: Si para un conjunto representativo de proyectos finalizados se dispone de la información del tamaño (en Puntos-Función, por ejemplo), plazo comprometido y plazo final (meses), la PRESIÓN podría calcularse dividiendo el plazo nominal entre el plazo comprometido (siendo el plazo nominal el tamaño dividido entre la tasa de productividad). Por otro lado, el RENDIMIENTO podría calcularse dividiendo plazo nominal entre plazo final. Por ejemplo, para un factor de productividad de equipo de 100 puntos función mensuales, un proyecto de 1000 puntos función (plazo nominal 10 meses), que se planificó en 5 meses y finalmente se ejecutó en 8, se obtendría un factor 2 de PRESIÓN (10/5) y un factor 1,25 de RENDIMIENTO (10/8).

La enseñanza de Tom Demarco podría resumirse así: Un jefe autoritario piensa que el rendimiento aumenta con la presión hasta un nivel máximo constante. Un jefe democrático piensa que la gente tiene un límite a partir del cual, la presión adicional hace que el rendimiento baje drásticamente. Si se representara la información histórica, tendríamos la siguiente sorpresa: ¡El rendimiento no depende de la presión! 

En nuestro ejemplo, para todos los proyectos siempre obtendríamos misteriosamente el mismo factor 1,25. ¿El lector sabe por qué?