Que no se hunda tu… proyecto

Recientemente he tenido la oportunidad de visitar Estocolmo y uno de sus museos más espectaculares, el Vasamuseet. Este museo está dedicado a un único barco, el Vasa. Este buque de guerra es tristemente célebre por su ambicioso (y carísimo) diseño y por su brevísima vida útil: el que tenía que ser el buque insignia de la armada sueca se hundió el mismo día de su botadura, el 10 de agosto de 1628, en condiciones de buen tiempo y casi sin salir del puerto.

Imagen del Vasa en el Vasamuseet

Fotografía del Vasa en el Vasamuseet (por Nick Lott)

El Vasamuseet dedica una parte importante de su exposición a analizar por qué se hundió el Vasa. El hecho innegable es que hubo un problema de ingeniería: el centro de gravedad del barco era demasiado alto y por lo tanto era inestable. Pero el problema de fondo fue una mala gestión del proyecto. De  hecho, la historia del Vasa podría ser la de muchos proyectos informáticos… Repasemos la lista de factores en contra, porque supongo que os resultarán muy familiares:

  • Los objetivos del proyecto eran muy ambiciosos: el Vasa tenía que ser el buque de guerra más poderoso que hubiera surcado los mares.
  • El proyecto incorporaba características innovadoras que nunca antes se habían probado: el barco tenía dos puentes de cañones, cuando en Suecia sólo había experiencia en construcción de barcos con un solo puente.
  • Había una gran presión en los plazos de finalización: Suecia estaba en guerra con Polonia y necesitaba el barco para el conflicto.
  • Los requisitos del proyecto cambiaron diversas veces desde el inicio: de un puente de cañones pesados se pasó a un puente de cañones pesados y otro de ligeros, y finalmente a dos puentes de cañones pesados.
  • Hubo un cambio de liderazgo a mitad del proyecto: el constructor murió durante el proceso de construcción y tuvo que ser sustituido.
  • Una persona externa al proyecto, con gran autoridad pero sin conocimientos técnicos, daba instrucciones que no podían ser cuestionadas: el rey Gustavo II Aldofo de Suecia se entrometió en el proceso de construcción y un rey nunca podía equivocarse.
  • Hubo fallos en la comunicación de las incidencias detectadas: el rey no estaba presente el día que se probó la estabilidad del barco – 30 marineros corriendo de un lado a otro de la cubierta estuvieron a punto de volcar el barco (!). Las noticias no le llegaron a tiempo… o nadie se atrevió a decírselo.
  • La puesta en producción fue prematura: en el viaje inaugural las troneras de los cañones estaban abiertas por cuestiones de imagen. La inestabilidad del barco hizo que entrara agua por ellas y acabó hundiéndolo. Este problema podría haberse evitado navegando con las troneras cerradas.

Os dejamos algunos enlaces con más información sobre esta historia. Es curioso ver que después de 400 años el ser humano sigue cometiendo los mismos errores…

3 Comments

  1. Todos hemos tenido nuestro propio Vasamuseet… o desgraciadamente tenemos constantemente un Vasamuseet debido a que el cliente no tiene claro qué quiere y nosotros tampoco hemos conseguido acertar tratando de “adivinarlo”

    Reply
  2. Creo que en demasiadas ocasiones nos enfrentamos a un Vasamuseet y lo que es más triste es tener conciencia de ello al comienzo de un proyecto y además detectar indicios de que será casi imposible evitar que se hunda antes de construir…

    Reply
  3. Realmente, creo que como se comenta, fueron muchos los factores que influyeron en que el proyecto no fuera un éxito. Intentaré hacer un pequeño análisis personal “punto a punto”, sobre los errores que se mencionan.

    – Objetivos ambiciosos: Creo que los objetivos deberían haber sido realistas y no ambiciosos. Tendrían que haberse planteado acorde a los recursos y conocimientos de los que se disponían en el momento de empezar el proyecto.

    – Innovaciones no probadas con anterioridad: Para avanzarnos al éxito de un proyecto, o evitar el fracaso, es importante tener conocimiento de que la combinación de recursos y tecnologías que se utilizarán han demostrado funcionar como se desea. En caso contrario, y si lo que se desea es innovar, hay que dejar un margen amplio para pruebas, que puede ser largo en función de si estas cumplen con lo esperado o no. En el punto siguiente se observa un conflicto con la innovación.

    – Presión en los plazos: La presión en los plazos es un tema común en la mayoría de proyectos, y esto puede ser un factor muy negativo si no se adaptan correctamente a las necesidades del proyecto. También hay que tener en cuenta que si el proyecto necesita periodos para efectuar pruebas, este podrá retrasarse si las mismas no dan los resultados esperados, teniendose que plantear alguna modificación “extra”.

    – Continuo cambio en los requisitos: Este punto es muy importante, y tiene una fase (al inicio del proyecto) en la que se debe llevar a cabo. Una vez presentado el proyecto inicial, si que debe de ser revisado por otros expertos para rectificar posibles fallos o conflictos que puedan surgir. Lo que no se debe hacer, son cambios constantes en todas las fases del proyecto.

    – Cambio de liderazgo: Un cambio de liderazgo es un tema delicado, ya que si el proyecto no ha sido minuciosamente documentado, pueden existir partes del mismo de las que no tenga constancia el nuevo responsable. Esto probocará que ciertos aspectos puedan ser omitidos, y por lo tanto, puedan aparecer en forma de problemas durante la evolución del proyecto.

    – Instrucciones por una autoridad sin conocimientos técnicos: Este punto me recuerda al tipo de clientes que exigen un bien imposible de producir. Para poder llevar a cabo el proyecto, hay que dejar claro hasta donde se puede llegar, y que aspectos técnicos son posibles con los medios de los que se disponen. Todas las decisiones, deben ser puestas en común entre técnicos, para poder conseguir la mejor solución.

    – Incidencias detectadas durante la prueba: Con los avances técnicos actuales, este tipo de incidencias se pueden detectar (en la mayoría de ocasiones) antes de finalizar el proyecto. De todos modos, y situandonos en el contexto del que trata el artículo, en caso de que la prueba no sea positiva, el proyecto nunca debe darse por finalizado y se tendrían que haber revisado todos los posibles puntos que puedan haber influido negativamente en el éxito de la misma.
    – Puesta en producción prematura: Nos indica claramente que los tiempos no eran los más indicados para dar por finalizado el proyecto. El caso de las troneras de los cañones abiertas ponen de manifiesto que no siempre el diseño puede ser más relevante que la funcionalidad. La clave está en encontrar un diseño que beneficie la funcionalidad.

    Como he indicado con anterioridad, este es un análisis personal, por lo tanto queda totalmente abierto a críticas, sugerencias, rectificaciones, …

    Un saludo cordial,

    Àlex Planelles Soler

    Reply

Trackbacks/Pingbacks

  1. Las pequeñas mentiras que nos contamos los jefes de proyecto | iNFoRMáTiCa++ - [...] interesante post de mi colega (y sin embargo amigo) Robert Clarisó que publicó hace algunas semanas en esta mismo…
  2. Bromas aparte (más sobre gestión de proyectos) | iNFoRMáTiCa++ - [...] de proyectos, después de las historias más o menos sarcásticas de algunos posts anteriores [1][2] y los comentarios de…
  3. 50 entradas (y seguimos trabajando) | iNFoRMáTiCa++ - [...] Que no se hunda tu… proyecto  323 visitas [...]
  4. It’s not a bug | iNFoRMáTiCa++ - [...] complicada que necesita una buena gestión para no naufragar. Esto ya lo habíamos comentado en una entrada anterior. Sin…

Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Leer entrada anterior
Symbaloo: una herramienta útil de escritorio web

Symbaloo es una herramienta 2.0 que genera escritorios web con un diseño webmix muy moderno, sencillo y atractivo. Además, es...

Cerrar