Trabajar con un código mal escrito, no puede cumplir con un plazo estricto en el período de prueba [duplicado]

Me uní a mi empresa actual recientemente y estoy en período de prueba. El código que he heredado es frágil y tiene problemas de rendimiento. Todavía no estoy familiarizado con el sistema, pero mi gerente me dijo que refactorizara este código, lo documentara y estableciera una fecha límite para hacer el primer lanzamiento a fines del próximo mes.

Empecé a trabajar en este proyecto la semana pasada. Para una pequeña refactorización en un componente simple, tuve que hacer muchos cambios en varios lugares. Me temo que si hago una refactorización importante, terminaría codificando el proyecto desde cero, y seguramente perderé la fecha límite. Si evito hacer esto, el proyecto está condenado al fracaso ya que el código puede fallar de varias maneras.

Mi gerente me hizo firmar un documento que dice que debo completar todas las tareas. Estando nervioso y confundido, firmé el documento. Ahora temo que si no puedo completar las tareas, toda la culpa será mía. El proyecto ya ha fallado tres veces, y mi gerente se toma muy en serio esta vez para que funcione.

¿Cómo debo comunicarle profesionalmente a mi gerente que los problemas con el código pueden hacer que no cumpla con la fecha límite?

No habla en serio o no lo estaría haciendo así.
@john doe He editado la descripción de su pregunta para incluir una pregunta que infiero que es su objetivo real. Su pregunta original de "¿qué debo hacer?" es demasiado abierto y no es adecuado para este sitio. Si no está de acuerdo con esto, hágamelo saber o edite la pregunta para incluir una pregunta prácticamente respondible con la que podamos intentar ayudar. El duplicado vinculado probablemente también sea útil en su situación.
No creo que el duplicado sea un duplicado real. Esta es una fecha límite de la gerencia frente a una fecha límite autodeterminada, que por sí sola hace una gran diferencia.
@Erik Ese es un punto excelente, parece que lo pasé por alto. Sin embargo, no está claro si se consultó al OP antes de que el gerente estableciera la fecha límite. También existe la posibilidad de falta de comunicación aquí. El hecho de que el gerente diga: "Nos gustaría tener el primer lanzamiento para el próximo mes" no implica necesariamente que sea una fecha límite "difícil", solo que la gerencia lo desea. Esa parece ser una razón más por la que esto no es un duplicado, me retractaré de mi voto duplicado.
Recomendaría documentar las partes rotas, los desafíos también. Es necesario tener en cuenta el tiempo que pasa. Definitivamente necesita invertir tiempo personal para obtener más progreso si quiere mostrar determinación. Por otro lado, esto parece una habilidad de liderazgo débil y una microgestión de arriba hacia abajo, con el tiempo, con problemas crecientes, según mi experiencia, empeora. Use ese lugar como un trampolín para un mejor trabajo y déjelo en su espejo retrovisor lo antes posible.
@sdkks Tiene algunos buenos puntos, es posible que desee considerar desarrollarlo en una respuesta completa.
No está claro qué problema está tratando de resolver. ¿El código funciona correctamente pero tiene problemas de rendimiento? ¿Por qué la refactorización es la solución? ¿El código tiene errores y es difícil de mantener? ¿Es posible corregir los errores sin refactorizar TODO como primer paso? Tampoco entiendo cuál fue el punto de firmar un documento ya que está en período de prueba y su gerente decidiría si continuaría de todos modos. Creo que tu publicación omite información importante.
@smith Creo que no leyó la pregunta claramente, hay un novato que no sabe qué es un SRP o DRY y ha escrito un sistema completo que se supone que se lanzará el próximo mes. Firmar el documento no fue mi elección, fue la elección de mi gerente.
@johndoe: el código tiene problemas de rendimiento, supongo que algunos errores y debe publicarse rápidamente. Mis preguntas para usted son 1) ¿puede solucionar los problemas de rendimiento y los errores y hacer que funcione correctamente sin refactorizar todo dentro del acuerdo? 2) ¿Tiene alguna razón para no presentarle eso a su gerente como una solución? Me refiero a que su gerente lo quiere fuera de la puerta. Seguro que refactorizar no es lo que más le importa
Por cierto, me acabo de encontrar con esto. Seguridad psicológica en el trabajo, algunos puntos positivos: blog.intercom.com/psychological-safety
No te comes un sándwich de un pie de largo, todo de una vez, ocúpate de los problemas que puedes resolver antes de una fecha límite. Iterar desde ese punto
Las personas serias y bien intencionadas a menudo cometen el error de comprometerse con proyectos con plazos poco realistas. Sienten la urgencia de la solicitud y luego intentan un esfuerzo heroico para cumplir con la fecha límite, yendo al proyecto sin tener idea de los problemas y obstáculos que van a encontrar. Tales tramas serían un buen forraje para un programa de juegos en la televisión, pero conducen al fracaso y la decepción en los proyectos reales. Los gerentes que exigen y aceptan tales compromisos también son culpables y merecen algo de dolor, pero lamentablemente, los trabajadores duros como el OP son los que realmente salen lastimados. Tómalo como una experiencia de aprendizaje.
¿Qué pasa si el doctor es una artimaña para que trabajes fuera de horario?

