Pregunta:
¿Cómo critica / retroalimenta el trabajo de alguien sin desmotivarlo?
Lucas Kauffman
2012-04-11 02:09:02 UTC
view on stackexchange narkive permalink

¿Cómo critica / da retroalimentación sobre el trabajo de alguien sin desmotivarlo?

Si necesita revisar el trabajo de alguien, ¿cómo puede evitar desmotivarlo cuando hizo un mal trabajo?

Mi respuesta - no volver a publicar - http://programmers.stackexchange.com/a/131749/39294
Pregunta relacionada (pero no duplicada): [¿Cómo tratar con un equipo en el que uno de los miembros no acepta críticas?] (Http://workplace.stackexchange.com/q/6409/316)
Seven respuestas:
#1
+16
John N
2012-04-11 02:13:51 UTC
view on stackexchange narkive permalink

De forma abierta, honesta y en una cultura que enfatiza el aprendizaje de los errores en lugar de castigar el fracaso.

Sin eso, es muy, muy difícil.

Gran +1 para una cultura que se trata de aprender de los errores. Existe un equilibrio entre la responsabilidad y la rendición de cuentas que alguien puede y quiere asumir, y la cantidad que usted puede darles de manera segura sin poner en peligro proyectos / trabajo / negocios. Trate de trabajar ese equilibrio y dé a las personas suficiente espacio para crecer sin tanta cuerda que se cuelguen. Luego, bríndeles retroalimentación periódica a lo largo del camino.
#2
+13
Nicole
2012-04-11 02:12:54 UTC
view on stackexchange narkive permalink

¿Cómo lo haría un profesor?

  • Encuentra los aspectos positivos y habla sobre ellos.
  • Haz preguntas para que entiendas sus pensando.
  • Luego, haga preguntas que los lleven a la respuesta correcta.

Después de todo, si no puede conectar los puntos entre el problema y una mejor solución , entonces no aprenderán nada del proceso. Entonces, tienes que ayudarlos a resolver el problema por sí mismos.

#3
+9
ChrisF
2012-04-11 03:11:01 UTC
view on stackexchange narkive permalink

Concéntrese en el trabajo, no en la persona. Dicho esto, es muy difícil hacerlo bien.

Lo que quieres es que la persona cambie su comportamiento de alguna manera, así que concéntrate en eso, explicando por qué el existente el comportamiento es un problema y qué se puede hacer para mejorarlo. Esto debería (con suerte) crear cierta distancia emocional entre la persona y el problema para que puedan ver que no es personal y ayudarlos a concentrarse en la solución.

Esto es generalmente una buena idea. Es el primer punto de la [Negociación basada en principios] (http://en.wikipedia.org/wiki/Principled_negotiation). Otro punto de la negociación basada en principios (utilizar criterios objetivos) también se puede aplicar fácilmente en las discusiones sobre el desempeño laboral.
#4
+4
HLGEM
2012-04-11 03:34:49 UTC
view on stackexchange narkive permalink

Cuando a alguien no le va bien, lo mejor que puede hacer por él es decirle qué está mal y qué debe solucionarse. No arregles las cosas a sus espaldas (nunca sabrán que lo que hacen es inaceptable), no finjas que todo está bien. Sea honesto sobre el problema, pídales soluciones pero indíqueles la solución que desea si es necesario.

No necesita ser desagradable o atacarlos personalmente, pero debe establecer expectativas claras de lo que es aceptable y lo que no. Una vez tuve dos empleados y promocioné a uno y no promocioné al otro y tuve que sentarme con ella y decirle exactamente lo que tenía que hacer para conseguir ese ascenso. Tenía una lista específica de cosas que necesitaban mejorar y que tenía que demostrarme que podía lograr antes de convertirse en una persona mayor. Finalmente consiguió ese ascenso porque sabía qué estándar tenía que cumplir y que yo la promocionaría tan pronto como cumpliera con ese estándar. Esas conversaciones son difíciles, no son divertidas para el gerente, pero no puede manejarlas bien a menos que esté dispuesto a tener esas conversaciones.

En el mundo del desarrollo de software, las revisiones de código son un buen lugar para comenzar. No está atacando a la persona, solo viendo lo que hace el código y cómo se puede mejorar. Conseguir que los desarrolladores no piensen que son dueños del código y que nadie más debería verlo o tocarlo también es parte de la revisión del código, lo que lo hace aún más importante en cualquier tienda de software. Y no se limite a revisar a los de peor desempeño, si todos tienen el código revisado, las críticas se tomarán mejor.

En el mundo no relacionado con el software, también puede tomarse el tiempo para hacer comprobaciones del trabajo de alguien de forma regular, especialmente si la persona es nueva o muy joven. Es más fácil detectar un problema en las primeras semanas que trabaja para usted, que enojarse por un problema de larga data después de haberlo estado haciendo de esa manera durante un año y usted nunca dijo nada.

Brinde comentarios positivos cuando esté justificado. Si observa una mejora en un área específica de preocupación, asegúrese de que la persona sepa que lo notó.

Y sea justo. No reserve todos sus elogios para una persona y todas sus críticas para otra.

Y no critique públicamente. Se elogia en público, pero se critica en privado.

#5
+2
Renan
2012-04-11 02:35:41 UTC
view on stackexchange narkive permalink

Muéstreles todos sus aspectos positivos, luego explíqueles los aspectos negativos / critique su trabajo.

Luego discuta abierta y francamente sobre cómo mejorarlos. Demuestre que está abierto a discutir problemas y nunca sea condescendiente (creo que esto es lo más hiriente).

Esto puede aplicarse a otras situaciones, como dar retroalimentación sobre el comportamiento negativo.

#6
+2
Randy E
2013-02-22 21:40:45 UTC
view on stackexchange narkive permalink

Todas estas respuestas son excelentes. Pero todos se pierden uno muy obvio. ¡Conozca a su gente!

Si conoce a sus subordinados directos ... y me refiero a cosas no relacionadas con el trabajo ... entonces sabrá cómo abordar esta situación.

Con mi puesto actual, tengo 24 subordinados directos, pero trabajo codo a codo con otros 4 gerentes para gestionar una sección completa (cada uno con unos 24 subordinados directos). Como puede adivinar, cada persona es un individuo. Sé que con la persona X puedo acercarme a él y decirle directamente "oye X, tu trabajo no es suficiente. Recógelo". Persona Y Puedo decir "Oye, Y, tu trabajo no es suficiente. Esto es lo que debes hacer para llegar a lo que esperamos". Pero también tengo algunos que están en la categoría de persona Z. Tengo que decirles todas las cosas buenas que están haciendo para poder discutir lo que no están haciendo bien. De cualquier otra forma y se lo toman como algo personal.

Si es una persona a la que ha estado administrando durante un tiempo, ya debería conocerla. Si son nuevos para ti, debes usar el método del sándwich. He estado usando este método durante algunos años y encuentro que funciona mejor para la persona promedio. Es decir, encuentra 2 cosas que son buenas y 1 cosa en la que desea que la persona mejore. Empaqueta esa mejora entre las dos cosas buenas. De esa manera, comenzará bien la reunión, abordará el tema del que realmente trata la reunión y luego la terminará con algo bueno.

Lo más importante que he aprendido es concentrarme en una deficiencia a la vez. . Establezca metas mensurables para lograr que cumplan con los requisitos. Establezca un tiempo en el que deberían estar donde deben estar. Asegúrese de que sea realista.

Por supuesto, si no eres su gerente, todo esto es discutible. Lo mejor que se puede hacer en ese caso es el método sándwich. Pero debes asegurarte de que quieran tus comentarios. A mucha gente no le gusta escuchar este tipo de cosas de sus compañeros. Si sabe que esa persona es de este tipo, lo mejor que puede hacer es discutirlo con su gerente.

#7
+1
Erik Reppen
2012-05-17 09:16:26 UTC
view on stackexchange narkive permalink

Dos preguntas:

  1. ¿DEBEN saber que la cagaron?

  2. ¿SABEN que la cagaron?

[sí, no]: golpéelos (fuerte) en el trasero.

[no, sí]: reconozca el error pero tenga sentido del humor sobre

[no, no]: Tómese el tiempo para mostrarle al novato las cuerdas y señalar la naturaleza del problema.

[sí, sí]: "Está bien, entonces ¿qué pasó? "



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...