Tratar con plazos no negociables como el único recurso en un proyecto de software [duplicado]

Gerente: No puedo cambiar las estimaciones ahora. Tienes que manejar esto de una forma u otra. Empiezo a sentir que no eres la persona adecuada para trabajar en este proyecto.

Su gerente está renunciando a la responsabilidad de su función, por lo que también tendrá que hacer su trabajo.

• Comience por armar lo que considere una línea de tiempo realista para esta tarea, trazando un mapa de todos los pasos que ve y estimando la cantidad de horas para cada paso. No dediques demasiado tiempo a esto, ya que podrías ser acusado de "detener" el proyecto. Puede ser algo tan simple como una hoja de Excel que enumera los pasos, la cantidad de horas estimadas y el cálculo de la fecha de finalización estimada. No incluya ninguna referencia a la fecha límite. Envíelo por correo electrónico a su gerente.

• Al final de cada día, junto a su tiempo estimado, coloque la cantidad de horas que pasó en el paso junto a su estimación y el porcentaje completo (ciertamente subjetivo) junto a eso. Incluya también una referencia a cualquier tiempo "fuera del proyecto" (reuniones obligatorias, solicitudes de emergencia, etc.). El cálculo de la fecha estimada de finalización debe actualizarse a partir de eso. Envíelo por correo electrónico a su gerente al final de cada día.

• No te quejes. Proceda en su mejor habilidad. Pon todo el esfuerzo que puedas.

Al final del proyecto, habrá sucedido 1 de dos cosas:

1. Te habrás sorprendido a ti mismo y realmente habrás cumplido con la fecha límite.
2. Habrá incumplido el plazo y su jefe no tendrá ninguna razón (legítima) para ser duro con usted, ya que lo ha mantenido informado en cada paso.

Sobre todo, mantén tus emociones fuera de esto. Esto es solo trabajo. Si te emocionas al respecto, no te irá bien y las cosas que digas mientras estás angustiado pueden usarse en tu contra más tarde. Si mantiene la calma, la concentración y la productividad, podrá decir honestamente que hizo su mejor esfuerzo y que no le ocultó nada a su gerente.

Si su organización no puede respetar eso, entonces nunca hubo una manera de tener éxito en primer lugar.

¿Cómo trato los plazos poco realistas en un proyecto de software? ¿Cómo me aseguro de no pasar por alto ningún plazo cuando los plazos en sí no son realistas?

Si no son realistas, los extrañará. Dicho esto, es posible que su gerente considere alcanzables los plazos (como en "no poco realista") considerando que hará horas extra (ver más abajo).

Después de haber trabajado en la industria durante un par de años, sé que tendré que trabajar 12 horas al día y probablemente también los fines de semana solo para cumplir con la fecha límite de cada subtarea.

No sé cuál es tu situación, pero si alguien me dijera que tendría que trabajar 12 horas al día para cumplir con un plazo con el que (personalmente) no me comprometí, respondería repasando mi CV y ​​comenzando a busca en otra parte Hay dos cosas a tener en cuenta sobre las horas extras planificadas:

• primero, cuando la fecha límite no es realista, las horas extraordinarias no son la respuesta, sino un síntoma del problema.

• segundo, a menos que trabaje en un país sin leyes de protección laboral, no se le pueden imponer horas extras. Si le pagan por 9 horas al día (por ejemplo), es completamente irreal que su gerente espere obtener más de su tiempo, básicamente de forma gratuita. Le piden que invierta 1,5 días-hombre por cada día-hombre y no obtenga nada a cambio (es tan poco realista como la fecha límite).

• tercero, cuando trabaja horas extras, trabaja por debajo de la mitad de su capacidad, durante más tiempo. No se siente así, porque estás reparando cosas y tienden a funcionar a corto plazo. Considerablemente cometes más errores cuando trabajas horas extras, y la mayor parte del código que escribes se traduce en deuda técnica. Los retrasos y problemas causados ​​por la deuda técnica aumentan exponencialmente con el tiempo, hasta que terminas con un código base que no se puede mantener.

