Como fracasar como lider de proyectos en 20 sencillos pasos

Yo soy un amante de la tecnología, la programación y la informática en general, y muchas veces me han preguntado ¿Por qué no dejas de programar y te dedicas solo a liderar proyectos? para algunas personas esto es su sueño, dejar de lado el desarrollo y dedicarse a planificar, ordenar y coordinar proyectos informáticos (Yo en lo personal creo que me aburriría demasiado si dejara de programar totalmente).

La verdad es que ser lider de proyectos es más una vocación que una alternativa para dejar de programar o para sentir que se tiene poder, y por eso muchos no saben como ser un buen lider, yo en lo personal admiro a aquellos que conocen cada componente tecnológico sobre el que esta edificado su proyecto o al menos se preocupan por entenderlo, por lo general es gente con mucha experiencia que han trabajado antes como desarrolladores o por lo menos han estudiado informatica o por lo menos, entienden que es lo que su equipo hace, y saben como darle solución a un problema en conjunto.

Lastimosamente los buenos lideres de proyectos están en peligro de extinción y muchas veces la burocracia puede mas que el sentido común, y proyectos que pudieran ser exitosos terminan siendo una pesadilla.

Acá esta una lista de 20 pasos a seguir si usted NO quiere ser un buen lider de proyecto:

  • Cuando visites o te reunas con el cliente/Usuario dile que SI 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.
  • Cuando el cliente te pregunte por alguna tecnología que no conoces, haz como si la conocieses. Incluso dile que tenéis varios casos de éxito en la empresa con esa tecnología. Cuando hables con tu equipo de desarrollo y te digan que no tienen ni una pálida idea de como hacerlo, diles que lo busquen en Google.
  • A la hora de preparar un plan de proyecto se 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 tu jamás hayas programado. 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/finales ajenos al desarrollo. Ya se encargarán los programadores de ir probando lo que hacen.
  • A la hora de preparar un presupuesto, olvídate de los gastos imprevistos, no consultes proveedores, céntrate en presupuestar bien tus horas. Si se acaba el dinero antes de tiempo, échale la culpa a tus programadores.
  • No tengas en cuenta fechas críticas,asuetos o imprevistos en tus plazos, tu equipo no va de vacaciones ni se enferma nunca.
  • 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 ser creativos ya tienen los fines de semana.
  • 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 compartas con ellos información que pueda afectar al proyecto, cuanto menos sepan mejor. Dales una vaga explicación de sus tareas, se sabrán arreglar solos.
  • Nunca pidas que se documente el desarrollo ni dejes que los programadores lo hagan por propia iniciativa. Si por ejemplo, llega alguien nuevo al equipo, ya tiene el código, que es OBVIO.
  • 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.
  • Siéntete libre de participar en el desarrollo cuando quieras, aunque no tengas ni idea de como programar, siempre puedes delegar lo que no terminaste a uno de los programadores. Toca el código que quieras sin avisarles, eres el jefe.
  • Tú no tienes porque saber en que está trabajando cada miembro de tu equipo ni las prioridades de cada momento. Ya son mayorcitos. Elaboraste un plan al principio, solo hay que seguirlo, es perfecto.
  • 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.
  • 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.
  • Sorprende a tu equipo con entregas para mañana, pocas horas antes de terminar su jornada. Tú vete a casa a tu hora, tu época en las trincheras ya pasó.
  • Cuando muestres una demo al cliente y esta falle miserablemente, échale la culpa a los programadores. No tienes porque revisar su trabajo antes de mostrárselo al cliente.
  • 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 alguna casualidad tienes éxito en un proyecto, no traslades ese éxito a tu equipo no vaya  a ser que se motiven. El éxito es solo TUYO, hazlo saber a tus superiores.