5/27/2009

Errores típicos en la gestión de proyectos

Cualquiera que haya estado metido en algún proyecto software sabe que despúes de cada uno, se aprenden cosas que no deben volver a ocurrir. El proceso que acompaña a un proyecto software es tan complejo que es muy complicado que algo no se escape. Muchos procesos estándar se han puesto en marcha para eliminar o mitigar estos problemas. En otros casos, se proponen soluciones más sencillas pero útiles, como la utilización de checklists (recomendo la lectura de este artículo del New Yorker sobre su utilidad en diferentes ámbitos; impresionante).

En este artículo de PCWorld se mencionan 14 errores típicos que ocurren en la gestión de proyectos. De ellos, los que me parecen más relevantes y menos obvios son:
  1. Ni suficientes recursos ni con el perfil más adecuado. Sí, es obvio, pero es algo tan complicado de subsanar que hay que ponerlo. No siempre es posible decir que no a un proyecto, aunque se sepa que no se cuenta con los perfiles más adecuados. La formación en las tecnologías o metodologías requeridas puede no ser la más adecuada, pero, ya sea por necesidad, ya sea por avaricia, o por lo que sea, aunque los libros hablan de "formación proactiva", "eliminación de proyectos no prioritarios", etc., esto sigue y sigue.
  2. A los gestores/jefes de proyecto les falta formación. Cuando alguien programa bien, se le pasa a analista. Después, a jefe de proyecto. Pero resulta que las capacidades requeridas son totalmente diferentes. Pasas del compilador/CAD al excel. Pasas de ponerte los cascos y ponerte a trabajar "a tu rollo", a tener que gestionar equipos multidisciplinares. Nada nuevo bajo el sol.
  3. Estado del proyecto. No se mantiene adecuadamente. Mucho baseline, mucho retraso acumulado, pero, o no se sabe qué hacer con ello, o se queda en eso, sin fijarse en otros detalles de la relación con el cliente. Darse cuenta de que algo aparentemente intrascendente ahora puede ser crucial más adelante, o que algo aparentemente importante ahora es mejor dejarlo pasar por el bien del proyecto o de la relación futura con el cliente, es un arte y es un trabajo enorme.
  4. No utilización de técnicas de gestión de cambios. OK, los clientes cambian los requisitos a mitad de camino. Y nos seguimos quejando, aún cuando Fred Brooks lo escribió muy claramente hace ya más de 30 años. Las técnicas ágiles e incrementales han ayudado a mitigar este problema, pero no al nivel esperado.

Hay más, pero mejor lo leéis en el artículo.

Pero si queréis leer más sobre este tema, hay un libro y un wiki asociado con 97 artículos sobre elementos a tener en cuenta al crear arquitecturas empresariales. Cada artículo está escrito por un profesional de estos temas. Escribiré con toda seguridad sobre algunos de sus artículos más adelante, pero por si queréis adelantarme ;)

No hay comentarios: