Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

?id=218b1efe-5e5b-4034-bfba-c51702aa26c0

15 consejos para programadores que aspiran a ser jefes de proyecto y responsables de equipo

Imagen ornamental. Hombre asomado al borde de una montaña en Yosemite, por Jeremy Perkins, CC0, vía Unsplash

Nota: este artículo también podría haberse enfocado a los responsables o directores de recursos humanos de empresas de programación, ya que son ellos los últimos responsables de fijar los organigramas de los equipos de desarrollo de software.

Hace unos meses tuve una conversación sobre este tema con un compañero de trabajo. Alejandro, programador sénior, me contó su historia:

Soy un programador "nato", y lo he sido durante más de 30 años. Muy orientado a objetivos y a los plazos, una especie de obseso del control. Está en mi naturaleza. Durante mi vida laboral he ejercido de jefe de proyecto dos veces. Lo odiaba. Siempre fui muy bueno en la gestión de mis proyectos y de mi tiempo. Casi siempre cumplía con los plazos, dentro o cerca del presupuesto, superaba las expectativas, y todas las demás cosas que hacen los buenos programadores.

Sin embargo, era absolutamente pésimo en la gestión de los miembros de mi equipo. Siempre me pareció que las cosas que eran obvias para mí -casi instintivas- no lo eran tanto para los demás. A menudo me frustraba que los miembros de mi equipo no pudieran sacar adelante cosas que eran obvias y fáciles de hacer para mí. Rápidamente me di cuenta de que quería programar. No quería sentarme en reuniones -me aburría- repasando los requisitos del proyecto hasta el aburrimiento para acabar detectando que algún miembro del equipo no solo es que estuviese fuera de juego, sino que ni siquiera estaba en el campo de fútbol en relación con el proyecto.

La parte más frustrante es saber que lleva más tiempo (a veces mucho más) explicar algo a un programador que lo que lleva hacerlo uno mismo pero así es como aprenden los programadores novatos. Aun así, es frustrante. A mis 55 años, la única forma viable que veo para volver a ejercer de responsable de equipos sería "desaprendiendo" todo lo que sé y reajustando y reciclando todas mis aptitudes y habilidades en las que destaco, y no volviendo a programar jamás. Pero eso no va a pasar...

En otras palabras, lo que Alejandro me quería transmitir es que la programación exige una forma de pensar muy particular: tiene que ser analítica, focalizada, obstinada, con capacidad de abstracción y de creación de modelos y patrones. Estas son todas importantes aptitudes para un programador, pero no tanto para un coordinador de equipos.

Los responsables de departamento tratan con personas, que son susceptibles e incoherentes, donde las opiniones y los sentimientos importan tanto como los datos y los hechos, donde el responsable debe pasar rápidamente de una actividad a otra, y donde nunca se termina o cierra nada como sí sucede con la programación.

Los buenos programadores, los programadores natos, rehúyen de la gestión de equipos y siempre están buscando la precisión y la fiabilidad de trabajar con máquinas.

Porque la gestión de personas no es el siguiente paso en la trayectoria profesional de la programación, es una trayectoria profesional completamente diferente. Es lo mismo que plantearse por qué los pintores no quieren dirigir galerías de arte 🤔

En pocas palabras, la coordinación no les proporciona demasiada satisfacción a muchos programadores. Los coordinadores no programan, en general, y a muchos programadores lo que les gusta es la programación.

Muchos programadores que pasan a ser coordinadores de equipos suelen ser las primeras víctimas del principio de Peter, que afirma que las personas que realizan bien su trabajo son promocionadas a puestos de mayor responsabilidad, a tal punto que llegan a un puesto en el que no pueden formular ni siquiera los objetivos de un trabajo, y alcanzan su máximo nivel de incompetencia.

Hay muchos casos como el de Alejandro, que aceptan el reto de gestionar un departamento o un proyecto y terminan optando por volver a ser programadores sénior y repudiando el trabajo de coordinación.

Por este motivo, estas palabras pueden servir de advertencia a los responsables de recursos humanos. El mejor programador no siempre es el mejor jefe, ni mucho menos, y eso te lo dicen los propios programadores si se sienten libres para expresar lo que de verdad piensan.

En general, los desarrolladores evitan la gestión porque no quieren ser incompetentes y no quieren ser vistos como incompetentes - pues ya lo han sufrido en sus propias carnes cuando un compañero programador les ha dirigido.

Ahora bien, si eres programador, pero en verdad tienes vocación de líder, estos 15 consejos son para ti. Si el simple hecho de imaginarte haciendo cualquiera de estas tareas ya te repugna, ya sabes que no es lo tuyo 😜

1. Inspira y motiva a tu equipo

Inspira a los miembros de tu equipo para que piensen a lo grande y ayúdales a conseguir sus metas. Debes buscar siempre motivar a través de tus actos y de tus palabras, incluso compartiendo tus experiencias de fracaso personal para hacerles perder el miedo a no tener éxito siempre.

2. Lidera con el ejemplo

