¿Cómo proporcionar retroalimentación constructiva sobre un colega al gerente?

Fondo :

Trabajo como ingeniero senior en un proyecto de software (~3 años). Recientemente, se agregó un nuevo ingeniero para trabajar conmigo durante un par de meses para ayudar a resolver algunos de los problemas (corrección de errores) y mejorar la herramienta. Esta adición se debió a la carga de trabajo y al apuro del horario.

Si bien estaba feliz de capacitarlo y ayudarlo a ponerse al día, veo que se apresura a hacer cosas para terminar sus tareas rápidamente a expensas de comprometer la calidad de nuestro trabajo. Dado el estado de nuestro proyecto, prefiero soluciones permanentes a soluciones provisionales, código bueno, formateado y refactorizado a parches de código temporales, ya que tendré que lidiar con la deuda técnica incurrida más adelante. Aunque es bueno en la resolución de problemas, creo que no se dedica suficiente tiempo a aprender las funciones de la herramienta (nivel alto) y comprender el código existente.

Reviso informalmente sus cambios de código y, en la mayoría de los casos, descubro que requieren más esfuerzo u optimización antes de que sus tareas puedan considerarse completas. (los comentarios de revisión, el retrabajo realizado, etc., no están documentados, por lo tanto, mis clientes potenciales no son conscientes del trabajo adicional que tengo que realizar para cerrar sus tareas).

Pregunta :

Mi gerente parece estar muy complacido por el hecho de que está completando más tareas a pesar de ser nuevo en el equipo, pero creo que la calidad del código y no la cantidad de tareas es una métrica válida para medir el trabajo de un desarrollador. Estoy tratando de entrenarlo en el código de construcción correctamente. Le he pedido que no se apresure y que mejore la calidad de su trabajo, pero no veo mucha mejoría. ¿Cómo puedo comunicar esto a mi gerencia como una retroalimentación sin sonar como 'un imbécil que está celoso del desempeño del nuevo miembro del equipo'?

EDITAR : Él no es más rápido que yo. Como es nuevo (fase de aprendizaje), se le asignan tareas más simples mientras yo trabajo en tareas críticas y complejas. Así que no es el caso en el que me siento amenazado. Pero me preocupa que no esté usando este período de tiempo de manera efectiva para aprender cosas, ya que parece concentrado en afirmar que las completó. Esto se convertiría en un problema para mí cuando le asignen tareas más grandes o complejas pronto, ya que no podría acomodar ayudarlo con sus tareas en mi horario.

Respuestas (3)

Desafortunadamente, este es un problema de representación del trabajo. La mejor manera de obtener un trabajo de calidad inferior es anunciar que el puesto es un recurso provisional para hacer frente a una situación temporal. Para empezar, aclaro que la etapa de emergencia ha terminado. Todavía va a estar trabajando en algunos problemas en el equipo, y eso les da a todos la oportunidad de comenzar a seguir algunas de las mejores prácticas estándar de aquí en adelante, para que la situación de emergencia no vuelva a surgir. Esto hace mucho trabajo: reconoce sus contribuciones y deja en claro que el trabajo fue deficiente, al tiempo que le permite salvar la cara por tener una razón perfectamente válida para hacer un trabajo de mala calidad. También atribuye la culpa de la emergencia al trabajo de mala calidad que no hizo. Todo esto establecerá que en el futuro las cosas son diferentes y le permitirán reiniciar. Más importante,

Si puedes hacer esto sin hablar con su jefe, genial. Si necesita traerlo al circuito, le daría la misma narrativa al jefe.

No reaccione de forma exagerada ante la percepción de que está siendo devaluado debido a su desempeño. Entonces le estás dando crédito a la idea. Es normal en todas las partes de la organización tener estrellas de rock que pueden hacer cosas maravillosas hasta que todo el proyecto se derrumba debido a la calidad del trabajo. Asuma el rol de liderazgo aquí y es probable que todos simplemente le dejen tenerlo.

Aquí está tu problema:

los comentarios de revisión, el retrabajo realizado, etc., no están documentados, por lo tanto, mis clientes potenciales no son conscientes del trabajo adicional que tengo que realizar para cerrar sus tareas

Arregla eso. Probablemente no pensaste que iba a ser algo continuo. Si está usando elementos de trabajo, y él verifica el elemento de trabajo, haga sus comprobaciones contra el mismo . Considere usar una herramienta de revisión de código que cree algún tipo de artefacto de lo que debe hacerse (un documento de texto sin formato en el que escribe notas, si nada más. O si realiza los cambios, una diferencia que muestra lo que tenía que hacer). ) Si puede, en lugar de solucionar los problemas, asígnele la tarea de solucionarlos. (Probablemente ese es el único enfoque que podría lograr que lo haga bien la primera vez).

Hacer un seguimiento de la revisión y la limpieza que realiza le dará la oportunidad de ver si hay alguna mejora con el tiempo. Tal vez al principio tuvo que hacer cambios al 100% de su trabajo "terminado". Pero ahora es el 75%. Si bien eso es frustrante, es una mejora.

Entonces si quieres acudir a tu jefe, tienes datos. "Tengo que editar más del 80 % de su trabajo para limpiar la deuda técnica; no me refiero a formatear o comentar, me refiero a no validar los parámetros que se pasan, no manejar errores, no considerar la posibilidad de que alguien cancele un transacción, y así sucesivamente. Fue 100% al principio y he discutido cada uno de mis cambios con él y le pedí que hiciera un trabajo más completo, pero solo he visto esta mejora marginal". Luego pasas tu resumen de lo que has tenido que limpiar. Luego haces una pausa y dices "Sé que, en la superficie, parece que es súper rápido en comparación conmigo, pero eso se debe a que supera la parte fácil haciendo un trabajo descuidado, además de que estoy dedicando tiempo a arreglar todo esto. Como dije, yo

Aspectos importantes de este enfoque:

  • está respaldado por datos
  • se trata de ti : "Tengo que arreglar a, b y c la mayoría de las veces que dice que una tarea está lista"
  • es fáctico: no diga "Todos" si es "La mayoría"
  • reconoce explícitamente que el chico nuevo se ve más rápido que tú y explica por qué eso no es cierto
  • le pide al jefe que haga algo específico (si el jefe no se ofrece voluntario para hacerlo)

Lo que no hace es simplemente ir al jefe y quejarse al azar sobre el chico nuevo. "No es justo" y "no es tan bueno como crees" son frases peligrosas, incluso cuando son ciertas.

Agregaría que no arregla nada usted mismo, se lo envía de vuelta para que lo arregle después de la revisión. Las personas no mejoran cuando no tienen que hacer la reparación por sí mismas. Sigue rechazando el código hasta que sea correcto. En nuestra oficina, no puede ir a control de calidad hasta que el revisor de código apruebe el código para el 100 % de nuestro código. Te sugiero que implementes lo mismo.
Esto va junto con el consejo de nunca permitir que alguien cierre un ticket de soporte si el problema vuelve a ocurrir, incluso meses después. Las personas son recompensadas, a menudo explícitamente, por cerrar tickets y eliminar elementos de una lista de tareas pendientes. No vuelva a colocar el artículo como un nuevo ticket/artículo atrasado. "Fix it" no es un elemento nuevo. Que alinee las métricas con el comportamiento y con la percepción del desempeño.

Si no tiene autoridad real sobre él, cuando se acerque al gerente, le daría sus puntos buenos y malos. Empezando por lo bueno. Es un buen solucionador de problemas, hace las cosas rápidamente.

Luego pasaría a los puntos negativos, su trabajo es un poco descuidado y no está produciendo un código de un nivel lo suficientemente alto en tal o cual área.

Este es el mejor enfoque en mi experiencia. Da una estimación sólida y veraz de cómo se pueden mejorar las cosas en lugar de una diatriba porque no está sangrando su código correctamente.