Para responder a su pregunta, haría dos cosas:

• asegurarme de que el gerente comprenda y realice un seguimiento de mi progreso en este proyecto (es decir, si hice el 50 % de lo que debería hacer para cumplir con la fecha límite, lo comunicaría en los términos menos ambiguos posible).

• negarse a hacer horas extraordinarias sistemáticas. Si hay una emergencia y el futuro de la empresa está en juego, aceptaría quedarme hasta tarde en la oficina por un día o dos (y el tercero, respondería con "Lo siento, tengo planes" y me iría).

Si nada se quemó y un gerente decidió "No puedo cambiar las estimaciones ahora" por algunas estimaciones poco realistas, haría lo mejor que pudiera en el tiempo que le di a la empresa . Su contrato con la empresa está ahí para especificar lo que la empresa puede pedirle (¿especifica horas extras? ¿en qué términos?).

Si no se cumpliera con el plazo, sería un problema de gestión (es decir, no sería mío para resolverlo), y la responsabilidad sería del gerente.

Su responsabilidad en esto es hacer lo que realmente pueda (teniendo en cuenta que no es realista que la empresa espere trabajo gratis de usted) y comunicar los retrasos y problemas a su gerente. A partir de ahí, es su problema.

Editar en negrita .

¿Qué hizo cuando se enfrentó a plazos poco realistas que no eran negociables?

Muy pocos plazos son realmente no negociables. Si realmente no fuera negociable, habría más de una persona en el proyecto. Por el simple motivo del riesgo de que ya no esté disponible para trabajar en él y, por lo tanto, la posibilidad de que se pierda la fecha límite.

Gerente: No puedo cambiar las estimaciones ahora. Tienes que manejar esto de una forma u otra. Empiezo a sentir que no eres la persona adecuada para trabajar en este proyecto.

Si un gerente me dijera esto, mientras me da una fecha límite que considero irrazonable, entonces amablemente estaría de acuerdo con él y le preguntaría a qué proyecto le gustaría que me cambiara.

Si realmente siente que no puede realizar el trabajo en el tiempo requerido, entonces su trabajo es levantar esa bandera ante la gerencia. Lo que has hecho. El trabajo de la gerencia es entonces determinar si hay barreras para la finalización que puedan eliminar o impulsar el cronograma y hablar con las partes afectadas.

Sin embargo, si la gerencia simplemente va a tratar de obligarlo a cumplir con el cronograma, entonces esta es una receta para el desastre que simplemente no terminará bien. En cuyo caso, es mejor terminar con la parte difícil ahora en lugar de estar completamente estresado y lidiar con un posible despido más tarde.

Al aceptar cortésmente que tal vez no sea la persona adecuada para trabajar en estas condiciones, sucederá una de tres cosas. O le estás engañando y cambiará el horario, agregará a otra persona para que te ayude o terminarás sin trabajo. Honestamente, si te despiden por eso, probablemente lo habrías hecho si no cumplieras con la fecha límite de todos modos.

¿Cómo trato los plazos poco realistas en un proyecto de software?

En general, hay un par de puntos a considerar aquí:

1. ¿La fecha límite se debe a algún evento externo que no se puede mover? Por ejemplo, si hay una feria comercial en la que se debe realizar el proyecto, esto es un poco diferente a una fecha límite arbitraria.

2. ¿Qué tan bien puede probar que la fecha límite no es realista? La fecha límite puede estar planificada, pero ¿qué evidencia tiene para contrarrestar estos puntos?

¿Cómo me aseguro de no pasar por alto ningún plazo cuando los plazos en sí no son realistas?

Poner horas extra y pedir ayuda sería mi sugerencia.

¿Qué le digo a mi gerente cuando pierdo una fecha límite?

Si sabe que se perderá una fecha límite, le sugiero que informe a su gerente lo antes posible y vea qué curso de acción se recomienda. Quizás haya una lucha de poder o algo más aquí, pero puede haber alternativas. También está la cuestión de cómo se manejan los plazos dentro de la empresa, ya que he visto todo, desde todos en la empresa ayudar a cumplir con el plazo hasta los plazos son solo fechas esperanzadoras que no significan nada.

¿Qué hizo cuando se enfrentó a plazos poco realistas que no eran negociables?

Dependiendo de esos primeros puntos, habría algunas opciones:

1. Plan de contingencia - Revisar el alcance para que se pueda hacer una demostración pero con funcionalidad limitada.

2. Rechazar: De acuerdo, esto fue feo, ha habido ocasiones en las que mis compañeros de trabajo y yo le dijimos al líder que la fecha límite no era posible y le preguntamos qué querían que hiciéramos. Después de todo, es posible que tengan otras cosas que se puedan hacer dependiendo de por qué se presionó tanto.

3. Sumérgete: también he visto momentos en los que el equipo dedicaba horas extra y cumplía con la fecha límite. De acuerdo, esto conlleva el riesgo de que posiblemente se le pida que haga esto nuevamente, pero aquí es donde uno debe tener cuidado con la forma en que se maneja el tiempo en la empresa, ya que si se invierte mucho tiempo adicional, esto podría usarse más adelante. Alternativamente, obtener la aprobación de OT puede ser otra estrategia aquí.

Esta es la respuesta de su gerente:

Gerente: No puedo cambiar las estimaciones ahora. Tienes que manejar esto de una forma u otra. Empiezo a sentir que no eres la persona adecuada para trabajar en este proyecto.

Y la clave para mí es esta:

Empiezo a sentir que no eres la persona adecuada para trabajar en este proyecto.

El argumento principal de este gerente para que cumpla con un plazo poco realista es que quizás no sea la persona adecuada para el proyecto. ¿En serio? ¿Cómo inspirará realmente el acoso el trabajo?

Mi instinto me dice que la presión para cumplir con este plazo, y las consecuencias de por qué no puedo ser yo, realmente recae sobre su gerente y la falta de perspectiva de su gerente.

Y, lamentablemente, este gerente quiere asegurarse de que cualquier retroceso por esta fecha límite incumplida recaiga sobre el desarrollador (es decir, usted).

El mejor consejo que puedo darte es mirar el proyecto en sí mismo y dividirlo racionalmente en estas categorías.

• Funcionalidad central: lo que se puede hacer antes de la fecha límite que sería sólido y beneficioso para que el proyecto avance. Su objetivo sería avanzar dando lo mejor de sí mismo admitiendo que la fecha límite general no puede cumplirse, pero qué bien me veré y qué bien se verá el proyecto para cuando se cumpla la fecha límite.
• Problemático pero necesario: lo que no se puede hacer antes de la fecha límite sin comprometer seriamente la calidad. FWIW en cada proyecto de programación en el que he estado, siempre ha habido una funcionalidad central que puede ser invisible para los no técnicos, pero cubre el 80% de lo que se debe hacer. Entonces, si puede poseer esa base al obtener esa funcionalidad central sólida, gana a lo grande.
• Problemático y requiere una nueva estrategia: qué partes del proyecto parecen "cosas buenas" pero, de manera realista, serían un pozo de tiempo y recursos que afectaría negativamente al proyecto en general. Muchas veces, especialmente en el mundo invisible de la programación, las ideas que parecen conceptualmente buenas en el papel pueden terminar siendo una pesadilla en el mundo real. Por ejemplo, si su proyecto incluye aspectos de diseño frontal que requieren una revisión grupal y sabe que consumirán tiempo y requerirán revisiones, eso entraría en la última categoría.

Ahora, dicho esto, compile esa lista y acérquese a su gerente con los detalles. Si bien claramente están diciendo que no eres una buena opción para el proyecto, la realidad es que si hubiera alguien más que pudiera manejarlo, ya habría obtenido la tarea. O tal vez su gerente encontraría una manera para que ustedes dos trabajen de manera cooperativa.

Pero tal como está, mi actitud es que si el proyecto cae en tu regazo y sabes que los plazos no son razonables, estás en tu poder para dar forma a una discusión sobre la mejor manera de abordar esto.