archivo

Archivo de la etiqueta: trabajo en equipo

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.

Una condición necesaria para conseguir el éxito en un proyecto es crear un equipo. No te centres solo en el equipo de desarrollo sino en el conjunto de equipos que participan activamente en el proyecto.

Si ya es difícil a un grupo de personas hacerlas funcionar como equipo, hacer que diversos grupos con distintos intereses, con diferentes objetivos y que pueden ser incluso de varias organizaciones funcionen como un equipo, es un auténtico reto. Reto que, por supuesto, merece la pena porque de lo contrario el proyecto estará en peligro.

La situación de partida suele ser que cada equipo es como una ciudad estado, con sus muros gigantescos y con sus propias leyes. En algunos casos estarán organizados y en otros reinará el caos (con toda la escala de grises entre un extremo y otro). Este ecosistema es un caldo de cultivo óptimo para el antipatrón “arrojar al otro lado del muro“, ya que cada cual se centrará en su parte concreta del proyecto, olvidándose de que todos dependen del trabajo de los demás. En este contexto la comunicación entre los equipos es poco fluida y generalmente muy procedimentada, lo que pondrá una resistencia importante a la interacción entre las personas y no solo eso, la actitud de los equipos será defensiva, algo que suele tener como efecto que los muros sean cada vez más grandes.

He descrito un panorama extremo, es cierto, porque todos los equipos no tienen por qué tener de partida un comportamiento de ese tipo, pero también resulta algo poco real pensar que de partida todos los equipos van a estar funcionando como uno.

Para tratar de tirar o reducir el tamaño de esos muros es muy importante la tarea de alinear los equipos al objetivo del proyecto, enfocarlos, hacerles entender que su esfuerzo es esencial para sacarlo adelante y que solo se conseguirá el éxito si todos los equipos tienen éxito en la parte del proyecto en la que le toca trabajar.

Esto no se consigue con una charla, se consigue conversando mucho, escuchando más y promoviendo que los trabajos de los equipos sean abiertos, de manera que todos tengan la oportunidad de conocer qué se está haciendo. De esta forma se reducirá la complejidad de la integración resultados ya que se detectarán problemas más temprano y por otro, que se tenga una visión global de los trabajos lo que facilitará el entendimiento de que o todos colaboran o esto no tendrá éxito.

No es sencillo que los equipos se abran a otros, sobre todo si son de organizaciones distintas, para facilitar esto es necesario que la apertura sea bidireccional y en las mismas condiciones, por otro lado hay que estar muy atento para atajar cuanto antes los conflictos que puedan acontecer.

Hay que evitar tener favoritos y tener un trato justo con los equipos. Es posible que un equipo esté desarrollando la parte más crítica del sistema y es posible que eso haga que le dediques mayor atención. Eso es algo lógico y no expresa favoritismo, sino sentido común. El trato justo se mide cuanto ante circunstancias similares tu comportamiento es el mismo con un equipo que con otro y cuando respetas de la misma manera el trabajo, siempre y cuando el mismo merezca ese respeto.

Mantener el equilibrio es complicado porque en el proyecto pasan muchas cosas. Habrá pasos adelante y pasos atrás, siendo estos últimos más largos generalmente que los primeros porque esto de trabajar en equipo funciona si hay confianza y la confianza cuesta mucho conseguirla y es muy sencilla de perder.

Al final, uno puede intentar todo lo posible porque todos los equipos trabajen como uno, para reducir distancias, para ayudar en la resolución de problemas pero sin la voluntad por parte de los mismos y/o sus organizaciones no será posible. Se puede estar un tiempo con el viento en contra, con un equipo o varios equipos que no quieren adaptarse a este esquema de funcionamiento, pero no todo el proyecto, porque habrá quien, con razón, termine por no aguantar esta situación.

Un equipo de personas que no se entienden, que no conectan, que no está equilibrado, es una forma de tirar talento individual a la basura porque en el desarrollo de software se obtiene provecho de ese talento cuando se pone a favor de un colectivo, en el que se rompen las matemáticas porque su valor conjunto será mayor que la suma de las individualidades. Esto es así porque se complementan conocimientos y experiencias y porque visiones diferentes de un problema ofrecen mayores alternativas de solución.

Si un equipo no funciona, el proyecto no irá bien. Y no hace falta mucho para que un equipo no funciona, como tampoco hace falta mucho para que un código no compile. Por ese motivo, es necesario hacer un esfuerzo para conformar el mejor equipo posible dentro de la disponibilidad que exista en la organización.

Este antipatrón surge cuando no se le da importancia a la formación del equipo, seleccionándose exclusivamente perfiles sin tener en cuenta a las personas, como si fuéramos simples piezas de una maquinaria que se escogen al azar, y si hay algo que no es precisamente simple son los seres humanos.

El lado opuesto del antipatrón se encuentra en dar autonomía a los equipos para que sean ellos mismos los que seleccionen a las personas que lo van a formar y decidan sobre las entradas y salidas a lo largo del proyecto. Quienes están a pie de obra saben muy bien (aunque se equivoquen) quiénes pueden ser los mejores compañeros para este viaje.

