Nuevo trabajo y plazo imposible [cerrado]

¿Qué pasa si después de un mes de unirse, su gerente le dice que lo ayude a lanzar un proyecto que parece casi imposible sin la opción de extenderlo?

Fondo:

Me uní a un nuevo trabajo en el que el único desarrollador trabaja en un proyecto y afirma que está casi terminado. Es su primer trabajo y su estilo de programación y codificación no cumple con los estándares de la industria y no está listo para la producción.

Escenario actual:

Ni mi colega ni la gerencia quieren que limpie el código base porque retrasará la fecha de lanzamiento, por lo que esperan que continúe mi trabajo en el código base de mierda.

También me dijeron que la financiación del proyecto ya ha terminado y que tienen que terminar el proyecto lo antes posible.

Tengo muchas ganas de hacerlo bien, pero este es mi primer trabajo en el que la gerencia está en contra de una revisión o reescritura del código. Estoy considerando buscar otro puesto, pero quiero explorar otras opciones antes de irme.

Editado, no hay necesidad de hablar mal de tu colega.
@FrankFYC "no según los estándares de la industria" suena muy elegante, pero créanme, la realidad es horrible y no estoy feliz de decir eso, quiero decir que no puedes entender ni siquiera los nombres de las variables.
¿Tu colega usa SE?
@FrankFYC no lo creo, incluso si usa, no creo que sepa que es él porque este tipo de historia es común :)
Incluir los insultos te hace quedar mal a ti, no a ellos... Solo para tu información. Mostrar respeto no se trata de la persona que estás respetando, se trata de la persona que eres.
"Y si...?" no es exactamente un objetivo que podamos abordar. Si desea dejar el trabajo, puede hacerlo, pero no podemos tomar esa decisión por usted. ¿Le ha dicho a su gerente que cree que la fecha límite sería imposible de cumplir? Aunque los problemas sobre la fecha límite curiosamente están ausentes de su pregunta, parece que está insistiendo en hacer una reescritura, lo que presumiblemente llevará mucho más tiempo que simplemente hacer lo que se le dice. El 99,99% de las empresas estarían en contra de que un nuevo empleado comience a hacer una reescritura, especialmente con una fecha límite inminente.
Esta es una compensación realmente clásica al trabajar en el código de otra persona. Desafortunadamente, muchos desarrolladores intentarán reescribir el código existente en lugar de tratar de comprender la base del código, pero de hecho podría tratarse de un software mal diseñado. Puede plantear sus inquietudes a su gerencia, especialmente sobre por qué el software está mal diseñado (¿No escalará el rendimiento? ¿Será difícil agregar nuevas funciones?) y depende de la gerencia decidir qué hacer a continuación.
@Dukeling, ¿parece que está bien que el 99 % de las empresas no revisen el código? y ¿está bien que el 99% de las empresas dejen manejar un gran proyecto por parte de algunos más nuevos? Sé que no estás en la misma situación, pero trata de evitar declaraciones tan genéricas que tienen poco o ningún sentido en algunos casos. Además, tenga en cuenta que OP también debe tener algo de experiencia, no es como si hiciera preguntas aquí, entonces necesita ser un tonto o algo así. En todo tu comentario huelo que no crees en la situación actual, está bien pero no generalices.
@OnetimeOnly No estoy en contra de las reescrituras a gran escala (de hecho, todo lo contrario), pero son difíciles de vender desde una perspectiva comercial: eso es mucho tiempo de desarrollador gastado en nada que genere dinero para la empresa (la idea es por supuesto que es beneficioso a largo plazo, pero esa compensación es difícil de medir de antemano). Si solo ha estado allí durante un mes, no es razonable que confíen en que usted comprende esta compensación (pero es posible que pueda hacer que lo entiendan). No tengo opinión sobre pedir a los empleados nuevos/recién graduados que trabajen en grandes proyectos, aparte de "sucede".

Respuestas (4)

Ni mi colega ni la gerencia quieren que limpie la base de código porque retrasará la fecha de lanzamiento, por lo que esperan que continúe mi trabajo en la base de código de mierda.

Por lo tanto, debe continuar su trabajo en el código base de mierda, a menos que pueda encontrar alguna forma de limpiar el código base y aún así cumplir con la fecha de lanzamiento. La forma en que escribiste tu pregunta hace que parezca poco probable.

También me dijeron que la financiación del proyecto ya ha terminado y que tienen que terminar el proyecto lo antes posible.

Por lo tanto, debe esforzarse por concluir el proyecto lo antes posible. Asegúrese de comprender lo que su jefe quiere decir con "lo antes posible".

