¿A qué dedican su tiempo los programadores?

Cuando intentamos estimar trabajos intensivos en mano de obra es fácil errar... y generalmente por el lado del optimismo.

En entornos muy industriales, puede que aún tengan validez técnicas taylorianas de medida de tareas y tiempos pero ¿qué pasa con los trabajadores de cuello blanco?

Una disciplina que es especialmente elusiva, difícil de gestionar y planificar por las técnicas de carácter industriales es el de la ingeniería sofware y más específicamente la programación.

Diferencias en la experiencia, formación, habilidad, motivación o inteligencia entre diferentes programadores, puede dar tasas de productividad sorprendentemente diferentes.

Pero más allá de esto, hay un error mucho más básico, y más fácilmente enmendable,  a la hora de estimar la duración de un proyecto de software: sobreestimamos la dedicación efectiva de los programadores a escribir líneas de código o probar lo que han programado.

Lo cierto es que un programador, como cualquier otro trabajador, dedica una parte de su jornada laboral a tareas que no están directamente relacionadas con su puesto de trabajo o con aquello que se supone es su labor: reuniones, cafés, asuntos personales, distracciones...

En su libro 'Going Agile' Gloria J. Miller aporta referencia de dos estudios.

Menciona por un lado un estudio llevado a cabo en 2001 por Booch y Brown. Según este estudio, los programadores dedican:

• 3% de su tiempo a llamadas telefónicas
• 7% de su tiempo leyendo
• 17% de su tiempo en reuniones

Si suponemos que el resto se dedica a programar o probar, nos queda un 73% de tiempo productivo. Si realmente ese 73% se dedicara completamente a su labor, no me parece una mala cifra, especialmente teniendo en cuenta que el 7% dedicado a leer, si es en relación con su trabajo, es un potenciador y podríamos considerarlo como parte de la formación y desarrollo profesional, algo que redunda en la productividad futura.

Sin embargo, en 1995 Brook daba una estimación algo más grosera... y bastante más pesimista, estimación que atribuía sólo un 50% de dedicación a programar y depurar mientras el resto se perdía en reuniones, burocracia, bajas por enfermedad, etc.

Dos conclusiones creo que se obtienen.

Por un lado, que es conveniente vigilar la productividad y establecer medidas para mejorarla porque si Brook tuviera razón, la cosa parece preocupante.

Por otro, que no es realista planificar un proyecto de sofware suponiendo una dedicación 100%. Incluso siendo moderadamente optimistas, deberíamos suponer que, por ejemplo, un 25%  de la capacidad de trabajo en horas se va hacia tareas que no se planifican y que no tienen que ver directamente con la producción de software.

Muy relevante es hacer notar que en este artículo tratamos con el caso de la programación pero que, si pensamos en planificación en otros campos, siempre debemos partir con esa dedicación inferior al 100%. Por ejemplo podemos, de forma quizá conservadora, reservarnos un 20% para actividades no planificadas y difícilmente planificables.

Una virtud del director de proyecto es el realismo...y esta receta añade, creo, realismo a las planificaciones.