Chess - antoniomartel.com

Archivos por Etiqueta: Estimaciones

No te dejes engañar por un diagrama de Gantt y la Falacia de la Planificación

¿Cuántos proyectos conoces que hayan acabado dentro del tiempo y presupuesto estimado sin que haya habido que reducir el alcance del proyecto? Muy pocos ¿no? Yo tampoco conozco muchos casos. Esto pasa en casi todos los sectores, no sólo en la industria del software, pero me temo que nuestra industria tiene una tasa de proyectos fracasados más alta que otras industrias. El estudio realizado para el Informe CHAOS 2015 revela que sólo el 29% de los proyectos TI pudo considerarse un éxito.

Nuestras estimaciones de tiempo y coste de un proyecto se salen de toda escala e incumplimos habitualmente nuestros relucientes diagramas de Gantt hechos al inicio del proyecto ¿A qué se debe esto? Bueno, al menos tiene una explicación científica. Se debe a un sesgo cognitivo que tenemos todas las personas no deprimidas y que hace que caigamos, una y otra vez, por exceso de optimismo en la llamada falacia de la planificación.

Este fenómemo, el de la falacia de la planificación, es debido a que los seres humanos tendemos a subestimar cuanto nos va a llevar terminar una tarea. Somos demasiado optimistas y siempre pensamos que vamos a tardar mucho menos de lo que finalmente nos va a llevar terminarla.

Lovallo y Kahneman, los autores de esta teoría, realizaron un estudio en el que preguntaron a 87 estudiantes de una universidad cuánto tiempo creían ellos que necesitarían para terminar su proyecto de fin de carrera. De media estos estudiantes estimaron que tardarían 34 días en finalizarlo el proyecto pero sólo el 30% de ellos fueron capaces de hacerlo en ese tiempo. La media real empleada en terminar sus tesis fue de 55.5 días, un 63% más de lo estimado.

Este exceso de optimismo es provocado en parte por la llamada ceguera de ausencia (absence blindness) que nos dice que por muy bien que planifiquemos nuestro proyecto nos será muy difícil planificar los imprevistos porque son eso, imprevistos, y no los conocemos de antemano. Planificamos todo lo relacionado con las especificaciones del proyecto pero olvidamos calcular los tiempos para las vacaciones, bajas por enfermedad, paternidad, maternidad, reuniones, otras tareas que causan overhead, dependencias de otros proyectos, requisitos que no están bien definidos y un larguísimo etcétera. Como dice Forrest Gump en su película, shit happens (esas cosas pasan).

Todo esto nos lleva además a tener en cuenta la Ley de Hofstadter: «Todo proyecto lleva siempre más tiempo del previsto incluso si se tiene en cuenta la propia Ley de Hofstadter«. Y si esto ocurre y nuestro proyecto se alarga más de lo previsto, probablemente caigamos todavía en más costes de lo que supone terminar más tarde. Como no llegamos a la fecha del fin del proyecto la presión nos llevará a meter a más gente dentro del proyecto para terminaar a tiempo haciendo que tengamos que contabilizar gastos extra directos como el salario de estas nuevas personas pero también indirectos de los cuáles no siempre somos conscientes.

Al incluir más personas olvidamos que necesitarán formación en el proyecto y que cometerán más errores al ser nuevos, errores que habrá que dedicar un tiempo a corregir. Se estima que un nuevo perfil en un proyecto tarda unos tres meses en ser totalmente productivo. Por otro lado, alguien que ya estaba trabajando en el proyecto tendrá que parar lo que estaba haciendo para enseñar a los nuevos. Como ya nos decía Brooks en los 70: «Añadir más gente a un proyecto retrasado, hará que se retrase aún más«.

Pero la presión aún nos hará incurrir en más costes en el proyecto. Las prisas nos harán bajar la calidad del producto que producimos, aparecerán más errores que también necesitarán tiempo para ser corregidos, o nos saltaríamos las pruebas del software con lo que saldrá a producción con bugs que nos harán perder la confianza y credibilidad con nuestro cliente. Y queremos que nos contrate de nuevo ¿no?

 

¿Qué podemos hacer para evitar esto?

En primer lugar debemos hacer un esfuerzo para tener en cuenta el máximo número posible de imprevistos que puedan surgir calculando así un tiempo extra para esos inconvenientes del día a día y aquellos otros que puedan ser aún más imprevisibles.

Podemos también intentar apoyarnos en las estadísticas de proyectos similares al nuestro. Si comprobamos cuanto tardaron probablemente nos llevemos una sorpresa si lo comparamos con lo que nosotros hemos previsto inicialmente.
Por último, sería bueno apoyarnos también en pruebas empíricas y no en estimaciones predictivas y medir la velocidad del equipo para calcular cuantas tarjetas podemos consumir en cada sprint. Así sabremos calcular un poco mejor qué podremos tener terminado en determinadas fechas. Los equipos de trabajo no son siempre iguales y si nos basamos en la cantidad de puntos o historias de usuario que nuestro equipo ha podido hacer durante los últimos sprints, podremos calcular algo mejor la cantidad de tiempo que nos llevará hacer otras funcionalidades similares en las próximas semanas o meses.
Otros artículos que pueden ser de tu interés:
Referencias:

Errores comunes en las estimaciones (II): La trampa del ancla

Hablaba hace unas semanas sobre uno de los errores más comunes al hacer estimaciones en un proyecto, el exceso de confianza. Les voy a hablar esta semana sobre otro error muy frecuente: la trampa del ancla.

Al tomar una decisión, como la que hacemos al dar una estimación, le damos un peso desproporcionado a la primera información que recibimos. El comentario de un cliente o algo que hemos oído sobre otro proyecto similar puede hacernos anclar nuestra propuesta a ese dato inicial aunque otra información más objetiva nos habría llevado a otra cifra.

Cierto profesor universitario suele hacer una prueba para mostrar a sus alumnos el efecto del anclaje en sus predicciones. Les pide a cada uno que hagan lo siguiente:

  • Anote en un papel las últimas tres cifras de su número de teléfono. Súmele 400 a esa cifra y anótelo en el mismo papel.
  • Atila el Huno fue uno de los conquistadores más terribles de nuestra era hasta que fue derrotado por los romanos ¿Fue derrotado antes o después de la fecha que anotó en el papel? Escriba en el papel la palabra ‘Antes’ o ‘Después’.
  • Escriba ahora el año en el que cree que Atila el Huno fue derrotado.
Curiosamente a aquellos cuyo número de teléfono más 400 estaba entre 400 y 599 predecían de media que Atila fue derrotado sobre el año 580 pero para aquellos cuyo número estaba entre 1200 y 1399 se inclinaban de media por la cifra de 1340. Habían relacionado ambas cosas pero ¿Qué tiene que ver el año en que Atila fue derrotado con nuestro número de teléfono? Nada, pero todos tendemos de forma natural a caer influenciados por esas primeras informaciones que recibimos.
Esto es lo que nos pasa cuando nuestro cliente nos pide un presupuesto pero nos dice que sólo cuenta con 20000 euros. Hacemos nuestros cálculos sobre el coste del proyecto influenciados por esta cifra como cuando lo hacemos por el número de teléfono del ejemplo anterior. Si las cifras reales al finalizar el proyecto muestran un número muy superior ¿Ejecutamos mal el proyecto o estimamos mal debido al ancla a los 20000 euros?
No confíe demasiado en su experiencia en proyectos del mismo tipo. Los expertos también fallan en sus estimaciones. Dos investigadores preguntaron a cirujanos especializados en enfermedades del pulmón por las posibilidades de que cierto paciente desarrollase una enfermedad pulmonar. A un primer grupo les preguntaron si la posibilidad era mayor o menor que un número aleatorio sacado de una tarjeta, digamos el 20%, y que escribieran luego su propia estimación. A un segundo grupo les hicieron la misma pregunta pero sobre una tarjeta aleatoria distinta, pongamos 50%
Ya puede imaginarse los resultados. Los cálculos de la mayoría de miembros del primer grupo rondaban el el número mostrado en la primera tarjeta y en el segundo grupo las predicciones se acercaban al 50% de la segunda. El número aleatorio que se les mostró influyó mucho más en su predicción que todo su conocimiento previo en el área. 
Tenga cuidado con toda información que pueda anclar sus estimaciones. Le podría salir muy caro.

Si quieres saber más sobre estimaciones aquí te dejo algunos de los post más populares:

Fuentes:

  • Curso Successful Negotiation de George Siedel en Coursera.

Errores comunes en las estimaciones (I): El exceso de confianza

