¿Qué es mejor? ¿Sobrestimar (decir tiempo de más) un proyecto o subestimarlo (decir tiempo de menos)?

En este mundo hay dos tipos de informáticos: los que han sufrido un proyecto mal estimado y los que lo van sufrir. Los problemas relacionados con malas estimaciones son tan antiguos como la informática, hay informáticos en cuyos ojos se puede leer la palabra “dolor” cuando se susurran las palabras “hemos a estimado el proyecto en…”.
Los problemas, errores, malas prácticas, buenas, leyendas, ritos, mitología, etc., relativos al mundo de la estimación podrían cubrir varias decenas de post, si bien en esta ocasión me voy a detener en un clásico: ¿sobrestimar o subestimar?
Es decir, dada la incapacidad de haber acertado con una estimación mínimamente razonable en el pasado, debido al dolor que aun producen las cicatrices provocadas por las malas estimaciones, muchas empresas, equipos, etc., caen en intentar cubrirse las espaldas diciendo tiempo de más, sobrestimar, y otras, siendo este el caso más frecuente, dicen tiempo de menos.
Lo de decir tiempo de más es un caso más raro, suele darse para inflar proyectos o para cubrirse las espaldas. Subestimar es más común, las razones suelen ser típicamente dos: llevarse un proyecto frente a la competencia, al bajar tiempos y costes, o meter presión a desarrollo, “-si les digo que son 5 meses aunque realmente son 10 me aseguro que terminan a tiempo-“, que aún piensa algún gerente bajo el paradigma de gestión TM (Troglodita Management).
Aunque te pueda parecer una obviedad, lo más económico es que a la hora de estimar te acerques lo máximo a la realidad, te aseguro que aunque esto te pueda parecerte una obviedad para demasiada gente no lo es, al menos eso es lo que me ha enseñado la “calle”, el ver y ver proyectos software.
¿Es que entonces tiene sobrecostes tanto estimar como subestimar? Si claro ¿Y que conlleva más coste? ¿Sobrestimar o subestimar? Vamos a ver…

Los sobre costes de sobrestimar

¿Qué pasa si dices tiempo demás? Lo normal, por la naturaleza humana, es que seas presa de la llamada Ley de Parkinson.
Dice la ley de Parkinson que “el trabajo se expande hasta ocupar el tiempo disponible para realizarlo”. Es decir, que si una tarea se puede hacer sólo en un mes, pero dispongo de dos… al final estaré los dos meses liado con la tarea.
La conclusión es que si sobrestimo, es decir, digo que tardaré más tiempo en realizarlo del que realmente se podría tardar, es muy probable que finalmente el proyecto ocupe todo ese tiempo innecesario e incurramos en un sobrecoste.
Típicamente, el sobrecoste de sobrestimar se incrementa linealmente según pasa el tiempo y tiene un tope, ya que el trabajo extra innecesario ocupará un tiempo máximo conocido, la fecha máxima hasta la que se sobrestimo.

Los sobre costes de subestimar

¿Qué pasa cuando estimo tiempo de menos? Es decir, se necesitarían razonablemente 10 meses para hacer el proyecto pero alguien decidió que se podía hacer en 5 meses. Bueno, tampoco hay que ser un genio para saber que pasa, sólo haz un poco de memoria… ¿Qué paso la última vez que viviste esta situación?
Cuando un proyecto va con retraso comienzan a aparecer un conjunto de actividades tipo “sálvese quien pueda o crisis mode on” que normalmente no aparecen en un proyecto que va bien de tiempo: reuniones de crisis o de seguimiento con la dirección, reuniones con el cliente para explicar la situación, hacer demos parciales no planificadas para calmar al cliente, reuniones sobre qué requisitos son estrictamente necesarios, cuáles son los mínimos para salir a producción, etc.
Además, aparece el pánico, el miedo, las jornadas interminables, las nocturnas, todo ello conlleva a hacer las cosas mal, a tener que hacerlas dos veces, a dejar ya sabes, como decía aquel en las “mejores” frases que he escuchado en proyectos : “las prisas pasan y la m**rd* queda”.
Pero subestimamos el sobrecoste generalmente crece exponencialmente, cuanto más alejada este la subestimación del tiempo real mayor será el sobre coste y, además, no el sobre coste no está acotado.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “¿Qué es mejor? ¿Sobrestimar (decir tiempo de más) un proyecto o subestimarlo (decir tiempo de menos)?”

  1. Yo normalmente calculo el tiempo que necesito para hacerlo y si son 10 días digo 12 más que nada porque siempre puede ocurrir alguna cosa por enmedio, pero normalmente si no pasa nada raro cumplo siempre con los plazos y luego se lo entrego al cliente incluso un día antes y el cliente está mega contento, es mi manera de trabajar la verdad, tampoco exagero con los timmings, siempre pongo un poco más, si por ejemplo me va a llevar 4 horas pues que sean 6 para no pillarme los dedos por lo que pueda ser, no se, es mi forma de trabajar y nunca he tenido queja de ello. Lo de subestimar lo veo horrible, pq al final o se hacen horas extras todos los días o no se llega y no das buena imagen, porque encima que no llegas, el coste de producción va a costar más caro que no el coste del proyecto y encima el cliente va a estar cabreado y quizás ya no vuelva a pedirte nada e igualmente se vaya a la competencia.
    Aunque ultimamente en España se lleva mucho lo de subestimar y luego tardar lo que se debería tardar, me he encontrado mogollón de gente diciendome que estos otros me lo hacen en menos tiempo y al final han tardado más que lo que le decíamos nosotros y encima no lo han acabado y han vuelto a nosotros con la mierda de otros para finalizar.
    Se deberían firmar más contratos a la hora de trabajar, contratos de definición del trabajo y contratos conforme fechas de entrega, entonces la gente empezaría a trabajar de forma eficiente creo yo.

  2. Entonces por lo que dices es mejor sobreestimar que subestimar, aunque es claro que lo mejor sería acercarse lo máximo posible a la realidad, cosa harto dificil si partimos de la base que, además de lo que tu expones, muchas veces los requisitos no están suficientemente cerrados y se modifican a lo largo del proyecto (y en muchos casos no se replanifica)

  3. Hola Javier, excelente Post
    Una de las cosas que aplico es la sobre estimación en los proyectos. Utilizo lo que se llama el buffer del proyecto que se utiliza para la gestión de proyectos, es decir, en caso de que existan riesgos poder manejarlos ese tiempo extra; sin embargo, ese sobre tiempo que manejo no lo menciono al equipo de proyecto. Es decir, para el equipo de proyecto manejo unos tiempos y para la alta dirección manejo otros. De esta forma evito la famosa ley de parkinson o también el síndorme del palo de golf.
    Saludos

  4. Me parece horrible no trabajar con transparencia.
    En mi opinión, sobrestimar es una forma de gestionar los riesgos. Al fin y al cabo estás aumentando el presupuesto del proyecto.
    Respondiendo a ant sobre motivos para sobrestimar:
    – El equipo no está dedicado el 100% del tiempo al proyecto.
    – El equipo no domina las tecnologías
    – El equipo no tiene dominio funcional sobre la temática
    – El equipo no tiene suficiente experiencia
    – El entorno de desarrollo es ineficiente
    – Si es un proyecto de mantenimiento, el equipo no conoce el código lo suficiente
    – Dudas o huecos en los requisitos funcionales
    – En los requisitos no se han tenido en cuenta cuestiones de seguridad y rendimiento

Dejar un comentario

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