¿Cómo lidiar con los cambios rápidos en las especificaciones del proyecto en un escenario de plazo ajustado? [cerrado]

Question

Cómo tratar con un gerente de proyecto que impone fechas límite muy ajustadas pero con un día o más antes de que la fecha límite incorpore nuevas funciones y cambios de especificaciones para implementar, con otra fecha límite ajustada.

Lo peor de esto es que la mayoría de las cosas nuevas conducen a una reescritura importante del código existente, ya que las reglas comerciales implementadas anteriormente ya no son aplicables o se obtienen "quot". Casos extraños de esquina que necesitan ser tratados por separado.

Parece que no importa cuánto intentemos que el sistema sea extensible, siempre hay cosas que surgen literalmente en el último momento y deben implementarse y admitirse rápidamente.

¿Cómo podría lidiar con tal situación? Es realmente desmoralizante y un colega ya ha renunciado al equipo.

Answer 1

Es cierto que no importa lo que hagas, eres humano y cometerás errores o te perderás de algo. Dicho esto, los cambios regulares en sus requisitos son a menudo el resultado de requisitos deficientes o un proceso de desarrollo deficiente, o ambos.

¿Algún diseño por adelantado?

A los desarrolladores, los gerentes de proyecto, etc., el análisis de negocios se les concede poca importancia. La mayoría de los desarrolladores solo quieren comenzar a piratear el día 1, y la mayoría de los PM les encanta: "Vaya, podemos pasar de la iniciación del proyecto ¡Fase a la fase de construcción en 1 día sin que nada de ese ridículo análisis de negocios tome tiempo! ¡Se verá genial para los bonos de finalización! & Quot; Pero recuerde que el trabajo principal del primer ministro es mantener el proyecto bajo control (a tiempo y dentro del presupuesto) ... no necesariamente para hacer felices a los usuarios y, por supuesto, no para hacer felices a los desarrolladores. Eso no quiere decir que son totalmente desalmados; Los buenos PMs lograrán sus objetivos mediante la aplicación del control de alcance y el fomento de la comunicación, que son útiles.

Pero tomarse el tiempo para pensar realmente en lo que se necesita y pasar por los posibles escenarios puede marcar una gran diferencia en los problemas con los que está tratando.

• Si ha hecho un esfuerzo por realizar un análisis comercial exhaustivo y aún está terminando con los cambios de última hora, tal vez su problema sea otro desafío clásico: los usuarios desconectados. Sus expertos en la materia son su arma principal para tratar e identificar los casos de esquina. Si tiene usuarios que no participan en el proceso de análisis, obtenga mejores expertos en la materia.
• También es posible que los usuarios estén desconectados porque están demasiado ocupados haciendo su trabajo habitual. En ese caso, es un problema de administración y se les debe dar instrucciones de que la participación en el proyecto es parte de sus trabajos; eso es difícil a veces porque a menudo la misma administración que te dijo que "lo hicieras ayer" " es el mismo grupo de nudillos que esperan que el proyecto se realice de manera mágica sin contratiempos y sin recursos (son comunes porque no entienden las complejidades del desarrollo de software personalizado y suponen que es fácil). Si la administración no tiene ni idea y no cambiará ... bueno, tiene que trabajar horas extra y tratar los problemas que ha descrito, u obtener un nuevo trabajo.

¿Puede Agile ayudar?

Seguro que sería bueno que tus usuarios te informaran sobre esos casos de esquina más temprano que tarde, ¿no? Esto está relacionado con lo que Toby Hede discutió en su publicación. Quizás una metodología que ponga el software frente a los usuarios tan pronto como sea posible, incluso en un estado sin pulir, pueda desencadenar comentarios antes. Esa fue una de las inspiraciones de todos los conceptos ágiles. Los creadores estaban cansados ??de lidiar con los problemas que describe y también se dieron cuenta de que si la administración y los usuarios no iban a cambiar, tal vez el desarrollo podría hacerlo. Aún está en desarrollo, pero hay un énfasis en obtener retroalimentación temprana a través de una variedad de técnicas (haga que expertos en la materia se ubiquen junto con el equipo de desarrollo, obtengan prototipos aproximados en las manos de los usuarios, programen en parejas para captar la experiencia del desarrollador y mucho más) . Todo esto se debe a que se entiende que somos humanos y que vamos a extrañar cosas.

