Todos los métodos
Problem SolvingAvanzado

Shared Problem Definition

Shared Problem Definition es un juego de roles en el que de cuatro a seis personas representan cada una a un profesional o a una organización distinta dentro de un proyecto con múltiples actores y avanzan paso a paso desde sus visiones separadas del asunto hasta un único enunciado del problema redactado en común. Lo documentó Edith van Ewijk para el Transition Makers Toolbox de la Universidad de Ámsterdam y la TU Delft, a partir de la investigación sobre el encuadre conjunto de problemas en proyectos interdisciplinarios. La secuencia es deliberadamente lenta: primero las tareas, luego la versión del problema de cada parte, después los puntos en común, las diferencias y las interfaces, y solo entonces una definición compartida.

Duración
4h–5h
Tamaño del grupo
4–6 people
Materiales
Fichas de rol y lecturas de contexto para cada rol profesional, Papel de rotafolio y marcadores, Notas adhesivas…

Guion de facilitación

  1. 1

    Presentar el caso, el objetivo y las reglas del juego de roles; confirmar quién interpreta cada rol.

    20 min
  2. 2

    Ronda de presentaciones dentro del rol: quién es cada persona y a qué organización representa.

    15 min
  3. 3

    Anotar en el rotafolio las tareas y los objetivos clave de cada organización, un rol a la vez.

    30 min
  4. 4

    Cada rol explica por qué el asunto es un problema para él; registrar todas las visiones del problema.

    30 min
  5. 5

    Comparar las visiones y anotar puntos en común, diferencias e interfaces.

    30 min
  6. 6

    Redactar la definición conjunta del problema a partir de los puntos en común y las interfaces, y probar la redacción con cada rol.

    15 min
  7. 7

    Pausa y, después, salir del rol.

    20 min
  8. 8

    Reflexión individual por escrito sobre qué tan bien comprendió cada persona a las demás y cómo fue la integración.

    15 min
  9. 9

    Puesta en común en plenaria: qué hizo posible una redacción compartida, qué quedó sin resolver y qué llevar al proyecto real.

    40 min

Consejos

  • Conviene mantener al grupo en el orden de los pasos.

  • Las mesas que saltan a las soluciones durante la ronda de tareas terminan con un enunciado del problema que en realidad es la medida preferida de una de las partes, disfrazada.

  • Hay que anotar las diferencias con el mismo cuidado que los puntos en común, porque le indican al proyecto dónde habrá que negociar más adelante.

  • Si alguien interpreta su rol como una caricatura, preguntarle qué perdería ese profesional si el proyecto saliera mal.

Errores comunes

  • Saltarse la ronda de tareas para ahorrar tiempo, de modo que las visiones del problema llegan sin los mandatos que las explican y el grupo interpreta las diferencias como terquedad

  • Dejar que el rol de mayor jerarquía o de mayor facilidad de palabra escriba la definición, lo que produce un enunciado que los demás toleran en la sala y abandonan después

  • Redactar una definición tan amplia que todos puedan firmarla, lo que oculta las diferencias y no le da al proyecto nada con qué trabajar

  • Una preparación superficial de los roles, que convierte la sesión en personas adivinando lo que diría un ingeniero o un urbanista

  • Eliminar la reflexión fuera del rol, con lo que los participantes recuerdan el contenido del caso y no lo que aprendieron sobre integrar perspectivas

Variaciones

La secuencia de la sesión también funciona con partes interesadas reales y sin el envoltorio del juego de roles: cada organización habla por sí misma y la preparación se reduce a traer su mandato y sus objetivos. Con un grupo más grande, se pueden llevar varias mesas en paralelo sobre el mismo caso y comparar las definiciones resultantes, o dejar que las personas adicionales observen una mesa e informen de lo que vieron. En remoto, usar un tablero compartido con una columna por rol y mantener una sola mesa por sala de video. Cuando dos días de preparación del rol no sean realistas, entregar una ficha de una página por rol y aceptar un resultado menos profundo.

Casos de uso

Arranque de proyectos con múltiples partes interesadasAlineación de proyectos entre departamentosPuesta en marcha de equipos interdisciplinariosFormación para el trabajo de transición e innovación de sistemasEnsayo de una negociación real entre partes interesadasEnseñanza del encuadre conjunto de problemas

Cuándo usarlo

  • Un proyecto reúne a varias organizaciones o disciplinas que describen el problema cada una en sus propios términos y aún no han notado que las descripciones difieren

  • Un equipo está por entrar en un proceso real con varias partes y necesita practicar la escucha de otros mandatos antes de defender el propio

  • Estudiantes o personal nuevo necesitan vivir lo difícil que es el encuadre conjunto antes de estudiar la teoría

  • Un proyecto anterior se estancó porque los socios acordaron una solución sin acordar qué debía resolver

  • Se dispone de al menos medio día y de participantes dispuestos a preparar un rol con antelación

Cuándo no usarlo

  • Un solo equipo necesita afinar su propio enunciado del problema: una Declaración de Punto de Vista o Los 5 Porqués es más rápido y no requiere roles

  • Los participantes no pueden prepararse y no saben nada de los campos que representarían, porque entonces el juego de roles se apoya en estereotipos; conviene usar primero un Mapa de Interesados para ubicar a los actores

  • Las partes reales están en conflicto abierto: ensayarlas en un rol puede endurecer las posiciones, y una conversación mediada con Comunicación No Violenta es el camino más seguro

  • Hay menos de tres horas y media: se recortan los pasos de comparación y redacción, que son la razón de ser del ejercicio

Métodos relacionados

Preguntas frecuentes

¿Qué es Shared Problem Definition?▾

Shared Problem Definition es un juego de roles para grupos de cuatro a seis personas en el que cada una representa a un profesional o a una organización distinta dentro de un proyecto con múltiples actores. La mesa anota las tareas de cada parte, registra cómo ve cada una el problema, compara esas visiones y luego escribe una única definición del problema redactada en común. Fue publicado por Edith van Ewijk en el Transition Makers Toolbox.

¿Cuánto dura Shared Problem Definition?▾

Hay que prever de tres horas y media a cuatro horas y media en la sala. La versión original añade unos dos días de preparación individual en los que cada participante estudia el campo que va a representar, lo cual es el mayor costo del método.

¿Se puede hacer con partes interesadas reales en lugar de personas que interpretan roles?▾

Sí. La secuencia de tareas, visiones del problema, puntos en común y diferencias, y redacción conjunta funciona sin el envoltorio del juego de roles. Cada organización habla entonces por sí misma, y la persona facilitadora debe prestar más atención a las diferencias de poder entre las partes que en un juego de roles en el aula.

¿Cómo es una buena definición conjunta del problema?▾

Son una o dos frases que todas las partes pueden leer en voz alta sin incomodarse, construidas a partir de los puntos que comparten las visiones y de los lugares donde las organizaciones dependen unas de otras. Nombra el problema y no una solución. Las diferencias que no se pudieron salvar se anotan al lado para que no se olviden.

¿En qué se diferencia de un juego de roles normal?▾

Un juego de roles habitual representa una escena y analiza después el comportamiento. Aquí los roles sirven a un análisis estructurado: el grupo produce rotafolios con tareas, visiones del problema e interfaces y termina con una definición escrita. La actuación es ligera y el resultado es un documento.

🪡

Planifica tu próximo taller con IA

Workshop Weaver te ayuda a combinar métodos como Shared Problem Definition en una agenda completa y cronometrada en minutos.

Probar gratis

Method descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Edith van Ewijk, Transition Makers Toolbox (University of Amsterdam / TU Delft).