archivo

Archivo de la etiqueta: trabajo en equipo

Interesante la siguiente reflexión de Steve McConnell en su libro “Rapid development”: “Un equipo existe cuando dos cabezas juntas son mejores que dos cabezas individualmente”.

Para llegar a esto es muy importante la actitud de las personas. Si se considera que gran parte de quienes trabajan contigo en el proyecto no son capaces de aportarte ideas estás perdiendo la posibilidad de descubrir nuevos puntos de vista y mejores soluciones que las que tenías pensadas inicialmente.

Trabajar en equipo no es fácil ya que los desarrolladores somos muy individualistas y muchas veces la presión dificulta todavía más este asunto, pero cuando se consigue funcionar de esa manera el rendimiento de las personas crece en gran medida, no solo porque todos sean capaces de aportar al colectivo sino porque se trabaja mucho más a gusto.

Anuncios

La gestión de un colectivo debe perseguir que la suma del esfuerzo común sea superior a la que se obtendría de cada elemento por separado ya que de esta forma los pasos para conseguir los objetivos serán más amplios y precisos.

Una mala gestión de un colectivo no solo no consigue eso sino que empequeñece el talento individual de cada componente del equipo, de manera que el resultado común es inferior al individual. Esta circunstancia en una actividad donde se requiere la interacción, cooperación y comunicación entre las personas resulta nefasta y lo peor de todo es que resulta demasiado frecuente.

Una base para una adecuada gestión de un colectivo es que el gestor crea en el trabajo en equipo (más allá de palabrería barata), crear espíritu de equipo, mantenerlo unido y gestionarlo de forma adecuada. Esto requiere de mucha aptitud pero sobre todo de actitud porque lo cómodo es mantener una distancia, no mancharse las manos y dejar que sean los integrantes del equipo los que se gestionen.

Sin embargo eso no funciona siempre ya que la autogestión necesita de liderazgo y, además, las decisiones del gestor (o las no decisiones) impactarán en el equipo y al ser menos precisas (cuanto más lejos te encuentres del objetivo más complicado será acertar en él) y no pensar en equipo serán una continua fuente de desequilibrio.

La siguiente cita de Parker Palmer me hizo reflexionar sobre la esencia de lo que es un equipo de proyecto: “Cuando no dependemos el uno del otro, la comunidad no puede existir”.

El desarrollo de software debe ser colaborativo porque el conocimiento está repartido por todo el equipo y porque la visión del conjunto mejora la suma de las visiones individuales.

No todo el mundo se adapta a trabajar de esta forma porque muchos desarrolladores tienen una visión orientada al cumplimiento: “estas son mis tareas, las termino, cumplo y a otra cosa”, el desarrollador puede ser excepcional y lo mismo encaja en tareas donde trabaje solo pero si no es así deberías plantearte si efectivamente quieres a personas así en proyectos en donde sea necesario su cooperación y colaboración con otros. Es cuestión de crear equipo, sí, pero también de crear una cultura.

Precisamente la principal culpable de que prolifere la figura del cumplidor es la propia organización cuando no entiende de la importancia del trabajo en equipo, de manera que en su funcionamiento general y más específicamente en los diferentes proyectos lo que hace es reunir/juntar a una serie de personas en lugar de hacer que las mismas funcionen bajo un esquema de colaboración y cooperación.

Si se te pasa por la cabeza no escuchar las opiniones de tu equipo o de personas concretas de él porque piensas de antemano que no están a la altura, que no tienen experiencia o que técnicamente no son gran cosa, recuerda la siguiente cita de Descartes: “La verdadera inteligencia consiste en descubrir la inteligencia ajena”.

Cuando te des cuenta de eso, seguro que tus proyectos empezarán a marchar mejor. No es fácil gestionar opiniones diferentes que pueden ser divergentes entre sí y con la tuya pero desde mi punto de vista resulta mucho peor quedarte con la tuya sin tener segundas y terceras opiniones, ya que seguro que hay algo que no has tenido en cuenta o que no has percibido o interpretado de manera adecuada.

En el momento en que decides no escuchar a tu equipo, las personas tenderán a ser menos participativas contigo, ¿es eso lo que quieres?, ¿te sientes cómodo en ese contexto? Tal vez te encuentres bien de esa manera pero el desarrollo de software es de personas para personas por lo que a la larga y lo verás también a medio y corto plazo, los resultados de tus proyectos se resentirán si continúas con esa actitud.

