No somos islas

A menudo es fácil sentirse solo. Tienes un problema que resolver y no tienes a quién acudir. ¡Así es la vida del informático!

La ley del “yo me lo guiso, yo me lo como” es la más utilizada. Se nos ve como personas individualistas y, a menudo, poco sociables.

Sin embargo, esta no es la realidad. Ni para los informáticos ni para nadie.

¿Por qué?

Podemos ver la diferencia en los futbolistas: no es lo mismo jugar en un estadio en el que todo el mundo te está animando que en uno en el que te insultan. De la misma manera, no se trabaja igual en un proyecto en el que los jefes te animan que en uno en el que utilizan el látigo.

Es curioso que España tenga el dudoso mérito de ser uno de los países en los que se trabaja más horas pero se rinde menos. También es curioso que en España tengamos mucha de esa “cultura de látigo”. ¿Es posible que estén relacionados?

A mí me da la sensación de que el tiempo pasa más deprisa cuando estás acompañado. Y no sólo pasa más deprisa, sino que también se hacen más cosas. Está claro que todo tiene sus límites; ya conocéis la famosa frase: “Si quieres que algo no se haga, nombra un comité que lo organice”.

Comparando

Si lo piensas, no hay tantos trabajos colaborativos. El profesor también se encuentra solo ante su clase. El Policía que está patruyando se sentirá igual. El fontanero, electricista, jardinero,… Hay pocos trabajos realmente colaborativos.

La diferencia entre un trabajo colaborativo y uno aislado no depende del desempeño, sino de cómo se lleve a cabo. Dos personas que desarrollan la misma actividad pueden sentirse de forma diferente: una de ellas puede sentirse arropada mientras que la otra se encuentra sola.

Pero… ¿Cuál es la diferencia esencial?

Nos gusta saber que tenemos un colchón. Saber que hay alguien ahí. A menudo, tratamos de hacer amigos de los compañeros de trabajo. Cuando funciona, nos encontraremos bien. Si no funciona, tendremos esa sensación de soledad.

Hay distintas técnicas que favorecen cada uno de estos sentimientos, y me gustaría estudiarlas brevemente.

Programación “CowBoy”

El jefe manda un trabajo y se espera que el desarrollador lo realice. Éste no tiene a quién preguntar y, a menudo, se encuentra solo.

Éste es el modo tradicional de trabajo.

Pair Programming

Resulta evidente que programar por parejas puede eliminar la soledad. Además, permite sentirnos arropados y tener red: si se hace algo mal, hay otra persona observando.

Scrum

Todas las mañanas se reúne el equipo. Y como equipo, se mira lo que se ha hecho, hacia dónde se va y qué problemas pueden surgir.

Y cada sprint, todo el grupo decide el camino a seguir. No hay figuras; es un grupo.

Team Building

En la empresa en la que estoy hay un evento de “Team Building” cada trimestre. Durante una mañana o una tarde, el equipo realiza una actividad fuera de la empresa.

El único en el que he participado hasta ahora lo pasé en el parque de atracciones :D

Hack me up

Una vez cada trimestre (más o menos) se propone un tema y se dan 24 horas para realizar lo que quieras; hay dos categorías: proyectos relacionados con el tema y otros.

Si se trata de seguir el tema, es posible que tengas que contar con algún miembro de otro equipo que tenga más soltura con dicho tema. Si no, seguramente tengas que tratar con otra gente debido al poco tiempo que hay para resolverlo.

Team launch

Casi todas las semanas nos vamos a comer el equipo junto. A menudo no salen temas de trabajo, pero nos permiten conocernos más en un entorno distendido.

Revisiones de código

Cuando no se puede hacer pair programming, revisar el código de otra gente provoca que haya interacciones. Estas interacciones nos ayudan a tener mayor confianza en lo que estamos haciendo, produciendo un código de mejor calidad.

Además, alguien que llega de fuera puede aportar un punto de vista completamente diferente y más acertado. Tratar de convencer al otro de que nuestra idea es mejor nos ayudará a tener una idea más clara del problema y de la solución.

Integración contínua

Si al realizar un arreglo se rompe un test, es posible que tengamos que contar con la ayuda de quien hizo el test. Esto enlaza con TDD, ya que dejar una buena batería de pruebas favorece que otros comprendan nuestro código.

Cada vez que algo se rompe, todo el grupo debe arreglarlo. Ya no es nuestro código, sino el del grupo.

Quizá se vea un poco forzado, pero yo creo que, en cierto modo, la Integración Contínua sólo es posible si hay un buen sistema de pruebas, si los componentes interactúan correctamente entre ellos y si hay un buen diseño arquitectural. Todo esto sólo es posible cuando el equipo trabaja como un único ente.

Conclusiones

Resulta curioso comprobar cómo todas las conocidas “técnicas ágiles” (Scrum, Integración Contínua, Pair Programming, …) van enfocadas a evitar la soledad. Todas tienen el único objetivo de ver el trabajo de equipo, no trabajos aislados.

También parece que las empresas, sobre todo las extranjeras, se han dado cuenta del valor del grupo frente al pichichi: mayor productividad y mejor entorno de trabajo. Por eso fomentan actividades de grupo fuera de la empresa. Un trabajador que se encuentra cómodo, tranquilo, seguro y se siente parte de un equipo producirá mucho más que alguien que no cumpla estas condiciones, por muchas horas que dedique.