Realmente quiero hacerlo bien, pero este es mi primer trabajo donde todos están en contra. Tengo muchas ganas de huir, pero no quiero cambiar con demasiada frecuencia. ¿Qué se puede hacer en tales situaciones?

Bueno, podrías huir, pero esa no es una gran solución.

Puede dar su mejor estimación para la finalización y solicitar una extensión. Pero parece que lo has hecho y te han rechazado.

Podría pedir más ayuda, si cree que eso traería la fecha de finalización. (A veces, agregar personas a un proyecto tarde empeora las cosas).

Puede preguntar si se pueden recortar las características o si se puede revisar el proyecto de alguna otra manera para lograr la fecha de lanzamiento deseada.

Podría preguntar si el proyecto puede simplemente cancelarse. Supongo que eso no es factible.

Cuando me enfrento a una fecha límite imposible, le digo a mi jefe que no creo que la fecha límite sea alcanzable. También le hago saber a mi jefe que haré lo mejor que pueda con lo que me den. Actualizo a mi jefe con mis estimaciones a medida que avanza el proyecto.

Luego dejo que mi jefe tome la decisión de seguir adelante con el proyecto, agregarle recursos, revisarlo. cancelarlo, o extender la fecha.

Si la decisión es seguir adelante sin una extensión de fecha, simplemente hago lo mejor que puedo. Al final, eso es todo lo que cualquiera puede esperar razonablemente.

Estoy feliz de trabajar en la base de código de mierda porque tengo que hacer menos trabajo y estar con "flujo", pero el problema es que el proyecto ahora también tiene mi nombre y si algo sucede, también sería culpa mía. También estoy en período de prueba y un proyecto fallido puede reflejarse negativamente en mí. Dije fallido porque la forma en que está escrito el código seguramente fallaría.
Entiendo que todo llega al entendimiento del jefe, él es el que sabe la verdad y debe ver que tengo muchas ganas de hacer el bien pero en mal momento. Solo tenía miedo de que no afectara mi período de prueba.

Fuiste asignado al equipo, así que sé un miembro del equipo.

Lo mejor que puede hacer es simplemente tomar las tareas de ellos, concentrarse en su tarea, completar sus tareas de manera oportuna y eficiente, y pasar a la siguiente tarea.

Eres el chico nuevo, no obtendrás el proyecto bonito porque aún no te has probado a ti mismo. Este proyecto puede fallar y usted aún puede tener éxito. Lo haces poniendo tu mejor esfuerzo en hacerlo. Renuncie a cualquier esperanza de que el desastre en el que está trabajando sea un buen proyecto, solo trabaje para apoyar al desarrollador original.

En ningún momento debe menospreciar o criticar a su compañero de trabajo por el desorden que tiene. Es posible que hayan heredado este lío y estén haciendo todo lo posible para que funcione. E incluso si no eres el chico nuevo. No necesitan que entres y hagas que el desarrollador original se sienta mal por lo que hace o ha hecho. Eso no va a ser útil para el negocio.

Si en algún momento en el futuro se le pregunta sobre el proyecto y el código base, está bien ofrecer una crítica objetiva de opciones o problemas específicos, pero no está bien dar un genérico * su estilo de programación y codificación es patético y créanme si digo patético porque tengo suficiente experiencia* - Sea específico acerca de las opciones de programación que fueron problemáticas y cómo las soluciones que habría elegido habrían resuelto los problemas.

Pero por ahora haz tu mejor esfuerzo para contribuir al proyecto como un miembro del equipo siguiendo el ejemplo del desarrollador existente. A veces, ser un buen miembro del equipo significa dejar de lado el hecho de ser un buen programador y simplemente hacer lo que se le dice y cómo se le dice que lo haga.

Permítales tomar el crédito y la culpa por impulsar el proyecto mientras hace todo lo que está a su alcance para ser un gran miembro del equipo. Ponte a prueba en este proyecto y espera uno mejor la próxima vez. Si esta es la última vez en su carrera que le entregan un sándwich de mierda y le dicen que debe saber a costillar la próxima semana, será verdaderamente bendecido.

