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, sin importar cuánto análisis y recolección de requerimientos hagamos, es imposible conocer por completo el alcance de las características de la aplicación desde el inicio (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.
Compartir
  • Invitado

    Excelente artículo, hay algunas observaciones ortográficas; pero en términos generales muy bien :cheer: . Siempre son muy acertados este tipo de artículos. Tengo a los coordinadores de desarrollo de mi empresa luchando contra sus antiguos paradigmas y cada día les revuelvo mas la cabeza con este tipo de apuntes :lol:. Continua así. Si se puede colaborar corrigiendo artículos con gusto lo haré. Yo entro todos los días entonces seria fácil ayudar.<br /><br />-- <br />Carlos Alfonso Pérez Rivera<br />Coordinador de Desarrollo Web<br />Departamento de Sistemas<br />COMFAMILIAR RISARALDA<br />Pereira, Risaralda (Colombia)<br /><br />PD: Visita www.comfamiliar.com

  • Invitado

    el desarrollador debe estimar,<br />el jefe de proyecto calcular el costo<br />y el cliente ver si acepta o no.<br /><br />ese es el orden.

  • Invitado

    Si bien estoy de acuerdo con el planteamiento, creo que es muy díficl vender un proyecto que no esta estimado, o sea es casi imposible, no lo puede decir a un cliente tu proyecto costará X pero podría costar más, generalmente los presupuestos se aprueban con anterioridad. Entonces que nos queda?

  • [quote name="Luis Cruz"] Entonces que nos queda?[/quote]<br /><br />¿Mentir? Digo, parece ser que lo hacemos bastante bien eso. <br /><br />Ahora de en serio, nadie dice no hacer estimaciones a largo plazo, lo importante es que ambas partes deben entender eso: es una *estimación*, no un contrato. Cuando se usa la planificación como si fuera un contrato se cae en una trampa que perjudica a ambas partes. Y eso atenta con lograr una relación sincera y de confianza con el cliente, que debería ser nuestro objetivo. <br /><br />Una buena técnica para estimar a largo plazo consiste en armar un Gráfico de Burn-Up.<br /><br />Por otro lado, es claro que el cliente tiene que acompañar este proceso. Aquí reside la gran dificultad de estas técnicas: todas necesitan un cambio cultural importante por parte de todos los involucrados, no sólo de sistemas.

  • La idea seria convencer al cliente que lo mejor que puede hacer es firmar un contrato de este tipo... http://www.proyectosagiles.org/contrato-agil-scrum<br /><br />Saludos!

  • Cesar

    Loco fue como si me leyeras la mente. Verdaderamente muy bueno.
    Y Yo que pensaba que era el unico loco.... :p

Deja tus comentarios

Post comment as a guest

0

El nuevo Dos Ideas.

Nuevo logo, nuevo buscador, nueva portada, podcast mensual... ¡y muchas novedades más!

Más novedades en Dos Ideas

Los Comentarios.

Juan Pablo
En una estructura CASE: cada opción se debe inferir como un IF/ELSE?
nicolas
El problema es que no en todos los casos te podes dar cuenta al instante de quien tiene razón (como ...
manny
muy interesante todo los que se escribió aquí.
Alejandro Cortes
"Si hubiera que definir la arquitectura en pocas palabras, se diría que es la ponderadora creación d...
alex
hey no me dieron el resultado que esperaba xD
JSP
Hola, soy nuevo en esto de java y no consigo hacer funcionar los ejemplos. ¿Podrías poner el código...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw