Estuve en una revisión de desempeño recientemente y el líder de mi equipo, que no es una persona técnica, estaba pasando por lo habitual: qué sientes que ha ido bien en lo que va del año, qué crees que podría haber ido mejor, etc.
Luego me tomó completamente por sorpresa que el líder de mi equipo dijo que había revisado nuestro historial de control de versiones (presumiblemente con la ayuda de un técnico del equipo) y que estaba revisando todas nuestras solicitudes de incorporación de cambios anteriores para este período de revisión de rendimiento. para ver qué comentarios habían dejado nuestros compañeros en cada una de nuestras solicitudes de incorporación de cambios. Como resultado, el líder de mi equipo dijo que en varias de mis relaciones públicas se habían identificado comentarios similares sobre correcciones/mejoras y, como resultado, estaban marcando mi desempeño durante este período como que necesitaba mejorar. Admitieron que no habían leído el código en sí, ya que no habría significado nada para ellos, pero al leer los comentarios que habían dejado mis compañeros, pudieron tomar esa decisión.
Para información, el líder de mi equipo es muy nuevo en el rol de gerente pero ha estado en el equipo por más tiempo que yo (que ha sido un par de años).
Esta es la primera vez en mi carrera que mi desempeño como desarrollador ha sido cuestionado en base a este criterio, me preguntaba si esto era un lugar común fuera de mi lugar de trabajo actual, o es una señal de alerta de que algo más puede estar pasando?
Eso depende completamente.
Si simplemente se sentaron allí y miraron los comentarios sin entenderlos, entonces ciertamente es un mal indicador y nunca he oído hablar de eso.
Si realmente entendieron los comentarios y vieron un problema recurrente específico con su código, sería un buen indicador.
Entonces, con esta "mejora" que quieren que hagas, ¿te dieron un objetivo específico sobre qué mejorar al codificar? ¿O simplemente dijeron que necesitas menos de esos comentarios?
Uno sería un buen plan, el otro sería totalmente inútil.
Cuando uno necesita construir la estimación de un empleado, debe constar de varios factores. No solo en una cosa.
Por ejemplo:
Entonces, a su pregunta: los comentarios en los PR deben ser una parte de la revisión general. ¿Quizás recibes constantemente los mismos comentarios una y otra vez, lo que provoca la frustración de tus compañeros de equipo? "Johny siempre escribe código como en los años 70 y no usa las últimas funciones"
Entonces, "sí": los comentarios de relaciones públicas pueden brindar información sobre su desempeño, PERO debe combinarse con otros parámetros.
Estoy bastante horrorizado por esto. Cuando hago comentarios técnicos sobre el trabajo de alguien, propongo mejoras que están dentro de la capacidad de corrección de la persona pertinente, y cuanto más capaces sean, más altos serán los estándares que aplicaré al revisar su trabajo.
Como gerente, no me preocuparían los comentarios que otras personas hicieran sobre su trabajo; estaría mucho más interesado en cómo responde usted a esos comentarios.
Ajusto mis comentarios para adaptarlos a la habilidad del autor del código, por lo que la sola presencia de comentarios no es un indicador de su competencia. Es un indicador de un revisor que quiere que crezcas. También hay ciertas cosas que son fáciles de olvidar para cualquiera de vez en cuando. Con suerte, el líder de su equipo lo entenderá.
Sin embargo, también puedo imaginar una conversación como la siguiente:
"¿Puedes hablarme de las habilidades técnicas de Echo Bravo?"
"Para ser honesto, me ha parecido que ha sido necesaria una cantidad excesiva de repeticiones para ver mejoras en ciertas áreas".
"¿Tienes un ejemplo? Prefiero basar las evaluaciones de desempeño en algo objetivo".
"Claro. Aquí hay algunos comentarios de solicitud de incorporación de cambios que muestran de lo que estaba hablando".
Por supuesto, también podría ser simplemente un líder de equipo no técnico que aún se encuentra en su lugar. Solo digo que no es inusual citar evidencia objetiva en una revisión de desempeño menos que favorable.
Esto es completamente ridículo y vergonzoso.
Imagine que cada parte del trabajo que realiza el líder de su equipo se revisó de acuerdo con estándares estrictos como los suyos. ¿Cuántos comentarios podrías dejar que impliquen que necesita mejorar? Solo revisa los últimos diez correos electrónicos que te envió. ¿El inglés en ellos es perfecto? ¿Sin errores de ortografía en absoluto, nada faltante, nada engañoso, nada poco claro en su comunicación? Lo dudo mucho.
Ahora, si hubiera revisado su código y dejado los comentarios... Primero, se encontrarán errores. Esa es una de las partes más importantes de una revisión de código. eso es normal A menos que trabaje en la industria aeroespacial, donde los errores son inaceptables y la gente no escribe más de 17 líneas de código al día en promedio, es normal. Hay un punto en el que encontrar errores en una revisión de código es más efectivo que tratar de escribir código sin errores (y mantiene al revisor alerta). es trabajo en equipo Su "líder de equipo" debe saber qué es el "trabajo en equipo", ¿verdad? Aparentemente no lo hace.
En segundo lugar, habrá sugerencias. Te diré "Haría XXX en lugar de YYY". Esa es una sugerencia. No tienes que tomarlo. Su código está perfectamente bien, pero lo habría hecho de otra manera. Puede tener en cuenta esa sugerencia y usarla la próxima vez, pero de ninguna manera es negativa.
Tercero, muchas personas hacen sugerencias que están fuera de la tarea que tenías que realizar. Criticarte por eso es una estupidez.
Entonces, si esto le sucediera, en base a mis revisiones de código, necesitaría una reunión individual muy seria con el líder del equipo, y si no puedo hacer que lo entienda, entonces cada revisión de código individual para usted en el el próximo año contendrá solo un comentario "Tu código es absolutamente perfecto, el mejor que he visto".
(Reenvíame sus últimos veinte correos electrónicos de él, y apuesto a que puedo abrir agujeros enormes en cada uno de ellos. Y lo que te hizo a ti sería un "necesita aprender los conceptos básicos de su trabajo antes de que pueda comenzar a mejorar" de mi parte).
Nunca he oído hablar de este específico, y tiene poco sentido, pero este es un problema bastante común cuando las personas no técnicas buscan alguna métrica en la que basar algo.
¿Es esto una especie de señal de alerta de que tal vez esté pasando algo más?
Creo que es poco probable a menos que haya otros factores que no están en su pregunta. Habiendo dicho eso, es muy posible que alguien más haya señalado esto para que lo miren.
Esto suena bastante similar a los escenarios que he encontrado con compañeros varias veces a lo largo de mi carrera. Daré una narración de lo que pudo haber sucedido desde la perspectiva de un tercero.
De vez en cuando aparece un compañero de trabajo que parece bastante capaz, pero que se resiste a aprender cosas nuevas o adaptarse a los estándares del equipo. Otros miembros del equipo dejarán comentarios similares en las solicitudes de incorporación de forma rutinaria. por ejemplo: "Solo una clase por archivo". o "No usamos la notación húngara. Deje de anteponer 'str' a los nombres de sus variables".
Los miembros del equipo más experimentados eventualmente notarán que el compañero de trabajo no muestra un intento de aprender de los comentarios publicados repetidamente en las solicitudes de extracción. Cuando tengan un 1 a 1 con el gerente, probablemente mencionarán esta frustración.
Un buen gerente pediría entonces ejemplos y pruebas de cuándo y dónde sucede esto. Una vez que el gerente vea evidencia empírica de que se trata de un problema continuo, es probable que plantee este problema al compañero de trabajo. En lugar de arriesgarse al drama y la fricción del equipo al contar anécdotas de los compañeros de equipo, presentar la evidencia empírica y dejar que hable por sí misma debería ser suficiente para que el compañero de trabajo sea consciente de las áreas en las que puede mejorar.
Si bien es posible que su gerente esté siendo más proactivo que la mayoría, es al menos tan probable que sus compañeros les hayan llamado la atención sobre el problema.
Cuando reciba comentarios de sus compañeros, tómelos en serio. Si la retroalimentación es de naturaleza general, como el cumplimiento de los estándares del equipo, o algo que recibe más de unas pocas veces, anótelo. Finalmente, antes de publicar su código para revisión, realice una revisión de su propio código usando sus notas para anticipar que sus compañeros de equipo lo van a marcar por esas violaciones una vez más.
También tuvimos una práctica similar en nuestra empresa, pero el revisor es una persona técnica.
La cuestión es que cada vez que el desarrollador genera el PR/MR, el revisor/mantenedor de ese proyecto revisará los cambios y agregará su comentario en el MR relativo. Durante el tiempo de revisión del rendimiento, visitarán los comentarios proporcionados para el MR generado y, si hay comentarios repetitivos, se considerará un problema de rendimiento. es decir, si el desarrollador está haciendo un código que es vulnerable a la inyección de SQL y si está cometiendo este error repetitivamente, no está haciendo la validación adecuada del lado del servidor y, por lo tanto, el sitio es vulnerable a XSS, etc.
Si ya se proporcionaron comentarios al menos una o dos veces y si el desarrollador sigue cometiendo el mismo error, se considerará un problema de rendimiento.
Por ejemplo, si está escribiendo un código que es vulnerable a las inyecciones de SQL y ya recibió los comentarios, pero su futuro MR/PR todavía tiene ese problema, entonces sí, será un problema de rendimiento.
Entonces, en primer lugar, como propietario de un negocio y ex desarrollador, puedo decir que un mensaje de compromiso a tiempo es una oportunidad maravillosa para ver los comentarios de un desarrollador senior a un desarrollador junior completo con todo el contexto de por qué alguien se siente como se siente. sobre tu desempeño. Esta es información valiosa para que su gerente tenga y para informar su decisión sobre cómo calificar su desempeño.
Desafortunadamente, han desperdiciado esta oportunidad al no revisar todo el contexto y, en cambio, sacar una conclusión que probablemente no deberían haber hecho. El objetivo de la revisión por pares (presumiblemente, por qué los otros desarrolladores estaban comentando en primer lugar) es mejorar ese código y la persona que lo escribe. He visto desarrolladores 10x (ya sabes, las personas que solo parecen dejar de producir código de calidad increíble por breves momentos cuando los tontos como nosotros los interrumpen) son llamados en una revisión de código por cosas que deberían haber detectado al 100%. Estas son personas que, literalmente, son tan productivas como el resto del equipo, pero supongo que su gerente les habría dicho que también necesitan mejorar.
Hay una serie de cosas en juego: el año pasado fue un año difícil para todos, incluidos los presupuestos. Es posible que solo tengan una cantidad limitada disponible para los presupuestos de este año, y dado que las bonificaciones y los aumentos están vinculados al desempeño, necesitan una razón para no darle una cantidad tan grande.
Lo mejor que puedes hacer es tomártelo con calma. Pida detalles sobre qué mejoras quieren ver de usted. Honestamente, deberías hacer eso sin importar cuál sea su calificación. Podría obtener una A+ o lo que sea que tenga y aun así debería hacer esa pregunta.
Tenga en cuenta que esto puede ser una señal de un problema financiero con la empresa. Odio terminar las respuestas con "repasar el currículum" y no digo que debas hacerlo, pero digo que estés al tanto de otras posibles señales de alerta. Esta es una bandera de color rosa claro: busque a otros, y si ve demasiados indicadores de problemas, busque otro trabajo mientras todavía está empleado. (Así es mucho más fácil).
Sí No. No es normal que te lo digan explícitamente, pero es totalmente normal que la gente pierda su trabajo por eso. Entonces, supongo que no es una locura que te lo mencionen en una revisión de desempeño. Si sigue recibiendo exactamente las mismas sugerencias para mejorar su código una y otra vez, entonces hay un problema como: a.) no puede o no está interesado en aprender, b.) es difícil trabajar con usted (en este trabajo en particular ).
En mi carrera, la única vez que vi que se convirtió en un gran problema fue con un tipo que todavía estaba en su período de prueba. Lo despidieron porque nunca escuchó a nadie. Tuvo 120 comentarios repetitivos sobre su trabajo (algo que la mayoría de la gente haría con 0-6 comentarios) durante unos meses y nunca consiguió nada aprobado porque nunca escuchó y pensó que lo sabía todo. Eso simplemente no vuela. Por lo general, no es un problema porque las personas adquieren la experiencia suficiente para hacer las cosas de la manera correcta/aceptada muy rápidamente.
El hecho de que hayan esperado hasta tu reseña para decir algo me resulta extraño. Por lo que he visto: si tienes experiencia (y probado en el trabajo) y digamos que hiciste algo muy diferente de la forma normal (aceptada en la empresa), la gente probablemente ni siquiera haría comentarios negativos de relaciones públicas. El líder/jefe simplemente hablaría con usted y le daría la oportunidad de corregir las cosas sin siquiera hacer un gran problema al respecto en los comentarios de revisión. Simplemente no obtendría su código aprobado hasta que fuera "correcto".
De todos modos, supongo, decida si quiere tener "razón" o ser considerado correcto. Ja. Elige tus batallas como dicen.
Si la pregunta es "¿Es normal que se haga para todos y sin previo aviso?", entonces no, no creo que sea normal, y tampoco creo que sea justo. Este gerente habría lanzado nuevos estándares arbitrarios de juicio a las personas, probablemente tratando de ser 'inteligente' sin comprender realmente el propósito de los comentarios de solicitud de extracción.
Sería como decir:
"A partir de hoy, lo juzgaremos según la cantidad de días a la semana que venga a la oficina. Oh, parece que solo viene tres días a la semana, mientras que [otro empleado] viene todos los días, así que [otro empleado] obtiene un ascenso y necesita seguir un plan de mejora del desempeño".
Dicho esto, parece que lo que realmente podría haber sucedido es que las personas de su equipo plantearon un problema y revisaron su historial de control de versiones en busca de evidencia. Si ese es el caso, entonces parece razonable usar comentarios de solicitud de extracción como evidencia en un caso más grande , pero no necesariamente de forma aislada.
No estoy comentando sobre su destreza en el código, sus compañeros de equipo o cómo es el proceso de revisión en su equipo. Solo el método y la implementación para su revisión de desempeño.
El objetivo de una revisión de desempeño es tener una metodología clara y procesable que tanto el gerente como la persona administrada acordaron. Normalmente, dicha metodología es explicada por el departamento de recursos humanos. al comienzo del proceso, se detallan indicadores claros de desempeño en el proceso, se establecen/negocian objetivos, se especifican indicaciones de logro en el proceso, se establecen términos de inicio/fin del proceso, se analizan los resultados y se extraen conclusiones. Nada de eso sucedió aquí, en mi opinión.
A menos que todo su equipo sea consciente de que los comentarios de revisión son una indicación del desempeño, y todo el proceso de revisión de comentarios de revisión y asignación de niveles de desempeño en función de su contenido se discutió de antemano, su evaluación no tiene sentido.
Su gerente podría haber adivinado su nivel de desempeño en tripas de pollo con los mismos resultados.
Le pediría una conversación 1 a 1 con él, le explicaría que no puede simplemente inventar una métrica y evaluar su desempeño en ella y esperar que esté de acuerdo con la evaluación post factum y sin ningún aporte de usted. Si su evaluación resulta en alguna pérdida para usted (incluida la emocional), le plantearía el problema a Recursos Humanos, diciéndoles que estuvo sujeto a un proceso de evaluación injusto y sesgado en el que no tuvo participación. Si consideran que su queja es infundada o la ignoran, busque otro proyecto/trabajo. Su gerente es incompetente y el departamento de recursos humanos. simplemente ignoré tu situación.
mi líder de equipo, que no es una persona técnica
Ese es tu problema, ahí mismo.
No es una buena idea designar a una persona sin conocimientos técnicos para administrar un equipo de desarrolladores (o cualquier equipo que incluya desarrolladores). Un gerente también debe ser una persona amable, positiva y constructiva. El gerente debe tener la actitud de que te está sirviendo, no al revés.
Puede ser apropiado que un líder de equipo revise los RP y le pregunte respetuosamente sobre los comentarios, pero no es apropiado usar esto como base para una revisión de desempeño sin siquiera hablar con usted al respecto. Por lo general, una revisión de desempeño se registra en su registro y podría dañar sus perspectivas de carrera.
Sugiero encontrar un mejor lugar para trabajar. Trabajar por cuenta propia es bueno.
Si no quiere irse, puede pedirles a los líderes de la empresa que busquen un mejor gerente para su equipo, pero es poco probable que eso suceda. Los líderes de alto nivel son muy a menudo arrogantes como resultado de su éxito y su posición de poder. A menudo son incapaces de admitir que han cometido un error.
Kilisi
más plano