Esta entrada ha sido muy difícil de escribir, pues he tenido que seleccionar de este blog sólo diez de los veinte mangíficos consejos para fracasar como jefe de proyecto informático. He intentado seleccionar aquellos 10 que me han parecido más imprescindibles para conseguir el objetivo, y especialmente en un proyecto de Business Intelligence, pero es recomendable la lectura de la lista completa . Ahí va mi selección:

• Cuando visites al cliente dile que sí a todo, sea lo que sea. Tu trabajo es complacer al cliente y lo haces muy bien, si los programadores no saben hacer el suyo, es su problema.
• A la hora de preparar un plan de proyecto sé muy optimista con los tiempos, sobre todo con los de desarrollo, los programadores tardan en desarrollar los módulos lo que tú dices que se tarda, por algo eres su jefe, aunque jamás hayas programado ni el vídeo. Sobre todo no consultes tiempos con ellos, no vaya a ser que te digan que necesitan más horas.
• Jamás, y digo jamás, reserves horas del proyecto a una fase de pruebas con usuarios reales ajenos al desarrollo. Ya se encargarán los programadores de ir probando lo que hacen.
• Cuando un programador tenga una iniciativa creativa o una buena idea, recházala de inmediato. Las cosas se hacen como tú lo dices y punto, para sus creatividades ya tienen los fines de semana.
• Cuando un miembro del equipo haga algo mal, díselo delante de todos sus compañeros y sobre todo, no te sientes con él para solucionar el problema.
• No dejes que el equipo tenga una visión global del proyecto, si un programador está encargado de la impresión de informes, no tiene porque saber de que va el resto del proyecto ni de que partes se ocupan sus compañeros.
• No motives a tu equipo, su sueldo debería de ser su motivación. Nunca les digas la importancia que tiene su trabajo en el proyecto y en la empresa. Tampoco les felicites, para eso les pagan.
• Cuando tu equipo necesite algún recurso de la empresa (o fuera de ella), que lo busquen ellos. Tú no tienes tiempo de solicitar compras o peticiones al departamento de sistemas, y mucho menos de justificarlas por ellos. Desentiéndete.
• Cuando haya problemas con los plazos, échale la culpa al equipo en general, y a ese programador que hizo algo mal en particular. Recuerda, tú escribiste un plan que era perfecto, si no lo han seguido es su problema.
• Cuando un superior te pida explicaciones acerca del proyecto, nunca saques la cara por tu equipo, tu responsabilidad no llega a tanto y si alguien tiene que ponerse colorado que sean ellos.
• Si por algún casual tienes éxito en un proyecto, no traslades ese éxito a tu equipo no vaya a ser que se motiven. El éxito es solo tuyo, házlo saber a tus superiores.

¿Qué os parece? ¿Os suena?