project-management - proyectos - project manager office

¿Infla sus fechas estimadas de finalización del proyecto? (30)

¿En qué se basan sus estimaciones?

Si no se basan en nada más que en una vaga intuición de la cantidad de código que requeriría y cuánto tiempo llevaría escribir ese código, entonces es mejor que los rellenes MUCHO para dar cuenta de subtareas que no pensaste, comunicación y sincronización sobrecarga y problemas inesperados. Por supuesto, ese tipo de estimación es casi inútil de todos modos.

OTOH, si sus estimaciones se basan en el conocimiento concreto de cuánto tiempo tardó la última vez en realizar una tarea de ese alcance con la tecnología y el número de desarrolladores, la inflación no debería ser necesaria, ya que los factores inflacionarios anteriores ya deberían estar incluidos en las experiencias pasadas. Por supuesto, probablemente haya nuevos factores cuya influencia en el proyecto actual no se puede prever; tales riesgos justifican una cierta cantidad de relleno adicional.

Si es así, ¿por qué? ¿Cuánto cuesta?

Tiendo a inflar un poco la mía porque puedo ser demasiado optimista.

Como mucho dijo, es un delicado equilibrio entre experiencia y riesgo.

Comience siempre por desglosar el proyecto en piezas manejables; de hecho, en piezas, puede imaginarse fácilmente comenzando y terminando en el mismo día.
Cuando no sabes cómo hacer algo (como cuando es la primera vez) el riesgo aumenta
Cuando aumenta su riesgo, es donde comienza con su mejor estimación, luego duplíquelo para cubrir parte de lo inesperado, pero recuerde, lo está haciendo en una pequeña parte del proyecto, no en todo el proyecto en sí mismo.
El riesgo también aumenta cuando hay un factor que no controlas, como la calidad de una entrada o la biblioteca que parece que puede hacer todo lo que quieras, pero que nunca has probado
Por supuesto, cuando adquiere experiencia en una tarea específica (como conectar sus modelos a la base de datos), el riesgo baja
Suma todo para obtener tu subtotal ...
Luego, en todo el proyecto, siempre agregue aproximadamente otro 20-30% (ese número cambiará dependiendo de su compañía) para todas las respuestas / documentos / aciertos que estará esperando, reuniones que siempre olvidamos, los cambios de idea durante el proyecto y así sucesivamente ... eso es lo que llamamos el factor humano / político
Y nuevamente agregue otro 30-40% que represente las pruebas y correcciones que salen de las pruebas que generalmente realiza usted mismo ... como cuando primero se lo muestra a su jefe o al cliente

Por supuesto, si mira todo esto, termina que puede simplificarlo con las fórmulas mágicas de "doble", pero la diferencia es que podrá saber lo que puede exprimir en un plazo ajustado, lo que pueda comprometerse con, cuáles son las tareas peligrosas, cómo construir su agenda con los hitos importantes, etc.

Estoy bastante seguro de que si observa el tiempo dedicado a cada tarea pura de "codificación" y lo compara con sus estimaciones en relación con su riesgo, no estará tan lejos. La cuestión es que no es fácil pensar en todas las piezas pequeñas por venir y ser realista (en lugar de optimista) en lo que se puede hacer sin ningún obstáculo.

Cualquier organización que le pida a sus programadores que calculen el tiempo para las características de grano grueso está fundamentalmente rota.

Pasos para unbreak:

Contratar gerentes de programas técnicos. Los desarrolladores pueden duplicar estas personas si es necesario.
Ponga cualquier solicitud de función, solicitud de cambio o error en una base de datos inmediatamente cuando aparezca. (Mi organización utiliza Trac, que no es completamente desagradable).
Haga que sus PM rompan esas solicitudes en pasos que cada uno toma una semana o menos.
En una reunión semanal, sus PM deciden qué tickets quieren que se realicen esa semana (posiblemente con comentarios de marketing, etc.). Asignan esos boletos a los desarrolladores.
Los desarrolladores terminan tantas de sus entradas asignadas como sea posible. Y / o discuten con los PM sobre las tareas que creen que duran más de una semana. Los boletos se ajustan, dividen, reasignan, etc., según sea necesario.
El código se escribe y revisa cada semana. QA siempre tiene algo que hacer. Los cambios de mayor prioridad se hacen primero. El marketing sabe exactamente lo que está por venir, y cuándo. Y ultimamente:
Su empresa cae en el lado derecho de la tasa de éxito del 20% para proyectos de software.

No es una ciencia exacta. La clave es el paso 3. Si el marketing quiere algo que parece complicado, sus PM (con la información del desarrollador) averiguan cuál es el primer paso que llevará menos de una semana. Si los PM no son técnicos, todo está perdido.

Desventajas de este enfoque:

Cuando el marketing pregunta, "¿cuánto tiempo llevará obtener [X]?", No obtienen una estimación. Pero todos sabemos, y ellos también lo saben, que las estimaciones que obtuvieron antes eran pura ficción. Al menos ahora pueden ver pruebas, todas las semanas, de que [X] está siendo trabajado.
Nosotros, como desarrolladores, tenemos menos opciones para lo que trabajamos cada semana. Esto es indudablemente cierto. Dos puntos, sin embargo: primero, los buenos equipos involucran a los desarrolladores en las decisiones sobre qué boletos se asignarán. En segundo lugar, OMI, esto realmente mejora mi vida.

Nada es tan desalentador como darme cuenta en el plazo de 1 mes que la estimación de 2 meses que di es irremediablemente inadecuada, pero no se puede cambiar, porque ya está en la literatura oficial de marketing. O molesto a los superiores modificando mi presupuesto, arriesgándome a una mala crítica y / o perdiendo mi bonificación, o hago muchas horas extraordinarias sin pagar. Me di cuenta de que muchas horas extraordinarias no son la marca de un mal desarrollador, o la marca de una "apasionada": es el producto de una cultura tóxica.

Y sí, muchas de estas cosas están cubiertas por (diversamente) XP, "ágil", SCRUM, etc., pero en realidad no es tan complicado. No necesita un libro o un consultor para hacerlo. Solo necesitas la voluntad corporativa.

Digo cuando puedo hacerlo. Me aseguro de que las solicitudes de cambio sean seguidas con una nueva estimación y no el "Sí, puedo hacer eso". sin mencionar que tomará más tiempo. La persona que solicita el cambio no asumirá que tomará más tiempo.

Es una mejor idea agregar tiempo de búfer específico para cosas como la depuración y las pruebas que simplemente inflar el tiempo total. Además, al tomarse el tiempo para planear realmente las piezas del trabajo, hará que la estimación en sí sea mucho más fácil (y probablemente también la codificación).

En todo caso, asegúrese de registrar todas sus estimaciones y compararlas con el tiempo de finalización real, para tener una idea de cuánto tiende a subestimar y bajo qué condiciones. De esta forma puede "inflar" con mayor precisión.

Esta es parte de la razón por la cual los equipos ágiles estiman las tareas en los puntos de la historia (una unidad de medida arbitraria y relativa), luego a medida que el proyecto avanza rastrea la velocidad del equipo (puntos de historia completados por día). Con estos datos, puede calcular teóricamente la fecha de finalización con precisión.

Infra promete, entrega excesiva

La regla de Scotty:

haz tu mejor conjetura
redondear hasta el número entero más cercano
~~el doble que~~ cuadruplica eso (gracias Adam!)
aumentar a la siguiente unidad de medida más alta

Ejemplo:

crees que tomará 3.5 horas
alrededor de eso a 4 horas
cuadruplicar eso a 16 horas
cambiarlo a 16 días

Ta-daa! Eres un hacedor de milagros cuando lo haces en menos de 8 días.

Muchas personas aquí dicen que hagan una estimación y la duplican (y a veces la duplican nuevamente). Otros dicen que usan la programación basada en evidencia (al la Joel).

Cuando estoy estimando un proyecto, hay cuatro componentes para cada tarea:

Mi mejor estimación sobre cuánto tiempo tomará.
La incertidumbre (riesgo) - como quizás haya algo (un desconocido conocido / desconocido) no en la especificación que duplicará el tiempo.
Corrección de errores
Tiempo de contingencia

Para el n. ° 1, utilizo la estimación más realista que puedo.
Para # 2, decido el riesgo probable y luego multiplico # 1 por eso obtengo un estimado ajustado,
Para # 3 y # 4 multiplico la estimación ajustada en un 20% y ese se convierte en el valor de cada uno.

Entonces, para cualquier tarea, el total final es 140% o más de la estimación original.

Para todo el proyecto, las contingencias y las correcciones de errores se recogen en dos tareas separadas y se consumen a medida que avanza el proyecto.

Por supuesto, eso no incluye las pruebas que generalmente hago iguales al valor total para cada tarea.

