10 Oct 2009
20 consejos para fracasar como Jefe de Proyecto
Categorías: General
Escrito por: Fernando del Pozo

Extraído de un artículo original de mi blog personal.
- 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.
- 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 puta 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 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.
- 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 o imprevistos en tus plazos, tu equipo no va de vacaciones ni se pone malo 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 sus creatividades 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, sabrán apañárselas.
- 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 puta idea de programar, siempre puedes dejar el marrón que has empezado 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 miseráblemente, é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 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.


13 Octubre 2009 a las 04:28:05
Muy bueno el listado, realmente muy común
13 Octubre 2009 a las 12:33:42
20 consejos para fracasar como jefe de proyecto
20 errores a evitar para triunfar como jefe de proyecto
Muy bueno, y real como la puta vida misma
17 Octubre 2009 a las 21:26:32
Es que es muy bueno!!!, visto lo visto de este listado diría que el Jefe de Proyecto por mi experiencia lo llevaba a la práctica literalmente, es increíble pero calcado!!!!
Muy bueno, como la vida misma si.
18 Octubre 2009 a las 07:47:39
[...] 20 consejos para fracasar como Jefe de Proyectowww.failbeta.com/2009/10/20-consejos-para-fracasar-como-jefe… por Nabuko hace pocos segundos [...]
18 Octubre 2009 a las 08:35:44
[...] 20 consejos para fracasar como Jefe de Proyecto: http://www.failbeta.com/2009/10/20-consejos-para-fracasar-como-jefe-de-proyecto/ [...]
27 Octubre 2009 a las 02:40:58
Metedura de pata de las gordas en mi opinión:
“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.”
5 Noviembre 2009 a las 04:08:09
[...] 20 consejos para fracasar como Jefe de Proyecto | Fail Beta. [...]
6 Noviembre 2009 a las 22:15:37
¿Es lo único en que se puede fallar?
Sinceramente, me parece que esto está escrito por un programador cabreado con su jefe de proyecto. . y que básicamente solo quiere desaogarse.
Como consejos pueden ser positivos, pero la elección de estos es desastrosa.
Me parece estar leyendo: ” Si quieres hacerlo bién, lo ÚNICO que tienes que hacer es mimar a tus programadores.
Consejo 21 para fracasar: “Solo hay un punto de vista importante ( en este caso el programador) si lo haces así, todo saldrá bien”
6 Noviembre 2009 a las 23:59:44
No Klaus, se puede fallar en más, esto son solo 20 consejos.
No está escrito por un programador, está escrito por un jefe de proyecto con 10 años de experiencia.
No se trata de mimar a los programadores, se trata de gestionar bien los recursos (humanos), con un equipo desmotivado nunca podrás llevar a cabo un proyecto con éxito, nunca.