Trabajar en equipo

Durante diciembre y enero, en el trabajo, hemos hecho bastantes entrevistas para una posición de Project Manager Assistant. Entre la gran mayoría de candidatos destacaba una misma idea: todos buscaban trabajar en equipo. Formar parte de un equipo. Los equipos tienen un propósito que está por encima del individuo. Compartir talentos, puntos de vista, formas de trabajar... para conseguir soluciones bajo unos objetivos comunes es clave para el buen rendimiento y el desarrollo personal.

Un equipo sin propósito, sin objetivos comunes, es sólo un grupo de personas haciendo tareas individuales coordinadas en tiempo y espacio. No son un equipo. No han creado las dinámicas para que unos mejoren a los otros. Un equipo debe querer mejorar su rendimiento siempre. Cambiar el rendimiento del equipo en su conjunto tiene mucho más impacto que hacerlo en el rendimiento individual. Un primer paso es trabajar en la autonomía.

Los equipos con la libertad de tomar decisiones y con la capacidad de improvisar marcan la diferencia. En cualquier momento un equipo puede encontrarse en adversidades, cambios imprevistos o situaciones no planificadas. En cada uno de estos momentos el equipo deberá dar respuestas. Para poder dar respuestas a estas situaciones es importante que el equipo tenga toda las capacidades necesarias para completar un proyecto. Podemos conseguirlo con un equipo multidisciplinar. Otra característica a tener presente es que los equipos pequeños hacen el trabajo más deprisa que los equipos grandes. Uniendo estas dos ideas lo mejor es crear equipos multidisciplinares del orden de siete personas.

Dentro de la dinámica de un equipo, culpar es un error. No hay que buscar personas que lo hacen mal. Hay que centrarse en buscar los sistemas malos, que incentivan la mala conducta y premian el bajo rendimiento.

Otro error muy común es querer añadir más efectivos a un proyecto de software en retraso. Como dice la Ley de Brooks, lo retrasará más. Las personas que se incorporan a un equipo necesitan un tiempo para ser productivas. También se genera un aumento de costes generales, en tiempo, a medida que aumenta el proyecto. Estamos hablando de los canales de comunicación, la toma de decisiones o la velocidad con la que viaja la información a través del equipo.

Existen algunas excepciones o soluciones a la Ley de Brooks. En primer lugar debemos determinar si el proyecto se encuentra realmente en retraso o si las estimaciones iniciales fueron demasiadas optimistas. En segundo lugar, debemos analizar si podemos añadir profesionales para tareas muy concretas, que liberen el volumen de trabajo sin aumentar los canales de comunicación (documentación, control de calidad...). La integración continua, el desarrollo guiado por pruebas, el desarrollo iterativo, la construcción de mínimos productos viables y otras prácticas del agile nos ayudan también a solucionar estos problemas.

Te ha gustado el post? Ayúdanos a dar a conocer Scrumízate i comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!