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.
Y pensar que todavía hay gente que planifica proyectos sin tener ni idea de ingeniería del software…
Me ha gustado el ejemplo del muro, pero me gusta más el que usa mi jefe: «Una mujer tiene un niño en nueve meses, lo cual no implica que nueve mujeres puedan tener uno en un mes».
Cuando se está cerca de la fecha límite, meter más gente en un proyecto es el mayor de los desatinos. Como bien dices, no es que no ayuden, es que significan una carga aún mayor para el proyecto. Cualquier nueva incorporación ha de ser -por lo menos en un principio- formada y supervisada de cerca : arquitectura del proyecto, herramientas de desarrollo, alcance funcional del proyecto, etc… En definitiva explicarles «de-qué-va-este-marrón». Y eso no se hace ni en un día, ni en dos, requiere tiempo y esfuerzo extra -justo lo que no tienes- por parte del resto del equipo.
Como ha dicho root zero el problema es que quienes se encargan de la planificación suelen ser gestores y no ingenieros, y muchas veces no entienden que un «parto» requiere su tiempo (muy bueno el ejemplo, Martin Silennus :-D).
Otras veces, creen que si marcan una línea de tiempo agresiva, el equipo se pondrá las pilas y hará el trabajo en el plazo; el problema viene cuando el equipo no da más de sí y llega esa especie de bajón colectivo…
Gracias por las aportaciones :-)
También depende del trabajo y los conocimientos previos del mismo. Precisamente yo me incorporé en una situación así (junto a 3 técnicos) y logramos cumplir nuestros objetivos de usuarios atendidos. Y el tiempo marcado venía de Europa (subvención FSE). ¿Qué tienes que aterrizar y conocer? indudable, tardamos 4 días en ello pero de no haberlo hecho el programa no hubiera salido (era una OPEA en un ayto, materialmente imposible variar las condiciones que fija el Programa).
Saludos
Hace tiempo que no pasaba por aquí y me encuentro con una verdad como un castillo…
Pau, en realidad ya lo señalas tú en el post y lo deja meridianamente claro Martin Silennus. La cuestión no es de ingeniería informática, sino de la falta de visión estratégica de muchos directivos y «gestores» (que, entre otras cosas, cobran para tenerla) y el desastre de muchos departamentos de lo que se ha dado en llamar (en curiosa transcripción del inglés) «recursos humanos» (en vez, por ejemplo, del castizo «personal», que es más corto).
En informática se nota mucho porque hoy todos creemos «saber de ordenadores», pero también ocurre en otras profesiones de cuyo objeto «todo el mundo sabe» (p. ej.: psicología, enseñanza, etc.).
Saludos.
¿»Horda mongoliana»? ¡¡Pero si es la ley de los rendimientos decrecientes (economía)!! Estos «ingenieros del software» que creen que han descubierto algo nuevo… (no te me piques que te conozco):-P
Vaya, creo que le diré a mi jefe que se pase por este post a ver si se entera de una vez. Hace poco más de un año se decidió empezar un desarrollo vertical con el nuevo ERP adquirido por la empresa. El razonamiento de los ‘capos’ fue el siguiente: si necesitamos unas 5000 horas para concluir el proyecto y tenemos 2 personas dedicadas a ello al 100% tardaremos X tiempo, por tanto si contratamos 2 personas más, tardaremos la mitad, y si contratamos a 4 más, la mitad de la mitad, así terminaremos en menos de 1 año. Resultado: llevamos más de 1 año y ya somos 8 personas en el equipo y tenemos aproximadamente la mitad del proyecto terminado. Lo bueno es que tienen previsto contratar un par de personas más porque a principios del 2007 tiene que estar implantado en el primer cliente. Y lo mejor de todo es que los veteranos de la empresa dicen que siempre se ha trabajado así aquí, con lo que me pregunto como coj… esto no se ha hundido todavía. En fin, es lo que tiene que tu jefe no tenga ni idea de informática y le haga más caso a los comerciales que al ingeniero.
Saludos.
De todos modos, hay un beneficio que no se le escapa a nadie: hay más contratos de trabajo. Vale, los que trabajan por amor al arte o de gratis a lo mejor no lo valoran pero otros sí. (Y conste que me parece un análisis magnífico y económicamente impecable)
Saludos.
Antes de nada, a Misslucifer hay que aclararle que no hemos inventado nada… lo que pasa es que lo que recibe el nombre de «horda mongoliana» no es la ley de rendimiento decreciente en sí, sino lo que puede sobrevenir como consecuencia de ignorarla, normalmente cuando se piensa equivocadamente que más personal supone más velocidad de desarrollo. Muchas empresas ignoran esto y al final se encuentran con la «horda»: un equipo excesivamente grande que no es capaz de avanzar por la descoordinación interna.
El ejemplo aportado por el anónimo es un caso típico en que se ha formado una horda que es complicada de mantener… y enlazando con lo que ha comentado Mikel, a mí me da un poco de miedo pensar qué harán con diez desarrolladores una vez se entregue el proyecto… aunque es indudable que puede tener ese efecto positivo y que muchas veces no hay más remedio…
Posiblemente la cuestión no es qué hacer cuando hay presión, sino más bien saber planificar una línea de tiempo que no provoque retrasos en las entregas…
Muchas gracias a todos por los comentarios :-)