This post was originally published on Medium.
Escribo esto solamente para tener a mano a partir de ahora el artículo de Paul Graham que explica la diferencia entre agendas ejecutivas y creativas.
Pon una reunión a las 11:00 y destroza la mañana de un programador (o un diseñador, o cualquiera con agenda creativa). Pon otra a las 17:00 y le habrás hecho perder un día entero. Y, sin embargo, no tendrá ningún efecto negativo sobre un comercial o sobre el director de la empresa. ¿Por qué? Es justo lo que explica Paul Graham en su artículo y lo que voy a intentar resumir yo.
Agenda creativa, agenda ejecutiva
La agenda ejecutiva divide el día en horas. Es lo que usan los directivos, los comerciales, y muchos mandos intermedios en las empresas. Cada hora cambian de tarea, y es perfectamente normal para ellos.
Sin embargo, ni un programador, ni un diseñador dividen así su día. Suelen hacerlo en mañana y tarde. Tramos mucho más largos. Porque, a fin de cuentas, en una hora no te da tiempo a programar casi nada. Esta es la agenda creativa.
Van bien cada una por su lado, pero no juntas
Alguien en agenda ejecutiva no tiene problema para poner una reunión a las 11:30. Pero como programador, te parte la mañana. Empiezas a trabajar, te tienes que concentrar, pero sabes que vas a tener que parar a las 11:30 para una reunión. Es muy probable que, si el problema que tienes entre manos es complicado, sin querer, no te concentres lo necesario, aunque empieces a las 9 en punto. Sabes que tienes la reunión luego, así que… inconscientemente, prefieres ponerte con otra cosa más sencilla. Mañana perdida. Ya ni te cuento si una reunión es a las 10 y otra a las 13, entonces sí que es mañana perdida del todo.
Divides tu tramo habitual en dos trozos demasiado pequeños, y en cada uno de ellos no te da tiempo a hacer nada productivo, o mucho menos de lo que esperabas.
Solución: reuniones al principio o al final de cada tramo
Planifica las reuniones al principio o al final de la mañana o la tarde para resolver el problema.
Algunos libros
Paul Graham, además de por Y-Combinator y HackerNews, es conocido por su libro Hackers and Painters. Es una recopilación de artículos muy interesantes sobre temas técnicos y de planteamiento vital como programador (por ejemplo, explica por qué los programadores “generan valor” en lugar de redistribuirlo solamente).
El libro más clásico sobre cómo las reuniones (y los espacios abiertos, ya puestos) destrozan la productividad es Peopleware. Dice que cada interrupción te hace perder 15 minutos hasta que vuelves a estar concentrado, me parece un poco exagerado, pero puede que no le falte razón. Casi me convence más lo de que una reunión en el momento inapropiado te predispone a perder el tiempo.
Y como hay mucha cosa psicológica en todo esto, y el trabajo de desarrollo es materia gris todo el rato, hay otro libro que explica muy bien cómo pensamos, para programadores: Pragmatic Thinking and Learning — refactor your wetware.