ES
Modelo mecánico transparente conectado a cuatro módulos pequeños mediante piezas y conductos azules.

Cómo validar que una arquitectura representa el trabajo real

Para validar una arquitectura de skills, confronte sus definiciones con decisiones, entregables y situaciones reales antes de utilizarla para evaluar personas.

PRYSMAP5 min de lectura

Antes de comenzar, defina el alcance de la validación. Seleccione un track, los roles que contiene y los usos que tendrá el modelo. Intentar revisar toda la organización a la vez transforma una prueba verificable en una discusión interminable sobre nombres.

El objetivo no es demostrar que el catálogo puede describir cualquier actividad. Es comprobar si representa el trabajo relevante con precisión suficiente para diferenciar contribuciones y sostener las decisiones previstas.

Elija situaciones que exijan algo distinto

Reúna trabajo frecuente, excepciones que hayan requerido criterio y situaciones poco habituales con consecuencias importantes. Un entregable final aporta información, pero rara vez permite reconstruir por sí solo cómo se produjo.

Para cada situación, identifique el resultado esperado, las restricciones disponibles y las decisiones que cambiaron el recorrido. Registre quién tenía autoridad, qué información faltaba y cuándo fue necesario pedir apoyo.

La Office of Personnel Management conecta el análisis del trabajo con tareas reales, competencias requeridas y la relación entre ambas. Ese vínculo orienta la validación hacia exigencias observables, en lugar de limitarla a opiniones sobre etiquetas. U.S. Office of Personnel Management: Job Analysis.

Los casos deben ser suficientemente diferentes. Si todos representan la operación habitual, la arquitectura puede parecer adecuada y fallar ante una excepción. Si solo se eligen incidentes extraordinarios, puede sobrerrepresentar capacidades que rara vez organizan el trabajo cotidiano.

Reconstruya primero; clasifique después

Pida a las personas involucradas que expliquen la secuencia completa. ¿Qué ocurrió? ¿Qué alternativa consideraron? ¿Cuál fue la decisión difícil? ¿Qué consecuencia debían anticipar?

No abra todavía el catálogo. Cuando las etiquetas aparecen demasiado pronto, las personas tienden a acomodar el relato dentro de categorías conocidas. Esa operación puede ocultar contribuciones que el modelo no representa bien.

Una misma situación puede combinar análisis, coordinación, gestión de riesgos y comunicación. Comprenda primero cómo se relacionaron esas contribuciones. Después examine qué skills permiten describirlas sin duplicar nombres ni fragmentar artificialmente el trabajo.

Si dos participantes recuerdan episodios distintos, conserve la discrepancia hasta aclararla. Un desacuerdo sobre los hechos no se resuelve negociando una clasificación común.

Pruebe las skills compartidas y las diferencias entre roles

Los roles de un mismo track deben conservar el mismo conjunto de skills. Se distinguen por la profundidad, la autonomía, la complejidad, el alcance, el liderazgo y el impacto esperados.

Tome una situación representativa y preséntela a personas que ocupan dos roles del track. Pregunte qué resolverían directamente, cuándo necesitarían apoyo y por qué consecuencias deberían responder.

Dos técnicos revisan y ajustan un mecanismo sobre una mesa en un taller de bicicletas.

Si ambos roles describen exactamente la misma contribución, la distinción de nivel puede ser nominal. Si uno integra más variables, resuelve excepciones y responde por efectos más amplios, la diferencia pertenece a la expectativa, no a un catálogo distinto. La distinción entre amplitud, profundidad e integración permite probar si la configuración responde a la demanda sin fijar una identidad.

Revise también el recorrido inverso. Seleccione una skill y solicite evidencia de dónde se manifiesta. Cuando nadie logra asociarla con decisiones o resultados identificables, puede estar mal ubicada. También es posible que los casos seleccionados hayan dejado fuera una situación relevante.

Esta comprobación amplía la distinción desarrollada en Una lista de skills no es una arquitectura: las relaciones del modelo solo adquieren valor cuando explican trabajo reconocible.

Diagnostique el desacuerdo antes de modificar el modelo

Dos especialistas pueden asignar niveles diferentes al mismo episodio por razones muy distintas. Quizás uno observó el resultado y otro conoció el proceso. También pueden haber usado anclas ambiguas o comparado contextos con diferente autonomía.

Conviene separar al menos cuatro posibilidades:

  • falta información sobre el episodio;
  • la definición admite interpretaciones incompatibles;
  • los casos tienen complejidad diferente;
  • la responsabilidad pertenece a otro rol o track.

Cada origen pide una respuesta específica. Reunir evidencia, ajustar una definición y cambiar el alcance no son decisiones equivalentes. Tampoco corresponde convertir la ausencia de información en un déficit comprobado.

Registre el cambio y vuelva a probar

Documente la situación examinada, el problema detectado, la información reunida, la decisión adoptada y quién responderá por su seguimiento. Mantenga el registro limitado al propósito acordado.

La lista de comprobación de la OPM incluye la documentación de tareas y competencias relevantes para sostener decisiones posteriores. En una arquitectura corporativa, esa trazabilidad permite explicar por qué una definición se conserva, se modifica o se retira. U.S. Office of Personnel Management: Job Analysis Checklist.

Si cambia una skill compartida, revise sus efectos sobre todos los roles del track. Después repita la prueba con otra situación. Una modificación que corrige un caso excepcional y vuelve incomprensible el trabajo habitual todavía no está lista.

Una arquitectura validada no necesita anticipar cada excepción futura. Debe representar el trabajo conocido, distinguir contribuciones y hacer visible qué evidencia falta cuando aparece una situación nueva.

Para ampliar esta lectura, pueden consultarse El organigrama no es un mapa del trabajo y Cómo escalar después del piloto sin perder calidad, que desarrollan dimensiones complementarias del problema.