Gerente de proyecto que quiere bloquear el tiempo estimado con un contrato firmado

En un empleo anterior, un gerente de proyecto (PM) no estaba satisfecho con el tiempo de entrega del código en un proyecto en el que estaba. El jefe de mi proyecto me dijo que el primer ministro estaba considerando pedirme que firmara un contrato para asegurar las estimaciones de tiempo que di para las tareas y las fechas de entrega.

La situación en el proyecto era que estábamos trabajando con nuevas tecnologías, bases de código, estándares de codificación y requisitos muy propensos a cambiar. Estaba aprendiendo cosas nuevas y aplicándolas lo mejor que pude a los requisitos que seguían cambiando. Los requisitos a lo largo de las iteraciones crecieron de 2 a 3 veces, con mi estimación para completar un crecimiento de aproximadamente 5 a 8 veces. Lo único que no cambió fueron las estimaciones y las fechas de entrega.

Sí, terminé perdiendo la mayoría de los plazos. Y estaba trabajando en algunas tecnologías muy nuevas que nadie más en todo el equipo de desarrollo realmente podría ayudar porque no estarían familiarizados con él. Al menos no fácilmente.

Entonces me pareció que el primer ministro quería que sus números se sumaran, y por lo tanto quería que firmara un contrato para "asegurar" que siempre entregaría el código de trabajo a tiempo. Supongo que con un contrato firmado, el primer ministro podría usarlo en mi contra si no pudiera entregar a tiempo.

Creo que lo que sucedió después fue que otros gerentes de proyectos y / o líderes de proyectos me defendieron y no dejaron que esto sucediera.

Mi pregunta es, ¿ debería esto levantar una bandera roja sobre el gerente? ¿Es una práctica común que un gerente bloquee las estimaciones de tiempo de un desarrollador de software con un contrato firmado? O en este caso, intenta hacerlo.

Tenga en cuenta que era un empleado a tiempo completo, no un consultor independiente.

Actualización : Quiero agregar que entregué nuevas estimaciones semanalmente, pero parece que las estimaciones originales y las fechas de entrega fueron las que fijaron el PM.

Mi pregunta es, ¿debería esto levantar una bandera roja sobre el gerente?

Sí . Significa que es hora de que actualice su currículum / CV y ​​comience a buscar un nuevo trabajo. O significa que su gerente está a punto de comenzar a jugar algunos juegos muy desagradables con usted.

¿Es una práctica común que un gerente bloquee las estimaciones de tiempo de un desarrollador de software con un contrato firmado?

Nunca he oído que esto se aplique a un empleado.

La estimación del tiempo y el esfuerzo siempre es difícil. Sobre todo porque nuestra profesión está llena de excesivo optimismo. Hay algunos sistemas de estimación que podrían ayudar con las estimaciones en el futuro, pero necesitan recopilar estadísticas históricas de usted mismo. Uno es PSP . Otro son los puntos de función . A muchos desarrolladores no les gusta ninguno, y encontrarás opiniones muy fuertes en contra de ambos.

La dificultad clave para estimar el tiempo y el esfuerzo es la falta de retroalimentación en nuestras heurísticas de estimación. Una de las claves es anotar cuál cree que es la estimación y qué parámetros utilizó para estimarla. Luego, en función de lo que realmente hace, compare eso con lo que pensó que haría. Y use eso para modificar sus parámetros de estimación. En ingeniería, llamamos a esto " retroalimentación ".

Sí, eso debería sonar absolutamente las alarmas.

Si hubiera estado en el puesto, para mi entretenimiento personal, le habría pedido al gerente que firmara un contrato que congelara todos los requisitos. Me imagino que el gerente probablemente se iría. Entonces me iría.

Pues eso es simple. Solo dígale a su gerente que firmará para bloquear su estimación de tiempo cuando él firme para bloquear la especificación. Debido a que no puede, seguramente proporcione estimaciones para algo que se desconoce. Especificaciones completas del proyecto antes de comenzar, sin cambios, y puede terminarlo a tiempo :)

