ERP

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.

Motivación del equipo

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).

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

Sobre Sergio Martínez

Dirección desarrollo e implantación ERP en Daemon4 Socialmedia, TIC, IDi, e-commerce, 2.0... Blogger en https://mundoerp.com

5 comentarios

  1. Es de agradecer contar con tu experiencia para enseñarnos a los demás. Gracias por compartirla. Buen trabajo.

  2. A mi una cosa que se me ocurre, y que ya te dije en su momento, 🙂 es que se puedan desarrollar proyectos propios, sois una empresa de desarrollo de software y se puede hacer de todo, en algunas ocasiones desarrollar cosas diferentes motiva, distiende y amplia conocimientos, algo muy valido para esta profesión.

    • Gracias Toni por tu comentario.

      Estoy de acuerdo en lo fundamental, y es la necesidad de que el personal siga encontrando atractivo este oficio, sobre todo con proyectos ajenos al alienante trabajo diario y que de alguna forma les permita desarrollarse en otros ámbitos (técnica como personalmente).

      Ahora bien, las organizaciones, hoy día (a excepción de Google y algunas empresas similares), no tienen el sustento mínimo garantizado, por lo que dedicar recursos a actividades de «dudosa» utilidad debe ser analizado en cada caso.

      Estoy seguro que recuerdas algún caso de algún programador que de forma recurrente te decía que se tardaba 2-3 días en realizar un proyecto, y así presupuestabas tú, en base a ese criterio, y el susodicho tardaba semanas y semanas en finalizarlo. Eso sí, había satisfecho notablemente su creatividad así como mejorado sus conocimientos a costa de la empresa (y de sus compañeros, claro).

      Pienso que en el término medio puede darse una coexistencia de ambos puntos de vista. Se trata de pensar en proyectos, y consensuarlos con el personal, que sean atractivos para los desarrolladores pero que nazcan con un claro objetivo de aplicabilidad para la empresa. De esta forma la organización puede obtener un rendimiento de su comercialización desde el minuto 0 y el desarrollador puede satisfacer su creatividad.

      Un saludo, y puedes volver cuando quieras por aquí.

Comentar

Su dirección de correo electrónico no será publicada.Los campos necesarios están marcados *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

x

Check Also

El Internet de las Cosas (IoT), la tecnología que impulsará el crecimiento de las empresas

El IOT es el conjunto de tecnologías que permite la interconexión de objetos con elementos de su alrededor.

Subvenciones y ayudas para proyectos TIC

Me siento desanimado y frustrado. Hace años que lo intentamos, pero no hay forma. Siempre ...

Deshojando la margarita… Proyecto sí, proyecto no…

Hace un par de semanas me llamaba un cliente con gran urgencia para acometer un ...

No todos los cambios son percibidos como buenos

De vuelta sobre el rechazo al cambio

Sé que hemos hablado en innumerables ocasiones sobre la gestión del cambio, pero no deja ...

Industria inteligente/digital (4.0), IoT, Big Data, … y los actuales ERP

Desde hace unos meses, parece haberse extendido nuevos conceptos tales como Smart Industries, Industria Inteligente, ...