ALLSOFT - Blog Allsoft , Estimación

El estimado no es la meta, es solo el punto de partida

Thu, 15 May 2025 10:21:00 -0600

Es un hecho: no conocemos todos los elementos al inicio de un proyecto. Los estimados que incluimos en la propuesta inicial se basan en la información disponible en ese momento y tienen, por tanto, un grado de incertidumbre. Su cumplimiento dependerá de varios factores, entre ellos, cuánto conocemos nuestra propia organización y qué tanto aprovechamos la experiencia previa.

Sin embargo, el estimado no debe ser una referencia estática. A medida que el proyecto avanza y se obtiene mayor claridad sobre los requerimientos, restricciones y capacidades del equipo, es posible —y recomendable— ajustar y refinar esos estimados. En el peor de los casos, al menos deberíamos validar el estimado anterior con los datos actuales.

Existen momentos clave para revisar y actualizar los estimados, como al concluir el levantamiento de requerimientos o al finalizar el diseño. Si el proyecto incluye una etapa de factibilidad, ese también puede ser un buen momento para generar una primera estimación más informada.

Lo importante es planificar desde el inicio qué estimaciones se realizarán a lo largo del proyecto, en qué momentos y con qué metodología. Además, utilizar métricas relacionadas con los estimados es fundamental para generar aprendizaje. Analizar las desviaciones entre lo estimado y lo realmente ejecutado —ya sea contra la propuesta inicial, la estimación de requerimientos o la de diseño— nos ayuda a entender nuestra capacidad de predicción y a mejorar continuamente nuestras prácticas de estimación.

Photo by Brands&People on Unsplash

El tamaño es importante

Thu, 05 Aug 2010 19:11:43 -0500

Lo más sencillo para estimar un proyecto de desarrollo es hacerlo a través del esfuerzo que implicará la tarea, hacer un diseño: 20 horas, y listo. Pero, ¿Qué implican esas 20 horas?, ¿Es un trabajo complejo?, ¿Sencillo?. Esas 20 horas nos dice tanto como que un ingeniero civil que nos diga que va a construir un puente de 50,000 horas de esfuerzo. ¿Qué nos viene a la mente?, no mucho. ¿Qué nos viene a la mente si le damos volumen?, si nos dice que en realidad es un puente de 10,000 metros cuadrados.? Ya tenemos una mejor idea de la magnitud del trabajo y podemos hacer un comparativo contra otros puentes que conocemos. De la misma forma sucede con la estimación de los proyectos de software. Si esas 20 horas las ponemos en 25 hojas, en 10 casos de uso o en 5 puntos de función. Con el tamaño podemos hacer comparaciones de una mejor manera y lo que es más importante con el tamaño podemos capturar y hacer uso de la historia. Si utilizamos puntos de función en nuestros estimados, estos los podemos traducir a un esfuerzo y podemos hacer análisis de la productividad y usarla para estimar. ¿Cuántos puntos de función hacemos por hora?, ¿En un proyecto pequeño cuantas horas por puntos de función implican?, ¿Cuántos defectos generamos o encontramos por punto de función?. Con los puntos de función tenemos una referencia con la que podemos trabajar entre los diferentes equipos y proyectos. Por eso en la estimación de proyectos de desarrollo de software el tamaño si importa.

Métricas

Wed, 07 Oct 2009 00:56:47 -0500

A medida que una organización de desarrollo de software va evolucionando hacia una organización más madura, el conocimiento de lo que este sucediendo en la organización es más importante. Las mediciones del software ayudan al conocimiento de la organización y a mejorar el trabajo que se hace, sin embargo, un programa de métricas mal enfocado puede presionar a la organización y perder terreno en lo que se había logrado antes de implementarlo. Las métricas deben de ser un medio de comunicación entre lo que la gerencia esta buscando y lo que la organización esta produciendo, y no debe ser del interés de solo una persona, grupo o departamento, es algo que debe de ser interés de todos y apoyado por todos. Las mediciones no nos proveen soluciones por si mismas, estas son índices cuantificables que pueden ser utilizados para comparar productos de software, procesos o proyectos, para predecir los resultados, o para comprender el proceso de desarrollo de software. Basados en estas deberemos crear acciones, programas e iniciativas para corregir o mejorar lo que esta sucediendo o prevenir que suceda algo en particular en el futuro. Si desea implementar algún programa de métricas debe tener en cuenta algunas reglas básicas para obtener mejores resultados.

Primero que nada busque el soporte de la gerencia y que esta le de visibilidad a través de su utilización y la aportación de recursos.
Debe de identificar que métricas son de beneficio para la organización y que estén orientadas a soportar los objetivos del negocio, el tener toneladas de métricas sin ningún sentido es solo es un desperdicio de recursos.
Las métricas deben de ser fáciles de generar para no crear procesos adicionales y poder utilizar la información cuando nos es útil, no cuando ya tenemos el problema.
La información contenida debe ser fácil de entender, correcta y precisa. Debemos entender la información y tomar decisiones para retroalimentar al proceso que las genera.
Hágalas publicas, muestre los progresos y retroalimente a la organización.
Informe a la organización como utilizar las métricas para el beneficio de sus actividades.
Nunca utilice las métricas para medir el desempeño de las personas.

