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.

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.

No sabemos de todo, no tenemos las respuestas a todas las preguntas, no somos infalibles, no dominamos todos los contextos. Cuanto antes asumamos esto menos errores evitables cometeremos por nuestro exceso de suficiencia.

La confianza en uno mismo no consiste en considerarte por encima de todo y de todos sino por saber que no eres ni mejor ni peor por buscar las respuestas donde podrías encontrarlas.

Escucha lo que te tengan que decir, aunque no estés de acuerdo. Después es posible que sigas sin estar de acuerdo pero por el simple hecho de escuchar has tenido que poner en contraste tus ideas con otras diferentes y eso aporta valor.

El desarrollo de software es un trabajo colectivo en el que todos tienen la capacidad (y deben aportar). Más percepciones de la realidad amplía el abanico de posibilidades y el número y calidad de las respuestas. Lo importante es sacar el proyecto adelante no que la idea decisiva la hayas dado tu.

Por último os dejo la siguiente reflexión de Jerry Weinberg que puede resumir el contenido de este artículo: “Cuando no eres terriblemente inteligente, te ayuda ser un buen oyente”.

Incluso siéndolo debes ser siempre un buen oyente.

Limitarte en un rol puede llegar a ser cómodo, pero no es ágil. Tampoco es ágil ser en cada momento un comodín porque probablemente no termines de hacer de manera adecuada todas tus tareas ya que se puede ser un buen hombre orquesta pero es imposible tocar a la vez todos los instrumentos.

Es conveniente que los equipos ágiles estén formados por personas polivalentes pero teniendo en cuenta que si alguien es muy bueno en algo es conveniente que enfoque su esfuerzo en donde más provechoso puede ser su trabajo.

Conocer qué rol tiene cada uno es importante, encasillar a cada persona en su rol, un lastre. Para evitar eso es conveniente definir responsabilidades como elementos que trascienden al rol, de manera que personas con roles distintos podrían compartir determinadas responsabilidades.

Sin embargo para que esto funcione es fundamental la actitud de las personas ya que sin ella el rol tenderá a prevalecer sobre las responsabilidades porque siempre se podrá encontrar una buena excusa para ello.

Es cierto que es necesario medir bien qué responsabilidades se le asigna a cada persona, no vale todo porque eso va en contra de la persona, del equipo y del proyecto. Eso te obliga a conocer bien a todos los que participan en el proyecto, algo que no siempre se sabe al principio pero en donde hay que tener en cuenta que la asignación de responsabilidades tampoco tiene que realizarse al detalle o de manera completa al comienzo y que posteriormente se pueden realizar todos los ajustes que sean necesarios.

Un desarrollador de alto nivel en el rol que desempeña es capaz de rendir exponencialmente mejor que otro que no tenga sus conocimientos, experiencia y brillantez.

Cuando se trata de proyectos donde el equipo es muy reducido unas buenas individualidades pueden compensar un mal funcionamiento colectivo.

Cuando el equipo es más numeroso no vale solo con tener buenas individualidades sino que debe funcionar como tal, no se trata del no aprovechar el talento sino optimizarlo como parte del talento colectivo de manera que la suma de todo el conjunto supere a la suma de las individualidades.

Un héroe puede salvarte una vez, dos, tres veces…, tal vez incluso pueda salvar el proyecto pero no es el camino, a medio y largo plazo serán muchos los proyectos que fracasen mientras esperan que el héroe vuelva a hacer un imposible.

Hay mucho trabajo que hacer en el proyecto y cada cual se tiene que encargar de lo suyo sin olvidar que forman parte de un equipo por lo que debe existir comunicación e interacción con los demás y estar siempre a disposición del equipo para echar una mano donde haga falta. Si cada cual hace la guerra por su cuenta está creando una resistencia para el resto de sus compañeros, los cuales verán mermada su eficacia.

Bob Martin realiza la siguiente reflexión: “Un equipo de desarrolladores medios que se comunican bien tienen más probabilidades de tener éxito que un grupo de superestrellas que fallan al interactuar como equipo”.

Muchos proyectos fracasan porque no se consigue formar ese equipo (dentro de los desarrolladores) y en extensión cuando no se consigue formar un equipo con el resto de implicados en el proyecto.

Es muy importante construir ese equipo y eso no se consigue simplemente juntando una serie de personas. Muchos gestores olvidan eso y piensan que todas las combinaciones pueden ser válidas y no es así. Dentro de las opciones existentes hay que procurar conformar la mejor, a partir de ahí, con un buen equipo, se tendrá una buena base para luchar por el éxito en el proyecto.

Una vez elegida una buena combinación toca consolidar el equipo y mantenerlo que es lo más difícil teniendo en cuenta el desgaste existente en un proyecto de desarrollo de software sobre todo en circunstancias de presión, algo que por desgracia ocurre casi siempre.