IEDGE – Proyectos de TI: Estimación
1.- Estimación previa
Tal y como vimos en el post anterior, lo primero que debemos hacer es saber qué tenemos que hacer. Una vez conocemos más o menos el alcance, debemos realizar una estimación. Un problema habitual al que se enfrentan proveedores o departamentos de TI es que se les pide que hagan esta estimación antes de la toma de requisitos y su correspondiente análisis funcional. Se llega a exclamar frases como: “si no sé qué tengo que hacer, como te voy a decir el tiempo y coste del proyecto”.
En la práctica es necesario dar una estimación con un conocimiento muy escaso del alcance. No podemos evitarlo. Pero todos, usuarios y técnicos, clientes y proveedores, debemos saber que esta es una estimación muy poco precisa, que tiene mucho riesgo y que por lo tanto no puede ser tomada como una verdad absoluta.
Los usuarios y clientes se sienten tentados en utilizar estas estimaciones iniciales, normalmente realizadas por analogía con proyectos similares, para presionar en las negociaciones y así obtener mejores condiciones. Estas estimaciones top-down o de arriba abajo, deben revisarse en cuanto se disponga de información detallada con la que podamos contrastar y no simplemente ser utilizadas con verdades hasta que ya tenemos desviaciones significativas en plazo y coste.
2.- Análisis de esfuerzos
La planificación de los proyectos conlleva el desglose del trabajo en tareas más o menos pequeñas y manejables. Este proceso de Estructura de Descomposición del Trabajo (EDT), o Work Breakdown Structure (WBS), es la base para realizar un análisis de esfuerzo o estimación bottom-up o de abajo arriba, que va acumulando las valoraciones de cada parte y ofrecerá una valoración mucho más precisa del proyecto.
Aunque hay muchos métodos de valoración de las piezas de software, las valoraciones siguen siendo subjetivas, aunque más detalladas. Para intentar evitar esta subjetividad, desde hace varias décadas se han ido generando métodos formales para realizar estimaciones de esfuerzo.
Algunas de estas técnicas son:
- Puntos función
- COCOMO
- Mark-II
- Slim
- ObjectMetrix
De una forma u otra estos sistemas formales de estimación tienen en cuenta:
- Se parte de una Unidad de Medida: subsistema, casos de uso, clases, componentes, interfaces, páginas Web, ficheros, etc.
- Se realiza una valoración de la Complejidad/Tamaño/Reutilización de cada elemento: Alta, media, baja
- Se pondera la Productividad (tecnología – personas): Java, .NET, PHP, etc.
- Se establecer una Distribución de Esfuerzo de cada Fase: Análisis y maquetación 20%, Diseño 20%, Construcción 40%, Pruebas 12%, Instalación 5%, Gestión y planificación 3%
- Por último, se tienen en cuenta actividades de gestión, como reuniones del grupo de trabajo y de seguimiento, documentación, etc.
Una vez conocido el esfuerzo debemos establecer la planificación, que organiza el esfuerzo, los recursos y las actividades de forma temporal. Los proyectos tienen un tamaño “natural”. Intentar comprimir la planificación de forma excesiva produce una presión que aumenta el riesgo, complica la gestión y pone en peligro la propia planificación. Además, un proyecto, cuanto más grande es, más energía requiere para labores de coordinación y comunicación. La estructura y organización del proyecto también afecta a la planificación.
3.- Partir de la capacidad y no del alcance
En los proyectos es habitual tener una acumulación de buffers de seguridad (Cadena Crítica de Goldratt) que se incorporan en la planificación para gestionar imprevistos. Esto, unido a que el trabajo se expande hasta ocupar todo el tiempo disponible (Ley de Parkinson), hace que las planificaciones rara vez son excesivas y los proyectos casi nunca acaban antes de lo planificado.
Por ello se han planteado métodos alternativos basados en definir un plazo concreto de tiempo y un conjunto limitado de recursos. Una vez que conocemos las constricciones o limitaciones de plazo y coste, entonces decidimos que funcionalidades son abordadas, es decir, que “cabe” dentro de estas limitaciones.
Este “modelo de caja” es bastante práctico en entornos con definiciones muy cambiantes y poco definidas, donde es más fácil conocer que limitaciones de plazo y esfuerzo tengo, para desde ahí analizar que alcance podemos abordar con estas limitaciones.
En el siguiente post revisaremos los riesgos en proyectos de TI y cómo podemos realizar una gestión activa de los mismos.
¡Quedo a la espera de sus comentarios!
Profesor de Dirección de Sistemas y Tecnologías de la Información
Nota: aprender de una forma práctica y rápida como poner en marcha, desarrollar y controlar planes totalmente eficaces de Sistemas y Tecnologías de la información para pymes, les invitamos a que consulten la Especialidad Europea en Gestión de Sistemas y Tecnologías de la Información
* Los contenidos publicados en este post son responsabilidad exclusiva del Autor.
¡Pronto grandes sorpresas en Facebook y Twitter!:
- Síguenos en Twitter: @iedge
- Hazte fan en Facebook: http://www.facebook.com/IEDGEBusinessSchool
Fernando Pulido Soto
comento el día 28 de septiembre a las 8:04 pm (#)
Hola Pablo,
Muy interesante blog, en este caso que haces cuando tu estimación es muy por debajo de tu real?
Saludos
Fernando