Recuerde que nada se puede mejorar si no se mide, de que otra forma podemos saber donde estábamos y donde ha quedado todo ese esfuerzo que hemos dedicado.

¿Por qué no estimamos bien?

Fri, 27 Mar 2009 18:10:42 -0600

Hacia el final de un proyecto de desarrollo de software estamos con los tiempos en contra de nosotros, nos esforzamos por cumplir con el tiempo, funcionalidad y si se puede con la calidad, lo que nos genera un desgaste tremendo. La realidad es que lo resolvemos como dicen a “fuerza bruta”, con puro corazón. Después de varios proyectos ya el ánimo no es el mejor y nos preguntamos: ¿Por qué cada vez tenemos que pasar por lo mismo?, algo que dijimos que ya no sucedería. ¿Qué fue lo que no vimos?

Es claro que cuando estimamos lo hacemos con poca información disponible, nuestro proceso de recopilación de información no es muy efectivo o no le dedicamos el tiempo suficiente, es común también, que no conocemos quién hará el proyecto, desconocemos las capacidades de la organización. No siempre conocemos la tecnología en la que se implementará el proyecto. A lo anterior le podemos añadir un proceso de desarrollo inmaduro,que en las primeras semanas de ejecución vemos al estimado alejarse rápidamente. Por ultimo, nuestro proceso de estimación es deficiente dado que no consideramos muchos factores, como los mencionados anteriormente.

¿Cuándo estimamos?

Wed, 26 Nov 2008 00:06:22 -0600

Esta es una pregunta interesante ya que típicamente asociamos la estimación a un cobro al cliente y no es siempre así. Antes de tener un proyecto se hace una estimación para la propuesta con información no muy clara, bastante general y que es lo que le vendemos al cliente.

Cuando ya tenemos un proyecto, es decir que la propuesta ya fue aprobada, necesitamos revisar la estimación de la propuesta o estimar de nuevo para cerciorarnos que las condiciones iniciales se siguen cumpliendo. Quién conformará el equipo, qué experiencia tiene, se puede lograr el proyecto con este equipo, se tiene la infraestructura que se pensó, etc., si no es así, hay que hacer los ajustes necesarios.

Cuando se trabaja en los requerimientos detallados pueden surgir nuevas cosas, por lo que debemos de estimar de nuevo para determinar el trabajo que se agregó o que se eliminó. Al terminar el diseño necesitamos revisar si los requerimientos se pudieron plasmar como se pidió o si fue necesario hacer ajustes, por lo que podríamos revisar los estimados. Si existe un cambio durante el proceso de desarrollo, añadir requerimientos, modificar requerimientos, cambiar el diseño, la tecnología, etc ., debemos de hacer una estimación del impacto de los cambios y si estos son aceptados debemos de afectar los planes y actividades para incorporarlos. En general podríamos estimar el proyecto al final de cada etapa del mismo en donde cada vez tendríamos más información y debería de ser mejor el estimado. De esta forma estimaríamos en:

• Al inicio del proyecto • Contando con los requerimientos detallados • Con el diseño terminado (opcional) • Ante cambios en el proyecto ¿Qué pasa si los estimados difieren mucho de lo que vendimos?, Aquí podemos hacer dos cosas, negociar el nuevo alcance, sobre todo en cuanto a los costos, o bien absorber nosotros los costos. Esto ultimo si fue a nosotros a los que se nos paso algo y que el no tenerlo la aplicación no funcionaría. Independientemente de cómo negociemos, es necesario revisar nuestros estimados para ver si las condiciones del proyecto siguen siendo las mismas y podemos llegar a la fecha de entrega con la funcionalidad y costo requerido.

¿Cómo vender los estimados?

Wed, 10 May 2006 20:34:00 -0500

Siempre que nos llega una solicitud de un nuevo sistema o requerimiento generamos un estimado del esfuerzo, tiempo y costo que nos va a tomar solucionar dicha necesidad. Este estimado, el cual es nuestra mejor aproximación a la realidad, es parte de nuestra propuesta o control de cambios que presentado al cliente. ¿Cómo manejamos esto?

El problema inicial surge en cómo presentamos el estimado, y no tiene nada que ver con el estimado en sí mismo. Típicamente se presenta el estimado como tal, entendiendo que quedará claro al usuario con la explicación que podamos hacer al presentarlo. Se incluyen como valores estimados las horas, tiempo y costo, lo que generalmente se toma como el deber ser, no importa que tanto conversemos con el usuario al respecto. Para trasmitir mejor el mensaje podemos poner indicar que lo mostrado es un estimado y tiene un porcentaje de desviación o certeza (p.ej. +/- 20%) de lo que se esta indicando.

Sería mejor si se incluye el porcentaje de certeza y los rangos de los estimados en estos porcentajes de certeza. Siempre indicando que de surgir algún cambio en estos estimados serían comunicados al cliente para tomar acciones correctivas o un plan de acción. Parte del trabajo es también vender estos estimados para que quede claro y acordado entre el equipo y el cliente que se esta trabajando sobre un estimado y que este puede bajar o subir dependiendo de cómo se va ejecutando el proyecto y los ajustes que se van presentando y que su presupuesto se base en estos estimados.

Es posible que no nos funcione a la primera pero hay que trabajar con los clientes en función de esto y nunca dar estimados al aire por que esto nos tira por los suelos todo nuestro trabajo ganado.