Iohannes fac totum

0

Iohannes fac totum, o dicho en castellano, chico para todo. Esto es lo que muchas veces le sucede a un jefe de proyecto en el mundo de las TI. Se espera de él que sirva para todo. Si un programador se atasca, se espera que pueda actuar como programador experto y desatascarlo. Si un programador se pone de baja, pues que programe el jefe de proyecto. Así dicho parece de chiste, pero ¿no os resulta familiar? La realidad es que gran parte de los interesados consideran que los problemas en los proyectos son problemas del jefe del proyecto. Como diría Emilio Duró, los marrones del universo le orbitan y caen en él.

Al principio pensaba en ponerle al artículo otro título, algo más directo, como “El come-mierda”, pero al final he pensado que una expresión pedante en latín quedaría mas elegante.Pero al final va de eso, de marrones. Y de que cuando no hay nadie en el proyecto para comérselo, le caen al jefe de proyecto. El escarabajo y su pelotita de estiércol que he usado para ilustrar el artículo, representan la idea de un project manager arrastrando su marrón.

Últimamente pienso mucho en por qué sucede esto en el mundo de la informática. En la construcción, por ejemplo, no veo que esto pase. Si a mitad de proyecto hay un corrimiento de tierra que destroza gran parte de la obra, aumentando costes y retrasando plazos, a nadie se le ocurre decir que es culpa del jefe de proyecto. Puede ser culpa del geólogo que hizo mal el estudio, si es que se podía haber previsto ese corrimiento. Pero en cambio, en el mundo del desarrollo todo es culpa del jefe de proyecto. Si al ponerte a desarrollar destapas que la complejidad que el analista había estimado realmente se multiplica al avanzar en el proyecto, es culpa tuya. Seguro que el analista te dirá, con razón, que era imposible estimarlo, y que el riesgo no se documento porque era improbable, lo cual puede ser del todo cierto. Las reservas de gestión inexistentes, lo cual no es culpa del jefe de proyecto, porque eso lo debe venir de una política de la organización. Al final, el jefe de proyecto es el que se lleva todas las tormentas. ¿Y qué ha hecho mal? Nada. Pero a alguien hay que culpar.

Y no sólo eso. Es común que durante el proyecto aparezca alguna actividad que en la planificación no se había tenido en cuenta. Somos humanos y a todos nos puede pasar. Lo normal sería que en este caso se ampliasen los recursos del proyecto para realizar esta nueva tarea. Pero a la hora de la verdad muchas veces pasa que no hay recursos. ¿Y quién lo hace? Pues el culpable de que no se haya definido esa actividad al comienzo: el jefe de proyecto. Os pondré un caso que me sucedió a mí. Hace unos años dirigí un proyecto de desarrollo e implantación en una administración pública. En el pliego ponía algo como “deberá desarrollarse el material formativo en la plataforma corporativa de formación […]” Al presentarnos estimamos que tendríamos que hacer manuales de la aplicación, como suele ser habitual. Así que se desarrolló y se realizó esa documentación. Pero la sorpresa fue cuando el cliente nos dijo que su plataforma de formación estaba basada en video tutoriales, y que a lo que se refiere el pliego es a realizar estos videotutoriales. ¡No estaba planificado inicialmente realizar esta actividad!. Y lo peor es que era condición para cumplir un hito, por lo que había que hacerlo en tiempo record. A qué no adivináis quién se tiró un par de noches grabando video tutoriales. Claro, yo. ¿Qué culpa tenía yo de que de repente sucediese esto?. Al cliente le  informé de las tareas que íbamos a realizar, y no detectó que faltaba eso hasta la fase final. Como lo ponía en el pliego y en el contrato queda claro que lo que pone el pliego va a misa, me lo tuve que comer. Yo estoy seguro que actué bien, entonces ¿Por qué me lo tengo que comer yo?. Pues porque eres el jefe de proyecto.

Por eso, yo ya me he rendido. Ya he asumido que si pasa algo, es culpa mía y que yo lo tendré que resolver solito. Por eso creo que un jefe de proyecto en TI debe ser capaz de bajar al barro, es decir, de ponerse a escribir código. Además es la mejor manera de ganarse el respeto de tu equipo. Tu equipo es técnico. Saben de cosas técnicas. Es complicado que valoren tus habilidades de gestión. En cambio si cuando se atascan te sientas al lado y les demuestras que no sólo sabes gestionar, te ganas más fácilmente su respeto.

Volviendo a los marrones que te orbitan, siento contradecir al Señor Duró. Los marrones pueden venir, como dice él, porque Dios te los manda (poco probable) o porque tú eres el marrón. Se olvida de la tercera opción: que seas el jefe de proyecto.

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.

No comments

Te puede interesar...