Mucho depende de qué tan detallado desee obtener, pero el tiempo adicional de ''buffer'' debe basarse en una evaluación de riesgos, en un nivel de tarea, donde coloca varios tiempos de buffer para: Alto riesgo: 50% a 100% Riesgo medio: 25% a 50% Bajo riesgo: 10% a 25% (todo depende de la experiencia previa del proyecto).

Las áreas de riesgo incluyen:

Est. de cobertura de requisitos (área de riesgo n. ° 1 le faltan componentes en el diseño y niveles de requisitos)
conocimiento de la tecnología utilizada
conocimiento / confianza en sus recursos
factores externos como otros proyectos que afectan el suyo, cambios de recursos, etc.

Por lo tanto, para una tarea (o grupo de tareas) que cubre el componente A, la estimación inicial es de 5 días y se considera de alto riesgo en función de la cobertura de los requisitos; puede agregar entre 50% y 100%

No diría que los inflaré, pero sí me gustaría usar una plantilla para todas las tareas posibles que podrían estar involucradas en el proyecto.

Usted encuentra que no todas las tareas en su lista son aplicables a todos los proyectos, pero tener una lista significa que no dejo que ninguna tarea se salte las grietas, olvidándome de darles algo de tiempo.

A medida que encuentre nuevas tareas necesarias, agréguelas a su lista.

De esta forma tendrás una estimación realista.

Tiendo a ser optimista en lo que se puede lograr y, por lo tanto, tiendo a estimar en el lado bajo. Pero lo sé sobre mí mismo, así que tiendo a agregar un 15-20% extra.

También hago un seguimiento de mis datos reales en comparación con mis estimaciones. Y asegúrese de que el tiempo involucrado no incluya otras interrupciones, consulte la respuesta aceptada para mi pregunta sobre cómo volver al flujo .

HTH

aclamaciones

No diría que los inflaré, tanto como trato de establecer expectativas más realistas basadas en la experiencia pasada.

No llamaría "inflado" el tiempo estimado adicional en un proyecto a menos que realmente complete sus proyectos mucho antes de su estimación original. Si adquiere el hábito de completar siempre el proyecto mucho antes de su hora estimada original, los líderes del proyecto lo entenderán y lo esperarán antes.

No olvide que usted (un ingeniero) realmente calcula en horas ideales (scrum).

Mientras que la gerencia trabaja en horas reales.

La diferencia es que las horas ideales son el tiempo sin interrupción (con un calentamiento de 30 minutos después de cada interrupción). Las horas ideales no incluyen el tiempo en las reuniones, la hora del almuerzo o el chat normal, etc.

Tome todo esto en consideración y las horas ideales tenderán hacia horas reales.

Ejemplo: Tiempo estimado 40 horas (ideal) La administración asumirá que es 1 semana en tiempo real.

Si convierte esas 40 horas en tiempo real:

Suponga una reunión por día (duración 1 hora)
un descanso para el almuerzo por día (1 hora)
más un 20% de gastos generales para chit chat, baños, pausas, etc.

El día de 8 horas es ahora de 5 horas de trabajo (8 - reunión - almuerzo - calentamiento).
Tiempos 80% de efeciencia = 4 horas de tiempo ideal por día.

Este su ideal de 40 horas tomará 80 horas en tiempo real para terminar.

No se llama "inflar", se llama "hacerlos remotamente realistas".

Oh, sí, aprendí a multiplicar siempre mi estimación inicial por dos. Es por eso que la herramienta de programación basada en evidencia de FogBUGZ es muy útil.

Oh, sí, la regla general de la experiencia dura larga es darle al proyecto tu mejor estimación para el tiempo, duplicarla, ¡y eso es aproximadamente cuánto tiempo tomará en realidad !

Podré responder esto en 3-6 semanas.

Puede calcular la duración del proyecto de dos maneras: una es calcular todas las tareas involucradas y calcular cuánto tiempo tomará cada una, tener en cuenta los retrasos, las reuniones, los problemas, etc. Esta cifra siempre parece lamentablemente corta, razón por la cual la gente siempre dice cosas como ''doble''. Después de un poco de experiencia en la entrega de proyectos podrá contar rápidamente, con solo mirar brevemente una especificación de cuánto tiempo llevará, e, invariablemente, será el doble de la cifra alcanzada con el primer método ...

Seis semanas.

Estándar de la industria: cada solicitud tomará seis semanas. Algunos serán más largos, otros serán más cortos, todo promedia al final.

Además, si espera lo suficiente, ya no será un problema. No puedo decirte cuántas veces he pasado por ese tiroteo solo para cortar el proyecto / función.

Si inflan su estimación basada en experiencias pasadas para tratar de compensar su optimismo inherente, entonces no se está inflando. Está tratando de proporcionar una estimación precisa. Sin embargo, si se infla para que siempre tenga tiempo de pelusa, eso no es tan bueno.

Siempre duplico mis estimaciones por las siguientes razones:

1) Tampón para la Ley de Murphy. Algo siempre irá mal en algún lugar que no puedas explicar.

2) Subestimación. Los programadores siempre piensan que las cosas son fáciles de hacer. "Oh sí, tomará solo unos días".

3) Espacio de negociación. La Alta Dirección siempre piensa que los horarios pueden acortarse. "¡Simplemente haz que los desarrolladores trabajen más!" Esto le permite darles lo que quieren. Por supuesto, el uso excesivo de esto (más de una vez) los entrenará para asumir que siempre está sobreestimando.

Nota: siempre es mejor colocar el buffer al final del cronograma del proyecto, y no para cada tarea. Y nunca le diga a los desarrolladores que el buffer existe, de lo contrario la Ley de Parkinson (Work se expande para llenar el tiempo disponible para su finalización) tendrá efecto. A veces le digo a la Alta Dirección que el buffer existe, pero obviamente no les doy la razón # 3 como justificación. Esto, por supuesto, depende de cuánto confía tu jefe para que seas sincero.

Típicamente sí, pero tengo dos estrategias:

Siempre proporcione estimaciones como un rango (es decir, 1d-2d) en lugar de un solo número. La diferencia entre los números le dice al gerente de proyecto algo acerca de su confianza, y les permite planificar mejor.
Use algo como FogBugz ''Evidence Based-Scheduling'' , o una hoja de cálculo personal, para comparar sus estimaciones históricas con el tiempo que realmente tomó. Eso te dará una mejor idea que siempre doblando. ¡No menos importante porque duplicar puede no ser suficiente!

Tenemos que hacerlo, porque nuestro administrador idiota siempre los reduce sin ninguna justificación. Por supuesto, tan pronto como se dé cuenta de que hacemos esto, estamos atrapados en una carrera armamentista ...

Espero ser la primera persona en presentar una estimación de dos años para cambiar la redacción de un diálogo.

Suspiro

Tome cualquier estimación que considere apropiada. Entonces doblarlo.

Tomo mi peor escenario posible, lo doblo y aún no es suficiente.

Una buena regla práctica es estimar cuánto tiempo tomará y agregar 1/2 más tiempo para cubrir los siguientes problemas:

Los requisitos cambiarán
Serás arrastrado a otro proyecto para una solución rápida
El chico nuevo en el siguiente escritorio necesitará ayuda con algo
El tiempo necesario para refactorizar partes del proyecto porque encontraste una mejor manera de hacer las cosas

<sneaky>
En lugar de inflar la estimación de su proyecto, infle cada tarea individualmente. Para sus superiores es más difícil cuestionar sus estimaciones de esta manera, porque quién discutirá con usted durante minutos.
</ sneaky>

Pero en serio, al usar EBS descubrí que las personas suelen ser mucho mejores en la estimación de tareas pequeñas que las grandes. Si estima su proyecto a los 4 meses, podría ser 7 meses antes de que esté listo; o puede que no. Si su estimación de una tarea es de 35 minutos, por otro lado, generalmente es lo correcto.

El sistema EBS de FogBugz le muestra un gráfico de su historial de estimaciones, y según mi experiencia (al observar también los gráficos de otras personas), las personas son mucho mejores en la estimación de tareas cortas. Por lo tanto, mi sugerencia es dejar de hacer la multiplicación de vudú de sus proyectos como totales, y comenzar a dividirlos en muchas tareas muy pequeñas que es mucho mejor para estimar.

Luego multiplica todo por 3.14.

Kirk : Sr. Scott, ¿siempre ha multiplicado sus estimaciones de reparación por un factor de cuatro?

Scotty : Ciertamente, señor. ¿De qué otra manera puedo mantener mi reputación como un hacedor de milagros?

Ley de Hofstadter : cualquier proyecto de computación tardará el doble de lo que usted cree, incluso si tiene en cuenta la Ley de Hofstadter.