Situación de flujo

0

Programar es una labor creativa. Es una tarea en la que escribes líneas de código para dar respuesta a un problema. Hay que resolver un problema creando esas líneas de código, y esto es una tarea creativa, muy parecida a pintar un cuadro o componer música. Y como tarea creativa que es, necesitamos que las musas vengan a ver a los programadores y los inspiren. ¿Pero como funciona esta inspiración? A través de un estado especial de concentración en el que parece que todo sale, un estado llamado flujo.

Hace mucho tiempo, asistí a una conferencia en la que el ponente (disculpad, pero no me acuerdo de quien era) habló de la situación de flujo. Es un estado en el que estamos concentrados, el tiempo nos pasa volando y la productividad se nos dispara, sobretodo si estamos en procesos creativos o de resolución de problemas. Cualquiera que haya programado alguna vez sabe a qué me refiero. Es ese estado en el que sólo ves tu código. Estás absorto en tu trabajo y no piensas en otra cosa. De repente viene un compañero a decirte si quieres hacer un café y tu respuesta es un titubeante: “ah, sí, id bajando que ahora voy”. De repente vuelven, y piensas “si que han tardado poco”, hasta que te dice que llevan más de media hora. ¿Media hora? Cómo es posible. Eso es flujo. En ese estado el trabajo fluye a toda velocidad y para un programador es como echarle un nitro al motor, disparando su productividad.

Hace tiempo trabajé en investigación en la universidad. De repente un día se te ocurría una idea durante la cena y no veías el momento para sentarte delante del Matlab a programar como un poseso. Entraba en flujo en minutos y era capaz de tirarme toda la noche, y sólo paraba cuando veía que entraba el sol por la ventana. Cuando sales del flujo, sales cansado, pero minutos antes de salir no notas el cansancio. Vas a tope!

La verdad es que esta situación de flujo aplica sobretodo a los desarrolladores. A la gente de sistemas no les aplica tanto. A veces, cuando están peleándose con una nueva instalación que no sale, buscando un parche por aquí y un paquete por allá, pueden llegar a un estado parecido. Pero no es tan común ni afecta tanto a la productividad como en el caso de los desarrolladores.

Como gestores la verdad es que no hacemos mucho trabajo creativo. Yo veo como cada vez entro menos veces en flujo. A veces, cuando tengo que escribir una propuesta para un concurso, o escribiendo un artículo para el blog, entro en un estado parecida de concentración alta. Pero ni de lejos se parece a entrar en flujo, como cuando programas.

No obstante, aunque como gestores no entremos tanto en flujo, es importante reconocerlo y crear las condiciones idóneas para que nuestro equipo entre en ese estado, y que luego no salga de él.

Condiciones para crear el flujo

Primero, y ante todo, creo que el flujo se consigue de forma diferente para cada persona. Por lo tanto consiste más en dejar a cada uno definir como quiere trabajar y ver si así entra en ese estado. Hay algunos que quieren ponerse música a tope en los cascos. Otros no entrarán en flujo en la oficina nunca, y lo conseguirán estando en su casa. Hay gente que entra en flujo a los pocos minutos de llegar al trabajo, pero que al llegar la hora del café, san se acabó. Otros en cambio, entran en flujo por la tarde.

Lo importante es no forzar una forma de trabajo homogénea, ya que cada uno tendrá sus propias necesidades.

Por otro lado, creo que el trabajo en equipo es enemigo del flujo. Cuando estas en flujo no hablas, y si hablas, hablas sólo. Yo nunca he estado en flujo trabajando en pareja. Lo del trabajo por pares puede ir bien en resolución de problemas graves. Pero en mi caso era mucho más productivo aislado que en equipo. Ojo! que no hablo de ermitaños que no sepan trabajar en equipo, hablo de que cada programador tenga unas tareas claras y no necesite estar hablando con otros para resolverlas. Así puede entrar en flujo.

El horario libre es una ayuda. Es verdad que hay que tener cuidado en que no se abuse, pero cuando tienes a gente responsable por debajo, es mucho mejor que se vaya a casa cuando no tiene el día y dejar que se quede hasta altas horas de la noche cuando está animado. En esto la organización tiene que apoyar. Si la organización a las 18:00 dice que cierra puertas, mal vamos.

Lo mismo ocurre con la moda de los espacios abiertos. 100 programadores en la misma sala. Sinceramente, no ayuda mucho al flujo. Hay muchas distracciones.

Evitar romper el flujo

El flujo cuesta conseguirlo, por lo que hay que conservarlo. Cuando uno de nuestros programadores está en flujo, debería ser sagrado y no molestarlo. Y los primeros en molestarlos somos los gestores. No molestarlo es no preguntarle como lo lleva o pasarle una incidencia.

Lo primero para no romper el flujo es reconocer el estado. Si no me doy cuenta de que está en flujo, difícilmente lo podré proteger. Debe estar en la cultura del equipo, o aún mejor en la de la organización, el respetar ese estado de flujo. Es como en la película “la red”. Allí cuando alguien está conectado (“Wired in”, su forma de decir flujo), es sagrado. No se le molesta para nada.

Sinceramente, en España solemos tener la costumbre de que de repente llegan las 11:00 y todos al café, y cuando de repente un programador te dice “es que ahora estoy liado”, lo cual es sinónimo de estar en flujo, se le responde “venga! que te irá bien desconectar”. ¡No! ¡Definitivamente no!. No le irá bien. Todo lo contrario, le vas a romper el estado de flujo y le costará un motón recuperarlo. Tendríamos que tener un código para mostrar que estamos en flujo y las razones para molestarle tendrían que ser muy importantes.

Así que soy contrario a los horarios, ya sean establecidos o de facto. Soy contrario a que la cafetera esté en una sala apartada. Los programadores deberían tener a menos de 10 metros de su puesto agua y café. ¿No nos damos cuenta de que poniendo la cafetera sólo en el office le obligamos a salir del flujo? Y lo mismo con comer. En muchas empresas españolas está prohibido comer en el lugar de trabajo. ¿Por qué? Cuando estás en flujo no quieres parar, ni para comer. Pero tienes que comer. No hablo de obligarlos a comer delante del ordenador, sino a dejarles hacerlo si quieren.

Y por último, si una persona quiere quedarse en la oficina hasta las tantas, debería haber alguna manera para permitirlo. “Es que sólo el director y los de recepción tienen llave”, pues te estás perdiendo un pico de productividad.

Conclusiones

Los programadores son como artistas. Tienen días inspirados y días que no. Todos entendemos que si un pintor tiene un día inspirado es mejor no molestarle, porque le vas a fastidiar mucho. ¿Tanto cuesta ver eso en los programadores? Cambiemos el chip. Creemos el entorno para que entren en flujo y luego evitemos que salgan de él. Ellos estarán más contentos y serán más productivos. Todos ganamos.

 

 

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios