Aníbal el gestor de proyectos

Mi padre siempre tuvo mucho interés en la figura de Aníbal Barca, el general cartaginés que puso en jaque a la pujante república romana en la segunda guerra púnica hace casi 2000 años. Me contaba como partió desde el norte de África, atravesó la península Ibérica reclutando tropas y asegurándose una línea de suministros, atravesó los Alpes con elefantes de guerra cuando nadie lo imaginaba posible y como puso en jaque a todo lo que Roma pudo echarle encima durante años de sembrar el terror en el corazón de la República… para ser finalmente fue derrotado por un general enemigo (Escipión el Africano), con un plan lo suficientemente audaz y quizá por la falta de recursos que le provocaron los propios gobernantes cartagineses.

Aníbal fue una de esas personas que pudo haber cambiado la historia del mundo a lo grande. ¿Imaginas un mundo en el que el Imperio Romano no hubiese existido? Quizá ahora estaríamos hablando una variante del persa, la Iglesia Romana no habría existido y sabe dios qué clase de cultura tendríamos en Europa.

En inferioridad

Y pensando en Aníbal y en sus estrategias de batalla, no puedo dejar de ver ciertos paralelismos con los proyectos de desarrollo de software y una pregunta que me hago constantemente: ¿Cómo llevas a buen puerto un proyecto con menos recursos de los necesarios?

Una de las batallas de Aníbal, la batalla de Cannas o Cannae, es uno de los mejores ejemplos de cómo vencer a un enemigo superior en número aprovechando el conocimiento del terreno y planteando una estrategia que incluye conocer las características de tus tropas y ejercer el liderazgo de forma directa.

En esa carnicería, Aníbal logró utilizar las elevaciones del terreno, el curso del rio Ofantos (el entorno y circunstancias) y la variedad de fuerzas que tenía a su disposición: un ecléctico conjunto de caballería númida, infantería pesada cartaginesa e infantería ligera ibérica (el equipo). Planificando la batalla al milímetro (la planificación) y usando todo lo aprendido y refinado en batallas anteriores (la experiencia), supo leer la estrategia romana por adelantado (prevención) y acertó a situarse en el centro de todo el meollo, es decir en la peor parte, para poder infundir valor y mantener el orden evitando así el colapso previsible de su línea de batalla (liderazgo, control y un par de huevos) en circunstancias normales.

No rompas la línea, soldado

La línea de batalla es el nombre que se le da al “muro” de soldados que plantamos frente al enemigo y mantenerlo entero evita que el enemigo divida nuestras fuerzas en dos o más grupos. Una ruptura en nuestra línea impedirá la coordinación entre grupos aislados, debilitando a las unidades por falta de apoyo y facilitando que se nos rodee convirtiéndonos de facto en pasto de buitres. Por ello jamás debe (siempre hay excepciones) romperse la línea pues la única opción es la retirada (total, o para recomponer la línea). O el exterminio, claro, que en este caso se produjo en el bando romano gracias a la unidad del frente cartaginés.

No rompas la línea, developer

En desarrollo de software, también existe esa línea de batalla, y la compone cada uno de los miembros del equipo. Si alguno de los miembros del equipo se retira de un proyecto para trabajar en otro, habremos dejado un hueco en nuestra línea. Uno que debe ser cubierto por un perfil similar, o que debe ser cerrado reduciendo la longitud de nuestra línea.

Esto se traduce en que si tenemos un número de desarrolladores pequeño, nuestra línea, al alargarse para abarcar más, será fina, y por tanto débil, incapaz de soportar una ampliación o cambio en el proyecto (o el aumento de proyectos). Por otro lado, si nos empeñamos en mantener la línea con cierto “grosor”, el aumento de alcance de un proyecto o del número de proyectos acabarán por rodearnos, o colarse por nuestros huecos. Y si el trabajo nos rebasa por los flancos tendremos una versión de la carnicería de Cannas en versión desarrollo de software. En caso de que nuestra línea deje huecos, nos dividiremos, perderemos la comunicación, nos aislaremos y lo más probable es que aunque algunos puedan huir, el resto acabe siendo pasto de los buitres de un proyecto fallido.

Como última reflexión, normalmente toda derrota en el campo de batalla se traduce en dolor, sangre, soldados desertando, generales que se retiran antes del previsible final, y algún que otro héroe que morirá igualmente. Además de los castigos ejemplares para los supervivientes, porque hay que dar ejemplo :-(. Es curioso cómo pueden llegar a parecerse el desarrollo de software y las batallas de la antigüedad.

Anuncios

Un pensamiento en “Aníbal el gestor de proyectos

  1. Pingback: Analogías y desarrollo de software II | jbolano

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s