Como cargarse un buen programador

4

Carlos era el mejor programador del equipo. Con sólo hacer una pregunta a otro miembro del equipo, le estaba desatascando de ese bug que lo traía loco desde hacía un par de días. Era un crack de esos que dices: “no nos podemos permitir perderlo”. ¿Y que hacemos para no perderlo? Pues lo ascendemos a un puesto de más responsabilidad, en el que ya no tenga que programar y nos lo cargamos. ¿Absurdo? Sí. Pero aún y así ves esto todos los días.

Lo mismo puede extrapolarse al gestor de servicios en el que el administrador se convierte de forma natural en coordinador y posteriormente en gestor.

Principio de Peter

La razón detrás de este absurdo es el simple principio de Peter que nos dice lo siguiente:

En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia: la nata sube hasta cortarse.

Laurence J. Peter

Esto en nuestro negocio es dañino a niveles extremos debido a que no sé a quién se le ocurrió que un service manager o un project manager está jerárquicamente por encima de los administradores o programadores. En ese entorno, la evolución natural de los técnicos es ir ascendiendo a puestos en los que poco a poco van separándose del campo técnico para llegar a la gestión. Así un programador, pasará a ser analista, arquitecto, jefe de equipo o jefe de proyecto. El tema en nuestro sector es que la diferencia entre el trabajo de un programador y un jefe de proyecto es tan grande que obliga a los trabajadores a reciclarse. Y este reciclado no siempre es posible.

Midiendo los daños

El hecho de subir a los técnicos a cargos de gestión tiene múltiples daños asociados:

  • Pierdes gran parte del conocimiento de esa persona, ya que no le será de utilidad como antes. ¿Para que le sirve a un jefe de proyecto conocerse todos los métodos de JQuery? De hecho pierdes lo más valioso de esa persona.
  • Esta persona necesita aprender nuevos conocimientos, con el coste en formación asociado. Ojo que siempre hay un coste en formación, incluso cuando no invertimos. De hecho cuando no invertimos es mayor, ya que lo pagaremos en errores y tiempo que tardará en ser productivo.
  • Muchas veces la persona no está contenta con el tipo de trabajo que tiene que realizar, y puede llegar a la frustración. Ángela Covas, en la presentación de sus servicios de Coaching, indica que el programador se hace por vocación a programar, no a gestionar.
  • La habilidad no sólo se aprende, hay que nacer con parte de ella. Por lo que puede haber técnicos muy buenos incapaces de gestionar. Estos serán malos gestores siempre.
  • El técnico puro siempre será técnico, por mucho que en su hoja de trabajo ponga gestor. La cabra tira al monte y a la que tenga una oportunidad desatenderá sus tareas de gestión para meterse de lleno en temas técnicos. ¿Qué hace un gestor de este tipo cuando ve que se le come el tiempo y no llega a tiempo a un hito? Ponerse a programar él también.

Los daños, son múltiples y se resumen en que nos cargaremos a los buenos técnicos para crear malos gestores.

Y entonces ¿por qué se hace?

Desde mi punto de vista el error principal está en considerar que en el mundo del desarrollo existe una jerarquía en el que los gestores son superiores a los técnicos. Es una creencia en la que el gestor “manda” a los técnicos, su responsabilidad es mayor y por lo tanto debe cobrar más. Esto provoca varios efectos negativos.

Primero establece una fronteras salariales en los distintos perfiles en los que un técnico senior tendrá salarios similares o ligeramente inferiores a los gestores de proyecto. Sólo en raras ocasiones en las que el técnico pueda chantajear a la organización veremos que esta regla se rompe. Así que si el empleado quiere cobrar más la única salida que existe es pasarlo al grupo de project managers.

Por otro lado se crea en la mente del técnico ambicioso la necesidad de pasar a ese grupo elitista de los gestores. Yo mismo he estado en ese punto. Con formación de ingeniero lo que realmente me gustaba era programar, y cuanto más complicado mejor. El I+D era “El Dorado” para mi. Pero era ambicioso y en el I+D no veía opciones de promoción. Así que pasé al sector del desarrollo y tan pronto entré me emborraché de esa necesidad de querer ser “jefe”. En ese momento aportaba mucho más valor a la organización programado que como gestor (era un crack como programador y un pésimo gestor), pero conseguí pasar. Tuve suerte y me conseguí desarrollar como gestor, y tuve más suerte todavía en que me gustó. Pero todavía miro con ojos golosos esas pantallas de los desarrolladores con los IDE que hay hoy en día. Para los que hemos programado con Vim ver eso puede llegar a resultar erótico.

Es decir, los técnicos quieren esos puestos de gestión. No saben lo que piden.

Así que, ¿Qué haces con ese crack que se merece un salario mayor y que te pide pasar a gestor? Cuando llega ese momento, ya has perdido al crack.

La solución

Difícil, y además debe venir desde arriba. La única solución pasa por dos puntos:

  • Establecer el sistema de carrera dual en la organización. Los trabajos técnicos y los de gestión son dos carreras diferentes, no una sola. Un técnico de atención telefónica, podrá pasar a microinformática in-situ, luego a operador de sistemas, después a administrador y como mucho a experto. Pero no a coordinador. El paso de admin a coordinador debería ser tan raro como de admin a programador.
  • Establecer la filosofía de gestión y no de jefatura. El gestor es un gestor, no un jefe. El gestor no programará y no le dirá al administrador la versión del parche que hay que instalar.

Así probablemente tendremos administradores que cobren más que el gestor de ese servicio.

Además, cada vez más nos encontramos con que tanto el gestor de proyectos como el de servicios son carreras que se están profesionalizando, por lo que se puede encontrar a personal recién salido de sus estudios dispuesto a comenzar su carrera en puestos de gestión, con la formación adecuada para ello. No como nosotros que lo somos por accidente, tal como indica Joan Barceló en su blog.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

