icono_twiter
Alejandro Pérez García

Alejandro es socio fundador de Autentia y nuestro experto en J2EE, Linux y optimización de aplicaciones empresariales.

Ingeniero en Informática y Certified ScrumMaster

Si te gusta lo que ves, puedes contratarle para darte ayuda con soporte experto, impartir cursos presenciales en tu empresa o para que realicemos tus proyectos como factoría (Madrid).
Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación.

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2010-10-16

Tutorial visitado 3.803 veces Descargar en PDF
Reunión Madrid Ágil 14-10-2010: Equipos autogestionados, y motivación del individuo y del equipo

Reunión Madrid Ágil 14-10-2010: Equipos autogestionados, y motivación del individuo y del equipo

Creación: 15-09-2010



Índice de contenidos

1. Introducción
2. Equipos autogestionados, ¿qué es? ¿cómo se consigue?
3. Motivación, tanto del individuo como del equipo
4. Conclusiones
5. Sobre el autor


1. Introducción

El 14-10-2010 tuvo lugar una de las reuniones de Madrid Ágil, en la que se habló de:

  • Equipos autogestionados, ¿qué es? ¿cómo se consigue?

  • Motivación, tanto del individuo como del equipo.

En este artículo voy a contar mis impresiones después de la reunión.



2. Equipos autogestionados, ¿qué es? ¿cómo se consigue?

Los temas escogidos para esta reunión son especialmente complicados porque versan sobre el trato con personas y dejan a un lado la parte técnica. Teniendo en cuenta que las personas somos individuos únicos, con nuestros sentimientos, nuestros complejos, y nuestros condicionamientos, todo lo que tenga que ver con el trato personal y la “confección” de equipos (grupos de personas que tienen que relacionarse unos con otros constantemente) será siempre complicado, ya que no hay un libro de recetas que podamos aplicar igual para todas las personas en todos los casos o situaciones. De esta forma un equipo autogestionado conseguirá un ritmo sostenible, sera autoexigente, tendrá autoconfianza.

Sí hay algunos puntos en los que parece que todo el mundo está de acuerdo, por ejemplo ¿qué es un equipo autogestionado?

Un equipo autogestionado sería un equipo donde los desarrolladores son capaces de tomar decisiones y llevar las riendas del proyecto, sin necesidad de que exista un “jefe” que “ordene” las cosas. El equipo será capaz de llevar la relación con el cliente, será capaz de marcarse fechas ajustadas, será capaz de decidir la forma de trabajo, de exigirse cada vez un poco más, incluso será capaz de “darse un capón” a sí mismo en caso de no hacer las cosas bien (todo el mundo se equivoca, lo importante es reconocerlo y ser capaz de aprender de ello).

Esta respuesta parece obvia, pero no lo es tanto, sobre todo por lo difícil que resulta encontrar un equipo autogestionado. En casi todos los equipos encontraremos esa figura del “jefe”, incluso en muchas ocasiones por petición de los propios trabajadores. Esto puede ser debido a la costumbre (casi todo el mundo está acostumbrado a trabajar en entornos donde otro le dice que es lo que tiene que hacer), y a que hay gente que simplemente no quiere responsabilidades, y tomar decisiones es una forma de responsabilidad.

Después de hablar de estas cosas queda claro que los equipos autogestionados se ven poco, son mucho más productivos que el típico modelo de “ordeno y mando”, y que no todo el mundo sirve para estar en un equipo autogestionado.

