Estimación miope

0

Si algo me he dado cuenta como jefe de proyecto de desarrollo es que los desarrolladores son miopes. Todos son miopes, no se salva ninguno. Y es más, los jefes de proyecto, también son miopes. ¿Y que tiene que hacer un miope para poder ver bien de lejos? Ponerse gafas. Este artículo pretende daros gafas a aquellos que todavía no las tengáis.

Miopía en la estimación

La miopía es un defecto del ojo que impide ver bien los objetos lejanos. No afecta a los cercanos, sólo a los lejanos.¿Y por qué digo que los desarrolladores son miopes? Porque saben estimar el coste de tareas cercanas, pero no lejanas.

Mi experiencia me ha demostrado que cuanto más corta es una tarea, mejor estima el tiempo el desarrollador. Le preguntas “¿Qué tardas en cambiar el color del botón?” y si te contesta 20 minutos, probablemente tardará de 18 a 22 minutos. Le preguntas “¿Qué tardas en poner un nuevo botón que te haga una previsualización del resultado?” y te dice que dos días, probablemente tardará dos días, a lo sumo dos días y medio. “¿Qué tardas en hacer un nuevo formulario?” Una semana, y se puede ir a semana y media fácilmente. “¿Qué tardas en hacer un nuevo módulo de ventas?”, dos meses, y puedes prepararte para cuatro o más.

Incluso cuando se usan técnicas de estimación basadas en puntos, mi experiencia me dice que un punto no es la mitad de dos puntos, es menos. Y dos puntos no son la mitad de cuatro, son menos. Cuando alguien pone una tarea de 10 puntos, a temblar… puede ser el equivalente a 20 tareas de un punto.

Un ejemplo lo encontramos en la película “Esta casa es una ruina” en la que la estimación de la obra era siempre: 2 semanas.

Es decir, cuanto más larga es la tarea a estimar, mayor el error. Pero no sólo la varianza, también el sesgo. ¿No sabes que es el sesgo o la varianza? Pues en el siguiente punto te lo explico.

Un poquito sobre teoría de estimación y variables aleatorias

Cuando estimamos es un poquito como jugar a los dados. Damos una cifra y esperamos que esté lo más cerca posible del resultado. Si lo hacemos muchas veces (en distintas tareas) veremos que a veces nos quedamos más cerca a veces más lejos. A veces nos pasamos, a veces nos quedamos cortos. Pero si hacemos un estudio estadístico sobre nuestra fiabilidad para estimar veremos dos cosas:

  • Varianza: Es el factor de azar que hace que a veces nos pasemos o nos quedemos cortos. Cuanto mayor sea la varianza, peores nuestras estimaciones. La varianza produce errores de más y de menos a partes iguales.
  • Sesgo: Es un error sistémico en la medida. Es decir, por sistema tenderemos a decir de más o de menos.

Por ejemplo, imaginemos que la estimación de 3 tareas que luego han durando 10 días en ejecutarse habíamos estimado: 6 días, 7 días, 5 días. Las tareas han tardado todas 10 días. Por lo que veo dos cosas, una que probablemente en las estimaciones tenga un sesgo de 4 días. Es decir, siempre tiendo a quedarme corto unos 4 días. Y además tengo una varianza que “ronda” 1 día. Es decir, si sumase el sesgo a mis estimaciones me hubiese dado: 10 días, 11 días, 9 días. Con lo que si quitase el efecto del sesgo no me suelo equivocar en más de un día (eso es la varianza).

Los conceptos de sesgo y varianza son conceptos matemáticos exactos y no he querido entrar en ello, sólo una explicación breve sobre los mismos.

La varianza es dañina, porque hace que nos equivoquemos. Pero a veces nos hará quedarnos cortos y otras veces nos hará pasarnos. En un proyecto esto hará que algunas tareas tarden más y otras menos. Con lo que si el proyecto es largo y tiene muchas tareas, podemos esperar que lo que perdamos por un lado lo ganemos por otro. De esto viven los casinos. En una tirada de ruleta pueden ganar o perder. Pero tras muchas tiradas, saben que en promedio irán ganando. En una ruleta bien hecha, sólo hay varianza.