4 comments

  1. Pianista 11 Marzo, 2015 at 07:08 Responder

    Pues yo no estoy de acuerdo con el artículo.

    La mayoría de personas, no empiezan en un rol de gestión (por no decir un 1%) sino que empiezan prácticamente todas como programadores. Y para mí aquellas personas que destacan por su calidad técnica, acaban siendo arquitectos o el rol más parecido que se les asemeje.

    Lo que propones de que el rol de gestión, gane menos que un programador, no es viable (por muy bueno que sea el programador), porque el rol de gestión le pagan por sus decisiones tanto para bien, como para mal de las que dependen lo bien o mal que vaya el proyecto.

    Cuando tienes un programador que es tan decisivo para esas cosas, ese programador acabará siendo tu Team Leader o lo que quieras del equipo (o el arquitecto), y por tanto acabará subiendo en la escala salarial.

    Por otro lado es totalmente lógico que la primera vez que seas Jefe de Proyecto no tengas las dotes, igual que tampoco las tenías cuando empezaste de programador (no es lo mismo un tio que lleva programando 10 años, o que lleva gestionando 10 años, que uno que se ha leído el Pmbook).

    • Jose M. Huerta 11 Marzo, 2015 at 12:38 Responder

      Hola Pianista,

      Gracias por la crítica, un poco de contraste nunca viene mal.

      Hace unos años no había conciencia de formación para gestión de proyectos, hoy sí la hay. Yo preferiría contratar un project manager junior con esa formación, que a uno sin la formación. Hay una gran diferencia. A eso me refiero con que no tenía ni idea. Me refiero a que nadie me había explicado nada y conceptos como gestión de riesgos, seguimiento, o plan de comunicación eran cosas de las que ni había oído hablar. Cuando llega un programador novato, ha estudiado programación. Es cierto que está muy verde, pero no hay que explicarle lo que es un IF. En cambio un project manager novato sin formación, no tiene ni idea de nada.

      Por otro lado en desarrollo hay mucha diferencia entre el valor proporcionado por un programador o por otro. Yo he visto casos con ratios de productividad de 10:1. Es decir, un tio que saca 10 veces más trabajo que otro. Esa persona es muy valiosa y debería cobrar por su valía. Yo creo que el salario no se debe recibir por la responsabilidad de las decisiones, sino por el valor proporcionado a la empresa.

      Por último, ascender al mejor programador a jefe de equipo es un poco más de lo mismo. Le das tareas de coordinación, de gestión de personas a una que sólo ha demostrado que programa muy bien. Lo que haces es quitarle tiempo de programar para que comience a gestionar un equipo. Peter al ataque de nuevo. Y también he conocido programador buenos que cuando los pasas a arquitecto no lo son tanto. Eso de tener que documentar requisitos, les repatea.

      En cualquier caso, lo sano es que tengamos puntos de vista diferentes. Gracias de nuevo.

  2. edi 17 Marzo, 2016 at 10:53 Responder

    Necesito su opinion, se ve que sabe del tema, soy Ingeniero en sistrmas, trabaje un año como desarrollador, despues como independiente otro año, y tuve algo de suerte que de independiente tuve que contratar algunas ocasiones a gente que me ayudara y administrarlos.
    Soy alguien con buena logica de programacipn pero me di cuenta que me gusto mss gestionar y contacto con cliente dirigir calcular costos, y me gusta mas el contacto con la gente que programar, y quiero ser project manager asi que empeze a leer el pmbook y aprender microsoft project, y quiero colocarme como peoject manager ? Como ven? Las vacantes de project manager son con un enfoque mas administrativo y de gestion pero no piden conocimoento tecnico en casi ningún caso y ya tengo conocimiento tecnico pero a la vez tengo conocimiemto fimaciero de modelos de negocio calculos de costo, y como planificar un proyecto me apasiona mucho mas que programar. Algun consejo o opinion? Saludos.

    • Jose M. Huerta 17 Marzo, 2016 at 11:43 Responder

      Hola edi, creo que la realidad cambia mucho de un país a otro y de una empresa a otra. Lo que valora uno, no lo valora el otro. Por otro lado está lo que es útil para el nuevo puesto y lo que te van a valorar para contratarte. A veces es necesario conseguir algo, no por que nos haga mejores, sino porque nos hace más atractivos.
      Tengo dos consejos para tí:
      – Ten claro a qué tipo de empresa y puesto quieres ir, mira las ofertas de trabajo y enfócate a lo que te pidan. Es lo mejor para conseguir tu propósito. Si te piden PMP, hazlo. Si ni siquiera lo nombran y ves que en las entrevistas ni saben de qué va, entonces no pierdas el tiempo. Hoy en día está muy de moda todo el tema de proyectos ágiles. Las certificaciones SCRUM son mucho más fáciles y baratas de conseguir que el PMP y a lo mejor “decoran” mejor tu CV. Resumen: Fíjate en qué piden y a por eso.
      – El conocimiento técnico es vital para dirigir un proyecto técnico. No es imprescindible, y en un entorno muy burocrático como PMBOK implantado hasta la médula puede ser prescindible. Pero el valor añadido que te proporciona es muy elevado. Primero porque te costará menos seguir el proyecto. Segundo porque te proporcionará liderazgo sobre el equipo (si te ven como que no tienes ni idea de la parte técnica, es complicado ganarse el respeto). Resumen: Aunque no te lo pidan en la entrevista, ten claro que sí te hace mejor candidato. Prepárate la explicación de 20 segundos de por qué te hace mejor. Te servirá.

      Un saludo

Post a new comment

Te puede interesar...