Si no se cae en malas prácticas como el amiguismo o la falta de responsabilidad es una fórmula que puede funcionar muy bien, siempre y cuando exista comunicación fluida y en confianza con los gestores (recíproca) porque no todas las variables se encuentran en el equipo, ya que hay otras que se mueven a otro nivel ya sea dentro de la organización o en las relaciones cliente-proveedor.

Hay quienes consideran que el simple hecho de que el equipo sea designado por un tercero es un antipatrón (de hecho lo denominan: equipo designado). Yo no estoy de acuerdo con que ese simple hecho constituya una mala práctica, por mucho de que, por regla general, sean más óptimas soluciones más abiertas como la que comento en el párrafo anterior, ya que el antipatrón surge por no hacer esa selección de manera responsable, pensando más allá que en el simple hecho de cubrir huecos con personas.

Si realmente no tenemos que depender de nadie en nuestro trabajo no tiene por qué existir la organización, no tiene por qué existir una visión de colectivo o de trabajo en equipo.

Salvo que trabajes solo y que tu seas tu propia empresa no te vas a encontrar en ninguna circunstancia donde no dependas de un tercero por lo que lo quieras o no debes mirar un poco más allá de ti mismo y tener una visión más amplia del trabajo que realizas.

Aunque parezca mentira no eres el ombligo del mundo, cuando antes lo asumas mucho mejor. Eres parte de una maquinaria, una parte muy importante, tu trabajo es importante para que todo funcione, si lo haces bien todo va un poco mejor, si lo haces mal todo va un poco peor. Y no lo olvides, en esa maquinaria todas las piezas (sin excepción) son sustituibles.

Somos individualistas, los desarrolladores de software todavía más, sobre todo cuando vienes de trabajar mucho tiempo en proyectos basados en enfoques clásicos, yo siempre he sido muy individualista (y todavía arrastro mucho de ello) pero con los años me he dado cuenta de la importancia del colectivo para sacar adelante el trabajo.

Los enfoques ágiles que tienen como pilares fundamentales la cooperación y la comunicación están sentando unas bases importantes para que con el paso del tiempo los desarrolladores consideren como algo natural el trabajo en equipo y no como un inconveniente necesario.

Sin embargo los equipos dentro de una organización tienden a cerrarse sobre sí, a crear ciudades estado que si bien rinden pleitesía a la organización no dan ni agua a la de al lado (solo a las que son aliadas). Hay mucho que trabajar en ese sentido porque el trabajo en equipo no es solo con tu compañero de proyecto o con quien te lleves bien (o con quien te convenga llevarte bien) sino que debe extenderse más allá porque de lo contrario no estamos hablando de organización propiamente dicha sino de microorganizaciones cada una de las cuales con su conocimiento, sus objetivos y dinámicas de funcionamiento.

Cuando se rompe la colaboración efectiva y la confianza entre algunos de los equipos que participan en el desarrollo del proyecto comienza el inicio del fin del mismo.

Hay circunstancias que no puedes controlar, como es el hecho de que alguien de tu equipo o de otro equipo provoquen situaciones que pueden desencadenar en fracturas de esas relaciones.

¿Qué se puede hacer en estos casos?

– Gestionar de manera adecuada la presión, ya que en estos contextos este tipo de situaciones son más probables.
– En muchas ocasiones podremos detectar a tiempo que se va a producir un conflicto ya sea a través de una charla dentro del equipo o a través de correos electrónicos en los que estamos en copia y en los que las palabras y comentarios empiezan a tomar un tono áspero. Puede que, a veces, se trate de una falsa alarma pero agradecerás haber intervenido en cualquier caso.

Como gestor debes intentar prevenir estas circunstancias y ser consciente de que tu actitud y mensajes pueden alentar a la calma o al conflicto. Si haces que tu equipo adopte una posición defensiva, se defenderá y fuerte. Si haces que tu equipo vea en el otro al enemigo, no puedes esperar que siempre la actitud sea pacífica.

La prevención no será siempre suficiente y existe la posibilidad de que surjan conflictos, cuando eso ocurra no dejes que la bola se haga más grande, actúa. Tal vez las personas implicadas tarden en cicatrizar sus heridas pero será peor si se deja que la situación se encone porque los equipos tienden a cerrar filas con sus compañeros y lo que puede ser una discusión de dos se puede extender a otros componentes del equipo.

No todo el mundo tiene por qué entenderse, no se trata de forzar lo que a la larga no tiene arreglo, sino de entender que estamos en un proyecto y que para conseguir los objetivos se tiene que afrontar desde una situación donde predomine el espíritu de colaboración y no el conflicto. Habrá tiempo tras el proyecto de replantearnos circunstancias o incluso de hacer cambios, si fuera necesario, dentro del mismo si ello produce más beneficios que pérdidas.