Cómo determinar el costo y tiempo de un proyecto


Diagrama de GanttDeterminar el costo y tiempo de un proyecto de software es uno de los temas más importantes en el desarrollo de software. Mi opinión seguramente va a ser polémica, y acá está: es imposible determinar cuál será el costo y el tiempo de un proyecto de desarrollo de software. Más aún, es muy mala idea intentar usar la planificación como si fuera un contrato con nuestro cliente.

¿Por qué es imposible? (el triángulo de hierro)

Triángulo de hierro

El Triángulo de Hierro es una muy buena analogía para explicarlo. Lo que muestra el triángulo es que en los proyectos de software (y, básicamente, en cualquier proyecto), asumiendo que la calidad queda estática (los proyectos siempre deberían apuntar a tener la mayor calidad posible), hay otras tres variables en juego: el Tiempo (qué tan rápido queremos entregar la solución), el Costo (que tan barato queremos que sea el producto) y el Alcance (cuántas características queremos que tenga la aplicación). Lo interesante es que estas tres variables dependen entre si, por lo que resulta imposible dar más prioridad a una sin quitarle a las demás.

Lo que hace que sea imposible determinar el costo y el tiempo de un proyecto es que es imposible conocer por completo el alcance de las características de la aplicación desde el iniio, sin importar cuánto análisis y recolección de requerimientos hagamos (dije que iba a ser polémico). Y sin estos datos, ¿cómo vamos a calcular los otros dos lados del triángulo? Incluso cuando el costo es fijo, o el tiempo es fijo, es imposible calcular el otro vértice del triángulo.

Para analizar más, supongamos que estoy equivocado y que realmente podemos determinar el Alcance de la aplicación desde el inicio. Por lo tanto lo estimamos, y supongo que todos estamos de acuerdo en que la estimación tan sólo expresa una probabilidad; cuando digo “estará terminado en un mes”, quiero decir algo como “hay un 80% de probabilidad de que termine en un mes”. Cuando encadenamos las probabilidades (la estimación de cada una de las características que formaban el Alcance), la probabilidad de acertar cae exponencialmente, lo que significa que incluso aunque conozcamos todas las características, la probabilidad combinada de acertar en todas las estimaciones es ridículamente baja.

La planificación continua

La solución al problema es cambiar la perspectiva y mirar a la planificación no como una actividad enorme que se hace al comienzo del proyecto, sino como una actividad continua que se realiza druante toda la vida del proyecto. Mientras más hayamos desarrollado la aplicación, más podremos refinar nuestro plan.

Conclusión

Existe un círculo vicioso: un proyecto de software no se aprueba hasta que se estime el costo y el tiempo, pero esto no se puede determinar porque recién conoceremos el alcance real de las características al momento de empezar a desarrollarlas. Igualmente, esto no debe impedirnos de empezar un proyecto y crear una estimación inicial, y refinarla a medida que desarrollamos el producto. Pero tengan cuidado: crear una planificación inicial y usarla como un contrato va a afectar seriamente a todas las partes involucradas; es probable que el cliente no pueda hacer cambios durante el desarrollo, y el equipo de desarrollo trabajará bajo presión para cumplir fechas, y al terminar el producto final no será lo que el cliente esperaba y su calidad será pobre.

Traducido de How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfront), por Alberto Gutierrez.

Vía Dos Ideas

Anuncios

Acerca de Luis Castellanos

Luego de unos años en Maracaibo, de regreso en Caracas. Docente Universitario y Bloguero. Orgulloso padre de dos hijos. luiscastellanos @ yahoo.com | @lrcastellanos

Publicado el 16 diciembre 2009 en desarrollo de sistemas. Añade a favoritos el enlace permanente. 2 comentarios.

  1. Estimados foristas; (aprovecho el momento de ocio) en primer lugar un proyecto implica no una determinación sino una estimación, tanto en cuanto a costo como a tiempo; los elementos más volátiles de todo proyecto. El tratamiento de tales elementos deben hacerse con mucho conocimiento de causa pues lo que se espera de un gerente de proyectos es que termine el mismo cumpliendo con los objetivos fijados, dentro del tiempo fijado y dentro del presupuesto fijado. Así el problema estriba en como obtener una estimación que al final, contrastada con la realidad (resultado) presente la menor desviación posible. Si esto no fuese así no tendría sentido hablar de gerencia o administración de proyectos. el administrador de proyectos, además de su experiencia debe tener recursos para ejercer una exitosa administración.
    En primer lugar; los datos estadísticos. Este es uno de los principales activos del banco de conocimientos que las organizaciones modernas exitosas mantienen. Este banco de conocimientos registra las experiencias o lecciones aprendidas de proyectos anteriores, las mediciones de rendimiento de los ejecutantes, analistas, analistas-programadores y programadores (por supuesto que me refiero a un proyecto de s/w, pero el punto es aplicable a cualquier desarrollo, un producto físico, un bien de capital, el desarrollo de un mercado, la tecnificación de una organización, un estudio de opinión o una campaña electoral). La potenciación del rendimiento utilizando herramientas de productividad. Estos elementos (hay más) permiten evaluar con bastante certeza el costo del esfuerzo humano requerido para llevar adelante el proyecto. Como pueden observar es requisito previo a la concepción del proyecto.
    En segundo lugar está la correcta y exhaustiva determinación de los objetivos finales que requiere el beneficiario del proyecto. Aquí reside la principal falla de los diseños de proyecto, al querer pasar rápidamente por esta actividad dejan demasiados asuntos si resolver y que luego significan volver a los tableros de diseño con la consecuente pérdida de esfuerzo, tiempo y dinero. Como puede deducirse, tomarse el tiempo suficiente para conocer con precisión que es lo que el usuario quiere satisfacer redundará en un mejor diseño y por supuesto en la mejor selección de la estrategia de desarrollo, usando el término estrategia en el sentido coloquial con que se le usa, es decir el camino más directo, rápido y seguro para conseguir el fin que se pretende.
    En tercer lugar, una vez definidos los objetivos y logrados un buen diseño, y por supuesto; convenientemente calculado el esfuerzo estimado (costo y tiempo, en este caso); una draconiana dirección del proyecto, no se deben hacer cambios fundamentales, si los hay se fracasó en la fase de análisis de situación y en diseño de la propuesta; si se fracasa aquí no se puede ser analista de sistemas; debe buscarse trabajo en otra parte y haciendo otra cosa. Habrán cambios que seguramente serán necesarios, por la misma dinámica de la actividad humana, pero si se hizo un buen trabajo de diseño estos no serán fundamentales y podrán hacerse a expensas del esfuerzo ya contabilizado. Les resultará, entonces, obvio que la actividad clave en esta etapa es el control, el poder monitorear avances, obtención, aplicación y liberación de recursos, las métricas necesarias y suficientes para controlar la calidad y la explotación controlada de las habilidades y productividad de analistas y programadores.
    Espero que mi breve coentario les sea útil.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: