Motivación: Jefes de proyecto con valor añadido

Hace ya algo de tiempo conocí un caso en el que a una persona la iban a colocar como jefe de un proyecto dirigiendo a un equipo de unas seis u ocho personas porque se le daba muy bien tratar con la gente, trabajar con el project, manejar hojas de cálculo, crear informes, etc...

Hace menos conocí otro caso de una persona que dejaba su empresa para ir a trabajar en un camping porque le salía más rentable: cobraba más y se lo pasaba mejor.

Estos dos sucesos, aunque no lo parezca, tienen una relación. ¿Cómo puede motivarse un equipo de desarrolladores mal pagados para que permanezcan en la empresa durante un tiempo razonable?

Las metodologías ágiles promueven una serie de medidas para solucionar estos problemas como el realizar jornadas de trabajo de las horas necesarias, no realizar horas extras, mantener un buen ambiente de trabajo, trabajar en equipo, etc. etc. Todo esto está realmente bien, especialmente para no engañar a los trabajadores ( no es lo mismo cobrar 300€ a la semana por 40h que 300€ por 48h ), pero quizás donde algunas metodologías ágiles no se adentran todo lo necesario es en la figura de jefe de proyecto y sus consecuencias para el equipo. Algunas metodologías incluso promueven los equipos autónomos, sin ningún jefe de proyecto real que marque pautas, iteraciones, tareas, etc., pero bueno, eso ya es otro tema.

Muchas empresas se ven obligadas a contratar personas con unos salarios irrisorios, por diversas razones en las que tampoco voy a entrar. La cuestión es, ¿cómo mantener a estas personas en nuestra empresa cuando la realidad es que pueden cobrar más en cualquier camping y pasarse un verano fenomenal? Vaya, visto así, no parece demasiado sencillo, ¿verdad? :-)

La clave para mi está en la motivación, y uno de las personas que tiene la responsabilidad de tratar de motivar a estas personas es el jefe de proyecto. ¿De qué sirve tener un jefe de proyecto que sepa gestionar muy bien las tareas si no le va a ofrecer nada a sus desarrolladores? Normalmente estas situaciones terminarían en comentarios como "pepito no tiene ni idea", "tengo que hacer esto pero no me han dicho con qué", "vaya con el pepito, tenemos que resolver esto, le hemos preguntado como, y dice que lo busquemos en google".

La relación entre la empresa y el empleado en este caso ha de ser un acuerdo en el que los dos ganen algo. Ya que el empleado no va a cobrar mucho, al menos debe sacar otros beneficios. Por suerte, la época en la que la mejor quiniela en España era un trabajo ha pasado, al menos en este momento en el mundo de las TI. El acuerdo podría ser algo del estilo: "Mira, lo siento, me encantaría poder pagarte más pero ahora mismo es imposible. Nuestra oferta es para trabajar en este proyecto donde no vas a cobrar mucho pero vas a aprender un montón, trabajás con tecnologías actuales y se respetará el horario laboral".

El único modo de satisfacer esta propuesta es tener al mando de los equipos de desarrollo personas que realmente sepan lo que hacen, con un nivel técnico alto a la vez que capacidades de gestión de equipos. Poniéndome en el papel de una persona que cobre un salario bajo y que entre a trabajar en una factoría de software, o en cualquier cliente, bajo el mando de un jefe de proyecto, esto es lo que me gustaría encontrarme para que realmente me compensase el no irme a la playa a trabajar:

• Altos conocimientos técnicos: Puede llegar a ser difícil respetar a una persona que teóricamente es tu jefe y que sabes que no tiene los conocimientos técnicos para abordar el trabajo que tiene asignado.
  
  Del mismo modo, un proyecto necesita realizar una serie de decisiones técnicas, no sólo a su inicio, que no se deben delegar en terceras personas no relacionadas con el proyecto o incluso en el equipo de desarrolladores que quizás no tengan la experiencia necesaria para abordarlas.
  
  No confundirme en este último punto. Siempre se debe tener en cuenta la opinión del equipo de desarrollo. Esto es fundamental. Pero, en mi opinión, la decisión debería ser un consenso entre ambas partes. Sea como sea, es muy importante que el jefe de proyecto sepa realmente de lo que se está hablando.
  
  
• Hacer ingeniería: Es importante que un jefe de proyecto sea capaz de forzar buenas prácticas, patrones de diseño, que sea capaz de enseñarle a sus desarrolladores a adaptarse a una metodología, que siga buenas costumbres como la integración continua o el desarrollo orientado a pruebas. Todo esto hará realmente que los desarrolladores vean su trabajo como lo que es, como un arte, y no como una chapuza de tres al cuarto.
  
  
• Mantenerse al día: El jefe de proyecto debería ser el encargado de guiar a los desarrolladores y de saber discernir entre las últimas tendencias realmente útiles a los proyectos y los bluffs. Es muy importante que los proyectos utilizen tecnologías fiables, al tiempo que lo suficientemente novedosas para mantener alto el espíritu del equipo. ¿A quién no le gusta estar trabajando con lo último de lo último? Ahora bien, hay que saber distinguir el "último de lo último" que puede ser realmente útil al proyecto del mero artefacto de marketing.
  
  
• Capacidad de formación: El jefe de proyecto debería ser capaz de compartir sus conocimientos con las personas que tienen a su cargo. Esto hace que las personas se sientan bien porque están aprendiendo cosas y por lo tanto no sentirán que están perdiendo su tiempo en un lugar donde no se aprende nada.
  
  El estar trabajando con una persona que ves que cada día te ofrece algo nuevo y de la que continuamente estás aprendiendo algo, es una de las mejores sensaciones que puede tener una persona que comienza en esto de la informática, experiencia, por otra parte, probablemente extrapolable a cualquier otro sector.
  
  
• Ser capaz de bajar al nivel más bajo: Ser capaz de pringarse. Sí. Ser capaz de coger un ordenador, descargarse el código fuente del proyecto y mostrarle a un desarrollador del proyecto los errores que ha cometido. Esto evidentemente no quiere decir que el director tenga que solucionarle los problemas a los programadores, corrigiendo sus bugs, etc. Pero está muy bien el sentir la sensación de que hay una persona detrás de ti que tiene esa capacidad, lo que debería aumentar el respeto y la confianza del equipo de personas que está trabajando para ti.
  
  
• Habilidades como gestor de equipos: En todo equipo pueden surgir riñas, discusiones, conflictos, peleas, etc. que el jefe de proyecto debe ser capaz de afrontar y solventar. De nada sirven unas altas capacidades técnicas si después no eres capaz de mantener un buen entorno de trabajo.
  
  
• No forzar horarios: Y esto va en línea con todas las metodologías ágiles. Cuando tu equipo de personas ya se encuentra en una situación bastante precaria, de nada va a ayudar el hacerlos trabajar dos horas más al día.
  
  Sí, es cierto, a lo mejor resulta que el proyecto tiene que estar para ayer. Pero forzar la situación puede hacer que se te vaya de pronto la mitad del equipo a la competencia, así que igual la solución al problema está en otra parte de la jerarquía de la empresa.
  
  Evidentemente esto exige que el jefe de proyecto se deba a su equipo, sea un compañero más, y se encargue de velar de la estabilidad de la jornada laboral de sus subordinados
  

Bueno, y esto es más o menos todo lo que me gustaria tener. Básicamente, un trabajo en el que aunque no cobre mucho, me sirva para el futuro, me enseñe realmente tecnología, me enseñe realmente trabajo en equipo, y que no me haga sentir que estoy perdiendo el tiempo, y el dinero.

No sé si me he olvidado de algo, pero creo que es un ladrillo suficientemente grande :-)