La horda mongoliana
Vamos muy mal de tiempo. Hay que entregar un proyecto en quince días y el equipo está muy presionado, y es muy posible que el desarrollo no se concluya en el plazo previsto…
Los directivos no quieren correr el riesgo de perder a un cliente importante, e insisten en que el producto quede listo en el plazo previsto. Lo que no saben, o si lo saben no les importa, es que ese plazo era imposible de cumplir desde un primer momento… una vez más, las fechas las fijó un gestor en vez de un informático.
Los jefes se han reunido y han acordado que lo mejor es contratar a más personal para que se integre en el equipo… “si en vez de trabajar cinco personas, trabajan diez, lógicamente el proyecto se terminará en la mitad del tiempo previsto”. El equipo directivo sonríe satisfecho y cinco nuevos trabajadores se incorporan al equipo.
Dos semanas después, se cumple el plazo y el proyecto no está terminado… los directivos, confundidos, piden explicaciones al equipo técnico, que les dice que lejos de hacerles avanzar más rápido, las nuevas incorporaciones les hicieron ir aún más lentos…
¿Qué ha pasado?
Los directivos olvidaron que más personal no implica una mayor velocidad en el desarrollo, y han caído en la trampa conocida en la ingeniería del software como “La horda mongoliana”, que se resumen en “si no da tiempo, contrata a más gente”. Es posible que a primera vista esa forma de pensar parezca lógica, pero cuando uno lo piensa se da cuenta del grave error que supone.
Imaginemos que tenemos que construir un muro de ladrillo de un metro de alto y disponemos de dos albañiles que tardarán, pongamos, un día en terminarlo. Nadie nos garantiza que 24 albañiles lo construirán en una hora… de hecho es posible que tarden hasta más del día inicial, porque tendrían que coordinarse muy bien para alcanzar cierto rendimiento.
El ejemplo del muro nos desvela uno de los dos fenómenos que intervienen en el problema de la horda mongoliana: más medios son más difíciles de coordinar. El otro fenómeno que concurre es muy interesante, y consiste en que las personas tardamos en rendir al 100% al incorporarnos a un equipo: tenemos que aprender cómo se trabaja en la empresa, ponernos al día de los procedimientos, entender lo que se está desarrollando y en menor medida, necesitamos tomar un poco de relación con nuestros compañeros.
Para evitar caer en estos fallos tan lamentables como frecuentes es necesario escuchar al equipo de desarrollo antes de fijar los plazos de entrega, y dentro de unos límites, llegar a un consenso con los trabajadores. Si la presión es grande, puede ser mejor idea incrementar la jornada de los técnicos y pagarles las horas extra (lo cual a veces no interesa, pero esa es otra historia).
Si no queda más remedio que contratar a personal ajeno, es donde nos ayudará el contar con procesos sistemáticos de ingeniería que nos permitirán que el nuevo equipo se adapte con rapidez al desarrollo existente.