También se habló de como intentar conseguir que un equipo sea autogestionado. Algunos puntos interesantes:

  • Transparencia: El conseguir un entorno donde todo el mundo vea todo y sepa el por qué de las cosas, ayuda mucho a que la gente sea capaz de tomar decisiones por sí misma (sin información no se pueden tomar decisiones).

  • Un entorno que lo permite: Es fundamental un entorno donde los “jefes” tomen confianza para dejar hacer al equipo. Esto es muy difícil de conseguir sobre todo en situaciones de “crisis” cuando se ve que el equipo se está equivocando. La dirección tendrá que intentar hacer justamente eso, marcar una dirección, unos objetivos a conseguir, pero no debería sacar la vara para enderezar el rumbo. Debería hacer que el equipo comprenda la situación para que este se autoenderezca.

  • Todas las personas, y por lo tanto todos los equipos, son diferentes: Es por esto que no todos los equipos pueden llegar a ser autogestionados, y que la forma de conseguirlo no sea siempre la misma.

  • Rodaje: Todo el mundo está de acuerdo en que la autogestión no se consigue de un día para otro. Pede ser un proceso de meses o años, ya que hay que adaptar al equipo, a la dirección y a toda la empresa.

  • Reacios al cambio: Mucha gente no quiere cambiar, no quiere salir de su círculo de comodidad, así que va a poner pegas. En la reunión había quien decía que este tipo de personas hay que despedirlas de la empresa. Yo no soy tan radical (puede que peque de inocencia), pero siempre pienso que a cada persona se le puede encontrar su sitio o su motivación para cambiar (no todos somos iguales, no todos tenemos las mismas capacidades, intentemos aprovechar lo mejor de cada uno).

Dentro de los equipos autogestionados sí existe la figura de líder o de Gurú. Es una persona a la que respeta el resto del equipo y que saben que se pueden apoyar en él para la toma de decisiones. El equipo sólo recurrirá a este líder en situaciones especialmente difíciles.



3. Motivación, tanto del individuo como del equipo

Si el punto anterior es complicado, el de la motivación mucho más ya que hay que encontrar y potenciar las expectativas de cada uno como individuo y como equipo.

Se vio que algunos factores motivadores son:

  • Motivar en función de lo que busca cada uno. Hay quien quiere salir pronto, quien le gustan los retos, hay quien quiere posicionarse como líder técnico ... hay que intentar dar a cada uno lo que busca.

  • Foco, issues pequeños. Mola entregar y ver como movemos tarjetas y percibimos avance.

  • Agresión externa como factor motivador. Esto no siempre tiene porque ser bueno y puede llegar a desmotivar al equipo, pero en cierta medida, cuando el equipo se enfrenta ante un problema, en muchas ocasiones sacan fuerzas de flaqueza por el simple hecho de superación del escollo.

  • El estatus conseguido. Si el equipo lo hace bien, sabe que va a alcanzar un estatus y el reconocimiento de sus compañeros.

  • Facilitar resultados del equipo. Esto sería un poco el hecho de dejar trabajar a la gente. Es lo que hace el Scrum Master dentro de su perfil de “facilitador”.

  • Que el equipo sepa por qué se hacen las cosas. Estaría enlazado con la transparencia de la que hablábamos antes, y la autogestión. Si la gente no sabe porque hace algo, o no entiende el por qué, se sienten meros peones y no protagonistas, con la desmotivación correspondiente.



En general se habló de que el propio “cambio” genera motivación. Es decir, si nunca cambia nada, la gente se aburre, se acomoda y se desmotiva. El hecho de que constantemente haya cambios en el entorno parece que es un factor motivador en sí mismo, que mantiene a la gente despierta, alerta. Por supuesto estamos hablando de cambios a mejor, no a peor ;)

También se habló de la libertad como importante factor motivador. Muy relacionado con equipos autogestionados, donde es el equipo el que toma las decisiones y compromisos (si otro me impone un compromiso y luego no lo cumplo, no me afecta mucho puesto que el compromiso no era mio; si yo me comprometo y luego fallo, suele afectarme más y hacerme querer ser mejor la próxima vez).



4. Conclusiones

Es difícil sacar conclusiones absolutas y generalistas para estos temas, pero todo el mundo estaba de acuerdo en que un equipo autogestionado y motivado es mucho más productivo y feliz que otro que no lo es.

Está claro que para llegar a esta conclusión no hacia falta reunirse ;) pero lo interesante de la reunión es compartir las experiencias de cada uno e intentar buscar caminos para alcanzar ese estado. Incluso escuchar como gente habla de que una vez vio ese tipo de equipo y que por lo tanto no es un mito ;)



5. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. - "Soporte a Desarrollo"

http://www.autentia.com



A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL: