subestimar subestimado sobreestimar sinonimo que definicion contabilidad project-management project-planning time-estimation

project management - subestimado - ¿Qué es mejor: establecer fechas límite subestimadas o sobreestimadas?



subestimado sinonimo (12)

¿Está el desarrollador regresando a una cueva para desarrollar esto o hay una buena posibilidad de cambiar los requisitos a lo largo del proyecto? Creo que la mayoría de los proyectos tendrán una buena probabilidad de que algo no salga bien y, por lo tanto, sería mejor tratar de obtener el prototipo más pronto que tarde.

En cuanto a la pregunta inicial, creo que dividiría esto en algunos resultados diferentes y consideraría cada uno:

Subestimación bruta -> Esto lleva al problema de que todavía hay mucho trabajo por hacer y el gerente parece incapaz de hacer estimaciones razonables.

Subestimación menor -> En este caso, hay una extensión, el alcance se corta o algunos errores están en la versión, pero esto es mejor que el caso anterior.

Cumplió la fecha límite, a tiempo y dentro del presupuesto con calidad -> Si bien esto puede parecer óptimo ya que todo funcionó, no creo que este sea el mejor resultado posible.

Sobreestimación menor -> En este caso, hay un respiro que significa que las cosas se terminan temprano o se agrega algún trabajo adicional. Un punto aquí es que esto parece ofrecer un resultado ligeramente mejor que el caso anterior, como por ejemplo, cómo algunas compañías intentarán superar la estimación de ganancias con una pequeña cantidad para hacerlo mejor de lo esperado.

Sobreestimación bruta -> Creo que este sería el peor resultado del caso, aunque es similar al primero en términos de alguien que está fuera de su alcance para poder proporcionar una estimación razonable.

Esa es solo mi opinión sobre cada uno y otros pueden tener una opinión diferente a la de mí.

Supongamos que eres un gestor de proyectos. Puede estimar un esfuerzo en días para una tarea específica para un desarrollador específico. Después de realizar la estimación obtienes unos valores mínimos y máximos.

Después de esto delegas una tarea al desarrollador. En realidad también se establece fecha límite.
¿Qué estimación es mejor usar cuando se establece el plazo: mínimo o máximo?

Como veo, la estimación mínima puede resultar en estrés para el desarrollador, la estimación máxima puede resultar en el uso de todo el tiempo que se asigna al desarrollador, incluso si la tarea se puede completar más rápido (también llamado síndrome del estudiante ). ¿Qué otros pros y contras de dos enfoques?

EDITAR:

Pequeña aclaración: hablo sobre el establecimiento de plazos para los subordinados al delegar la tarea, NO para informar a mi jefe.

EDITAR:

Para agregar una aclaración más: puedo tener en cuenta mi estimación real , proporcionar al jefe una estimación un poco más grande, a los subordinados, un poco más pequeño. Y esta pregunta toca lo siguiente: ¿es buena idea proporcionar a la subestimación del desarrollador para hacerlo trabajar más duro?

¿Para qué estás usando las estimaciones? Específicamente, ¿por qué se sentirá estresado el desarrollador si normalmente subestima?

Si está intentando programar cuánto tiempo es probable que demore algo, elija un valor intermedio. Probablemente en el lado largo, ya que las personas normalmente subestiman. En cualquier caso, no debería utilizar estas estimaciones como objetivos firmes para los desarrolladores, por lo que no deberían ser demasiado estresantes.

Si está utilizando estas estimaciones para establecer compromisos, debe errar por el lado de la sobreestimación. Dándoles a los desarrolladores el tiempo insuficiente conduce a un agotamiento, un código de buggy que no hace lo que el usuario quiere, y baja moral y alta rotación. Establezca los compromisos para que sean alcanzables y anime a los desarrolladores a terminar temprano.

Algo que ha faltado en muchas de estas respuestas (tal vez porque es un poco fuera de tema) son las actualizaciones frecuentes. Con los desarrolladores más jóvenes / nuevos, esto es aún más importante: lea el código que confirman y / o consulte diariamente para solicitarles informes específicos y detallados.

Esto también le permite establecer plazos ajustados para los desarrolladores sin causarles demasiado estrés, porque sabrán que usted está cerca para ayudar a ajustar los plazos cuando sea necesario.

Las actualizaciones frecuentes le brindan la herramienta más importante para establecer las expectativas de los clientes y la administración: advertencias tempranas de problemas que podrían retrasar las cosas, y prefiero tener eso sobre cualquier fórmula.

Debe utilizar la mejor estimación, que es una función de las estimaciones mínimas y máximas *, no solo el promedio simple,

best_guess = (min * min_weighting + max * max_weighting) / divisor *

* Tom Neyland sugiere que debería ser (min_weighting + max_weighting) . En realidad no estoy seguro de si eso es correcto, pero probablemente sea más correcto que mi divisor original de 2.0 .

La ponderación que le dé a los valores mínimo y máximo dependerá de la complejidad de la tarea, los riesgos asociados con la tarea, la probabilidad de que ocurran los riesgos, la habilidad del desarrollador, etc. y variará de una organización a otra y de proyecto a proyecto. Si mantiene un registro de sus estimaciones anteriores y el tiempo real de cada toma, podrá refinar estas estimaciones con el tiempo.

También debe usar estos valores, más un valor de confianza, cuando hable con la alta gerencia y los clientes. Aunque dar el máximo y entregar con anticipación no es lo mismo que entregar el mínimo y entregar con retraso, todavía muestra que no tienes control sobre tu desarrollo.

Darle un valor de confianza y una idea de los riesgos también ayudará a manejar las expectativas, por lo que si hay problemas no son inesperados.

* Estas estimaciones mínimas y máximas se obtendrán por diversos medios: se preguntará a los desarrolladores, la experiencia pasada, etc. Si los desarrolladores de sondeo, los valores máximos y mínimos reales deben tratarse como valores atípicos y descartarse o modificarse de alguna manera. Lo que quiero decir aquí son los valores que obtienes de frases como "tomará 2 semanas si todo va bien o un mes si tenemos algunos inconvenientes". Así que los valores que se insertan en la fórmula no son los números en bruto.

El primer error que la mayoría de los estimadores utilizan al establecer la fecha límite es asumir que el desarrollador estará a tiempo completo todos los días en esa tarea, lo que es un error desastroso. Esto puede resultar en que no se cumpla el plazo, incluso cuando utiliza el sobreestimado para calcular el plazo. Estar bajo las horas, pero más allá de la fecha límite que le dijo al cliente es un gran problema. Las personas se van, se enferman, tienen un trabajo de jurado, tienen que asistir a las reuniones requeridas sobre alguna nueva política de recursos humanos, se les llama para ayudar en otro proyecto cuando alguien está atascado, tienen que cargar el software en una computadora nueva cuando se rompe el anterior. tiene que investigar un problema de producción en el código que implementaron recientemente, etc. Si está estimando más de 6 horas por día en el proyecto por persona, ya tiene problemas en la fecha límite antes de que comience el proyecto. Cuando realicé estudios de mano de obra, utilizamos una cifra que equivalía a poco más de 6 horas diarias de trabajo directo al calcular cuántas personas se necesitaban para cualquier trabajo. E hicimos muchos análisis estadísticos como base para la figura que usamos.

Creo que tienes que decidir cuál de estos usar sobre una base de caso por caso. Tenemos algunos proyectos que sabemos que la estimación máxima todavía es probablemente un poco baja (generalmente cuando alguien en la administración no pudo enfrentar al cliente con la estimación real), tenemos otros en los que estamos haciendo algo nuevo donde sabemos que las estimaciones son más Es probable que esté apagado, en este tipo de casos ir con el máximo. Pero para el trabajo que has hecho antes, eso está bien definido y sabes que el desarrollador asignado no aprenderá nuevas habilidades, luego se acercará más al mínimo (pero en realidad nunca usa el mínimo, hay obstáculos inesperados en el camino) . Además, cuanto más corto sea el proyecto, es más probable que pueda cumplir con el mínimo, es mucho más fácil obtener una buena estimación para un proyecto de una semana que para un proyecto de una semana.

Más importante es cambiar la estimación y el plazo cada vez que cambian las circunstancias. Si el cliente agrega trabajo, extienda el plazo y la estimación, no solo hágalo. Si su mejor desarrollador se rinde y tiene que poner a alguien nuevo en el proyecto, extienda la fecha límite para que esa persona tenga que tener tiempo para ponerse al día (aunque es posible que tenga que comer las horas, el cliente puede no estar de acuerdo en pagar por eso). El factor crítico para esto es decirle al cliente de inmediato. Tienden a ser mejores en cuanto a mover un plazo (aunque no están contentos) que a perder uno o hacer la dealine, pero el producto no funciona como lo espera. a muchos gerentes de proyectos les gustaría que un problema se vaya y no tengan que enfrentar esa conversación con el cliente. Pero generalmente cuando finalmente tienen que decirle que es una conversación mucho peor que la difícil que intentaron evitar. .

En caso de duda, bajo promesa y entrega excesiva: usted quiere ser la persona que está entregando más de lo que esperaba, no menos. Basado en esto, siempre vaya con el más alto de cualquier estimación.

Un poco más complejo:

Para una entrega potencial dada, si traza los tiempos de entrega en función de las posibilidades de que ocurran, obtendrá una curva que es una variación de una distribución normal , y puede asumir que las estimaciones mínimas de los desarrolladores serán En algún lugar hacia la izquierda de la curva y su máximo hacia la derecha.

El área debajo de la curva a la izquierda del número único que selecciona como su estimación representa la probabilidad de que usted entregue con éxito en esa estimación o antes. Entonces, si da un número en el lado izquierdo, la probabilidad de golpear es efectivamente cero, si da un número en el lado derecho, la probabilidad es 100%.

Lo que se realiza con menos frecuencia es que si asigna el valor medio (suponiendo que el promedio mínimo y el mínimo se asignan a un valor aproximado al promedio real) solo alcanzará ese plazo el 50% del tiempo. Efectivamente, si usa la media, perderá la fecha límite la mitad del tiempo . No sé sobre ti, pero no me gusta que me vean como el tipo al que le faltan la mitad de los plazos.

Así que quieres un número que te dé algo que toques, digamos, el 90% del tiempo. Convenientemente, el 95% representa la media + dos desviaciones estándar, pero si no puede calcularlo (y la mayoría de nosotros probablemente no tenemos los datos) mi experiencia dice que:

(3 x max + 1 x min) / 4

Da un resultado razonable.

Por cierto, lo que le dices al desarrollador es la fecha límite es otra pregunta completamente. Personalmente le daría un lugar alrededor ((2 x máx + 1 x min) / 3) y tendría el resto como contingencia.

En su lugar, solicite las mejores , posibles y peores estimaciones de caso . Luego use la Evaluación del Programa y la Técnica de Revisión . Sin embargo, es posible que desee echar un vistazo a algunas críticas de PERT primero.

Para tareas individuales o tareas que constituyen el camino crítico , simplemente no es prudente buscar las mejores estimaciones de casos. Es como decir que el proyecto está absolutamente libre de cualquier riesgo e incertidumbre. Si el trabajo real resulta ser cualquier otra cosa que no sea el mejor de los casos, terminará haciendo estallar el calendario. Es mejor terminar con un poco de tiempo adicional en sus manos y llenar el tiempo mediante la implementación de algunos buenos para tener en lugar de tener que trabajar noches y fines de semana.

Por otro lado, si los gerentes optaron principalmente por las estimaciones del peor de los casos y en el mundo del software, fácilmente pueden ser un orden de magnitud mayor que las mejores cifras de casos, la mayoría de los proyectos nunca superarán la etapa de factibilidad y planificación. No todos los riesgos van a materializarse.

Ir por la mejor estimación de casos no ayudará a combatir el síndrome de los estudiantes . En su lugar, incluya hitos y entregables provisionales, además de ser útiles para combatir el síndrome de los estudiantes, son un requisito previo para contar con datos confiables sobre el progreso del proyecto y descubrir pronto cualquier problema potencial.

Esto depende del proyecto.

Algunos proyectos pueden requerir un desarrollo rápido y no hay alternativas si la fecha límite ya está establecida y no hay una buena oportunidad para prolongar el desarrollo. Problema típico: campaña de marketing resultando en nuevo servicio. Dicha fecha límite puede ser suficiente para el desarrollo normal, pero en algunas organizaciones está tan cerca, que los desarrolladores trabajan en tensión y cometen muchos errores que se corrigen durante la etapa de producción. Ese es un tipo de proyecto cuando los desarrolladores tienen que trabajar con la máxima eficacia y es mejor que obtengan una buena recompensa en el éxito.

Algunos proyectos se planifican con precisión y aquí puede utilizar todos los análisis que tenga: datos históricos, algunas métricas de tiempo del desarrollador en subtareas, cálculo de riesgos, etc.

Pero de todos modos, el tiempo MAX no debe usarse: es la medida más inexacta que generalmente lleva a que se tome más tiempo. Y aquí hay una razón simple: cuando el desarrollador simplemente regala este MAX, casi no mide. Él simplemente regala su intuición que tiene muy poca información en ese momento. Pero si pasa al menos media hora entenderá detalles específicos de sus tareas, incluso puede dividirlo en subtareas y aumentar su precisión. Así que puedes darle al desarrollador algunos sesgos como "hey, chicos, solo piensen en qué hora proporcionarían un código estable aquí", pero envíenlo a él mismo. Es bueno para un trabajo, es bueno para un programador.

