Estimación de proyectos de software: Un problema, una solución

Hoy en día el factor del tiempo de duración de un proyecto es crucial y estratégico ya que se juega en una línea muy delgada que puede generar pérdidas o ganancias. En este sentido los proyectos relacionados con el manejo de información (Software: obtención, explotación) cobran una gran relevancia. La mayoría de las veces cuando se tiene que decidir la factibilidad de un proyecto de SW en etapas tempranas, la información con la que se cuenta es muy poca o es ambigua, esto sucede debido a que la adquisición de la información para un proyecto de SW es paulatina y en las primeras etapas es escasa y muy susceptible a cambios.

Lo anterior ocasiona que la manera más utilizada, más rápida, menos costosa y la más utilizada a nivel mundial para estimar esfuerzo, duración, costo de un proyecto de este tipo sea la utilización de la experiencia de los empleados de una organización, mejor conocida como “Juicio de Experto”.

Sin embargo, esto no siempre es una buena idea ya que esta manera de realizar estimaciones presenta algunos problemas como que le pertenece al experto y no a la organización, está influenciada por el contexto o circunstancias en las que esté el experto al realizar los juicios, además los expertos hacen inferencias a partir de variables de entrada con valores subjetivos (complejidad, experiencia del equipo, experiencia en la herramienta, etc.) no determinísticos y por si fuera poco, no se puede replicar sistemáticamente, lo que genera dependencia de los expertos.

Hasta aquí es la parte que representa el problema descrito en el título, a continuación voy a presentar un ejemplo de esta situación:
Para clarificar esta situación se describe a continuación un ejemplo de un proyecto específico el cuál se estimó en tiempo y esfuerzo de manera empírica, es decir utilizando juicio de experto, y las herramientas que tenía la organización a su alcance.

La empresa y el nombre del proyecto no se mencionan por confidencialidad, pero los datos son reales.

El proyecto

La definición del proyecto que proporcionó el cliente en primera instancia fue la siguiente: “Desarrollar solución técnica que permita brindar el servicio de tercero confiable para apoyo n las operaciones de comercio exterior”.

Como podemos ver, la información está dada a un nivel de abstracción muy alto y es muy ambigua. El cliente pidió con esto una cotización, lo que implicaba una estimación de duración y esfuerzo del proyecto.

Aunque sé que muchas personas por la finalidad de vender o por la costumbre de realizar así las estimaciones se verían tentados a dar los números solicitados, la realidad es que se pidió más información al cliente, éste proporcionó la siguiente información:

• Contar con una herramienta que permita apoyar la operaciones de Comercio Exterior de carga, sin la necesidad de presentación física de papeles, haciendo más eficientes los procesos en las agencias aduanales en cuestión de resguardo y localización de pedimentos, sus anexos y documentos relacionados.
• Contar con una herramienta que permita el resguardo digital de pedimentos, sus anexos y documentos relacionados por medio de un expediente único.
• Dentro del proceso de resguardo de archivos autentificar los mismos mediante el certificado digital de Firma Electrónica Avanzada.
• Contar con esquemas de búsqueda y consulta de información de acuerdo al rol del área y vigencia de resguardo.
• Contar con esquema de “Facturación” que incluya costeo de almacenamiento, manejo de niveles de cuotas, bonificaciones y emisión de reportes.
• Contar con información histórica (documentos) con una antigüedad hasta por 10 años.

Contexto del proyecto

El grupo que realizó las estimaciones conocía el contexto en el cual se realizaría el proyecto que lo describió de esta manera:

• El equipo que iba a realizar la solución no contaba con un buen conocimiento del negocio ya que usualmente ellos se dedicaban a cuestiones financieras.
• Tampoco se contaba con toda la experiencia de las tecnologías involucradas para el desarrollo de la solución como digitalización y firma electrónica aunque conceptualmente se conocían.
• El líder de proyecto no tenía toda la disponibilidad ya estaba compartido en tres proyectos y el suplente no tenía mucha experiencia ni liderazgo para llevar a cabo un proyecto de manera independiente.

Herramientas utilizadas para la estimación

Las herramientas con las que contaba la organización que realizó este proyecto eran la experiencia o sus expertos (herramientas empíricas, hojas de Excel generadas a partir de la experiencia, ejercicios históricos de FP (IFPUG) y Use Case Points (UCP) y una clasificación en rangos de esfuerzo históricos por tipo de proyecto específica para la organización, similar a la que se muestra en la Figura 1.


Figura 1. Rangos de Esfuerzo por tamaño de Proyecto.

Resultados

El proyecto que se estimó originalmente en 5 meses por un grupo de expertos de la organización, terminó en realidad en 13.25 meses lo que implicó un retraso de 165%. Cabe mencionar que este grupo realizó originalmente la estimación, en un aproximadamente una de esfuerzo.

Se puede observar claramente que el realizar malas estimaciones tiene una repercusión directa en la economía de las empresas ya que este tipo de defasamientos, que son comunes en la industria [1] implica que alguien tiene que absorber el gasto, ya sea el cliente o el proveedor, implicando negociaciones por demás complejas y desgastantes. Ver Figura 2.


Figura 2. Desfasamiento estimado Vs. real.

“De acuerdo al testimonio de la Government Accountability Office el pasado septiembre, si se establecieran con más realismo las líneas base de los requerimientos, costos, calendario y riesgos durante las fases de planeación de proyectos, cerca de la mitad de cancelaciones o programas que rebasan el presupuesto de TI podrían ser evitados. Eso ahorraría anualmente $5.5 billones, de acuerdo a un estudio hecho por Price Systems LLS, una compañía de software y consultoría de Mount Laurel, N.J de EEUU. El estudio considera 140 ejecutivos TI del Gobierno”. [2]

La sección de la solución correspondiente al título se mostrará en otra edición debido a la limitación del espacio.

Referencias:

1. The Standish Group International, Extreme Chaos, The Standish Group International, Inc, 2000 – 2004 Research Reports.
2. Off Base Insufficient expertise in setting baselines hits U.S federal IT budgets where it hurts”, PM NETWORK, March 2007 / VOLUME 21.