SKILL.md: Ingeniería de Sistemas Cognitivos para Diseño Complejo
licencia: Apache-2.0
metadata:
name: Ingeniería de Sistemas Cognitivos (CSE)
source: "The Role of Cognitive Systems Engineering in the Systems Engineering Design Process"
authors: Militello, Dominguez, Lintern, Klein
version: 1.0
activation_triggers:
- diseñar sistemas de agentes o arquitecturas de orquestación
- analizar por qué un sistema falló o está fallando a los usuarios
- descomponer tareas complejas para ejecución por IA o humanos
- elicitar requisitos de expertos en el dominio
- encontrar errores o comportamiento inesperado en trabajo cognitivo
- cuestionar si se está resolviendo el problema correcto
- diseñar para juicio experto, soporte de decisiones o automatización
- evaluar si una solución aborda el problema declarado o el real
Cuándo Usar Esta Habilidad
Carga esta habilidad cuando:
- Se está diseñando un sistema para apoyar la cognición humana — soporte de decisiones, orquestación de agentes, sistemas de información, automatización de experiencia
- Los requisitos parecen vagos, discutidos o cambian constantemente — esto es una señal de que los requisitos cognitivos son invisibles, no de que las partes interesadas estén confundidas
- Aparecen errores o fallos — trátalos como diagnósticos sobre supuestos de diseño, no como defectos que parchear
- El problema planteado parece incorrecto — cuando el espacio de soluciones parece no contener la respuesta real
- Es necesario capturar, replicar o apoyar la experiencia — y el experto "no puede explicar bien cómo lo hace"
- Un equipo o sistema distribuido debe coordinarse en trabajo cognitivo complejo — múltiples agentes, humanos, herramientas u organizaciones compartiendo carga cognitiva
- Se cuestiona el valor del trabajo de análisis — cuando las contribuciones cognitivas son invisibles frente a los entregables de ingeniería
Modelos Mentales Centrales
1. Los Requisitos Cognitivos Son Invisibles
Lo que los diseñadores asumen que los trabajadores necesitan y lo que los trabajadores realmente necesitan son sistemáticamente diferentes — y la brecha es enorme. Los profesionales expertos operan con conocimiento tácito, señales perceptivas, reconocimiento de patrones y conciencia de restricciones que no pueden articular fácilmente y que la sola observación no revelará. Cualquier proceso de diseño que no excave activamente estos requisitos construirá para un trabajador imaginario.
Implicación: La elicitación de requisitos debe usar métodos especializados (análisis de tareas cognitivas, método de decisión crítica, protocolos de pensamiento en voz alta), no entrevistas o encuestas. El artefacto de este trabajo es un modelo cognitivo del trabajo real, no una lista de características.
2. Los Errores Son Diagnósticos, No Defectos
Un error en un sistema cognitivo no es un mal funcionamiento — es una indicación precisa de dónde el modelo del sistema sobre el trabajo diverge de la estructura real del trabajo. El desajuste entre el comportamiento esperado y el observado es la señal con mayor densidad de información disponible para un diseñador.
Implicación: Cuando agentes, usuarios o sistemas conjuntos producen resultados inesperados, la primera pregunta es "¿qué revela este error sobre nuestros supuestos de diseño?", no "¿cómo eliminamos este error?"
3. El Diseño Es Diálogo, No Tubería
Los modelos de diseño secuenciales (requisitos → especificación → construir → probar) son pedagógicamente convenientes pero operativamente falsos. Los problemas complejos revelan nueva información a medida que los abordas. La declaración del problema con la que comienzas nunca es la declaración del problema con la que deberías terminar. Los intentos de fijar requisitos tempranamente suprimen el descubrimiento que los problemas complejos requieren.
Implicación: Las iteraciones no son fracasos de planificación. Revisitar el encuadre del problema a mitad del proyecto no es cambio de alcance — es el proceso funcionando correctamente. Incorpora puertas de reevaluación explícitas.
4. El Encuadre del Problema Es la Intervención de Mayor Apalancamiento
Lo más valioso que un análisis cognitivo puede producir es a menudo una reformulación del problema — no una mejor solución al problema planteado, sino evidencia de que el problema planteado es incorrecto. El caso de la planta nuclear: 80+ empleados reducidos a 35, cero nueva tecnología, simplemente entendiendo la estructura cognitiva real del trabajo.
Implicación: Antes de optimizar cualquier solución, invierte en verificar la declaración del problema. El costo de resolver el problema equivocado con alta calidad supera a casi cualquier otro error de diseño.
5. Sistemas Cognitivos Conjuntos, No Pares Herramienta-Usuario
La complejidad cognitiva reside en el sistema distribuido — los humanos, tecnologías, procesos y estructuras organizacionales que colectivamente realizan trabajo cognitivo. Ningún agente o herramienta puede diseñarse de forma aislada. Los mecanismos de coordinación, los flujos de información y la conciencia situacional compartida a través del sistema son donde se determina el éxito o fracaso cognitivo.
Implicación: Diseña las transiciones, no solo los nodos. Especifica los requisitos de modelos mentales compartidos entre componentes. Analiza cómo la automatización cambia la distribución de la carga cognitiva a través del sistema conjunto, no solo si la automatización funciona.
Marcos de Decisión
Diagnóstico de Problemas
SI un sistema está produciendo errores o comportamiento inesperado
ENTONCES carga: failure-modes-in-complex-cognitive-systems.md
→ Clasifica el modo de fallo antes de proponer una corrección
→ Pregunta: ¿Es esto sorpresa de automatización, problema equivocado, compartimentación, sobreespecificación o cuello de botella?
SI las partes interesadas no se ponen de acuerdo sobre los requisitos o estos cambian constantemente
ENTONCES carga: cognitive-requirements-are-invisible.md
→ El cambio es información: los requisitos cognitivos aún no se han hecho explícitos
→ Despliega elicitación estructurada antes de recopilar más requisitos
SI la solución propuesta parece resolver lo incorrecto
ENTONCES carga: problem-reframing-as-highest-leverage-intervention.md
→ Detén el trabajo de solución; invierte en encuadre del problema primero
→ Busca una reformulación que haga innecesarias las categorías actuales de solución
Proceso de Diseño
SI se está diseñando un sistema de agentes o arquitectura de orquestación
ENTONCES carga: joint-cognitive-systems-distributed-cognition.md AND cse-concept-map-for-agent-architecture.md
→ Mapea el sistema conjunto completo antes de diseñar cualquier componente
→ Diseña los mecanismos de coordinación y flujo de información primero
SI se está presionando para finalizar los requisitos antes de tener una comprensión adecuada
ENTONCES carga: design-as-dialog-not-pipeline.md
→ Distingue "fijar requisitos" de "tener un mejor modelo actual"
→ Propón puertas de reevaluación explícitas en lugar de bloqueo secuencial
SI se está diseñando para o alrededor del juicio experto
ENTONCES carga: expertise-recognition-and-tacit-knowledge.md
→ Aplica el modelo de Decisión Basada en Reconocimiento para entender cómo funciona realmente la experiencia
→ Planifica la brecha de articulación del experto en el trabajo de requisitos
Evaluación y Valor
SI se cuestiona el valor del trabajo de análisis cognitivo
ENTONCES carga: value-case-and-invisible-contributions.md
→ La paradoja: el buen trabajo de CSE se vuelve invisible (menos fallos, operación más fluida)
→ Usa indicadores adelantados, no solo recuentos de incidentes
SI una solución propuesta implica agregar tecnología o personal
ENTONCES carga: problem-reframing-as-highest-leverage-intervention.md
→ Verifica: ¿se ha utilizado un modelo cognitivo preciso del trabajo para validar esta solución?
→ El punto de referencia de la planta nuclear: ¿podría la reformulación del problema eliminar la necesidad del recurso propuesto?
Archivos de Referencia
| Archivo | Cuándo Cargar |
|---|---|
references/cognitive-requirements-are-invisible.md | Los requisitos parecen vagos o discutidos; diseñar para usuarios expertos; comenzar cualquier proceso de elicitación de requisitos; los métodos de investigación de usuarios están en cuestión |
references/design-as-dialog-not-pipeline.md | Presión para finalizar requisitos tempranamente; se cuestiona el proceso iterativo como ineficiente; el proyecto está en medio y la declaración del problema necesita revisión |
references/problem-reframing-as-highest-leverage-intervention.md | El espacio de soluciones no parece contener la respuesta correcta; las soluciones propuestas parecen costosas o desalineadas; necesidad de justificar pausar la ejecución para reformular |
references/joint-cognitive-systems-distributed-cognition.md | Diseñar sistemas multiagente o humano-máquina; analizar fallos de coordinación; evaluar cómo la automatización cambia la distribución de la carga cognitiva |
references/expertise-recognition-and-tacit-knowledge.md | Capturar conocimiento experto; diseñar soporte de decisiones; construir sistemas para replicar o asistir el juicio experto; el experto no puede articular cómo realiza el trabajo |
references/failure-modes-in-complex-cognitive-systems.md | Diagnosticar errores del sistema o comportamiento inesperado; pre-mortems de diseños propuestos; clasificar un fallo observado antes de responder a él |
references/cse-concept-map-for-agent-architecture.md | Mapear capacidades para un sistema de agentes; organizar funciones cognitivas entre componentes; resolver confusión terminológica entre marcos |
references/value-case-and-invisible-contributions.md | Justificar la inversión en análisis cognitivo; se cuestiona el valor del trabajo de CSE; medir resultados de sistemas que principalmente previenen fallos |
Antipatrones
Estos son los modos de fallo contra los que CSE advierte específicamente. Reconócelos temprano.
1. Diseñar para el trabajador imaginado Construir sistemas basados en cómo los diseñadores piensan que los expertos trabajan, no en cómo los expertos realmente trabajan. El trabajador imaginado es racional, tiene información completa, sigue procedimientos y toma decisiones como dice un libro de texto. El trabajador real no hace nada de esto.
2. Tratar errores como defectos en lugar de diagnósticos Parchear errores sin preguntar qué revelan. Un error corregido que no se entendió es una oportunidad perdida para corregir el supuesto de diseño subyacente — y una garantía de que el problema reaparecerá en una forma diferente.
3. Fijar requisitos antes de que se realice el trabajo cognitivo Los modelos de proceso secuencial crean presión para fijar requisitos tempranamente. En dominios cognitivamente complejos, esto garantiza que el sistema equivocado se construya de manera eficiente. La fijación temprana de requisitos no es disciplina; es cierre prematuro.
4. Compartimentación: optimizar componentes sin la visión del sistema conjunto Construir una herramienta excelente que rompe el flujo de trabajo de los humanos o agentes a su alrededor. Optimización local que degrada el rendimiento del sistema. La versión clásica: automatización que libera a un humano de una tarea pero lo deja sin conciencia situacional cuando la automatización falla.
5. Sesgo retrospectivo en el análisis de fallos Después de un incidente, diseñar solo para ese fallo específico. La claridad seductora de la reconstrucción posterior hace que los fallos parezcan más predecibles de lo que fueron — y enfoca la energía de diseño en el último fallo en lugar del siguiente.
6. Sobreespecificación que elimina la capacidad adaptativa Diseñar sistemas tan rígidos que los profesionales no pueden improvisar cuando la realidad se desvía del modelo. El trabajo complejo real requiere adaptación. La sobreespecificación hace que el sistema sea frágil precisamente en las situaciones donde la flexibilidad importa más.
7. El cuello de botella del experto por diseño Construir un sistema donde un solo experto (humano o IA) es la puerta de entrada requerida para todas las decisiones críticas. Incluso cuando ese experto es excelente, esto crea una fragilidad catastrófica. CSE aboga por distribuir la experiencia, no concentrarla.
Pruebas de Comprensión
Cómo saber si alguien ha internalizado realmente CSE en lugar de leer un resumen:
Dicen "los errores son interesantes" — no "los errores son problemas". Alguien que ha absorbido CSE trata un informe de fallo como una oportunidad de investigación, no como un ticket que cerrar.
Preguntan "¿es este el problema correcto?" antes de "¿cuál es la solución?" — y están dispuestos a dedicar tiempo real a esa pregunta incluso cuando retrasa el progreso visible. Han visto el caso de la planta nuclear y saben lo que puede valer la respuesta.
Resisten la fijación de requisitos sin análisis cognitivo — no como obstrucción sino porque entienden que fijar requisitos antes de entender la estructura cognitiva del trabajo es una forma específica, nombrada y predecible de construir lo incorrecto.
Piensan en sistemas conjuntos — al analizar un fallo o diseñar una solución, preguntan instintivamente "¿dónde se sitúa esto en el sistema cognitivo completo?", no "¿qué debería hacer este componente?"
Saben lo que cuesta el conocimiento tácito — no esperan que los expertos puedan decirles lo que necesitan saber. Han internalizado que la experiencia es en gran medida inaccesible a la introspección y planifican sus métodos de elicitación en consecuencia.
Tratan la naturaleza iterativa del diseño como señal, no como ruido — cuando una declaración del problema cambia a mitad del proyecto, lo leen como el proceso revelando algo real, no como un fracaso de planificación que gestionar.
Pueden nombrar los cinco modos de fallo — sorpresa de automatización, declaración de problema incorrecta, compartimentación, sobreespecificación, cuello de botella del experto — y los aplican de manera diagnóstica a situaciones novedosas, no como una lista de verificación.
Lo que no dicen: "Solo necesitamos mejores requisitos." "Si documentamos el proceso, el sistema lo seguirá." "Los usuarios solo necesitan capacitación." "Podemos evaluar la herramienta de IA independientemente de cómo la usen los operadores."
Carga los archivos de referencia bajo demanda según surjan situaciones específicas. La habilidad se activa con este archivo; el análisis más profundo requiere las referencias.