¿Cuál es el margen de error aceptable al estimar la duración de un proyecto?

La compañía donde trabajo apunta a tener un margen de error máximo del 10%. Esperan que los analistas no pierdan la estimación en más o menos del 10%.

No sé qué pensar al respecto, ya que no tengo nada con qué compararlo.

¿Cuál podría ser una buena línea de base para medir si estimamos demasiado mal, para más o menos? ¿Cuánto (en%) crees que está bien perder?

A menos que esté estimando algo muy similar a lo que usted y sus compañeros de trabajo han hecho antes, +/- 10% es ridículamente optimista. Su administración no tiene mucha experiencia con el software o no tiene conocimiento de los Grandes límites para la estimación del software . Ese documento tiene algún material de apoyo que lo acompaña , y se pueden encontrar muchos expertos .

Examinemos un sistema mucho más simple que un proyecto de software típico: el Cubo de Rubik. Puedes resolver cualquier posición en 20 movimientos , máx. Pero como estás haciendo una estimación, solo puedes mirar un cubo determinado durante unos minutos antes de dar la solución. ¿Puedes dar una buena estimación? No, a veces estimar un proceso lleva más tiempo que hacerlo.

Otro sistema simple: Pinocho. Un autómata de madera, su pieza nasal crece cuando dice una mentira. ¿Qué sucede cuando Pinocho está en reposo y luego dice "Mi nariz está creciendo"? Algunos sistemas no son susceptibles de predicción, son indecidibles.

Estos dos problemas están integrados en la mayoría de los sistemas de software. Debido a eso, nunca obtendrá estimaciones cercanas a +/- 10%.

Mi consejo es dar una estimación muy acolchada, trabajar como un esclavo para hacer el proyecto lo más rápido posible, y luego parecer ocupado hasta que esté dentro del 10% por debajo o por encima. En ese punto, anuncia un éxito espectacular.

Dudaría mucho sobre cualquier tipo de "margen de error objetivo" porque realmente depende del proyecto. Si está tratando de estimar cuánto tiempo llevará instalar, configurar y personalizar un nuevo sistema CRM en el que nadie esté seguro de qué tipo de personalizaciones serán necesarias y qué tipo de cambios en los procesos comerciales serán necesarios y la empresa no tiene historial de proyectos grandes similares, su margen de error debería ser bastante grande (es decir, puede suponer que tomará 18 meses +/- 50% y cotizará entre 9 y 27 meses). A medida que avanza el proyecto, las especificaciones se aclaran, se toman decisiones sobre los procesos comerciales, los desarrolladores se sienten más cómodos, etc., esos márgenes de error deberían ser más estrictos. Si está tratando de estimar cuánto tiempo va a construir el 101er sitio de comercio electrónico básico cuando ' Si obtuve una buena historia de los primeros 100, esperaría poder dar una estimación mucho más precisa. Sin embargo, la mayoría de los proyectos van a caer en algún punto intermedio.

Ahora, si está citando un número único en lugar de un rango, la respuesta probablemente sea comenzar a citar el rango para que la persona que realiza la estimación pueda especificar qué tan exactos esperan que sea su estimación.

Una buena línea de base sería aquella basada en datos reales que haya recopilado.

El primer paso para hacer esto es registrar todas las estimaciones . El segundo paso es registrar los resultados reales . Sé honesto, no caigas en la tentación de "autoajustarte" lo real. Reúna suficiente información y tendrá algunos datos para basar estadísticamente cuán buenas son sus estimaciones. Tenga en cuenta que esto puede / variará enormemente según quién hizo la estimación y quién realizó el trabajo. Solo haciendo esto se puede esperar razonablemente que dé un "margen de error" que sea cualquier otra basura pura.

No se detiene allí tampoco; analizar qué causa que las estimaciones estén apagadas puede ayudar a mejorar la precisión de sus estimaciones futuras. Nota: Siguen siendo estimaciones y, como tales, son solo estimaciones .

La estimación tampoco termina después de la primera estimación; Esto es algo que se puede ajustar a medida que el proyecto avanza a medida que se adquiere más conocimiento, lo que reduce el posible margen de error a medida que avanza. Cuanto más abierto sea con la comunicación, se discuten las sorpresas anteriores, lo que lleva a las personas a estar menos sorprendidas y les da más tiempo para hacer ajustes en el proyecto o en las expectativas de los clientes.

En segundo lugar, tal vez una mejor manera de manejar el margen de error es ' internos de confianza ' en lugar de simplemente% de márgenes de error. Usted basó su fecha estimada de entrega en un intervalo de confianza, en lugar de una fecha singular.

PERT es un ejemplo de un marco para manejar la estimación basada en el razonamiento estadístico. Por ejemplo:

"Según lo que sé ahora, tenemos un nivel de confianza del 90% que podemos ofrecer en 8 meses. 95% de confianza en 10 meses, 99% de confianza en 2 años, etc."

Nota aquí: cuanto más seguros te quieran, mayor será la estimación. Dependiendo de la complejidad (es decir, cuán preciso podría ser), podría ser una pequeña diferencia entre 80% y 90%, ¡o podría ser enorme!

