Eliminando reseñas de 360: cómo dejamos de calificar a las personas y comenzamos a gestionar el trabajo
¡Hola! Mi nombre es Vitalina y soy administradora de cuentas en SToFU Systems.
Somos el tipo de empresa donde los procesos nacen en movimiento y sólo después reciben nombres, reglas y supervisión de un adulto. Al principio no teníamos escuela de gestión propia, así que copiábamos lo que "todo el mundo copia". Uno de esos hábitos de gestión prestados fue la retroalimentación 360.
Sobre el papel, el 360 parece algo justo y maduro. Muchas fuentes. Menos prejuicios. "Objetividad". ¡Mmmm!
En la práctica, se convirtió en otra cosa. Para nosotros 360 no fue una herramienta que fortaleciera al equipo. Fue una herramienta que silenciosamente separó al equipo. Formalmente parecía correcto, pero en el trabajo real iba en la dirección equivocada. Entonces lo cortamos. Vayamos paso a paso.
¿Qué es 360?
360 es cuando recopilas comentarios sobre una persona. "de todos lados": del gerente, colegas, compañeros de equipo adyacentes y, a veces, clientes. Generalmente es un cuestionario con calificaciones y preguntas como "lo que va bien", "lo que estorba", "lo que se debe cambiar".
Nosotros también hicimos eso. Enviamos un cuestionario, recopilamos respuestas, las agregamos y escribimos recomendaciones. Formalmente, todo parecía ordenado. Hubo puntos de datos. Hubo conclusiones. Había un "plan de desarrollo".
Para que quede claro de qué tipo de "cuestionario" estamos hablando, pondré un ejemplo muy simplificado de lo que se suele preguntar en 360. Esta no es una cita palabra por palabra de nuestro formulario, sino una lógica típica.
Por ejemplo: "¿Qué debe seguir haciendo una persona?". Luego: "¿Qué debería empezar a hacer una persona?". Luego: "¿Qué debería dejar de hacer una persona?". Y otra pregunta que siempre parece inocente: "Describe una situación en la que la interacción fue difícil y por qué".
Y el resumen a menudo parece un pequeño informe de un ojo colectivo que todo lo ve. Más o menos así:
Puntos fuertes: asume las tareas rápidamente, ayuda a los demás, no desaparece del radar. Riesgos: "listo" a veces significa "casi listo", la discusión en las reuniones puede ser aguda, en el chat responde fragmentariamente. Qué hacer a continuación: acordar la definición de hecho, sincronizar las expectativas, acordar el formato de escalamiento.
Sobre el papel todo está bien. Hermosa, incluso. Pero hay un detalle. Está escrito por personas que trabajan juntas todos los días. Y una vez que agregas anonimato o retraso feedback "para después", deja de ser una herramienta de desarrollo y comienza a vivir una vida propia. Imagina un equipo de proyecto de cinco personas. Entonces alguien dice: "Aquí hay comentarios anónimos". Anónimo. En un equipo de cinco. Y en esta realidad, 360 empieza a mostrar su verdadera cara.
Por qué 360 se convirtió en una herramienta para separar al equipo
1. Punto uno. Alabanza - una línea, crítica - una novela de tres volúmenes
Cuando las cosas van bien, la gente escribe brevemente. "Todo está bien". "Trabajo cómodo." "Bien hecho". Se trata de retroalimentación al nivel de una pegatina en un cuaderno escolar. Cuando algo anda mal, comienza la literatura. Con detalles, con ejemplos, con emociones. Y técnicamente esto es normal: negativo es más fácil de especificar que positivo. Pero en 360 hay El problema: toda esta "novela" vuelve luego a una persona como un resumen generalizado. veredicto del equipo.
Incluso si lo expresas lo más suavemente posible, el cerebro humano lo dice así: "Nos reunimos todos y escribimos qué te pasa". Y eso es todo. Después de eso, cualquier intento de La "retroalimentación constructiva" se siente como una audiencia en el tribunal. tu querias una herramienta de desarrollo y consiguió un tribunal colectivo.

