¿Cómo debo abordar un 'uno a uno' con el gerente de mi jefe cuando hay problemas con el proyecto?

Sugeriría que, si tiene tiempo antes de la "gran reunión":

1) Haga una evaluación exhaustiva (o al menos no demasiado superficial) sobre el código, para identificar correctamente los bloques que "huelen mal" en su código, identifique la razón por la cual es malo y cómo se puede "arreglar" (o por qué debe arreglarse). Simplemente decirle a tu jefe "es malo, apesta" es un gran NO-NO, pero también es malo decir "es malo" y no poder afirmar una buena razón por la que es malo.

2) Diríjase a su jefe (jefe directo) y aborde tales inquietudes sobre el código. Sería una grave violación de la confianza si pasa por encima de él sin su conocimiento, y puede tomarse mal si no se habla primero con él, al menos para dar un "aviso" sobre el problema. Si se trata de un desarrollo de equipo, y usted fue el primero en darse cuenta, debe mencionarlo en una reunión de grupo, pero no antes de hablar con su jefe.

3) Si dicha reunión sale mal, puede dirigirse al jefe de su jefe e informarle sobre los problemas, pero hágalo de una manera que aborde el problema en cuestión, sin desviarse hacia un "juego de culpas", solo proporcione sus puntos de vista sobre el código y, si se le solicita, prepare un pequeño esquema de "¿cómo lo solucionaría?".

Cuando se unió o se hizo cargo de este proyecto, debería haber tenido esta discusión con el desarrollador anterior (su jefe). Si solo ha tenido un paso inicial en este marco, por supuesto que hay muchas refactorizaciones por hacer. Esto probablemente no va a ser una gran sorpresa.

Tienes la ventaja de la retrospectiva, así que no asumas que tu jefe es un pésimo programador debido al estado actual del código. Nadie escribe un código perfecto o cualquier otra cosa en el primer borrador. Te contrataron para entrar y llevar las cosas al siguiente nivel. Si se le da suficiente tiempo, su jefe probablemente podría arreglar las cosas.

Por otro lado, si tu jefe te sugiere que ignores el código porque "funciona lo suficientemente bien", podrías tener un problema. Esto podría dificultar su trabajo cuando intente depurar y agregar nuevas funciones (¿Pruebas unitarias?). No a todos les gustan las iteraciones, el código limpio o el nuevo cliché: la elegancia.

Averigüe la puntuación antes de intentar elegir al ganador.

Hoy se publicó una respuesta extremadamente oportuna en un blog de LinkedIn escrito por Steve Sinofsky, quien fue presidente de la división de Windows en Microsoft hasta hace unos meses, titulado Benefiting from skip-level 1:1s: tips and pitfalls . Alrededor de la mitad es para los gerentes que conducen la reunión. No se salte esto: léalo para que pueda tener una idea de cuáles podrían ser los objetivos del gerente de su gerente al hacer este 1:1 con usted.

La otra mitad de la publicación del blog es para usted como colaborador individual que asistirá a esta reunión, y contiene mucha sabiduría, comenzando con esto:

Un salto de nivel 1:1 es un buen momento para ofrecer sus perspectivas sobre lo que va bien y lo que no. Hay una línea muy fina entre ofrecer todas las noticias potencialmente malas y sonar como si estuvieras estableciendo expectativas, y pulir todas las noticias potencialmente buenas y sonar como si estuvieras presumiendo. Tienes que ser el juez.

Creo que esto es cierto para cualquier reunión. Tienes que ser capaz de identificar lo que va bien y lo que no va bien. Por ejemplo, podría decir, "es bueno trabajar para un gerente que conoce el código tan bien como mi gerente", o "Creo que hemos hecho un buen trabajo al terminar la primera versión del marco, y yo espero que tengamos tiempo para regresar y asegurarnos de que la arquitectura del código resista [algo importante: escalabilidad, mayores requisitos de rendimiento, etc., elija un área de preocupación de los olores de su código]".

Sinofsky también destaca que nunca se debe ser noticia en este tipo de reuniones. Esta reunión nunca es el primer lugar donde debe plantear una inquietud. Cierra con esto:

Sobre todo, aproveche al máximo el tiempo para asegurarse de que su gerente de nivel superior esté familiarizado con usted y su trabajo de una manera neutral y constructiva.

Aconsejaría una gran dosis de tacto y honestidad aquí, y eso debe comenzar con una conversación con su jefe sobre si se le permite modificar el marco existente. De nuevo, ¡permítanme decir que haga esto con tacto! Aquí hay algunas ideas que podrían funcionar:

• No use muchos términos negativos cuando se refiera al trabajo existente.
• Enmarque todas sus sugerencias como cambios que podrían facilitarle las actualizaciones o el mantenimiento en el futuro o que podrían facilitar que otros programadores nuevos retomen el proyecto más adelante. Serías el experto aquí ya que eres el primero en tener que hacer eso.
• Deje en claro que está analizando estas ideas para su aprobación y para obtener su opinión experta.

Asegúrese de solicitar algún tipo de proyecto oficial para que no parezca que está perdiendo el tiempo o que está progresando lentamente en sus otros proyectos.

Reunión con el jefe de su jefe: nuevamente tacto y honestidad.

Parte de la descripción no oficial del trabajo de un empleado es hacer que su jefe se vea bien. Debe hacer todo lo posible para hacer esto si honestamente puede hacerlo, pero el jefe de su jefe necesita la verdad para tomar las mejores decisiones. Asegúrese de que cualquier cosa negativa que pueda decir sobre el código o el proyecto se haya planteado primero a su jefe e informe en función de la decisión de su jefe. Nuevamente algunas cosas que pueden ser útiles:

• Trate de determinar el objetivo subyacente de la reunión lo antes posible, si el jefe de su jefe está buscando suciedad sobre su jefe, debe decidir si realmente quiere ser la fuente de eso y actuar en consecuencia.
• Si se trata de una reunión para conocerte, entonces no te detengas en estas cosas y trata de hacer una buena conexión personal.
• Trate de hacer que su jefe se vea tan bien como honestamente pueda, pero asegúrese de no subestimarse para hacerlo.
• Trate de actuar como si su jefe estuviera en la habitación de al lado escuchando.

Se ha pasado por alto la cadena de mando, que es algo que un gerente puede hacer mucho más fácilmente que un empleado, lo que sugiero es que actúe (lo mejor que pueda) como si no lo hubiera hecho y ponga a su jefe en contacto antes. (y probablemente después) de la reunión con el jefe de tu jefe.