Un cambio a spec => contract es nulo. Probablemente la cosa se anulará después de 10 minutos en su primer día :)

Sí, esto es una bandera roja. Lo que le dice es que el gerente no comprende cómo administrar el riesgo en proyectos de software. Lo que debería estar haciendo es descubrir qué causó exactamente la demora en primer lugar y luego comenzar a instrumentar un proceso para administrar de manera efectiva los riesgos del cronograma que inevitablemente sucederán durante un proyecto de software.

NUNCA bajo ninguna circunstancia firmaría un contrato con mi gerente que garantizara un horario. Otros han mencionado que debe firmar un bloqueo en las especificaciones. Esto en mi opinión no es suficiente. Esto no tiene en cuenta las dificultades imprevistas con las herramientas o la tecnología, diseños incompletos o deficientes, el rendimiento de otros miembros del equipo, etc.

Esto no es una bandera roja, es una estupidez de grado de armas.

Si las estimaciones y los plazos de entrega se reducen constantemente, lo racional es identificar las causas y mejorar los procesos.

Si culpas y pateas al caballo porque no sabes a dónde vas, ¡no te sorprendas si el caballo te muerde y se escapa!

Mientras que el gerente estaba fuera de línea con su demanda. No tiene toda la culpa. Si estaba trabajando en un territorio completamente desconocido, no hay nada de malo en decir "No sé". Me tomó un tiempo darme cuenta de que "No sé" es una respuesta perfectamente aceptable, así que sé cuánto duele pronunciar esas palabras. Pero si realmente no lo sabes, esa es la respuesta. Y si se niegan a eso, pídales que le den una estimación de cuántos centavos se necesitarán para hacer una pila tan alta como la Torre Sears (que sea Willis). ¿Y estarían dispuestos a firmar un contrato pagándole cada centavo que tenían?

Cualquier gerente de proyecto que valga su salario debe saber que algunas cosas no encajan bien en una hoja de cálculo. A veces las cosas se hacen cuando se hacen. Creo que lo estás haciendo bien al progresar en cuanto has hecho. Simplemente deja de dar las actualizaciones de números.

Otro ejercicio es dividir la tarea grande en unidades más pequeñas y estimables. Este ejercicio también lo ayudará a comprender mejor lo que debe hacer. Consulte la Estimación de software de Steve McConnell y los Patrones de requisitos de software de Stephen Withall para obtener consejos sobre cómo desglosar tareas y descubrir requisitos ocultos, respectivamente.

No dispares desde la cadera en una estimación. Tómese el tiempo para descomponerlo. Estimar una gran cantidad de tareas pequeñas le dará una mejor estimación general (debido a la ley de promedios, algunas de sus estimaciones estarán por debajo pero algunas terminarán y tenderán a sopesarse) de la gran tarea.

Pregúntele a su "gerente de proyecto": ¿Estamos vendiendo software o plazos?

Soy gerente de proyectos y programador :-) Podría hablar mucho acerca de cómo la mayoría de los PMs son de fuera de la industria y no puedo manejar nada que no encaja bien en un modelo de línea de producción ... pero yo No, no aquí. En cambio, aquí hay una larga polémica sobre qué hacer realmente (Sr. Mod, si es demasiado largo, haga lo que quiera con él). Estoy de acuerdo con los comentarios que ya se hicieron aquí, algunos que debe hacer antes que otros, pero esto es lo que creo que habría sido su mejor movimiento . Ah, y la respuesta obvia a su pregunta es sí, pero está elaborada en un lenguaje colorido y detallado a continuación.