Por último, buena suerte;) Si alguna vez resuelve el 'margen de error máximo' en la estimación de software mediante el cual puede especificar algo como 'todas nuestras estimaciones serán +/- 10%', asegúrese de encargar una película de taquilla para el resto de nosotros en la industria del software. Estoy pensando en algo así como un cruce entre Office Space y The Matrix: D

De hecho, depende mucho del tamaño y la complejidad del proyecto.

Si la estimación de su proyecto es de 1 semana, el 10% es razonable. Significa +/- 1/2 día.
Si es 1 mes, el 10% es inestable; según mi experiencia, es imposible pronosticar lo que descubrirá en 1 mes.

Más de un mes: todas las apuestas están apagadas :).

Estos son por desarrollador, por lo que para un equipo de 4 desarrolladores 1 semana == 1 mes.

Para un equipo de 4 desarrolladores, es bueno tener una lista de funciones que se pueden hacer en 1 mes, y estar dentro del 10% para esas funciones. Luego, vuelva a estimar para el próximo mes.

He hecho algunas suposiciones ingenuas aquí

1. Todos los desarrolladores pueden trabajar en paralelo.
2. No he considerado el probador, deberían tener algo de tiempo para probar
3. Todos los desarrolladores son iguales: frontend, backend, diseñadores, etc.

Hay que tenerlos en cuenta ... pero esta es la idea general.

Hay muchas variables:

1. ¿Cuánto dura el proyecto?

2. ¿Cómo se gestionará el proyecto? ¿Cascada? ¿Ágil? ¿MELÉ?

Supongo por la pregunta Cascada. Si ese es el caso, se espera que falle en algún porcentaje dada la solicitud de un margen.

Si la respuesta es alguna metodología ágil, especialmente algo como SCRUM. Realmente no importa cuál sea el porcentaje de margen. Un margen de error del 50% en un Sprint de 2 semanas es de 1 semana, en un Sprint de 1 semana es de 2.5 días, ambos escenarios en el peor de los casos. Esto se debe a que la fecha de entrega se vuelve a estimar cada Sprint, y será más y más precisa con el tiempo, en lugar de cada vez menos.

Con Waterfall tampoco se ignora el margen de error del 50%, pero en un proyecto de 12 meses que es de 6 meses, y realmente no se descubre / admite, es tan malo hasta los 10 meses en el 12.

Cuando solía liderar equipos de software, más o menos alrededor del límite Cretáceo / Terciario, en realidad estuvimos cerca de lograr +/- 10% en la estimación. Fue alrededor de +/- 15% si mi memoria muy poco fiable sirve. Pero esto se debía a que estábamos calculando cosas que ya habíamos hecho : firmware de comunicaciones en tiempo real relativamente simple que tomaba bytes de A y los movía a B usando un lenguaje con el que estábamos familiarizados, en un entorno en tiempo real diseñado por nosotros. , hablando con hardware diseñado internamente por chicos a unas pocas oficinas de distancia. Muchas variantes leves sobre el tema anterior, durante literalmente años .

Esperar alcanzar este tipo de tasa de error en la estimación normal de proyectos de software es, francamente, ridículo . Cuando ve que aparentemente se logró, es porque las personas sobreestimaron y acolcharon (haciendo cosas adicionales y proyectos de mascotas para usar el presupuesto), o subestimaron y trabajaron como perros en la noche y los fines de semana para recuperar el tiempo.

Probablemente has escuchado la cosa del 300% ¿verdad?

De hecho lo uso. Totalmente basado en lo que he visto durante años. Cuando escucho un día o dos, es una semana o más para terminar realmente . Y probado. En todos los ambientes. Documentación actualizada. Usabilidad probada. Rendimiento probado. Carga probada. Un par de horas es realmente más como un día.

Creo que somos muy malos para estimar debido a:

• Ayudando a otros
• Ser interrumpido
• Entrenando gente nueva
• Otras cosas por venir
• Enfermarse o sentirse mal
• Cubriendo personas que se van
• Necesitar vacaciones o tiempo libre
• Distraerse con los demás
• Ser retenido por otros grupos
• Ser demasiado optimista sobre realista
• No asignar tiempo para trabajar en fallas de prueba intermitentes
• Excluyendo fácilmente el tiempo para las pruebas, particularmente escribiendo pruebas automatizadas

Entonces, al nivel más alto, con personas de negocios que necesitan estimaciones superiores al 300%, lo que terminamos haciendo es apuntar a estimaciones razonablemente buenas, pero al precio de ser de un nivel más alto y más general. "Tendremos una función de edición de usuario" incluso si la versión 1 significa solo para 1 grupo de usuarios para cambiar 1 campo.

Cuando se trata de "¿Cuál es el margen de error aceptable al estimar la duración de un proyecto?" Me parece que este enfoque, utilizado en muchos entornos ágiles, ayuda a cambiar la pregunta a cuál es la funcionalidad mínima para obtener una versión alfa o beta en vivo y luego repetirla.