Finalmente, mencionas que estás tratando de hacer que el sistema sea extensible para ayudar con los cambios rápidos, pero ¿cómo? ¿Estás separando la lógica de presentación de la lógica de negocios? ¿Está encapsulando la lógica de negocios en objetos, particionados apropiadamente para minimizar las dependencias y el acoplamiento? Todas estas cosas son difíciles de hacer y pueden tomar tiempo para planificar y construir.

Por cierto, no estás solo. Muchas tiendas (tal vez todas) tienen estos desafíos.

Answer 2

No dejes que impongan la fecha límite en primer lugar.

Tienes 2 opciones

• El PM le brinda una lista de características y usted les dice cuándo estará listo.
• El PM le da una lista de características y una fecha límite. Luego les dices qué características implementarás en el tiempo dado.

Si el PM es su gerente o tiene la autoridad para imponer fechas límite + número de funciones, entonces estaría buscando un nuevo trabajo. careers.stackoverflow.com

Si el PM no es su gerente, entonces necesita tener a su gerente a bordo y hacer que le den sus opciones a la PM de la lista anterior.

Answer 3

Esto es realmente difícil de manejar. El verdadero problema aquí es que en realidad no tienes un proceso.

La respuesta realmente depende de la situación política en su organización y de la cantidad de energía que tenga para impulsar el cambio.

En el pasado, he intentado introducir un cambio de proceso en varias organizaciones y siempre ha sido una lucha. Sin embargo, es posible.

Me gustaría ver algunas metodologías para administrar el desarrollo de software. Yo uso y recomiendo Scrum, por ejemplo.

En una situación con cambios rápidos, trabajar en iteraciones cortas que tienen objetivos claramente responsables puede ser realmente útil. Probablemente deba defender y administrar su Project Manager, pero suena como el actual " proceso " claramente no está funcionando, por lo que vender un nuevo proceso en realidad se vuelve más fácil: tiene un caso de negocio sólido para mejorar.

Un proceso sólido lo ayudará a " retroceder " en los requisitos cambiantes. El cambio reaccionario rápido es a menudo un síntoma de problemas más amplios en la dirección y la estrategia de la organización y es de interés para todos solucionar este problema dentro de la organización.

Answer 4

Este es uno de los principales desafíos que enfrentará como desarrollador.

Una buena técnica que he usado en el pasado es hacer preguntas. Cuando obtenga las especificaciones, encuentre algo en ellas que necesite una aclaración de los usuarios finales. Esto siempre ralentiza las cosas y aumenta la posibilidad en la mente de los gerentes de los riesgos.

Asegúrese de que su gerente de proyecto conoce los riesgos involucrados en la implementación de cambios tardíos para un proyecto.

Answer 5

¿Usted y su equipo han tratado de discutir esto con el gerente? Eso es lo primero que debes hacer.

Es posible que no tenga mucha experiencia con el proceso de desarrollo, por lo tanto, los plazos ajustados y los principales cambios muy tardíos. He visto casos de este tipo, personas que no pudieron desarrollarse pero pensaron que podrían hacer un mejor trabajo en PM.
De estar sentado y hablar con él podría salir dos cosas, dependiendo de su personalidad / profesionalidad. Aceptaría tus puntos e intentaría cambiar la situación para el futuro o será un chico inteligente y no se rendirá en lo más mínimo, en cuyo caso vale la pena escalar la situación a un nivel superior. No creo que haya ninguna empresa que acepte felizmente la pérdida de desarrolladores.

Alternativamente, su manager podría estar sobre él. Y eso es un problema.

Si nada funciona, como ya se sugirió, cambiar el trabajo es algo que se debe hacer.