Sin embargo, antes de comenzar, tenga en cuenta que es muy probable que el primer ministro le dé pena, porque alguien más en la cadena alimentaria le está dando pena. Ellos (nosotros) somos criaturas simples ... Hay formas de evitar la situación que describiste: Mike Brown lo cubre bastante bien. Tampoco hay nada de malo en trabajar en algo durante 3/4/5 .. horas seguidas antes de comenzar (en realidad, todo tipo de alarmas deben activarse si esto no sucede). Y si va a un territorio desconocido, retroceda y solicite una semana para investigar el área y las tecnologías para poder hacer una estimación razonable (querrá hacer esto correctamente porque quiere que la nueva tecnología aprenda y juegue con don ¿no? Si su PM y la gerencia en el lugar donde se encuentra no entienden esto ... entonces actualice su currículum y busque la salida más cercana, dejándolos al destino que tanto se merecen. Que el primer ministro incluso piense en hacer que un empleado a tiempo completo firme un contrato como ese es una mala mala señal ... la única forma en que pude ver quepuede que no sea totalmente incompetente es que en realidad solo estaban jugando juegos mentales con el líder de su proyecto y usted (por lo que leí, no se lo pusieron directamente a usted, y finalmente no cumplieron con la amenaza). PMing es un refugio para tu psicópata corporativo estándar después de todo. Fue bueno que otros se pusieran en peligro por ti por lo que dijiste, por lo que el consejo a continuación probablemente te haya resultado positivo al final. Me imagino que habrían tenido una revolución en sus manos si hubiera resultado más que hablar.

Entonces, para la situación / agujero real que describiste , porque le volverá a pasar a alguien, en algún lugar (como hace unos 5 minutos, y nuevamente en otros 5, scheduleRepeat ()). Probablemente sin la estupidez del contrato, pero la historia básica es siempre la misma. Organizan una reunión (!), Les gustan las reuniones ;-) todos pueden darse una palmadita en la espalda al final como si realmente se hubiera hecho algo. IMPORTANTE:Asegúrese de incluir a su jefe de proyecto técnico / líder de equipo / arquitecto / gerente de diseño en la invitación a la reunión, ya que ya les hemos repasado el problema y los hemos incorporado. Cuanto más alto en la jerarquía pueda ir para alguien de su "lado", mejor. Porque su PM lo verá e intentará hacer coincidir su gerente de diseño con un equivalente. Si no, son tontos y ya has ganado. Eso en sí mismo generalmente los pondrá de nuevo en línea, porque ahora son visibles para alguien que probablemente pueda despedirlos en el acto. Si juegan juegos contigo, puedes devolver el favor.

En la reunión, repase los detalles técnicos de lo que está tratando y por qué toma el tiempo necesario. Deberían querer saber esto (y cómo pueden ayudarlo a hacerlo), pero el hecho triste es que generalmente esto no sucede ... probablemente obtendrá 10 minutos antes de que sus ojos vuelvan a su cabeza. Ahora, lo que quisiera que se haga aquí probablemente no sea legal ... sí, lo comprobé, en realidad es altamente ilegal y no querrás ir a la cárcel por tanto tiempo. El punto es que has hecho un gran esfuerzo para ser proactivo y si tienes algunos superiores presentes, tu dolor ahora es suyo ... como debería ser. Tendrás que usar tu juicio sobre cómo es probable que las cosas se desarrollen, porque 'escalamiento' es lo que sucederá. Si el liderazgo en el lugar en el que estás es medio decente, harán lo correcto, y haz lo correcto por ti también. Si no, entonces habría tenido su currículum en el mercado de antemano ... iba a irse a la primera oportunidad de todos modos (y parece que finalmente lo hizo). El liderazgo se dividirá en dos grupos: o son expertos en tecnología e instantáneamente verán su punto de vista; o no lo son y ¿qué van a hacer al respecto además de sonreír y soportarlo? Si pudieran hacer lo que haces, entonces ya lo estarían haciendo. ¿y qué van a hacer al respecto además de sonreír y soportarlo? Si pudieran hacer lo que haces, entonces ya lo estarían haciendo. ¿y qué van a hacer al respecto además de sonreír y soportarlo? Si pudieran hacer lo que haces, entonces ya lo estarían haciendo.

Mantenga el problema de los requisitos cambiantes como su tarjeta de triunfo para usar al final ... servirá como una salida para todos. El proyecto en sí y el maldito cliente / parte interesada tendrán su nombre en vano. El camino más fácil sería un tipo de reinicio en el proyecto, y tal vez ese PM sería reasignado silenciosamente a un área diferente. Los milagros suceden ocasionalmente. Si el primer ministro planteó el problema del contrato en la reunión, entonces responda con los requisitos para congelar la demanda del contracontrato; en lo que a mí respecta, ya quemaron sus puentes con usted y con todo el equipo de desarrollo, cuando comenzaron jugando ese tipo de juegos mentales.

Antes de cerrar sesión: Cambiar el alcance / los requisitos: una de las mejores razones para adoptar la metodología Agile, para que los clientes / partes interesadas sean responsables de cambiar de opinión sobre lo que quieren ...

Otra cosa: en la declaración "No sé", siempre ha sido mi punto de referencia personal sobre cómo evaluar el valor de un compañero tecnólogo o miembro de uno de mis equipos de proyecto. Creo que las únicas personas que pueden decir que directamente a la cara son las mejores que hay, principalmente porque alguien que sabe que está fuera de su alcance nunca lo dirá, lo abre a ser expuesto claramente por alguien con habilidad real en Un latido del corazón. Por otro lado, alguien que se pronuncie y lo diga, también tendrá un plan básico (incluso si no se ha pensado bien) sobre cómo abordar las incógnitas para que en 24 horas haya una respuesta más útil, y en una semana aún mejor. Cuando el Apolo 13 volaba alrededor del lado oscuro de la Luna, sucedía un montón de "No sé".

Sí, esto debería levantar una bandera roja, especialmente si es un empleado a tiempo completo. ¿Cuáles fueron las condiciones del contrato? ¿Sería despedido si no cumpliera con los plazos? ¿O simplemente te perderías un bono? ¿Qué harían ellos?

La bandera que esto plantea es que el gerente no tiene idea de cómo administrar un proyecto que trata con tecnologías nuevas / desconocidas y requisitos cambiantes que afectan directamente el esfuerzo estimado. Si bien a veces suceden plazos estrictos, un gerente que conoce la situación no debería tratar de hacer que los empleados firmen contratos para hacerlos cumplir. Tarde en la noche y tiempos de crisis serán malos, pero eso probablemente sea normal para el curso. Y aún a veces la fecha límite se deslizará. Sucede, y como alguien más publicó, la única forma de cumplir con el cronograma es congelar los requisitos ANTES PARA que aún haya suficiente espacio para mantener la línea de tiempo.

Por lo que has dicho, las alarmas son unos meses demasiado tarde. Normalmente es arriesgado basar un proyecto urgente en tecnologías con las que el personal aún no está familiarizado. Es insensato hacerlo si no tiene conocimiento de la recopilación de requisitos y la gestión del alcance.

Dicho esto, estoy de acuerdo con las otras respuestas. Además, es posible que desee actualizar su currículum si aún no lo ha hecho.

Al igual que todos los demás encuestados, no podría estar más de acuerdo en que esto debería levantar una bandera roja.

Parece que el primer ministro no quiere involucrarse en el proceso de desarrollo.

En mi práctica personal, me he alejado de tratar con especificaciones detalladas por adelantado, aprobaciones, estimaciones completas del proyecto o precios de oferta fija (desde una perspectiva de consultoría).

La razón de esto es la comprensión, de la que hablan muchos de los gurús de Agile and Lean Software, de que el software no es una entidad manufacturable fija, sino que es principalmente un proceso de descubrimiento.

Muchas personas todavía tienen problemas con esta noción, y parece que su PM también lo hizo. Todo se reduce a una simple comprensión de las compensaciones.

Las especificaciones rígidas por adelantado y las estimaciones fijas funcionan para sistemas donde el costo del cambio es alto. Como construir un rascacielos. Si olvidó especificar los pozos de los ascensores por adelantado, será muy difícil adaptar el edificio una vez que se haya erigido. El alto costo del cambio requiere mucha planificación inicial, aprender las incógnitas de los componentes y tecnologías, y la experimentación inicial. Solo una vez que haya hecho toda esta tarea, puede estimar el presupuesto y el costo.

En el software, las personas se han acostumbrado mucho a la idea de que el costo del cambio es bajo, por lo que les gusta aprovechar la posibilidad de cambiar las cosas una vez que ven un lanzamiento, incorporan una nueva comprensión de la aplicación, el negocio y el cliente. de forma continua. Todo esto es bueno y una gran oportunidad cuando se aprovecha correctamente. La mayoría de las personas de software con las que he conocido y trabajado no disfrutan pasar mucho tiempo planeando o investigando; La mayoría de nosotros (PM incluidos) queremos ver una tracción continua. De aquí proviene el desarrollo iterativo con sus pequeñas e incrementales versiones de funcionalidad. Hay otras prácticas que se pueden utilizar, como el desarrollo basado en pruebas para garantizar que el costo del cambio se mantenga bajo y contenga la deuda técnica.

Hacer que esto funcione implica un "contrato" entre ambas partes, el propietario del producto (Agile habla por su PM o clientes o equipo de control de calidad) y los desarrolladores. Los desarrolladores acuerdan trabajar solo en cosas que se hayan priorizado como las más importantes para la iteración dada y no tomarse una eternidad con eso, sino que se esfuerzan por liberar con frecuencia trozos de funcionalidad totalmente integrados (por ejemplo, semanalmente o mensualmente). Los propietarios de productos, por el contrario, acuerdan revisar continuamente las versiones incrementales y proporcionar comentarios rápidos. También acuerdan establecer las prioridades para la próxima iteración y una vez configurados para no cambiar de opinión durante la duración de la iteración.

Esta última parte del acuerdo es algo que su PM probablemente no entienda. Muchos PM tradicionales en realidad no lo hacen. Algunos de ellos piensan que su trabajo está hecho cuando dejan la especificación; no quieren escuchar sobre problemas, alternativas, mejores formas, etc. La desventaja es que esto no solo contrarresta el flujo del desarrollo de software sino que también perjudica a la organización al dejar muchas oportunidades sobre la mesa.

Eche un vistazo al Manifiesto Ágil: http://agilemanifesto.org/ Puede resonar con usted. Un buen libro para leer también es "Lean Software Development" de Mary Poppendieck.

Buena suerte.

Parece que el gerente está buscando a alguien a quien culpar cuando le informa a su superior.

Me parece que si tiene un gerente irracional que piensa que una "estimación" es lo mismo que un "período fijo", ¡lo mejor que puede hacer es pensar en un período de estimación muy generoso y luego duplicarlo!

Además, obligue al gerente a asegurarse de que los requisitos estén completamente detallados y arreglados. Cualquier cambio a partir de entonces no se abordará sin una 'renegociación formal' con el gerente del proyecto del nuevo tiempo de finalización.

Finalmente, el gerente del proyecto tiene la idea y los planes en consecuencia.

Mi experiencia personal con este tipo de cosas es que el gerente del proyecto está tratando de establecer un rastro de papel para deshacerse de usted mientras hace que su terminación sea su propia culpa. Eso lo convertiría en una bandera muy roja. Su kilometraje puede, por supuesto, variar un poco.

Buenas respuestas por todas partes, pero déjame agregar mis 2 centavos.

Si alguna vez estudia la probabilidad, existe una "variable aleatoria". Ese es un número cuyo valor no conoce, pero puede describir su no saber con una distribución, como una distribución normal (curva de campana) u otra.

El punto es que el trabajo tomará una cierta cantidad de tiempo, pero cualquier estimación previa será incorrecta, por un poco o mucho, en el lado negativo o positivo, por lo que hay riesgo, y alguien tiene que correr el riesgo. En general, si las personas toman riesgos, se les paga por ello. El seguro cuesta dinero.

Cuando era consultor, generalmente tenía la opción de firmar un contrato de tiempo y materiales en lugar de un contrato de precio fijo. Con tiempo y materiales, el cliente corre el riesgo. Con precio fijo, asumo el riesgo. Con el precio fijo, construyo un margen de seguridad, porque si no cumplo con el objetivo, nadie gana.

Pedirle que se comprometa con una fecha de entrega fija, especialmente sin requisitos fijos, suena como tratar de transferirle el riesgo, aunque no está claro lo que realmente está arriesgando. En cualquier caso, una respuesta es simplemente poner un generoso margen de seguridad.

PD: Ves esto todo el tiempo con contratos gubernamentales. Hay una solicitud inicial de propuestas, se hacen ofertas, se acepta una oferta baja, y luego comienzan a llegar las solicitudes de cambio, por lo que el costo se dispara y se culpa al contratista. Las cosas funcionan mucho mejor si hay una relación de trabajo en equipo entre el cliente y el contratista, en lugar de una relación conflictiva.

Sí, por supuesto, esto levanta una bandera sobre la experiencia y competencia de su antiguo jefe. Sí, como sugirió la mayoría de las personas, este sería un buen momento para actualizar su CV.

Sí, como dicen las otras respuestas, en la mayoría de las situaciones no querrá firmar ese acuerdo. Sin embargo, quiero sugerir que puede haber algunas situaciones en las que podría considerar firmarlo.

La mayoría de los desarrolladores y gerentes son conscientes de la constante fricción entre la funcionalidad, la fecha límite y el presupuesto. Muchos también nominarían la calidad como cuarta dimensión ("¡Puedo cumplir cualquier conjunto de requisitos que desee, para mañana con un presupuesto bajo, siempre y cuando esté dispuesto a aceptar que no funcionará!")

Pero hay otra dimensión más: el riesgo. Si solo necesito entregar con éxito el 50% del tiempo, puedo reducir mis estimaciones inmensamente; están acolchados para manejar una tasa de entrega mucho más alta.

Podemos abordar el riesgo de varias maneras (y las estimaciones de relleno es una de ellas). El gerente no está dispuesto a aceptar ningún riesgo y quiere poner el riesgo sobre sus hombros. Normalmente, debe rechazar tal movimiento ... a menos que esté bien recompensado.

Si puede nominar su fecha límite, con una cantidad mutuamente aceptable de relleno para lidiar con retrasos inesperados, y puede negociar un bono (muy grande) si lo alcanza, y está en una posición financiera para poder manejar el multas (por ejemplo, ser despedido) si no puede, puede encontrar que es una "apuesta" que vale la pena aceptar ese riesgo usted mismo y firmar el contrato, con cláusulas adecuadas para manejar los cambios de requisitos.

Esto es una estupidez directa. No sé cuál era el objetivo final, pero cada gerente de proyecto a mitad de camino responsable de los productos de software debe ser consciente de que las estimaciones son exactamente lo que se llaman: estimaciones. No son promesas y no se pueden hacer sin agotar al desarrollador de software de toda su energía u obligarlos a romper su "promesa" de todos modos.

Si desea mostrar cuán ridículo es ese contrato, podría haber dos sugerencias:

a) Sobreestimado hasta el punto en que el proyecto dura cinco o diez veces más de lo que se estima sin un contrato. Si el gerente del proyecto pregunta por qué las estimaciones son tan altas, simplemente diga que solo se está asegurando de que puede cumplir su contrato.

b) Esto ya se ha sugerido: solicite un contrato que se asegure de que no cambie un solo requisito y asegúrese de que esto incluye la corrección de errores ortográficos. En mi experiencia, no hay un solo proyecto de software donde los requisitos no cambien en algún momento durante el desarrollo. Es más probable que el gerente del proyecto tenga que romper su contrato que usted.

Si el gerente del proyecto aceptara cualquiera de estas dos sugerencias, sabría con certeza que están fuera de su mente.

Por cierto, ¿cómo funcionaría un contrato para un empleado a tiempo completo? No conozco las regulaciones laborales en otros países, pero como empleado a tiempo completo en una empresa, no creo que nadie pueda obligarlo a firmar un contrato vinculante para cumplir con un plazo y tener un caso válido. Claro, podrían darte un infierno si no cumples con la fecha límite, pero no necesitan un contrato para eso. Nadie podría despedirte o darte menos dinero. Podrían reducir su bonificación acordada en el peor de los casos. Entonces, a menos que esto sea diferente en otros países, esto parece más una amenaza vacía que cualquier cosa que debas tomar en serio.

Voy a ir contra la corriente aquí.

La situación que describe no es tan inusual en el nivel del equipo de Ingeniería , especialmente después de un proyecto / lanzamiento particularmente tardío. En muchas situaciones, es posible que su administración y toda su organización se hayan inscrito para una fecha de lanzamiento en particular, y otras partes de la organización estarán preparadas para esa fecha. Puede haber una presión tremenda en su cadena de administración para alcanzar esa fecha.

Aquí es donde entra un proceso de ingeniería general. Probablemente hayas oído hablar del modelo de cascada. Existen otros modelos, pero el objetivo final de todos ellos es entregar de manera consistente algo cuando se espera y que contiene lo acordado. Las especificaciones funcionales, los diseños, las listas de tareas, etc., hacen que este sea un proceso predecible. La comunicación, el análisis de riesgos y (como usted dijo) la actualización periódica de las expectativas sobre el cronograma reducen las sorpresas y hacen que la información esté disponible lo antes posible para que los planes puedan ajustarse. Y sí, debe haber ajustes en el plan cada vez que se agregan o eliminan funciones.

En algunos de los equipos con los que he trabajado, no dudaría en considerar mis estimaciones como compromisos firmados, pero eso refleja la calidad de los equipos y la administración, y no ninguna habilidad particular en la estimación. Un equipo que está dispuesto a firmar un contrato para entregar a tiempo es un indicador de un equipo que funciona bien, no una señal de alerta.

Digo ponte en su lugar y trata de entender lo que lo motivó. De los gerentes / contadores prospectivos necesitan un número para justificar lo que está sucediendo y cómo van las cosas.

Puede ser que al ser ridiculizado en la sala de juntas por cambiar los plazos, perder demasiados plazos, intentó la forma más simple posible de encerrarlos. ¡Dame un número y firma aquí! Al estar en el otro extremo, solo podría haber percibido que es algo en su contra. Sin embargo, hacer estimaciones y, a medida que avanza, darse cuenta de que deben ajustarse es lo que le resulta más útil. Si comprende qué motivó la solicitud y cuál es el verdadero problema que enfrenta, es posible que pueda ayudarlo a usted y a usted mismo. Como programadores resolvemos problemas. Esto no es diferente, entiende y resuelve su problema y él será tu mejor amigo. ¡Hay tanto trabajo por hacer que nadie tiene tiempo para planear una venganza personal! Necesita ayuda con su trabajo, ¡la solución más simple era que alguien firmara un documento! Probablemente lo obtuvo de un libro de administración para tontos, "Haga que sus trabajadores firmen y sean responsables de un número". Divertido pero triste

"Caminar sobre el agua y desarrollar software a partir de una especificación es fácil si ambos están congelados".

-Edward V. Berard

Si sus requisitos están cambiando, entonces no es razonable esperar que sus estimaciones iniciales sean precisas. Sí, esto debería ser una bandera roja.

¿El contrato especifica una multa por no cumplir con la fecha límite? Si no es así, no es un problema en absoluto; simplemente está firmando una estimación basada en su conocimiento en ese momento.