"Lo mejor que puede hacer es simplemente tomar las tareas de ellos, concentrarse en su tarea, completar sus tareas de manera oportuna y eficiente, y pasar a la siguiente tarea". ¿cómo? la última vez que traté de hacer lo mejor que pude, el único comentario que recibí fue "Mira, estás retrasando las cosas, no es necesario refactorizarlas". Me dijiste que fuera un miembro del equipo, pero quiero ser un buen miembro del equipo. Creo que no leíste que he pasado una gran cantidad de tiempo aprendiendo el arte de la buena programación.
@OnetimeOnly: a veces, ser un buen miembro del equipo significa dejar de ser un buen programador y simplemente hacer lo que se le dice y cómo se le dice que lo haga. (He editado esto en la respuesta por cierto) - Simplemente escriba el código que se le indica que escriba para hacer lo que se le indica que haga. No luche contra el sistema ni espere una refactorización, solo haga el trabajo y deje que el proyecto fracase sobre los hombros de su equipo. Eso no quiere decir que no ofrezcas sugerencias, simplemente no luches para cambiar solo porque está mal.
Lo siento si olvidé decírtelo, no hay ninguna pista. Estaba este tipo y ahora se supone que yo soy el protagonista, ya que tengo más experiencia, suena divertido pero es cierto. Entonces, nadie me dice que escriba código, solo quedan un par de destacados y eso se completó con mi ayuda.
@OnetimeOnly - Él es el líder ahora... déjalo ser el líder, oblígalo a ser el líder y sigue su dirección. Este es el mejor curso de acción para usted. Toma ese sándwich de mierda y atrágalo con una sonrisa en tu rostro y finge que fue maravilloso. Nadie recordará tu parte en este proyecto fallido en un año. Pero ser un buen y positivo miembro del equipo podría conseguirte una invitación a un mejor proyecto en el futuro.
Sí, suenas bien y eso también lo pensé, aunque se siente un poco vergonzoso, pero el lado bueno es que nadie me conoce aquí. Veamos qué hago después del lanzamiento porque no creo que esté aquí por más tiempo ahora.
@OnetimeOnly: es su elección, pero si se escapa de un trabajo cada vez que lo ponen en un proyecto de sándwich de mierda, se escapará mucho.

Sea objetivo y realista, tenga en cuenta los hechos del proyecto y preséntelo de una manera que no queme puentes.

Ante un objeto inamovible, identificar el hecho de que no cambia y ofrecer soluciones. Si no puede, sea directo y diga que no es realista.

Lo que no se puede cambiar:

  • Fondos
  • Extensión
  • Revisión de código

Dicho esto, mi sugerencia es volver a la mesa de dibujo e identificar qué funciones deben descartarse proverbialmente para que pueda salvar lo que queda para cumplir con la fecha límite. Con la idea de que es mejor tener un código bien pulido para algunas funciones que un código lleno de errores que cubre todas las funciones solicitadas. Una vez que esté envuelto con una pajarita, indique cómo, con más fondos, puede abordar las características que faltan.

Su colega, aunque sin experiencia, no está actuando maliciosamente. Este es su primer trabajo y fue asignado a un equipo de desarrollo de un solo hombre sin un mentor. Parece que ahora puede desempeñar ese papel. Si sigue adelante regañando a él/ella por sus errores, ahora está equivocado. Eres consciente de la razón de la mala calidad, pero eliges actuar con malicia. Esta es una oportunidad de crecimiento para ambos, usted como líder y él/ella como mejor programador.

Lo intenté después de un par de semanas de unirme, pero el problema es que mi colega es nuevo y es muy difícil persuadirlo, a veces no puedo comunicarme con él porque tiene poco o ningún conocimiento. Siempre dice que no hay nada malo en que podamos hacer esto o aquello que no tiene sentido.
No tienes que persuadirlo. Tienes que persuadir al director del proyecto. "Consulté con X sobre los problemas A, B y C. X respondió, a, b y c. No estaría de acuerdo en base a D, E y F. Le traigo esto para que tome una decisión". Una vez que se ha tomado una decisión, está fuera de tus manos.
Hoy estaba pensando en tomar las copias impresas de los códigos antes y después de la refactorización y mostrarle el cambio drástico en legibilidad y complejidad, pero el comentario del gerente sobre la financiación me está frenando.
La financiación está fuera de su control. Usted presenta su opinión profesional y deja la toma de decisiones al gerente. Si tu jefe decide en contra de lo que recomiendas, no te lo tomes como algo personal, haz lo que puedas con lo que te han dado. Este proyecto no será el fin del mundo.

No te preocupes por eso, es el gobierno. Los proyectos fallidos son parte del curso. Muchos departamentos tienen que ver con obtener financiación y todos sus recursos se destinan a eso, el proyecto real es menos importante o no habrían tenido a su predecesor en primer lugar.

Ya están enfocados en la siguiente fuente de financiamiento.

Así que haz lo que puedas.

Nuevo trabajo y plazo imposible [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v