Christian F. Rojas
ENES
Todos los casos

Caso 04

Un portal de evaluación 360°, con su modelo de puntaje corregido

La evaluación 360° de Recursos Humanos vivía en un libro de cálculo de 10 hojas. Dirigí tres generaciones de arquitectura y un análisis que redujo un cuestionario de 62 a 26 preguntas y corrigió cómo se califica a las personas.

62 → 26
preguntas para un rol al recuperar la matriz de rol a nivel (−58 %)
149 → 57
nodos de flujo al pasar de la primera a la segunda arquitectura
41 · 7
hallazgos corregidos en dos rondas de verificación adversarial, 7 de ellos bloqueantes
Diagrama del sistema: cómo se diagnosticó y replanteó el portal de carreraEl instrumento de RR. HH. es un libro de cálculo de 10 hojas. La prueba de concepto migró 3 de las 10 hojas. El diagnóstico, resaltado, encontró 7 hojas sin migrar y 62 preguntas frente a un diseño de 26. El proyecto se replanteó como la recuperación de un trabajo que RR. HH. ya había hecho; el modelo corregido funciona en la tercera generación, en producción.instrumento RR. HH.10 hojasprueba de conceptomigró 3diagnóstico7 hojas sin migrar62 vs. 26 preguntasrecuperacióndel trabajo de RR. HH.Gen 3 · en producciónDiagrama del sistema: cómo se diagnosticó y replanteó el portal de carreraEl instrumento de RR. HH. es un libro de cálculo de 10 hojas. La prueba de concepto migró 3 de las 10 hojas. El diagnóstico, resaltado, encontró 7 hojas sin migrar y 62 preguntas frente a un diseño de 26. El proyecto se replanteó como la recuperación de un trabajo que RR. HH. ya había hecho; el modelo corregido funciona en la tercera generación, en producción.instrumento RR. HH.10 hojasprueba de conceptomigró 3diagnóstico7 hojas sin migrar62 vs. 26 preguntasrecuperacióndel trabajo de RR. HH.Gen 3 · en producción
Fig. 04 · Diagrama del sistema

Mis decisiones 04

  • Recuperar la matriz de rol a nivel y las ponderaciones que la primera prueba de concepto había dejado fuera.
  • Redistribuir el peso de un evaluador ausente en lugar de contarlo como cero.
  • Mostrar siempre juntos el puntaje y el cumplimiento, porque el total solo engaña.
  • Responder al ruido de los umbrales con una alerta de cercanía, no con más evaluadores.

Ejecución asistida 02

  • Claude Code generó los flujos de n8n, los datos ficticios de demostración y las migraciones, con unos 30 scripts de Python en la primera generación.
  • Claude Code construyó el portal, corrió la simulación de umbrales y ejecutó dos rondas de verificación adversarial.

Contexto

El instrumento de evaluación 360° de RR. HH. vivía en un libro de cálculo de 10 hojas. Las restricciones eran estrictas: costo cero, que RR. HH. pudiera operarlo sin perfil técnico y sin backend propio.

Qué decidí

Al comparar la primera prueba de concepto con el libro, vi que solo había migrado 3 de las 10 hojas. Faltaban la matriz de rol a nivel y las ponderaciones. Decidí recuperarlas antes de construir cualquier otra cosa.

Medí esa decisión por su costo de revertirla. Adoptar el modelo corregido al principio cuesta casi nada. Cambiarlo con toda la organización ya evaluada obliga a decirle a todo el mundo que el modelo cambió.

Cómo funciona

Tres generaciones de arquitectura:

  1. Prueba de concepto. Un front end estático, 19 webhooks de n8n y Airtable con 10 tablas. Las sugerencias de desarrollo venían de un modelo de Anthropic dentro de n8n, con un prompt que RR. HH. puede editar sin tocar código.
  2. Postgres. Los mismos 19 flujos, regenerados. Los nodos bajaron de 149 a 57.
  3. Portal. Una aplicación de una sola página, modular y sin framework, con un sistema de diseño escrito y 8 vistas, empaquetada en un único archivo HTML sin conexión: 817 KB, una petición de red y cero errores en 14 recorridos por rol.

Recuperar las hojas faltantes cambió el modelo de puntaje:

  • El cuestionario. Para un rol pasó de 62 a 26 preguntas (−58 %).
  • La escala. 40/70/90/100 en lugar de una lineal de 2/3/4/5.
  • Las ponderaciones. Líder 0,35, par 0,35 y empleado 0,30, en lugar de pesos iguales.
  • La redistribución. Cuando falta un evaluador, su peso se redistribuye en vez de contarse como cero. Una habilidad calificada con 4 y 4 sin par daba 2,6 (“Bajo”); ahora da 4,0.

Una simulación de umbrales mostró que una persona en el borde de una banda cambia de banda cerca del 50 % de las veces, con 3, 4 o 6 evaluadores. Pasar de 3 a 6 evaluadores reduce ese ruido solo un 29 %, con el doble de esfuerzo. Por eso el portal muestra una alerta de cercanía al umbral.

El total solo engaña: un perfil con 44,88 puntos cumple 18 de 18 habilidades, y otro con 70,00 cumple 3 de 18. El puntaje y el cumplimiento siempre aparecen juntos.

Qué produjo

La versión en producción es la tercera generación: un portal autocontenido, un único archivo HTML sin conexión y sin backend. La primera generación se retiró cuando venció la licencia de Airtable.

El catálogo tiene 283 habilidades, cada una con 4 niveles descritos, y 15 roles con nivel esperado. Cada persona responde entre 18 y 34 preguntas, según el rol. Dos rondas de verificación adversarial corrigieron 41 hallazgos, 7 de ellos bloqueantes. El trabajo también documentó errores del libro original: una búsqueda rota, roles faltantes y duplicados en el catálogo.

Lo que aún no prueba

Los datos de demostración usan perfiles ficticios. Todavía no he medido usuarios reales, evaluaciones completadas ni la tasa de finalización por ronda. El puntaje está corregido en el papel y en el portal; cómo se comporta en una ronda completa de evaluación aún no se sabe.

Qué haría después

Correr una ronda completa y medir usuarios reales, evaluaciones completadas y tasa de finalización. Después, revisar cuántas personas quedan cerca de un umbral y si la alerta cambia la forma en que los líderes leen los resultados.