No uses ni min ni max sino algo intermedio.

Erring en el lado de la sobreestimación es mejor. Tiene un comportamiento de costos mucho mejor a largo plazo.

  • Para superar el estrés debido a la subestimación, las personas pueden tomar atajos que no son beneficiosos a largo plazo. Por ejemplo, la deuda técnica adicional que se debe pagar finalmente debe devolverse, y se devuelve con un interés. Los costos crecen exponencialmente.

  • El costo adicional de la ineficiencia debida al síndrome del estudiante se comporta linealmente.

Las estimaciones y los objetivos son diferentes. Usted (o sus gerentes y clientes) establece los objetivos que necesita lograr. Las estimaciones le dicen qué tan probable es que cumpla con esos objetivos. La fecha límite es un tipo de objetivo. La fecha límite que elija depende del tipo de nivel de confianza (riesgo de no cumplir con la fecha límite) que está dispuesto a aceptar. P50 (0.5 probabilidad de cumplir con el plazo) es un lugar común. A veces es posible que desee programar con P80 o algún otro nivel de confianza. Tenga en cuenta que la curva de probabilidad es larga y cuanto más confianza desee, más tiempo necesitará asignar el tiempo para el proyecto.

En general, no pasaría demasiado tiempo rastreando tareas individuales. Con los objetivos P50 la mitad de ellos llegará tarde en cualquier caso. Lo que más importa es cómo se comporta el agregado. Cuando se componen estimaciones de tareas individuales en un agregado, ni min ni max son sensibles. Es extremadamente improbable que todas las tareas se completen con el tiempo mínimo (probablemente algo como el tiempo P10) o el tiempo máximo (por ejemplo, el tiempo P90): para n tareas P10 / P90 la probabilidad es 0.1 ^ n.

PERT tiene algunas técnicas para crear distribuciones de probabilidad de duración de tarea razonables y agregarlas a conjuntos más grandes. No voy a entrar en las matemáticas aquí. Aquí hay un puntero para leer más:

Si está estimando para un desarrollador específico y sabe que sus estimaciones son generalmente precisas para ese desarrollador, entonces el valor mínimo es la fecha límite lógica (inicialmente). En el curso del proyecto se ajustarán los plazos según las circunstancias.

Si tiene poca experiencia con un desarrollador específico, uno de mis gerentes anteriores con mucho cariño le pediría al propio desarrollador que haga la estimación y establezca la fecha límite inicial en un tercio de la distancia entre el mínimo y el máximo de ese desarrollador, desafiando al desarrollador a superarla.

Si estás tratando de mantener a los desarrolladores en su estimación mínima, es una tontería. Nadie, en ninguna industria, alcanza constantemente su tiempo mínimo estimado para hacer algo. Eventualmente, solo aprenderán a rellenar sus estimaciones mínimas de manera significativa, y luego nunca alcanzarán los mínimos anteriores, porque todas las estimaciones estarán por encima de eso.

En Agile / Scrum, no establece plazos firmes, sino "cuántas horas quedan en esta tarea". Todos los días, actualiza la cantidad de tiempo restante. No realiza un seguimiento de las horas pasadas, pero sí realiza un seguimiento de las horas estimadas restantes e intenta ser honesto al respecto.

Si tienes desarrolladores perezosos, esto es malo, porque pueden jugar fácilmente ese sistema. Si tienes desarrolladores que valgan la pena, es genial. Mejoran en la estimación con bastante rapidez, y usted, como gerente de proyecto, aprende qué tan confiables son sus estimaciones, y tendrá una idea mucho mejor de qué estimaciones pasa la cadena según las estimaciones de los desarrolladores individuales.

Vaya un poco hacia Agile, despida a los malos desarrolladores a medida que descubra cuáles son, recompense a los buenos desarrolladores por hacerles daño, y tenga un equipo más productivo y más feliz al mismo tiempo que puede reportar expectativas más precisas a sus superiores.

Si la diferencia entre min y max es grande en lugar de utilizar alguna fórmula de magia negra, creo que lo mejor sería volver a los desarrolladores y pedirles que realicen una mejor descripción y creación de prototipos, lo que llevará a mejores estimaciones donde la brecha entre el mínimo y el máximo no es tan grande.

Nota para la pregunta: en mi opinión, los desarrolladores / arquitectos deben hacer las estimaciones, ya que tienen el mejor conocimiento técnico para poder desglosar las tareas y estimar esas tareas.