21 meneos

20 consejos para fracasar como Jefe de Proyecto

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...

negativos: 0   usuarios: 19   anónimos: 2  
compartir:  twitter  facebook  tuenti  
  1. #1   Los jefes que he tenido no necesitan leer este artículo. Aparte de ser dios y no necesitar consejos, seguían punto por punto todo lo aquí expuesto.
    7  votos: 0   link
    el 18-10-2009 08:21 UTC por rodaman rodaman
  2. #2   Yo añadiría unos cuantos que he sufrido en mis propias carnes en un proyecto realizado en C++:

    1. Invéntate restricciones absurdas a la hora de picar el código: notación húngara, prohibición total de utilizar la STL o memoria dinámica, prohibición de declarar tipos de datos globales en headers separados, utilizar excepciones absolutamente para cualquier cosa... Las posibilidades son infinitas, utiliza tu imaginación.

    2. No permitas que tus programadores utilicen librerías externas para hacer las cosas más básicas. Mejor, reinventa la rueda. Que accedan directamente a las llamadas a sistema, y ellos mismos hagan sus propias clases de ficheros, sockets, threads, mutex... incluso su propia clase string (sin utilizar memoria dinámica, por supuesto, ver punto 1). *

    3. Sucontrata una parte del código muy importante a una empresa externa. Tiene que ser una parte esencial del programa que el propio equipo sea capaz de desarrollar en dos patadas. No le proporciones a dicha empresa ningún tipo de documentación acerca de lo que tiene que hacer: es mejor que hable con el equipo y le haga perder el tiempo. Cuando, después de dos años, te des cuenta de que no funciona ni por casualidad, pásale el marrón al equipo.

    4. No supervises el trabajo de nadie. Si alguno de los programadores resulta que no tiene ni puta idea de C++ no pasa nada, ya aprenderá.

    5. Cambia las especificaciones del proyecto sobre la marcha tantas veces como quieras, pero no avises al equipo hasta el mismo día de la demo.

    6. Si le explicas una idea a alguien del equipo, y te la critica, ignórale. Aunque ese miembro del equipo sepa más que todos los demás juntos.

    * Aunque pueda parecer demasiado absurdo, esto es tristemente verídico. Si alguien se pregunta si a lo mejor el programa estaba destinado a controlar un sistema crítico como una central nuclear o un satélite en órbita, la respuesta es que NO (por suerte).
    69  votos: 6   link
    el 18-10-2009 08:59 UTC por Penetrator Penetrator
comentarios cerrados

menéame