Hacer estimaciones sobre costes y plazos es muy complicado. En general, los humanos somos muy malos estimando cuánto tiempo necesitaremos para realizar una tarea, y más todavía si la estimación tiene implicaciones económicas.

Cuando un posible cliente solicita una cotización para un proyecto, uno se enfrenta a dos grandes riesgos:

  • Una planificación realista / pesimista no será atractiva al cliente. Seguramente dará un plazo mayor que los de la competencia y lógicamente un presupuesto mayor para el proyecto.
  • Una planificación optimista puede resultar más atractiva, pero será una trampa a medio plazo. El cliente percibirá los plazos reales como desviaciones sobre la fecha de lanzamiento original.

La experiencia nos va enseñando que las estimaciones sobre tareas pequeñas son más fiables, y que la mejor manera de ajustarse al tiempo realmente necesario para un proyecto es dividirlo en fases, y cada fase en tareas, y luego estimar cada tarea individualmente.

En muchas ocasiones puede resultar útil conocer los tiempos medios por tarea en proyectos pasados. Calculamos nuestra velocidad real de resolución de tareas a partir de proyectos ya realizados y la usamos para comprobar si una estimación sobre un nuevo proyecto está siendo demasiado optimista.

Y en cualquier caso, todos debemos entender que existe un grado de incertidumbre inherente a cada proyecto, y que es imposible dar una fecha concreta de lanzamiento aunque nos gustaría. Cualquier estimación de plazo para un desarrollo de software a medida debe ser necesariamente aproximada, con una precisión tanto menor cuanto mayor sea el número de tareas a realizar a las que el equipo (incluyendo al cliente) no se haya enfrentado nunca.

Al final, aprendemos que es mejor no meterse en proyectos con plazos poco realistas: nadie sale ganando.

Comentarios (0)

5000 caracteres restantes

Cancel or

Quién soy

Soy Nacho Brito:

Actualmente desarrollo software en Nutritienda.com.

"Could Not Retrieve any Tweets"

Formulario de acceso