Honestamente nos preguntamos: ¿qué estamos realmente tratando de hacer con esta práctica? Disciplina el formato, sí, pero destruye la confianza.
De la vida se ve así. Un informe llega a una persona, donde hay tres. frases "todo está bien", y dos lienzos "por eso no está bien". Y el cerebro, por supuesto, recuerda no tres "ok", sino dos "no está bien". Porque así es como se organiza la atención: ¡duele, por eso es importante! Y a partir de ese momento, la persona no avanza hacia el desarrollo, sino hacia la autodefensa. Ellos empezar a demostrar que "no es cierto", o que "fue el contexto", o que "tampoco sois santos". Y en ese momento 360 se convierte en un ritual donde todos como si quisieran algo bueno, pero resultó como siempre.
2. Punto dos. El anonimato en un equipo pequeño es un autoengaño
Existe un conocido cuento de hadas sobre gestión: "La retroalimentación anónima elimina el miedo". ¿Anonimato? ¿En realidad? ¿En pequeños equipos de proyectos? En realidad, casi siempre significa "¡Voy a adivinar quién escribió esto!".
Una persona recibe varios comentarios desagradables y luego llega a la siguiente reunión del proyecto donde están sentadas esas mismas 3-5 personas. No piensan en el "desarrollo organizacional". Piensan: "¿Cuál ¿Alguno de ustedes fue?" Y eso inicia un proceso muy tóxico: todos Se muestra cortés en apariencia, pero debajo hay una capa oculta de desconfianza.
No siempre estalla en un conflicto abierto. simplemente Hace que el equipo esté más frío. Menos cohesivo. Menos dispuesto a ayudar. Y luego nos preguntamos por qué la gente no comparte sus problemas. "en las primeras etapas". Pero porque ya son una vez. compartido - y les devolvió de forma anónima una lista de reclamaciones.
3. Tan pronto como 360 afecta las decisiones de promoción, comienzan los juegos
Aquí estaba lo más interesante. Y lo más triste.
En una de nuestras conversaciones de coordinación, nos dimos cuenta algo extraño. Una persona puede ser educada, comprensiva y fácil de tratar durante las llamadas. Dentro del equipo pueden parecer un completo amor. Y luego les entregas un cuestionario "anónimo" donde pueden "calificar a otros", y de repente la puntuación baja o las críticas se vuelven excesivas. Nosotros mismos vimos ese efecto. Actuó directamente contra la integridad.
Imagínese la situación. Le dices al equipo: "Las calificaciones de 360 grados cuentan para ascenso." Y en el mismo segundo, entregas parte del equipo en jugadores, no en colegas. porque si Aparece el botón "influencia" en el sistema, alguien lo presionará. No siempre del mal. A veces solo por sentir injusticia ("y por qué lo ascienden, es..."). A veces de la competencia. A veces porque "así funciona el mundo". Y en ese momento obtienes lo que querías. Evite: política, juegos, calificaciones más bajas "por si acaso".
Esta, por cierto, es una de las razones por las que muchos investigadores y se recomienda a los profesionales que compartan sus comentarios para el desarrollo. y decisiones administrativas (dinero, calificaciones, promociones). El CIPD lo expresa claramente: hablemos de es mejor separar las evaluaciones/decisiones administrativas de las conversaciones, donde se brinda retroalimentación con fines de desarrollo. Aquí hay un PDF de su revisión de evidencia (resumen de la práctica): www.cipd.org/...e-review_tcm18-111378.pdf
4. Punto cuatro (nuestra dolorosa percepción). 360 a menudo reemplaza el trabajo del gerente
Después de varios ciclos, terminamos con una frase que primero sonó a insulto y luego a verdad.
Si un gerente necesita un 360 para comprender cómo trabaja la gente y dónde están los problemas, ese gerente no tiene un sistema de señales observables. No hay métricas. no hay conversaciones regulares. No hay ritmo. O todo eso existe "en alguna parte", pero en realidad no se está utilizando.
Y 360 se convierte en una muleta: "ahora recogeremos el cuestionario y finalmente aprenderemos la verdad." Y luego no entiendes la "verdad" y una imagen emocional, multiplicada por el anonimato, las conjeturas y juegos políticos.
Entonces esto no suena como "nos fue mal, por lo tanto 360 es malo", agregaré una referencia.
Existe un estudio sobre la retroalimentación de múltiples fuentes. Su conclusión es básicamente: "no esperes magia". En un metanálisis de 24 estudios longitudinales, Smither, London y Riley escriben que la mejora después La retroalimentación 360 suele ser modesta y no se debe esperar una gran "actualización masiva" después de una ola de comentarios. Las posibilidades de mejorar aumentan cuando una persona ve una necesidad real de cambiar, acepta los comentarios, cree que pueden cambiar, establece objetivos concretos, y realmente hace algo, en lugar de simplemente "leer un PDF y seguir adelante." Aquí está el texto en sí (PDF): www.bauer.uh.edu/...ngs/SmitherLondon2005.pdf
Bien, eliminamos 360. ¿Qué lo reemplazó?
Dejamos de medir a las personas por el número de entradas
Un boleto puede abarcar una semana de investigación, una decisión difícil, diez llamadas y solo 20 líneas de código. En otro - 50 funciones que realmente surgieron de una ejecución del agente AI en 20 minutos.
Si sólo estás midiendo boletos, en realidad estás midiendo no el trabajo, sino cómo su proceso reduce el trabajo en pedazos
Por eso cambiamos la pregunta. No "¿cuántas tareas cerré?" pero: ¿Qué se entregó, qué valor creó, cuál fue la calidad, fue predecible y los estados fueron honestos?
Cómo definimos "resultado" sin teatro de gestión
Convergimos en un marco simple.
Un resultado es cuando se entrega valor, la calidad es aceptable, el equipo es predecible y el progreso es transparente.
El valor no es "el código está escrito". Es "el usuario o cliente obtuvo un mejor resultado" o "fue más fácil para el equipo para apoyar el sistema".
La calidad no es "Me gusta tu código". Estas son consecuencias: fallos en el producto, incidencias, revisiones.
La previsibilidad no es "siempre lo logramos". Es: "entendemos honestamente para qué tenemos tiempo y para qué no, y no nos mentimos a nosotros mismos al respecto."
La transparencia es cuando el "casi hecho" no se convierte en una filosofía de vida.
Métrica
Cuando la gente escucha la palabra "métricas", muchos inmediatamente Recuerde al trabajador ligeramente traumatizado de experiencias pasadas: el que fue golpeado en la cabeza con números.
Las métricas no deberían ser un látigo. Deberían ser gafas. Sin ellos, un directivo suele estar ciego. Y cuando el directivo se queda ciego, empieza a buscar "objetividad" en los cuestionarios. Bueno, lo tienes.
¡Dejamos las métricas a nivel de equipo, porque la mayoría de los problemas son sistémicos! Y si no queremos buscar culpables, sino corregir el proceso, ¡entonces necesitamos medir el proceso!
Sinceramente, aquí no inventamos nada. DORA (DevOps) Investigación y Evaluación) ya promueve un enfoque muy práctico conjunto de métricas de entrega: qué tan rápido entrega el cambio y cuán dolorosos son los fracasos cuando los cambios salen mal. Aquí está su guía rápida: dora.dev/guides/dora-metrics.
También hay una observación importante que me gustaría concretar. en la pared para cualquiera que alguna vez haya querido crear métricas de KPI: "¡no hagas de la métrica el objetivo"! Porque tan pronto como dices "necesitamos implementar N veces por día", parte del El equipo comienza a implementar no valor, sino un número. este es el viejo historia de que una vez que una métrica se convierte en el objetivo, deja de serlo. un indicador. DORA se refiere explícitamente a la ley de Goodhart. y describe los errores típicos. Aquí está la página sobre las "cuatro/cinco llaves" en palabras simples: dora.dev/...s/dora-metrics-four-keys
Y una cosa más importante que DORA normalmente enfatiza: el contexto es importante. Estas métricas se ven mejor dentro de una equipo o servicio y a lo largo del tiempo, no comparando una aplicación móvil con una computadora central o un equipo pequeño con una plataforma para 200 personas.
Si no sois un equipo técnico la lógica es la misma. En lugar de "implementar" es posible que "el cliente haya aceptado el resultado"; en lugar de "incidente" puede tener "escalada"; en lugar de "revertir", "reelaborar" después de la alineación". El punto sigue siendo el mismo: qué tan rápido movemos el valor a través del sistema y cuánto nos cuesta el error.
Y ahora, el muy importante "no hagas eso". ¡No convierta estas métricas en KPI individuales! Porque entonces la gente empieza a optimizar no el producto, sino el número. KPI en "implementaciones", y de repente tienes implementaciones por el simple hecho de implementar. KPI sobre "tiempo de ciclo", y las tareas se desglosan hasta el punto de lo absurdo sólo para "cerrarlas rápidamente", mientras que las partes difíciles desaparecen silenciosamente en las sombras. KPI sobre "incidentes", y los incidentes comienzan a denominarse "peculiaridades" o "escenarios de usuario inesperados".
Lo primero que nos ayudó fue la previsibilidad. Simple Pregunta: ¿Qué prometimos en la planificación? y lo que realmente se dio. No por vergüenza. Por comprensión. Porque si constantemente prometes 10 y cumples 6, entonces el problema no es la "gente vaga". El problema está en la estimación, prioridades, WIP, bloqueadores, cambio de contexto. En otras palabras, en la gestión.
El segundo es el tiempo de entrega. ¿Cuánto tiempo lleva la tarea? en el camino desde "llevado al trabajo" hasta "realmente entregado". Es muy aleccionador. Porque muchas veces resulta que "escribimos código" rápidamente, pero "entregamos" despacio. Y luego podrás ver dónde está el cuello de botella: revisión, prueba, liberación, reconciliación, dependencias.
El tercero es WIP. Si el equipo está "trabajando" al mismo tiempo. diez problemas a la vez, nadie está haciendo realmente nada. Más precisamente, todos están haciendo todo a la vez. Y luego nos preguntamos por qué el progreso se siente lento y nervioso. Cuando el cerebro se extiende en una fina capa. en diez tareas, no se vuelve más productivo. simplemente se convierte más cansado.
Otra cosa que nos ayudó a pensar con mayor claridad fue la siguiente: si se quiere que el trabajo avance más rápido a través del sistema, la respuesta a menudo es no presionar más a las personas. Es para reducir el tamaño del lote. Los cambios más pequeños son más fáciles de revisar, probar, publicar y revertir. DORA señala directamente el mismo punto: los lotes más pequeños generalmente mejoran tanto la velocidad como la estabilidad. Suena obvio hasta que un equipo intenta vivir de acuerdo con ello durante un mes.
Calidad: dejamos de discutir "me parece" y empezamos a mirar las consecuencias
Evaluar la "calidad" con cuestionarios es una mala idea. Porque "calidad" En el cuestionario, a menudo se trata de simpatía, estilo y gusto.
Pasamos a las consecuencias.
Cuántos defectos llegaron a producción. ¿Qué tan serios fueron? ¿Cómo está cambiando la tendencia?
Cuántos incidentes hemos tenido. ¿Cuánto tiempo nos llevó recuperarnos? ¿Se repiten las mismas razones?
Cuantas revisiones. Cuántas tareas se "aprobaron" y luego se devolvieron. Porque "listo" resultó no estar listo.
Ya no estás discutiendo sobre "quién es el mejor". Ves lo que realmente está pasando con el producto.
Una conclusión contraria a la intuición: ¿Por qué evaluar a una persona?
Cuanto más indagamos, más a menudo nos topamos con una pregunta extraña.
¿Por qué evaluamos a una persona? ¿Rechazar un ascenso? ¿Para mostrar quién es la "estrella"? ¿Para comparar personas?
Y cuando hablamos de ello honestamente, resultó que la mayoría de nuestras necesidades reales no tenían que ver con la clasificación gente. Trataban sobre el desempeño del equipo: ¿estamos haciendo lo que Prometimos, ¿la calidad es buena?, ¿el trabajo es predecible? ¿Estamos agotados y el cliente obtiene lo que esperan?
Es decir, sobre el sistema.
Y si es así, entonces el primer objeto de evaluación es el equipo y el proceso. Y no una persona como objetivo.
El equipo tiene un rendimiento deficiente, por lo que revisamos todo cadena: contratación, incorporación, definición de tareas, planificación, revisión, pruebas, lanzamiento, comunicación, dependencias. esto es gerencial más duro, sí. Pero es más honesto.
A veces parece muy sensato. Por ejemplo, cuando "Otra vez no tuvimos tiempo", la primera pregunta no es "quién está desacelerando", y "¿dónde desapareció el tiempo?". Porque el tiempo puede desaparecer no en "trabajo", sino en espera: las tareas residen en revisión, en prueba, bloqueado por acuerdo, o simplemente hay demasiados en paralelo.
Cuando alguien tiene dificultades, lo que comprobamos primero
A veces también vemos situaciones en las que alguien "no tira". Pero en lugar de un cuestionario, hacemos un diagnóstico simple.
¿Este problema siempre ha estado ahí? Si es así, es probable que el problema en la contratación o incorporación. En ese caso, arreglas el proceso de contratación, no la persona con cuestionarios.
¿Era normal antes y luego empeoró? Entonces puede ser el contexto: agotamiento, cambio de tareas, conflicto de roles, circunstancias personales. Esta es la zona de trabajo directivo normal: Descubra qué pasó, reduzca la carga, ayude a la persona a recuperarse. controle y cree un breve plan de recuperación de 2 a 4 semanas.
¿Tiene la persona una comprensión clara de lo que es el éxito? parece en un futuro próximo? Porque muchas veces el problema no es que la persona es "débil". Es que los pusimos en la niebla y lo llamó expectativas.
Y un matiz más que también tuvimos. si una persona falló varias veces, el gerente a veces puede plantear subjetivamente barra: "ahora demuestra que no eres un fracaso". Eso a menudo funciona a nivel subconsciente y funciona mal para el equipo. Generalmente es mejor hacer lo contrario: reducir el alcance, reducir el tamaño de las tareas, eliminar el ruido, darle a la persona la oportunidad de hacer algunas cosas bien de manera consistente y recuperar la confianza en uno mismo. Ésta es una tarea difícil para gerentes. Y es exactamente por eso que miramos muy de cerca a los gerentes que contratamos.
Conclusiones
Por supuesto que el 360 puede funcionar. En las grandes empresas, donde el anonimato es realmente posible.
Cuando el equipo ya tiene una cultura de retroalimentación directa, y 360 es una señal adicional, no la principal "verdad".
No teníamos eso. Teníamos equipos pequeños, un ritmo rápido y un alto costo de desconfianza.
El 360 parecía una herramienta adulta sobre el papel. en nuestro realidad, se ha convertido en un mecanismo que acumula el miedo en un solo lugar, conjeturas, competencia y "juicio colectivo".
Eliminamos 360 y volvimos a lo básico: Métricas de equipo simples, conversaciones abiertas y estados transparentes.
Materiales y enlaces (si quieres profundizar más)
DORA — software delivery performance metrics. Una explicación fundamentada de las cinco métricas y las trampas en las que caen los equipos cuando las usan mal.
DORA — DORA’s software delivery performance metrics. Versión corta con el histórico "por qué cuatro/cinco" y una advertencia sobre juegos con métricas.
DORA Research: 2024 — DORA Report. Informe completo (descargar PDF en varios idiomas).
Smither, London (2005) — meta-analysis on multisource feedback. Por qué no deberías esperar un efecto mágico de una onda 360.
CIPD — Performance feedback: an evidence review (PDF). Sobre cómo funciona o no la retroalimentación y por qué confundir "evaluación" con "desarrollo" suele ser perjudicial.
CCL — 360 Degree Assessment & Feedback: Best Practices Guidelines. Si todavía haces un 360, hay algo en lo que pensar antes del inicio, no después del incendio.
CCL — SBI feedback model. Un marco muy simple para comentarios "sin atajos".
Google SRE — Postmortem Culture: Learning from Failure. Sobre autopsias irreprochables y por qué avergonzar a la cultura está acabando con el aprendizaje.
Amy Edmondson (1999) — Psychological Safety (PDF). Fuente primaria sobre seguridad psicológica en equipos.
WEF — Feedforward technique. Sobre cómo orientar la retroalimentación hacia "lo que haremos a continuación" y no hacia "lo que pasó ayer".
Goodhart’s law. Una de las "antiteorías" más útiles para cualquiera que quiera realizar métricas KPI.
Preguntas para la comunidad
¿Qué piensa la comunidad sobre 360? ¿Lo usas? ¿Cómo ha sido tu experiencia?
¿Cómo se soluciona el problema del "anonimato" cuando el equipo es pequeño y todos entienden todo?
¿Y qué métricas de entrega/calidad realmente le ayudan a gestionar el proceso en lugar de generar bonitos informes?
Gracias por su tiempo y atención.