¿Debe saber programar un jefe de proyecto?

La eterna disputa. ¿Debe un jefe de proyecto ser sólo un gestor…o debe también saber programar? ¿O debe haber sido programador? ¿O no hace falta? Bueno, hoy creo que me voy a ganar enemistades por razonar en contra de la moda. Vayamos a ello.

Algunos puntos a favor:

  • Sí, debe saber programar para saber dirigir mejor a sus equipos.
  • Sí, porque así tiene empatía con su equipo.
  • Sí, porque así sabe de qué hablar al negociar un cambio.
  • Sí, porque así sabe llevar un lenguaje técnico durante las ventas.

Algunos puntos en contra:

  • No, porque la dirección de proyectos en realidad tiene que ver muy poco con la programación. Dirigir a los equipos no es enseñarles cómo hacer su trabajo. Eso se llama formación. Dirección consiste en dar directrices, pautas y restricciones (limitaciones, restricciones, requisitos variados, etc.). Dirigir consiste en facilitar el enfocarse en una dirección, no llevar físicamente el peso del equipo. También en entender e identificar las dificultades que van surgiendo, anticiparse (riesgos), resolverlas cuando se producen (problemas), etc.
  • No, porque aunque la empatía es útil para conectar con la gente, la empatía no se consigue programando. Puedes ser un buen programador y sin embargo (y de estos me he encontrado unos cuantos), ser incapaz de conectar con clientes, compañeros, etc.
  • No, porque al negociar un cambio, ser programador no es la clave. La clave es conocer el impacto en el código, documentación, y otros proyectos o trabajos en curso. Es una temeridad creer que aunque seamos técnicos, vamos a poder identificar, en medio de una negociación, si el cambio se acepta o no, y mucho menos llevarlo a cabo. Para identificar el impacto de un cambio son necesarios: una mente analítica, tener identificada la estructura del proyecto (aquí ayuda la documentación, algún modelo o arquitectura bien estructurada, etc.). Y por supuesto, ayuda la experiencia. Pero no experiencia en programar, sino experiencia en la dirección de proyectos y cómo sus cambios cuesta llevarlos a cabo.
  • Es un error pensar que las ventas han de hacerse en un lenguaje técnico. Las ventas han de hacerse pensando en el lenguaje de la persona que tenemos delante, que no tiene porqué ser técnica. Pensar sólo en lenguaje técnico, es como mínimo, una falta de respeto a quien tenemos delante. Somos nosotros quienes tenemos que escuchar al cliente, lo más importante, y no al revés.

La realidad nos dice, y de esto encontraréis múltiples artículos en la web hablando de ello (incluido nuestro querido Dilbert), que los buenos programadores, cuando son promovidos a categorías superiores de dirección de proyectos, se encuentran con que no están preparados para dirigir equipos y proyectos. Es duro encontrarse con que se deja de tocar código, y se enfrentan decisiones organizativas, operativas, planificaciones, estimaciones, etc. Cuántos jefes de proyecto recién promocionados se sienten perdidos y decepcionados, y por supuesto poco preparados.

Tampoco estoy de acuerdo con que un jefe de proyecto deba ignorar la tecnología. Más bien al revés. Sin embargo, el mero conocimiento técnico, no nos convierte en buenos gestores. Cuantas veces oigo eso de “yo dirijo equipos”, de personas que se limitan a decir a sus programadores lo que tienen que hacer, a “pasarles las tareas”. Eso no es ser un jefe de proyecto, ni dirigir un proyecto. Hay un salto cualitativo (por la complejidad) y cuantitativo (por el número de tareas) que debe realizar un buen jefe de proyecto. Por desgracia, hay tantos malos jefes de proyecto, que es habitual oír quejas de sus programadores en los términos que comento más arriba en el apartado “Algunos puntos a favor”.

Para ser buenos los programadores, hemos de conocer los estándares de programación. Lenguajes, buenas prácticas, arquitecturas, frameworks, patrones…

Igualmente, para ser buenos gestores, hemos de conocer los estándares de gestión (PMBOK, PRINCE, ITIL,…), cómo adaptarlos a distintos proyectos, entender los riesgos que se corren con los cambios, establecer planificaciones (bien con un Gantt de los requisitos, una secuencia de sprints o iteraciones de historias de usuario, etc).

Mi conclusión, por tanto, es que sí y no. Un buen jefe de proyecto puede beneficiarse mucho de venir del área de desarrollo, y haber sido programador, analista, etc. Pero aún con toda esa experiencia, sólo con empatía, y saber hablar con los programadores, no se enfrentan y solucionan los problemas organizativos de un proyecto. Un marinero experto no es suficiente para ser un gran capitán. Aunque todo buen capitán, es fácil que haya sido antes marinero experto.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s