Un buen líder jamás exigirá a su equipo realizar un proyecto que no es capaz de abordar por sí mismo. Dar la matraca con charlas motivacionales no basta. Un buen jefe de proyecto tiene que saber planificar, actuar y rendir para liderar con el ejemplo.

3. Ten siempre un plan

Para sacar las tareas adelante con éxito siempre tienes que tener un plan para ir por delante de los acontecimientos. Da igual que la tarea en cuestión sea muy pequeña o si se trata de un gran proyecto, un buen líder siempre tiene un plan bien pensado para lograr cumplirlo.

4. Sé optimista

Tener una actitud positiva es un requisito indispensable. Mantente, junto con el equipo, enfocado en los aspectos positivos. Dale importancia a los detalles y motiva a los programadores con refuerzo positivo.

5. Pon el foco en cómo resolver los problemas

Debes tener un enfoque orientado a solucionar las cosas. Los reproches y estar constantemente buscando culpables no funciona cuando tratamos con desarrolladores. Además, no refleja una personalidad madura de líder. A los programadores les encantan los jefes que son capaces de prever los problemas con antelación y ayudarles a resolverlos, antes de que se conviertan en grandes bugs o errores de programación que obligan a rehacer grandes estructuras de código.

6. Mantén reuniones cara a cara

Para reconducir situaciones conflictivas es mejor sentarse cara a cara con las personas (aunque sea por videoconferencia), y más cuando tratamos con programadores. Los emails y los chats en muchos casos agravan los conflictos. Hay que saber detectar cuando algún miembro del equipo lo que en verdad necesita es tener una conversación en persona. Hay una máxima en gestión de personas que dice que es mejor alabar en público y criticar en privado.

7. Muéstrate accesible

Intenta comunicarte con tu equipo de manera periódica. Sé una persona cercana y déjales saber a los miembros del equipo que tu prioridad son ellos, que tu trabajo es ayudarles y darles consejo. No hay nada más potente en una empresa de desarrollo que contar con líderes que de verdad están ocupados en atender a los problemas de los programadores.

8. No te quejes

Procura no quejarte de todos los pequeños detalles a cada rato. A los programadores no les gusta mucho el estilo quejica de liderazgo. Mantén la serenidad en los momentos difíciles, aunque tengas razón, e intenta gestionar los problemas en frío.

9. Evita el favoritismo

Trata a todos los miembros del equipo de forma ecuánime. Ser laxo con unos y muy exigente con otros no te llevará muy lejos. No seas parcial.

10. Da reconocimientos y halagos

Muchas encuestas dicen que, a partir de un nivel de ingresos determinado, el 65% de los empleados se sienten más felices cuando se les reconoce su trabajo en público frente a un 35% que prefieren un aumento de sueldo. Un buen líder nunca infravalora la importancia de mostrar reconocimiento y aprecio de forma pública y en privado.

11. Sé mentor de tu equipo

A los empleados les gusta que alguien les acoja como tutor. Dales oportunidades de formación e impulsa el desarrollo personal y profesional. 2 de cada 3 programadores afirman que su jefe directo es la persona que más impacto tiene en su crecimiento profesional.

12. Asume riesgos

Ten confianza a la hora de asumir nuevos desafíos, incluso si son arriesgados. Un líder responsable siempre tendrá más margen para cometer errores y aprender de ellos. Anima a tus compañeros a asumir sus propios riesgos, y a que no tengan miedo.

13. Gestiona tu ego

No seas ególatra. La humildad es una fórmula que promueve la creatividad y las nuevas ideas, además te ayudará a ganar la lealtad de los miembros del equipo.

14. Otorga libertad

La libertad de trabajar, hablar y actuar es inherente a cualquier persona. No las limites ni controles todo lo que hacen los miembros de tu equipo. Evita la microgestión. Anímales a hacer su trabajo de la forma que mejor consideren y exígeles resultados. Dales confianza y muestra fe en sus propios criterios.

15. Muestra emotividad

Sé profesional, pero no dejes de mostrar tus emociones. Expresa emoción, aprecio, empatía y alegría cuando sea pertinente. Al final, un buen líder se muestra humano. Ser profesional y mostrarse humano y vulnerable es una buena combinación.

---

Conociendo a muchos programadores, soy consciente de que todas estas recomendaciones a muchos les causa, como poco, irritación (por decirlo de alguna manera 😆).

No obstante, también conozco un buen puñado de grandes líderes que en su día fueron programadores y que hacen un trabajo genial, logrando grandes resultados con sus equipos.

Si se te ocurre algún otro consejo, no dudes en compartirlo en la sección comentarios. ¡Muchas gracias por leernos!

Fecha de publicación:
Manuel A. Lores Manuel A. Lores González es licenciado en Derecho, especializado en la modalidad económico-empresarial. Tiene mucha experiencia como formador de trabajadores en activo y también como técnico de marketing en empresas del sector del software. En los últimos años además se ha especializado en la creación de contenidos para diversas publicaciones online. Ver todos los posts de Manuel A. Lores
Archivado en: General

