fbpx La Ilusión de Predecir el Futuro | SG Buzz

La Ilusión de Predecir el Futuro

Publicado en

Parece ser que en todas partes a donde voy los problemas en el desarrollo de software se concentran en la estimación de proyectos, ya sea porque nos dio una cantidad de esfuerzo demasiado grande y no somos competitivos o porque la estimación fue muy baja y no podemos salir. Parecería que la culpa del éxito o fracaso de un proyecto depende tan solo de la estimación. Cuando escucho esto me parece que le estamos dando demasiada importancia a la estimación y nos olvidamos de que el éxito del proyecto es cincuenta por ciento estimación y cincuenta por ciento ejecuciones.

Hace poco me encontré la siguiente frase: “El ser humano es excelente para proyectar pero pésimo para predecir”, y estoy totalmente de acuerdo. Somos sumamente malos adivinando lo que va a suceder en el futuro, para lo que somos muy buenos es para ver lo que ha sucedido en el pasado y proyectarlo a lo que va a pasar. Nuestro razonamiento estadístico y la comprensión de los procesos normales nos sugieren que si seguimos el mismo proceso y los mismos supuestos para lograr un objetivo podemos inferir el resultado que vamos a obtener. Por ejemplo, si pregunto: “¿cuánto tiempo te toma llegar de tu casa al trabajo?” seguramente me puedes dar un excelente estimado, sobre todo si has viajado de tu casa a tu trabajo innumerable número de veces y tomando en cuenta que sigues el mismo camino, a la misma hora. Pero si te pregunto cuánto tiempo te tomaría gatear de tu casa a la villa, la estimación es mucho más difícil de hacer.

Para que nuestro ejercicio de proyección funcione, lo más importante es modificar lo menos posible los supuestos con los que hemos trabajado anteriormente y requerimos tener la mayor cantidad de información sobre el resultado de nuestra predicción y nuestra ejecución. Por ejemplo, si en el pasado hemos hecho solamente proyectos de 10,000 líneas de código, y se han hecho exclusivamente con personal experimentado, y con esta misma información quiero estimar un proyecto de 50,000 líneas con personal nuevo, mi estimación será poco confiable. El riesgo aumenta cuando introducimos variables para las cuales no tenemos historia.

Vale la pena mencionar que al cambiar la forma en que estimas tamaño, dado que es la entrada de la estimación, automáticamente se hace obsoleta toda la historia. Así que la decisión más importante al desarrollar un modelo de estimación es precisamente la forma en se establece el tamaño.

Tomando estos puntos en cuenta podremos mejorar nuestras estimaciones. Pero pasemos ahora al otro 50%, a la ejecución que consta del seguimiento a proyectos y el control de los cambios.

El problema de seguimiento inicia al dejar claramente documentado los supuestos con los que hice la estimación. Si estimé que cada programa me tomaría tres días y me está tomando cuatro, desde ese momento entiendo que algo está mal y debo de corregir, ¿Cómo? detectando las causas raíz por las que me está tomando más de lo estimado y haciendo las correcciones necesarias. El seguimiento normalmente falla debido a que se hace de una manera tan general que no podemos detectar las diferencias con respecto a los supuestos utilizados en la estimación.

Lo siguiente que no debemos descuidar es el alcance del proyecto. Muchas veces he visto iniciar proyectos con una cantidad mínima de requerimientos al iniciar, los cuales se convierten cada vez en requerimientos más complejos que los supuestos iniciales o requerimientos cambiantes a través del tiempo, los cuales nos obligan a ejecutar varias veces lo mismo. Aquí aplica la frase, “El camino al infierno consta de un paso a la vez”, cada pequeño cambio se acumula y si no tengo claro los cambios que están en el proyecto y en qué punto debo de levantar la mano para renegociar, el proyecto está perdido. En mi experiencia en proyectos de desarrollo aquí es donde la mayoría de los proyectos realmente se barren, en otras palabras si tu organización tiene problemas de estimación, échale un vistazo a tu control de cambio porque lo más probable es que ahí esté el problema.

Cada vez veo más la idea de manejar el análisis por hora aplicada y estimar a partir de que el análisis está terminado porque esto definitivamente es una solución sobre todo cuando no están claros los requerimientos.

En resumen si nuestro costo está por encima del mercado no necesariamente es un problema de estimación sino un problema de eficiencia y a lo mejor para resolverlo tengo que enfocarme en el entrenamiento o el tipo de proyectos que estoy atendiendo. La estimación requiere de técnicas de predicción y no de adivinanza, lo que requiere registrar el histórico para ajustar el modelo frecuentemente. Y por último: es tan importante predecir cómo se comportará el proyecto, como asegurar que se comporte como se predijo.

Bio

Luis R. Cuellar es director de calidad a nivel mundial de Softtek. Es reconocido por la ASQ como Certified Quality Manager, Certified Software Engineer y Six Sigma Black Belt. @lcuellar