Respuestas (2)

Los gerentes pueden decir todo lo que quieran, generalmente no son muy buenos para calcular los plazos. Las únicas personas que realmente pueden decir cuánto trabajo es algo son las personas que saben cómo hacerlo y que están lo suficientemente familiarizadas con él para hacer las estimaciones.

Lo que querrá hacer es recopilar toda la información que tiene sobre el proyecto y hacer sus propias estimaciones sobre qué tan grande es este proyecto. Ya has hecho parte del trabajo, así que asegúrate de incluir eso, así como tus peores predicciones sobre cuán desordenado es el código y cuánto tendrás que reescribir.

Luego llame a una reunión con su gerente, muéstrele sus datos y sus predicciones sobre qué tan grande es realmente este proyecto y pregúntele qué quiere que se haga. Dígales cuánto puede hacer antes de la fecha límite, dígales cuánto tiempo le tomaría hacer todo y bríndeles algunas sugerencias sobre cómo se podría hacer mejor el trabajo (por ejemplo, hacer que más personas trabajen en él, omitir ciertos segmentos). que son muy difíciles pero no ayudan mucho, comprar alguna tecnología nueva que solucione parte del problema, lo que se te ocurra)

Al final, desea presentarles los hechos e intentar trabajar con el gerente para llegar a algo que sea útil para el negocio y realista.

Si su gerente no quiere escucharlo y simplemente lo obliga a cumplir con la fecha límite para la que se inscribió, entonces está negando la realidad. Y no importa cuánto quieras negar la realidad, al final va a ganar. Si cree que hacer todo es completamente irrazonable y su gerente insiste en que tiene que hacerlo, entonces lo único realista que le queda por hacer es dedicar su tiempo a buscar un nuevo trabajo, porque no puede complacer a alguien que ignora el hechos.

(Además, si su gerente le pregunta por qué firmó el documento, sea honesto. Dígale que estaba nervioso y que no lo pensó bien, y que se arrepiente de haberlo firmado porque ahora siente que no era factible. Es solo un documento. Las personas sensatas entienden que escribirlo no lo hace real y que tendrá que cambiar el documento si su objetivo es hacer el trabajo).

Todos buenos consejos. Además, por su propia cordura y seguridad, asegúrese de escribir pruebas a medida que avanza, o de lo contrario, el refactor puede terminar rompiendo cosas de formas inesperadas a pesar de sus mejores esfuerzos.
@Paul, en teoría, suena bien, pero escribir pruebas para un proyecto casi terminado parece una idea suicida a menos que tenga tiempo para volver a escribir el proyecto desde cero.
@johnDoe me refiero a escribir una prueba para todo lo que vaya a cambiar antes de cambiarlo. Yo diría que no hacer eso es un suicidio.
@Erik: el tipo de gerente que describe seguramente no tiene interés en una refactorización per se. Seguramente solo quiere que el producto salga por la puerta. Creo que falta algo en el post.
@smith es el trabajo de los ingenieros administrar la calidad del código, no el de los gerentes. Si el ingeniero no puede encontrar una manera de hacer que el código funcione de manera confiable y eficiente sin refactorizar, tendrá que explicárselo al gerente.
Leí la publicación que decía claramente "refactorizar y documentar".

Mi gerente me hizo firmar un documento que dice que debo completar todas las tareas. Estando nervioso y confundido, firmé el documento. Ahora temo que si no puedo completar las tareas, toda la culpa será mía. El proyecto ya ha fallado tres veces, y mi gerente se toma muy en serio esta vez para que funcione.

¿Cómo debo comunicarle profesionalmente a mi gerente que los problemas con el código pueden hacer que no cumpla con la fecha límite?

Dígale a su gerente ahora que su examen del código lo lleva a creer que no podrá cumplir con la fecha límite y por qué, pero que hará lo mejor que pueda de todos modos. Además, dígales ahora cuál será su enfoque y cuánto tiempo cree que llevará completar la tarea, y que actualizará su estimación a medida que aprenda más.

Es una tontería que su gerente crea que un documento firmado marcará la diferencia. Pero le debe a la compañía sus mejores esfuerzos y su mejor estimación. Y quizás su gerente entre en razón y acepte la realidad, quizás no.

Tenga en cuenta que al final puede no importar. Puede perder la fecha límite en el documento firmado y su empleador puede optar por dejarlo ir y comenzar de nuevo con otra nueva contratación. Pero deberías dar lo mejor de ti de todos modos.

Parece que el gerente no estaba interesado en una estimación. Y no estoy seguro de lo que está pensando este administrador, pero para dar una estimación razonable de la tarea "refactorizar y documentar este código", primero debe pasar una buena cantidad de tiempo para ver cuál es la calidad del código.
Trabajar con un código mal escrito, no puede cumplir con un plazo estricto en el período de prueba [duplicado]
RespuestasAquíPolítica de privacidad1y, 0v