Muchos proyectos software fracasan no por la falta de pericia o habilidad de los desarrolladores, tampoco lo hacen por la falta de talento y la buena voluntad de sacar el proyecto adelante. En ocasiones, el actor que provoca que un proyecto termine en desastre es el mismo gestor, responsable, manager o coordinador. ¿Puede gestionar un equipo de programadores alguien que apenas conoce...
No nos olvidemos de estos otras dos fuentes de problemas:
- Clientes que no saben lo que quieren o aportan "ideas" sobre temas que desconocen.
- Departamentos de marketing que sólo saben de "marketing"
- Jefes que quieren poner su "granito de arena"
Supongo que los programadores que creen estar trabajando para su propia satisfacción en lugar de estar proporcionando un producto que aporte a un cliente, que creen que ellos tienen derecho a cometer errores como humanos que son, pero los jefes de proyecto no pueden cometerlos en la gestión y desde luego los clientes mucho menos en su gestión de espectativas, no esos programadores autoconvencidos de su razón absoluta no son nunca un problema.
Por supuesto, es totalmente evidente que el único afectado por un cambio de especificaciones dos días antes de la puesta en marcha es el programador que tiene que picar el código. Es totalmente evidente que el cliente no tiene sudores fríos cuando se da cuenta que lo que le están haciendo por una pasta gansa no le resuelve tal o cual problema gordísimo con el que se va a encontrar al día siguiente de la puesta en marcha y que o bien no existía cuando se contrató el proyecto, o símplemente no se dió cuenta.
Y después de 25 años haciendo aplicaciones, dejadme que algo sepa de los dos lados de la mesa.
#6 Precisamente la gestión de proyectos se ocupa tanto de planificar el trabajo técnico como de gestionar las expectativas y el alcance del proyecto. Yo veo el scrum como una especialización de los procesos de ejecución y seguimiento y control del pmbok (porque no es lo mismo hacer puentes que hacer webapps)
El autor de este libro del meneo se centra mas en la parte de programar, tal vez porque es la que le escuece mas, pero aun en las partes de 'management' de clientes no hay nada por descubrir en la gestión de proyectos, todo lo que nos pasa ya le ha pasado a cientos de personas antes y si no se resuelve bien es por desconocimiento y con los recursos que hay por internet hoy en dia, no hay excusa.
Yo fui programador, me pase a sistemas porque me gusta, pero sobretodo por la sensación continua de no llegar nunca al final de proyecto,siempre sobreesfuerzos, siempre a medias. Ultimamente, por curiosidad he realizado dos cursos online (mooc) sobre gestion de proyectos basados en Pmbok (http://es.wikipedia.org/wiki/Project_Management_Body_of_Knowledge).
Despues de hacerlos puedo afirmar con rotundidad que nunca he hecho un proyecto en condiciones, y que lo raro no es que fallasen, lo maravillosos es que algunos saliesen adelante a base de fuerza bruta. Todos los problemas que he encontrado estan contemplados ahí. ¿Es perfecto? evidentemente no, pero no al menos si fallas sera por un problema inherente al proyecto, o por pereza.
Comentarios
No nos olvidemos de estos otras dos fuentes de problemas:
- Clientes que no saben lo que quieren o aportan "ideas" sobre temas que desconocen.
- Departamentos de marketing que sólo saben de "marketing"
- Jefes que quieren poner su "granito de arena"
...
Supongo que los programadores que creen estar trabajando para su propia satisfacción en lugar de estar proporcionando un producto que aporte a un cliente, que creen que ellos tienen derecho a cometer errores como humanos que son, pero los jefes de proyecto no pueden cometerlos en la gestión y desde luego los clientes mucho menos en su gestión de espectativas, no esos programadores autoconvencidos de su razón absoluta no son nunca un problema.
Por supuesto, es totalmente evidente que el único afectado por un cambio de especificaciones dos días antes de la puesta en marcha es el programador que tiene que picar el código. Es totalmente evidente que el cliente no tiene sudores fríos cuando se da cuenta que lo que le están haciendo por una pasta gansa no le resuelve tal o cual problema gordísimo con el que se va a encontrar al día siguiente de la puesta en marcha y que o bien no existía cuando se contrató el proyecto, o símplemente no se dió cuenta.
Y después de 25 años haciendo aplicaciones, dejadme que algo sepa de los dos lados de la mesa.
#6 Precisamente la gestión de proyectos se ocupa tanto de planificar el trabajo técnico como de gestionar las expectativas y el alcance del proyecto. Yo veo el scrum como una especialización de los procesos de ejecución y seguimiento y control del pmbok (porque no es lo mismo hacer puentes que hacer webapps)
El autor de este libro del meneo se centra mas en la parte de programar, tal vez porque es la que le escuece mas, pero aun en las partes de 'management' de clientes no hay nada por descubrir en la gestión de proyectos, todo lo que nos pasa ya le ha pasado a cientos de personas antes y si no se resuelve bien es por desconocimiento y con los recursos que hay por internet hoy en dia, no hay excusa.
#0 Avisa que el contenido del artículo está en el enlace al PDF(http://www.ellibronegrodelprogramador.com/sites/default/files/capitulos/cuando_el_gestor_de_un_proyecto_es_su_mayor_enemigo_el_libro_negro_del_programador.pdf)
Yo fui programador, me pase a sistemas porque me gusta, pero sobretodo por la sensación continua de no llegar nunca al final de proyecto,siempre sobreesfuerzos, siempre a medias. Ultimamente, por curiosidad he realizado dos cursos online (mooc) sobre gestion de proyectos basados en Pmbok (http://es.wikipedia.org/wiki/Project_Management_Body_of_Knowledge).
Despues de hacerlos puedo afirmar con rotundidad que nunca he hecho un proyecto en condiciones, y que lo raro no es que fallasen, lo maravillosos es que algunos saliesen adelante a base de fuerza bruta. Todos los problemas que he encontrado estan contemplados ahí. ¿Es perfecto? evidentemente no, pero no al menos si fallas sera por un problema inherente al proyecto, o por pereza.
Visto en: http://libros.barrapunto.com/libros/13/06/01/137242.shtml
no, siguiente pregunta