La motivación del equipo de desarrollo software

Antes de profundizar en los distintos aspectos a tener en cuenta para lograr la motivación del equipo de desarrollo, comenzaré este artículo con un relato algo personal …

En una ocasión, en una empresa en la que trabajé, el responsable de proyectos disponía de 8 personas a su cargo, yo uno entre ellos. A pesar de ser un equipo relativamente amplio, la concentración de trabajo recaía fundamentalmente en dos personas (un compañero y yo). Esto llevaba a que los proyectos más duros y complicados eran asignados a nosotros de forma recurrente. A pesar que el resto de compañeros disponían de un bagaje y competencia profesional sobrada, la confianza «ciega» que mostraba nuestro responsable hacia nosotros, le hacía derivar una excesiva carga de trabajo y responsabilidad hacia nosotros. Se daba también la circunstancia que determinados pequeños proyectos (algunos nada complicados) pero que requerían plazos muy reducidos de entrega, también nos eran encomendados precisamente por la misma razón de confianza.

Así las cosas, la presión ejercida sobre nosotros era de una gran intensidad, pero además, se nos relevaba de los proyectos sin haberlos finalizado (eso sí, una vez estuviesen encauzados y estabilizados) para trasladarlos a otros compañeros, debido a nuestra baja disponibilidad. La sensación era de ser un «zapador», siempre lleno de barro hasta los ojos, abriendo camino para dejar paso a las tropas uniformadas con su traje de desfile. 

Una cuestión no baladí era que el sueldo de todos nosotros era muy similar. El mío concretamente era ligeramente más alto, pero el de mi compañero estaba por debajo de otros compañeros (de los uniformados). Por esa época yo ya disponía de una vida familiar, por lo que fuera de mi horario laboral (de bastantes más horas de las 8 diarias) no podía hacer mucho más, pero mi compañero no era raro verlo trabajar sábados y algún que otro domingo.

Todo ello había sido hablado con nuestro responsable, y no era una percepción subjetiva nuestra, sino que valoraba la situación de la misma manera. Aunque eso daba igual, cualquier nuevo proyecto se seguían las mismas pautas. Tampoco podíamos quejarnos a nadie jerárquicamente superior, porque nuestro responsable era además gerente. La sensación de impotencia y frustración era creciente con los años.

Mi compañero se despidió de un día para otro, y yo continué en mi línea durante unos meses hasta que finalmente me trasladaron la responsabilidad como jefe de proyectos. En ese momento, mi superior estaba más dedicado a otros temas, así que derivó sus tareas y responsabilidad en mi persona, no sin antes provocar alguna crisis más tras dejar sin apoyo a un desarrollador ante un cliente muy exigente y con muy malos modos. El técnico se despidió tras una reunión con un cliente, y podéis adivinar a quien le tocó hacerse cargo del proyecto.

Estoy seguro que en mi cargo actual cometo un gran número de fallos y no comunico suficientemente bien a mis compañeros ciertas tareas, pero lo que sí procuro tener en cuenta es en mantener la motivación del equipo. Los proyectos se tratan de repartir por igual, por supuesto en base a las experiencias y conocimientos de cada uno, pero en cuanto se asigna un proyecto a alguien con cierta complejidad o tensión, se le ofrece los siguientes con algo más de relajamiento. En cuanto la carga de trabajo de uno se dispara, se reasignan tareas a otros hasta compensarse. Otras fórmulas que se ha usado en alguna ocasión es un incentivo económico puntual (por desgracia, estos últimos años esto es más complicado), así como el disfrute de algún día libre adicional.

Tras el caso personal, podríamos concluir que la motivación del equipo puede conseguirse atendiendo a algunos aspectos:

• Participando en los objetivos y metas del proyecto
• Clima de organización en el proyecto (y no hay nada mejor que involucrándolos en las decisiones)
• Acompañamiento en tareas de cierta responsabilidad y/o complejidad.
• Reparto y equilibrado de las tareas entre el equipo
• Confianza y respeto
• Asignación de tareas que permitan el crecimiento laboral de cada miembro del equipo
• Recompensas: económicas, días libres, reconocimiento, …
• Uso de refuerzos positivos
• Liderazgo por encima de la autoridad
• Y comunicación e información en todo momento tanto de la evolución del proyecto como de los problemas que se van originando.
• En ocasiones, por el hecho de ser el responsable de tomar decisiones y como no se puede estar justificando toda decisión, puede dar la percepción a los compañeros de decidir no siempre con mucho criterio (‘Yo habría optado por…’, ‘Te dije que …’, etc.), o lo que es peor, de tener un cierto carácter de prepotencia, o incluso despótico. Aunque pueda parecer exagerado, la visión que puede tener cierto personal de desconfianza hacia su superior puede a veces ir en esa línea. Yo soy muy poco hablador y en un ocasión tuve un problema con un compañero por este hecho, porque consideraba que no justificaba mis decisiones.
• En nuestra empresa, estamos inmersos en desarrollos verticalizados, donde son los clientes los que van sugiriendo mejoras funcionales a nuestras soluciones. Y aunque yo soy el responsable de uno de los productos, el roadmap funcional se consensúa con los desarrolladores, incluso en algunos casos, son ellos los que tienen plena potestad para decidir qué hacer y qué no, así como el orden de prioridades (siempre que informen). Evidentemente hay un roadmap estratégico que está por encima y en el que tienen menos capacidad de decisión, y que en este caso analizo y priorizo con el resto de miembros de dirección.
• Periódicamente (menos de las que debería) realizo reuniones con todos ellos conjuntamente para analizar la situación del producto, de los clientes, de la empresa, etc. Y periódicamente, también realizo reuniones individuales con cada uno de ellos con la finalidad de detectar problemas que puedan afectar a su rendimiento o al clima laboral. En esas reuniones suelen surgir mejoras o cambios ya sea en los productos o en la empresa y que trascienden a dirección. En ocasiones se aprueban y otras se deniegan, pero siempre tratamos de escuchar todas las peticiones.

Reconozco que ya me gustaría cumplir con todos los aspectos mencionados, pero es evidente que no es así. ¿Se os ocurre otras formas de motivación del equipo de desarrollo?

(En el Master en Software Libre de Gestión: Open Source & ERP II, estamos analizando situaciones como la que aquí acabamos de mostrar).

Autor: Sergio Martínez

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly

Email