Quién no se ha equivocado alguna vez estimando el coste de sus proyectos. Dividimos cuidadosamente el trabajo a hacer en una lista detallada de pequeñas tareas, consultamos a los compañeros que más experiencia tienen en las tareas más complejas, tenemos en cuenta los tiempos para preparar el entorno y un montón de cosas más pero aún así nos equivocamos y, con frecuencia, nos equivocamos por mucho. ¿Qué sucede? ¿No sabemos estimar? No podemos perder dinero en cada proyecto pero tampoco podemos aumentar las cifras ‘por si acaso’ porque lo que comenzaremos a perder son clientes.

Las razones por las que nos equivocamos una y otras vez cuando estimamos son muchas. Te explico aquí una de las más importantes:

El exceso de confianza en las estimaciones

El ser humano es optimista por naturaleza. Confía en exceso en sus propias posibilidades y olvida que los pequeños desastres del día a día le suceden a uno también no sólo a los demás. Cuando calculamos mentalmente lo que tardaremos en hacer una determinada tarea sólo tenemos en cuenta los pocos minutos que nos llevará teclear el código pero con frecuencia olvidamos el tiempo para testear, para desplegar, para documentar y comentar el código, para solucionar ese bug en el navegador, para escribir el manual de usuario y un sin fin de cosas más.

Tengo malas noticias: Usted también es demasiado optimista ¿no lo cree? Haga esta prueba conmigo:

Si le pido que me indique el año en el que nació Mozart probablemente no podrá darme un valor exacto pero si le facilito un poco las cosas y le pido que me indique un rango de años en el que con un 90% de probabilidad usted cree que Mozart nació posiblemente sí se atreva a darme una respuesta.

Ampliemos un poco esta prueba. Le planteo ahora diez preguntas. Anote por favor el rango de números entre los que cree con un 90% de probabilidad que acertará la respuesta correcta.

  1. Año en el que Mozart nació. Límite inferior: ____ Límite superior: ____
  2. Longitud del río Nilo. Límite inferior: ____ Límite superior: ____
  3. Número rayos que golpean la tierra por minuto. Límite inferior: ____ Límite superior: ____
  4. Tiempo que tarda la luz del sol en llegar a la Tierra (en segundos). Límite inferior: ____ Límite superior: ____
  5. Diámetro de la Luna. Límite inferior: ____ Límite superior: ____
  6. Número de cuchillos, tenedores y cucharas en la Casa Blanca. Límite inferior: ____ Límite superior: ____
  7. Número de lenguas vivas que se hablan actualmente en el mundo. Límite inferior: ____ Límite superior: ____
  8. Periodo de gestación (en días) de una elefante asiático. Límite inferior: ____ Límite superior: ____
  9. Número de nacimientos que tienen lugar diariamente en el mundo. Límite inferior: ____ Límite superior: ____
  10. Número de días en los que un caracol puede dormir si no es molestado. Límite inferior: ____ Límite superior: ____
Al final de este post tiene las respuestas correctas. Si sus estimaciones fueron correctas debería haber acertado 9 de las 10 preguntas ¿no fue así? No se preocupe, la mayoría de gente solo acierta unas pocas. Tendemos a ser demasiado optimistas y elegimos un rango demasiado pequeño para acertar. Nos pasa a todos, de hecho, las personas que no tienen este sesgo optimista se consideran clínicamente deprimidas.
Ahora que conoces un poco más tu propia forma de pensar quizás decidas ser un poco más precavido en su próxima estimación. Aún así no se confíe, las personas que fueron advertidas de este sesgo optimista antes de hacer pruebas como ésta también pecaron de exceso de confianza en sus predicciones.
Las próximas semanas iré publicando nuevas entradas sobre los errores más comunes que cometemos al estimar. Atento a las nuevas entradas. 
Si quieres saber más sobre estimaciones aquí te dejo algunos de los post más populares:

  1. Año en el que Mozart nació. 1756.
  2. Longitud del río Nilo. 6,738 kilómetros
  3. Número de veces que un rayo golpea la tierra por minuto. 6,000
  4. Tiempo que tarda la luz del sol en llegar a la Tierra. 492 segundos
  5. Diámetro de la Luna. 3,476 kilómetros
  6. Número de cuchillos, tenedores y cucharas en la Casa Blanca. 13,092
  7. Número de lenguas vivas que se hablan actualmente en el mundo. 6000
  8. Periodo de gestación de una elefante asiático. 645 días
  9. Número de nacimientos que tienen lugar diariamente en el mundo. 365,000
  10. Número de días en los que un caracol puede dormir si no es molestado. 1,095 días