Boletín campusMVP.es

Solo cosas útiles. Una vez al mes.

🚀 Únete a miles de desarrolladores

DATE DE ALTA

x No me interesa | x Ya soy suscriptor

La mejor formación online para desarrolladores como tú

Comentarios (5) -

Excelente articulo.
Muy buenos consejos, que nos permiten tener un panorama desde la perspectiva de un lider.

Muchas gracias por compartir.

Responder

Hay algo que se os ha olvidado en mi opinión; Un requisito que si no está presente en el responsable invalida un buen puñado de los consejos aportados: Conocer la tecnología que se está usando en el proyecto. De otra manera es casi imposible prever dónde pueden aparecer los problemas, ayudar a compañeros que se atascan y lo más importante: Saber a quien necesitas que sepa lo que el proyecto o parte de él necesita. Un jefe de proyecto debe estar bien formado en la tecnología del proyecto. De lo contrario el proyecto está abocado al fracaso por mucho que el responsable intente poner en práctica estos consejos.


Responder

José Manuel Alarcón
José Manuel Alarcón

Hola Álvaro:

Gracias por comentar. Sin duda un buen jefe de proyecto debe conocer la tecnología, al menos los conceptos fundamentales, pero en mi opinión un buen jefe de proyecto no debe conocer tan bien la tecnología como para meterse en los detalles del día a día o de bajo nivel. Si entra en eso corre el riesgo de hacer micromanagement, empatizar en exceso con los desarrolladores, no dedicarse a gestionar sino a hacer desarrollo, y al final redundará en que no será un buen gestor y que el proyecto fracase. Y te lo digo de primera mano porque soy culpable a menudo de eso 😉

Saludos!

Responder

Hola José Manuel: El comentario mío también se basa en la experiencia. En mi anterior empresa dos proyectos estrella para la empresa fracasaron con todo éxito, porque en ambos casos el jefe de proyecto desconocía la tecnología. En el primer caso el jefe era un tipo excelente. Desarrollaba en Salesforce, pero la parte de .net del proyecto, desconocida para el, lastró el proyecto. Como te digo buena persona y buen jefe, que también lo fue de un proyecto en el que tuve parte activa.
El segundo proyecto, también muy especial para la empresa, lo lideró un tipo completamente distinto en lo humano, personal y profesional (un soplanucas, para decirlo suavemente) . Un proyecto de "mvc" con SQL lo lideraba un señor que lo más que había hecho era Vb6 para escritorio. Solo éramos dos personas, sin arquitecto web, sin maquetador, para un proyecto de una multinacional que requería una aplicación web de RRHH: Control de presencia en la empresa, con todos los casos que puedas imaginar. El proyecto era para 5 personas como mínimo y 6 meses, yendo bien deprisa, pero este señor decidió que con un mes y medio había de sobra para hacerlo con pruebas y documentación para el cliente. Sin análisis funcional, ni diseño de BBDD ni nada que se le pareciese. La apreciación era ridícula hasta para mi compañero, desarrollador junior que apenas llevaba dos años en esto. Decir que estábamos perdidos era decir poco. Hubiéramos necesitado alguien que supiera de qué estábamos hablando, por que su concurso día a día era imprescindible. Para ponerse en el camino a la puerta de salida a ver cuándo nos íbamos a casa era un hacha...para el resto...solo sabía reunirnos todos los días para meter prisa, gritar e ignorar las dificultades que nos encontrábamos.
En fin, en el caso que te cuento, todas las prácticas que me señalas en tu mensaje como "no buenas" hubieran sido mucho, pero mucho mejor, que lo que tuvimos. Es más, casi prefiero esas "malas prácticas" que dices , yo creo que hay menos posibilidades de que el proyecto fracase, es una sensación mía claro.

En fin, solo decirte que me busqué otro curro y me largué de la empresa sin que el proyecto estuviera ni por asomo en vías de ser terminado a los tres meses de empezarlo, tan nefasta había sido la experiencia.

Saludos cordiales.


Responder

Antonio Calle
Antonio Calle

Yo también pienso en esto como José Manuel. Incluso en que hasta sería bueno que el responsable no sea el que más sepa de la tecnología usada. Yo también he sido el primero en fallar por no saber delegar, ya que me costaba mucho menos hacer algo que explicarlo, pero lo que conseguí es un equipo humano que no sabía desenvolverse por si mismo (o no sabía, o había llegado a la conclusión de que no valía la pena aprender). También he estado en el otro lado, como técnico con un jefe, digámoslo así, totalmente ignorante de la tecnología que usábamos, (de hecho, la última vez que programó su monitor era de fósforo verde), y es un suplicio...

El técnico debe saber de lo suyo, que lo apoyen para mejorar, y que lo dejen mejorar. El responsable debe entender a las personas y conocer a su equipo con sus fortalezas y debilidades, y la técnica lo suficiente para saber cómo dirigir a su equipo y poder apoyar en algún momento puntual, pero no lo suficiente como para "meter demasiado la mano" XDD.

Responder

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.