Las reuniones, la multitarea y la programación

Hay días que no paro y sin embargo tengo la sensación de que no he hecho nada. Esa sensación la tengo porque no he creado nada, que es muy distinto de no hacer nada.

Esto me ocurre cuando tengo que contestar muchos correos, consultar a otras personas para tomar decisiones, atender a los alumnos, “hacer papeles”, etc. Acaba el día y no he podido escribir ni una sola línea de código, no he podido escribir ni una línea de un artículo, no he podido crear ni una escena para un vídeo o no he podido leer ni un párrafo de un artículo.

Una de las razones de esta situación son las constantes interrupciones y el constante cambio de una tarea a otra. Ya he escrito varias veces sobre lo malo que es la multitarea en el trabajo (y en casi todo), ya que añade una sobrecarga de trabajo para cambiar de una tarea a otra, que se traduce en una pérdida de eficiencia:

• El intercambio de tareas es perjudicial para el trabajo
• Los mitos de la multitarea

Ahora, un alumno me ha pasado el artículo Maker’s Schedule, Manager’s Schedule que añade una pieza más al problema de la multitarea en el trabajo.

El artículo comienza con una “verdad absoluta”: a los programadores no nos gustan las reuniones, las consideramos una pérdida de tiempo (otro tema es lo mal que se organizan y realizan las reuniones, pero eso es tema para otro artículo). Si un programador te dice que le gusta tener reuniones, entonces es un falso programador 🙂

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.

A partir de ahí se presentan dos perfiles que se pueden encontrar en el ámbito laboral: los makers, los creadores, los que hacen cosas (el artículo se centra en los programadores, pero también indica que este problema se da entre otros grupos de personas, como por ejemplo los escritores: en realidad, un programador también es un escritor), y los managers, los gestores o gerentes, los que mandan a otros (a los makers) a hacer cosas.

Los makers y los managers conviven en el trabajo y de vez en cuando se tienen que juntar, tienen que tener reuniones para organizar el trabajo. El problema es que los makers y los managers tienen calendarios/horarios (schedule) diferentes.

Un manager está constantemente de reunión en reunión. Para un manager, una reunión es simplemente eso, una reunión más: el manager espera que después de una reunión haya otra reunión, sólo tiene que consultar su agenda para ver dónde, para qué y con quién tiene la reunión.

That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what.

Sin embargo, el maker trabaja de otra forma. Un maker no puede escribir un texto o programar algo en una hora o en menos tiempo. Un maker trabaja en unidades de tiempo más grandes, como por ejemplo medio día.

They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

Una hora o menos no es tiempo suficiente para hacer nada creativo (creativo = capaz de crear algo). Si tengo que escribir un artículo, en una hora no puedo escribir nada que valga la pena: necesito tiempo para releer lo que había escrito, conectar las ideas, pensar lo que voy a escribir, consultar algunas fuentes de información, escribirlo, revisarlo y finalmente darlo por bueno. Si tengo que escribir un programa o corregir un programa, en una hora no puedo hacerlo correctamente: necesito tiempo para recordar lo que voy a hacer, revisar lo que ya tengo hecho, decidir lo que voy a escribir, consultar alguna documentación, escribirlo, probarlo y finalmente darlo por bueno.

Para un maker, una reunión es una interrupción en su actividad. Para un maker, una reunión de media hora supone más de media hora en su tiempo de trabajo efectivo e incluso puede afectar a toda su jornada laboral.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.

El artículo también introduce un concepto del que huyen espantados los makers: las “reuniones especulativas” (speculative meetings), que creo que es mejor llamar “reuniones imprevistas”. Las reuniones especulativas son aquellas que no se han programado previamente: el manager tiene un hueco en su agenda una mañana y lo completa con una reunión más a la que convoca a los makers. Para el manager no supone ningún coste (por eso lo hace, y piensa que para el resto de los trabajadores tampoco les supone un coste). Sin embargo, para un maker, esa reunión es terrible, le supone un coste enorme en su productividad. El artículo sólo habla de reuniones, pero yo añadiría más cosas: una llamada de teléfono, un correo electrónico o la visita de un compañero, aunque sólo sean cinco minutos (eso es lo que siempre te dicen, y luego no son cinco minutos), pueden tener un impacto terrible en el trabajo de un maker. Y esto no sólo ocurre en el corto plazo del mismo día, sino que lo podemos alargar a varios días, la interrupción puede durar varios días.

Por ejemplo, en la universidad tienen la malsana costumbre de pedir cosas con la coletilla de “urgente”: “esto lo necesito para hoy, esto lo necesito para mañana… esto es muy urgente, lo necesitaba para ayer, se me olvido pedirlo con una semana de antelación (esto no lo dice la gente y creo que ni lo piensan) así que te lo pido ahora y lo necesito ¡¡ya!!”. Estas interrupciones me destrozan completamente mi plan de trabajo: tengo que dejar parado lo que estoy haciendo y cuando vuelvo una horas o días después, tengo que dedicar mucho tiempo para saber por dónde iba. Y además, estas interrupciones introducen un factor de error, pero eso es tema para otro artículo. Más de una vez me he quejado del abuso del “urgente”, pero a la gente parece que le da igual.

Yo iría un poco más allá, y más que makers, hablaría de creativos: el trabajo de un programador, de un escritor o de un periodista es altamente creativo, eso es lo que los conecta y eso es lo que hace que una reunión o una interrupción sea tan perjudicial. Salvo en ciertas ocasiones, el trabajo de un programador no es mecánico, necesita “inspiración”. Y para que la inspiración aparezca, se necesita conocimiento, tiempo y concentración.

El artículo ofrece una sencilla solución a este problema: agrupar todas las horas de las reuniones al final de la jornada laboral. De este modo, las reuniones no son una interrupción para el maker.

Several times a week I set aside a chunk of time to meet founders we’ve funded. These chunks of time are at the end of my working day, and I wrote a signup program that ensures all the appointments within a given set of office hours are clustered at the end. Because they come at the end of my day these meetings are never an interruption.

El artículo termina de forma optimista: empezar a entender el problema puede ser el comienzo de su solución.

Till recently we weren’t clear in our own minds about the source of the problem. We just took it for granted that we had to either blow our schedules or offend people. But now that I’ve realized what’s going on, perhaps there’s a third option: to write something explaining the two types of schedule. Maybe eventually, if the conflict between the manager’s schedule and the maker’s schedule starts to be more widely understood, it will become less of a problem.

Y tú, ¿eres un maker o un manager? ¿Qué opinas?