En un proyecto de desarrollo de software se manejan multitud de variables y una gran cantidad de tareas que son realizadas por personas de los diferentes equipos de trabajo que intervienen en el proyecto, algunos de ellos de departamentos distintos o incluso de organizaciones distintas (cuando se trabaja con un cliente externo, en una unión temporal de empresas o con alguna subcontratación).

Para que todo vaya bien no solo es necesaria la colaboración sino también la sincronización con que se realizan las tareas porque, de no ser así, las desviaciones provocadas por un equipo impactarán directamente en otros, teniendo en cuenta que el que pierde siempre con todo esto es el proyecto y a la larga, si el proyecto sale mal, todos salen perdiendo.

Este espíritu de colaboración, esa intención de conseguir que toda la “maquinaria” funcione de manera adecuada solo es posible si se ha conseguido forjar una relación de confianza (después influirán otros factores, como la capacitación del personal, del impacto de los errores, etc…).

Al principio cuesta un poco (sobre todo en aquellos casos donde los equipos no se conocen) pero sirve como contramedida el hecho de que se parte de cero y todavía no han existido fricciones (otra cosa es que se parta con equipos que se conocen del pasado, que no terminaron de funcionar y que erosionaron su confianza, en estos casos habría que plantearse si la situación es reconducible o no).

Sin embargo, conforme se avanza en el proyecto y algo no va como a los responsables de algunos de los equipos quiere (o a sus jefes) o bien, se decide cambiar de prioridades, la confianza empieza a resquebrajarse, a una velocidad vertiginosa en comparación con lo que costó construirla y mantenerla.

Ya lo decía Séneca: “Una era construye ciudades. Una hora las destruye”.

Partamos de la base que en un juego con tantos intereses es muy complicado, por no decir imposible, mantener un equilibrio. El objetivo no es que siempre sea todo un camino de rosas, sino que cuando haya problemas, que los habrá, se atajen pronto, antes de que la pérdida de confianza sea prácticamente irreversible.

Decía Nicolás Maquiavelo que: “Las armas se deben reservar para el último lugar, donde y cuando los otros medios no basten”.

Y es así, el enfrentamiento debe ser el último recurso si es que efectivamente se piensa que con ello se puede conseguir algo, ya que pocas veces se es vencedor absoluto y lo normal es que todas las partes en conflicto pierdan, aunque alguna crea que ha ganado.

Sucede muchas veces que se recurre directamente al enfrentamiento por creer que es el camino más corto y por entender que es lo más fácil, esa es la visión que el gigante cree tener sobre el débil y por eso recurre a ese atajo.

Sin embargo cada vez que se usa esa fuerza el gigante se hace cada vez más pequeño porque produce desconfianza no solo en los afectados directamente por sus actos o por sus decisiones, sino porque los observadores de esa situación empezarán a pensar que ellos pueden ser los siguientes y tomarán precauciones.

El enfrentamiento te aleja y cuando se trabaja en equipo es una de las causas principales de que dejen de funcionar y por ese motivo debe atajarse la situación cuanto antes.

Recuerda también que el liderazgo no se consigue con la fuerza. Con la fuerza solo consigues rehenes.

Contra el enfrentamiento está el diálogo, saber escuchar, entender que no siempre se tiene la razón y que la verdad absoluta no es un patrimonio propio.

En el desarrollo de software en general y en el enfoque ágil en particular es fundamental el trabajo en equipo en sus dos vertientes: por un lado cada equipo de manera individual y por otro considerando a todos los equipos que participan en el proyecto como un equipo global.

Susan Campbell resume perfectamente en la siguiente reflexión lo complicado que resulta mantener el equilibrio en el equipo: “El trabajo en equipo es un acto de equilibrio constante entre el interés propio y el interés colectivo”, por eso resulta tan complicado conseguir que los equipos funcionen y que se pueda mantener un determinado nivel de productividad y eficiencia en el tiempo.

Somos personas y como tales somos complicadas de gestionar, tenemos altibajos, pueden afectarnos circunstancias externas, tendemos a centrarnos en nuestra problemática individual por encima de otras más generalistas o colectivas.

Lo más importante de todo esto es entender esta realidad con el objeto de tener en cuenta que el rendimiento de los equipos no es constante y que lo será más o menos en función de cómo se gestionen y del tipo de personas que los integren.

Cuanto mayor sea ese equilibrio, cuanto más tiempo se pueda mantener más posibilidades existirán de que el proyecto salga adelante.