Cuando estás trabajando en un entorno colaborativo, esto es, con alguien más que vos en un proyecto, siempre es mejor jugar en equipo. No importa si estás en una rama aislada del proyecto o si trabajás en un aspecto específico de la implementación, la recomendación es verlo como un TODO. El resultado de un proyecto siempre va a ser más completo, enriquecedor y robusto cuando todos están en la misma página. Esto no quiere decir que el desarrollador tenga que estilar el header del sitio o el QA modificar tablas de SQL, me refiero a que todas las partes del flujo de trabajo dependen de todos, en menor o mayor medida, y todos pueden aportar sus conocimientos al desarrollo. ¿Qué pasa si un QA puede prevenir un comportamiento errado ANTES de que el desarrollador invierta horas de desarrollo en un flujo mal concebido? ¿Acaso un dev no puede advertirle a tiempo a un designer que la animación que está por ofrecerle al cliente no es posible hacerla en la estructura actual del sitio?

Es por esto que los brainstormings y las reuniones conceptuales son sumamente importantes. Pero aún así, sin el marco formal y sin la necesidad de las burocracias de bookear salas y/o agendar reuniones con los miembros del equipo, es muy sencillo y recomendable acercarse al puesto de trabajo del compañero de trabajo y conversar sobre la implementación. Es clave hablar e intercambiar opiniones cara a cara con los compañeros de trabajo. Es entendible que skype, un e-mail puede ser de utilidad o en ciertos casos hasta vitales para efectivizar una consulta, pero siempre se tiene que priorizar el diálogo como método de intercambio de ideas. Además, sirve para sentir esa red de contención profesional y anímica tan necesaria en ciertas etapas de un desarrollo.

Un equipo de trabajo unido y en sintonía siempre va a funcionar mejor que un grupo de desarrolladores trabajando como individuos. Al conocerse mejor todos van a saber cuáles son las fortalezas y debilidades de los otros y por la mera sinergia de la relación se van a acomodar de tal forma que cada uno hará lo que más le gusta y le sale, y de esta forma el resultado va a ser de comunión, con menos stress para todos y una óptima performance del grupo.

Desde ya que se puede tener, y generalmente es así, un equipo de trabajo en donde los integrantes no se conocen o simplemente a fuerza de profesionalidad llevan adelante las tareas diarias. Pero aquí es clave el rol de la empresa como agente unificador que define qué identidad desea tener. Claramente la empresa no puede forzar relaciones, éstas deben darse solas, pero si puede fortalecerlas y estimularlas. Al tiempo que debe buscar activamente ciertos carácteres más friendly para la filosofía establecida a seguir, más allá de aptitudes técnicas.

Las complicidades laborales terminan trascendiendo las salidas extra laborales y viceversa. Empiezan a aparecer los códigos y las conversaciones sin palabras. La fluidez del trabajo crece, se vuelve más efectiva y de mejor calidad. Porque no solo te importa hacer TÚ parte del trabajo, sino que quien tené tu lado lo haga lo mejor posible también en pro del equipo y del proyecto. Se dejan de lado los egos. Nadie sabe más que el otro, sino que es un solo conocimiento general potenciado. Hay que salir de la habitual visión de MI trabajo, para pensar en NUESTRO trabajo.

¿Por qué es importante trabajar en equipo?

Otro valor agregado es el aprendizaje, porque uno capitaliza cada nuevo conocimiento, que en un ambiente relajado es mucho mejor asimilado. Se aprende mucho más solucionando dificultades junto a otros colegas que mirando videos tutoriales. Es una utopía sin sentido pensar que una sola persona puede abarcar todas las áreas que involucran un buen desarrollo de software. Un full stack developer puede ser bueno, pero tener los recursos de otros profesionales y especialistas en ciertas áreas aunados, siempre funciona mejor y termina siendo más eficiente. ¿Qué más estimulante que nuevas miradas sobre un mismo problema que nos agobió por muchas horas? ¿Qué más útil que la mirada de un colega con otros conocimientos y experiencia? Cuánto tiempo pasaste dándole vueltas a un failure "imposible" hasta que vino alguien ajeno, que desde una perspectiva fresca y diferente te dijo: “a esto le falta una coma acá”. Algo tan simple que no podrías ver.

Es por esto, que por ejemplo, un buen diseñador tiene que saber de diseño, pero un buen diseñador dentro de un equipo tiene que tener aptitudes nuevas, ya que no se diseña solamente un slider para la aplicación, también se diseña pensando que un colega no se vuelva “loco” cuando tenga que colocar código.

Con el correr del tiempo, cada vez es más importante para el crecimiento de la industria del software eliminar la filosofía cuadrada basada en el “hasta acá llego yo”. Hay que dar un paso más, salir de la zona de confort y arriesgarse a hacer cosas diferentes para el crecimiento profesional y de la empresa. Es importante saber escuchar las sugerencias de los demás y tratar de participar para hacer que los proyectos no solamente mejoren, sino que además, reflejen una parte de tu trabajo.

El diseñador debe ser diseñador y el desarrollador debe ser desarrollador, pero un proyecto crece más, cuando el desarrollador es un poquito diseñador y cuando el diseñador es un poquito desarrollador.

Virtualmind propone un ambiente de trabajo donde comulgan ambas áreas, y en cada una reina el respeto y se valora los conocimientos, experiencia y trabajo del otro. En Virtualmind los desarrollos, los proyectos, las implementaciones y los sistemas no se hacen individualmente, se hacen en equipo, ¡porque siempre resulta mejor!

(*) Patricio Solé: Web Designer en Virtualmind