El sesgo es fatal si no se conoce. Porque no sólo hace que nos equivoquemos, sino siempre en la misma dirección. Es como si en un casino una mesa de ruleta se desbalancea y comienza a dar más veces los mismos números. Eso puede provocar que tienda a perder más veces y les fastidie la estadística. En proyectos es lo mismo. Si tenemos 100 tareas y en todas nos equivocamos en un 1 día en la estimación, se nos sumarán 100 días en el resultado final.

Volviendo a la miopía del desarrollador

Una vez tenemos claros los conceptos de sesgo y varianza, contínuo. Mi experiencia me dice que la estimación de un desarrollador tiene los siguientes defectos:

  • Varianza: Más o menos es constante. Es decir, es un porcentaje de la tarea que le pides. Si la tarea es larga, la varianza será grande. Si es pequeña la varianza será pequeña. Pero eso es de esperar.
  • Sesgo: Aquí viene lo bueno (o lo malo). Existe un sesgo que le hace estimar de menos. Y lo peor de todo es que cuanto más larga es la tarea, más elevado es el efecto de ese sesgo.

Mi experiencia me dice que para una estimación de uno o dos días, apenas hay sesgo. Para una o dos semanas, existe un sesgo del 25% al 50%. Es decir, cuando te dicen dos semanas, probablemente habrá una semana de sesgo. Si te hablan de varios meses, el sesgo puede llegar al 100%. Es decir, tres meses, pueden ser 6.

Origen del sesgo

Sigo con mi experiencia (lo cual quiere decir, que esto es más una intuición que un estudio científico). Cuando hago un análisis retrospectivo de por qué esa tarea de un mes se ha convertido en 6 semanas, siempre me encuentro con los mismos motivos:

  • Es que al final no había tenido en cuenta tal cosa.
  • Es que en los requisitos iniciales esto no estaba.
  • Es que al final, tal cosa me ha llevado más de lo que pensaba.

Yo creo que cuanto más grande es la tarea, más difícil es para el programador o el analista ver una figura completa de lo que hay que hacer. Así que hay partes que no ve. Como no las ve, no las estima. Y por qué no las ve, porque es miope. No ve bien de lejos, sólo de cerca. Así, cuando estima, mira la figura de lo que hay que hacer, no ve el detalle que complica la tarea, y hace una estimación muy optimista. Además en tareas grandes hay tendencia a subestimar las tareas dependientes del desarrollo, como las de QA.

 

Vale, el programador es miope, ¿y cómo le ponemos gafas?

No se puede. Simplemente no hay gafas para ver de lejos. La única solución es que no tenga que mirar de lejos. Es decir, y dejando las metáforas a un lado, haciendo que estime tareas pequeñas, y no grandes. ¿Pero si la tarea es grande, cómo la estimamos? Fácil, rompiéndola en tareas más pequeñas.

Una de las indicaciones que pido a mis equipos es que cuando desglosan las historias de usuario en tareas, se pongan un tope de puntos. Si creen que los superan, deben intentar romper la tarea y volver a estimar cada trozo. Hay veces que no se puede, pero suelen ser casos raros. Este es un buen criterio cuando se define una WBS.

Y esto aplica tanto en proyectos grandes como en pequeños. Es común ver un proyecto pequeño, de apenas un par de semanas, que se estima de golpe como una sola tarea. Una estimación de dos semanas, tenderá a ser miope.

La mala práctica: El padding

El padding consiste en hinchar las estimaciones para contrarrestar ese sesgo. Esto es una mala práctica. Lo mejor, como dije antes, es romper las tareas grandes en tareas más cortas en las que no exista ese sesgo. Pero aplicar un multiplicador es una mala práctica.

También lo es añadir reservas al proyecto. Una reserva es para un riesgo. Asumir que nuestra estimación es mala y “apañarlo” con una reserva no es la mejor solución.

Estimaciones up-down y down-up

Creo que en este artículo, aparte de hacer el chiste con la miopía, no he descubierto nada nuevo. Es la buena práctica que en todos los manuales de gestión de proyecto siempre se saca (PRINCE2, PMBOK, …): Las estimaciones deben hacerse de abajo (tareas pequeñas) hacia arriba (tareas grandes), y no al revés.

Y como conclusión final, recordaros que la correcta estimación de tiempos es quizás uno de los principales indicadores por los que medirán el éxito de vuestro proyecto, y vuestra imagen como buenos gestores de proyecto.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...