Fuentes:

  • Statistic Brain and Odd Trivia Facts de Russo y Schoemaker publicado a su vez en el curso Successful Negotiation de George Siedel en Coursera.

Cómo hacer que las estimaciones digan lo que quieras

Tu cliente te ha pedido una estimación. Tiene una idea en la cabeza y quiere saber cuánto le costará y en cuanto tiempo lo tendrá. Él ha hecho sus propios cálculos y te comenta brevemente las cifras que tiene en la cabeza.

Llegas a la oficina y te reúnes con los técnicos más expertos en este tipo de proyectos. Después de darle unas cuantas vueltas llegas a un acuerdo con ellos sobre el tiempo y la dificultad en realizar este tipo de trabajo. Has tenido que convencerlos un poco para que no sean tan precavidos, después de todo no parece un proyecto difícil.

Aún así la cifra obtenida es muy superior a lo que el cliente había previsto. Además, si esa previsión fuese cierta no podrían cumplirse las fechas en las que se necesita el proyecto terminado. Necesitarás reducir esta estimación en al menos un 50%. Aquí tienes cómo hacerlo en 5 fáciles pasos:

  1. Ya lo has hecho antes. Ahora vas a tardar menos. Has hecho proyectos parecidos en otras ocasiones, seguro que se ha aprendido de los errores cometidos y los problemas que surgieron en otras ocasiones no tienen por qué pasar ahora (10% menos) ¿seguro que no ocurrirán otros problemas nuevos?
  2. El cliente ha dicho que quiere algo sencillo. No será tan difícil de hacer. Podremos hacer algo básico eliminando complejidades (10% menos). El cliente conoce bien su negocio y le parece fácil pero ¿y tú? ¿tienes todo el conocimiento del negocio del cliente?
  3. Vigilaremos mucho los costes. En otras ocasiones el proyecto no se ha supervisado correctamente pero esta vez estarás especialmente atento a cada hora empleada y no dejarás que se te vaya de las manos (10% menos)
  4. Pondremos a los mejores técnicos. Es un proyecto relevante para un cliente importante. Habrá que asignar a los mejores técnicos para el trabajo (10% menos) aunque aún no sabes si estarán disponibles en las fechas que los necesitas.
  5. Se hará un esfuerzo extra. Si fuese necesario y comprobásemos que no podemos cumplir con el tiempo previsto se pedirá a todos los implicados que hagan un esfuerzo adicional durante unas semanas. Si fuese necesario añadiremos incluso algún técnico adicional a mitad del proyecto para así acabar en plazos. (10% menos) Recuerda la Ley de Brooks: ‘Añadir personal a un proyecto retrasado sólo hará que se retrase aún más

Ya lo tenemos. Con solo un poco de trabajo hemos conseguido reducir la estimación inicial en un 50%. En realidad, para hacer que la estimación encaje en un presupuesto, nos hemos autoconvencido de que podemos hacer el trabajo en la mitad de tiempo. Lamentablemente las estadísticas muestran que los proyectos software tardan, en promedio, un 120% más del tiempo previsto inicialmente y que el costo final resulta ser un 100% más elevado que el que se calculó en la primera estimación.

Puedes ver más sobre estimaciones en:

Referencias: Estimaciones: errores comunes (Carlos Fontela)

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

Repaso a 2013

Finaliza el año 2013 y con él se cierran casi diez meses de publicaciones semanales en el blog. Han sido unas 45 entradas en las que he escrito sobre muchas cosas diferentes. La temática ha ido adaptándose a mi propia evolución, a mis intereses y por supuesto, también a los temas que percibía como más interesantes por los lectores.

Les dejo aquí un resumen los posts que han tenido más repercusión, empezando por los más leídos:

Los más comentados o con más likes:
Algunas entradas se escribieron durante el primer mes de existencia de este blog por lo que creo que no recibieron la suficiente audiencia. Ahí van:
Este es mi resumen del 2013 en este blog de dirección de proyectos. Sólo me queda desearles que tengan un gran 2014. Espero verles por aquí en este nuevo año.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad