Lidiar con plazos poco realistas [duplicado]

Si hay una fecha límite poco realista, uno de los siguientes tiene que suceder:

1. una. Extender el plazo / b. entregar fuera de plazo.
2. Suelta características.
3. Caída de calidad (espere algún que otro bloqueo o pérdida de datos aquí y allá).
4. Traiga a alguien altamente calificado que pueda contribuir significativamente al trabajo, eso es costoso.
5. Trabaja horas ridículas y como resultado te enfermas, con resultados dudosos.

Lo que no funciona, pero lo que parece hacer su gestión, es

6. Cierra los ojos y los oídos a cualquiera que te diga que la fecha límite está en riesgo.

El número 5 tiene la desventaja de enfermarte, sin ninguna ventaja para ti (la empresa no te va a pagar horas extras, ni te lo va a agradecer, pero date cuenta de que pueden aprovecharse de ti), y de todos modos no ayuda mucho. , por lo que esa es la opción que debes evitar y rechazar a toda costa.

Sugeriría crear una lista de características que podrían eliminarse sin dejar de tener un producto útil, y una lista de puntos en los que se puede disminuir la calidad, incluidas las consecuencias obvias. Luego, su gerencia debe decidir qué hacer. Si es necesario, infórmeles que la opción 6 no funciona (ande con cuidado allí), y que la opción 1b. ocurrirá automáticamente.

Lo que debe enfatizar es que sin acción, no se cumplirá el plazo.

En primer lugar, acepte que si este es realmente el caso, no está bien. Demasiados programadores se llevan el trabajo a casa y guardan silencio sobre estos temas dejando a la gerencia en la oscuridad (incluso si parece no estarlo).

Tampoco querrás presentar un problema sin algún tipo de razonamiento o solución. Para ello, la comunicación es clave. No solo decirle a su gerente que no podrá cumplir con una fecha límite, sino refinar la forma en que lo comunica.

Si yo estuviera en su posición, dividiría el trabajo en elementos y pondría tiempos y plazos en torno a cada uno de ellos. Luego puede usar esto para comunicar exactamente por qué no se puede cumplir con la fecha límite, con datos concretos con los que la empresa puede sentirse cómoda para tomar una decisión. Si se siente cómodo haciéndolo (según su nivel y el equipo), incluso podría sugerir algunos compromisos que se podrían hacer (con cambios o su propio cronograma) para ayudar a que el proyecto vuelva a encarrilarse.

Si esto no funciona, a menudo continúo actualizando una hoja de trabajo a medida que el proyecto comienza a enviar un resumen semanal (o si es necesario, diario) de los elementos de trabajo que se han completado, los obstáculos para realizar el trabajo y el cronograma previsto.

En primer lugar, parece que su empresa está abusando del concepto de plazos y estimaciones: las estimaciones son estimaciones y eso es todo lo que son. Nadie debería esperar que una estimación se ajuste exactamente a una fecha límite y la fecha límite debe tener un margen de seguridad muy razonable sobre la estimación exactamente para estas situaciones. Entregar antes está bien, entregar después de la fecha límite no lo es.

Modificando las respuestas anteriores, y según mi experiencia previa, esto también podría ser un problema de comunicación por una razón simple: las personas en la administración a menudo carecen de habilidades técnicas y comprensión, y en pocas palabras, están subestimando la importancia de la calidad del software, que es un Aparentemente, es una necesidad real en este caso, ya que usted indicó que se necesitará una gran cantidad de refactorización. En base a eso, probablemente debería presentar a la gerencia el hecho de que hacerlo más tarde costará más, ya que la deuda técnica solo aumenta y el problema que ya existe no desaparecerá simplemente si se pospone, sino que aumentará en gravedad a medida que agregue más y más. complejidad al proyecto, y ese aumento será exponencial hasta el punto en que mantener el proyecto absorberá una gran cantidad de recursos. Yo no'

Si se trata de un producto interno, el argumento de que en realidad deberíamos producir algo que funcione bien en lugar de un pastel a medio hornear debería pasar con gran éxito.

Si se trata de un producto para algún cliente externo, aún más: las personas suelen ser lo suficientemente razonables como para aceptar extender los plazos si eso significa que el resultado final mejorará en un orden de magnitud.

Por último, pero no menos importante, debe averiguar por qué ocurrió esta gran subestimación en primer lugar y colocar un mecanismo para evitar que suceda en el futuro: ¿los técnicos no participaron en las estimaciones? ¿Se excluyó algo importante de las estimaciones y, de ser así, por qué? Y si es así, ¿por qué no se prorrogó el plazo después de que se demostró que no era realista?

Lo siento, pero creo que estás abordando el problema desde un punto de vista demasiado ingenieril. Es fácil acusar a la gerencia de no ser razonable, especialmente si no tienen conocimientos técnicos, pero estás perdiendo clientes. Esa es una realidad.

Como todas las situaciones de emergencia (pérdidas y daños graves con poco tiempo y recursos), hay que clasificar. En su caso, tiene que suceder tanto en la Refactorización como en las áreas de Características/Requisitos. Consigue esos dos en sincronía si es posible. Si la característica A ayudará a retener a la mayoría de los clientes, refactorice esa parte del código base si es necesario. Al menos limita la refactorización en las áreas de menor interés para tus clientes. Me doy cuenta de que puede estar refactorizando áreas, utilidades o marcos generalizados.

Soy escéptico acerca de este gran cambio de imagen en un momento en que los clientes no están satisfechos con su aplicación. Arregla lo que tengas para solucionar sus problemas. Si puedes ayudarme a cruzar el río, no necesito un nuevo puente.