No existe un punto único de verdad sobre los equipos y su forma de trabajar. De manera similar a la forma en que la mayoría de la literatura centrada en el liderazgo enfatiza demasiado la importancia de "las habilidades y rasgos del líder", descuida la perspectiva del "seguidor", la mayoría de las publicaciones centradas en el equipo se enfocan en "administrar / formar equipo". La narrativa sobre cómo pueden los individuos encajar bien o alinearse mejor dentro de un equipo es prácticamente inexistente. En el contexto de la popularidad del modelo multifuncional de equipos con toma de decisiones descentralizada y responsabilidad compartida (es decir, la capacidad de responder), esto crea un espacio de discusión sobre las expectativas de cada uno de los miembros del equipo.
En esta publicación de blog, espero resumir algunas de mis ideas sobre la perspectiva del compañero de equipo y las competencias necesarias para que un equipo funcione bien. Mi objetivo en este artículo es dibujar un esquema de ideas, y apuntar conceptos con los que quizá no estés de acuerdo y que puedas generar conversaciones posteriores. Además, lo que es más importante, mis puntos de vista están contextualizados y acotados a equipos involucrados en el desarrollo de software. Creo que cada profesión e industria tiene idiosincrasias que no se pueden obviar y vale la pena tenerlo en cuenta.
Te invitamos a escuchar nuestro podcast Cómo crear un dream team. Hablamos sobre estos temas con unos invitados muy especiales.
La motivación para generar un tipo de "trabajo colaborativo" se puede simplificar en dos dimensiones: volumen de tareas y complejidad. En este punto, creo que los personajes del equipo comenzarán a diferenciarse, los equipos con más enfoque en el volumen de trabajo tendrán formas y propiedades muy diferentes a los que se enfocan en resolver problemas complejos. Independientemente de los valores para un eje dado, un equipo puede reinventarse como una versión ampliada de un solo individuo. Lo que diferirá es la fuerza de la interdependencia y los patrones de comunicación resultantes.
Desde la perspectiva de un miembro del equipo, la confianza y la comunicación parecen ser elementos subyacentes de una colaboración eficaz. A partir de esos dos elementos, podemos inferir más dependencias que son componentes del marco del equipo. Creo que la confianza está en el centro del proceso de trabajo en equipo y sin ella es difícil avanzar. Para establecer la confianza, debemos ser capaces de satisfacer los tres criterios principales: ser un yo auténtico, tener una lógica sólida (es decir, ser capaz de transmitir argumentos lógicamente sólidos de manera comprensible) y, finalmente, mostrar empatía hacia otros miembros del equipo. Es más fácil decirlo que hacerlo, y resulta difícil practicar cualquiera de los criterios (especialmente la autenticidad y la empatía) que necesitamos para crear seguridad. Establecer la seguridad, ante todo, requiere tiempo, que también implica la apreciación mutua de las diferencias personales, el apoyo compartido y una cierta fuerza de carácter de todas las personas involucradas.
He mencionado anteriormente la comunicación, que no solo es una opción obvia, sino también la más fácil de aprender y dominar de las "soft skills" (habilidades CORE). Creo que la mayoría de las personas que se dieron cuenta de que podrían tener demasiadas suposiciones sobre lo que alguien está diciendo y están sintonizadas para escuchar y prestar atención a lo que escuchan, están en el camino correcto para comunicarse bien. El siguiente paso suele ser aprender a hacer más preguntas para aclarar más y eliminar sus suposiciones. La regla general aquí es: cuanto menos sepa, más vacíos llenará con su imaginación, cuanto más seguro esté, menos probabilidades tendrá de estar en lo cierto. Perfectamente enrevesado.
Recientemente realicé una serie de meetups sobre soft skills en los equipos desarrollo de software, que podrían servir de base a las diferencias personales, la empatía y la comunicación (entre otras cosas).
Una nota final, los equipos que adoptan la experimentación activa (es decir, diseño, planificación, recopilación de datos, análisis, comentarios) tienden a superar significativamente a los equipos que no lo hacen. En ese sentido, vale la pena recordar que el riesgo de caer en el sesgo de confirmación durante la experimentación tendrá consecuencias negativas. Celebra el fracaso. Pero esa es otra historia.
Si quieres ampliar información sobre este tema, te proponemos que continues leyendo:
Las certificaciones cloud se han convertido en un aspecto esencial del sector tecnológico, y Azure ofrece una amplia gama de certificaciones para..
Matheus Marabesi, software craftsperson en Codurance, analiza en profundidad la lista de los 22 antipatrones de TDD recopilada por James Carr. A..
Ser un líder técnico eficaz va más allá del establecimiento de tareas y objetivos: abarca la creación de un entorno donde los developers realmente..
Suscríbete a nuestra newsletter para que podamos hacerte llegar recomendaciones de expertos y casos prácticos inspiradores
