Ir al contenido principal

QDD: una buena metodología para la comunicación

En el libro Ideal Executive, Adizes tiene una reflexión sobre algo que es bien interesante en el manejo de reuniones, creo que especialmente de "brainstorming", que es el QDD: Questions, Doubts, Disagreements.



La idea básica y copiada literalmente es:

'Questions' means you're asking for more information. 'What is this?', 'What is that"', 'What happened to this?', 'What happende to that?', 'How will this work?', 'How will that work?' You aren't expressing an opinion and don't necessarily have one; your're simply asking for more details.

'Doubts' means you have all the information you need but you're in doubt about wheteher it's going to work. Here you list your concerns.

'Disagreements' means you're not in any doubt; it's not going to work, and here's why.

Con ese marco Adizes desarrolla la dinámica de la reunión siguiendo el orden de: evacuar primero las Preguntas (Questions) de todos alrededor de un tema, de modo que quede claro para todos de qué se trata, luego las Dudas (Doubts) transformándolas en preguntas y ahí evacuarlas y finalmente los posibles Desacuerdos (Disagreements) pasarlos a Dudas/preguntas en la misma dinámica.

En resumen: la intención es ir moviendo todo hacia las "Preguntas", de algún modo todo se reduce a eso.

En mi experiencia el QDD es aplicable en muchos más contextos que una reunión de brainstorming, diría que en cualquier conversación (personal, telefónica, mail, etc) que implique algún "planteo" (90% de las que tengo a diario).

Creo que muchos de los conflictos que se dan son por una mala interpretación del tipo planteo, por ejemplo: se interpreta como "Desacuerdo" algo que en realidad era una "Pregunta" (o viceversa) o se dan porque la dinámica no llega a orientarse a las preguntas y se mantiene en la "duda" o "desacuerdo" donde todo es más "ofensiva/defensiva" en lugar de "constructiva". No es problema tener un Desacuerdo, lo incorrecto es tratar de resolverlo en ese plano y no en el de las Preguntas.

Es bueno, en esas interacciones entonces tener claro el tipo de planteo (QDD) y tratar de orientar la misma hacia la dinámica de las preguntas.

Partamos de un ejemplo, un diálogo entre dos personas que alternan los roles de emisor/receptor ¿qué considerar para que sea lo más sano/productivo?

Sea explicito con el QDD para que ambos sepan en qué "nivel" están y cómo seguir.
Comenzar la frase con "tengo una pregunta" deja en claro que lo que viene es una "pregunta" y no otra cosa, si comienza con "no sé qué pasaría con tal cosa" está explicitando una duda.

No solo es QUE se dice sino COMO se dice, el tono y el "body language" son fundamentales en esto. Por ejemplo si se dice "¿Te parece?", dependiendo de la entonación/body language puede ser una pregunta, una duda o una desacuerdo.
Si se dice "¿Tengo una simple pregunta...?" con determinada entonación puede ser claramente un Desacuerdo.
Por lo cual aunque las palabras no sean tan explicitas, otros medios pueden estar manifestando un nivel de QDD.

Exija siempre claridad en lo que se emite, del mismo modo que debe ser explicito cuando se es emisor, cuando se es receptor se debe tener claro el QDD, no se debe asumir que es una Pregunta cuando es un Desacuerdo, ni a la inversa. Si no es claro, aclárelo antes de continuar.

Considere siempre el contexto del otro, este contexto muchas veces induce a un nivel específico en el QDD. Por ejemplo, un adolescente tenderá siempre a plantear las cosas como Desacuerdos y eventualmente son Preguntas. Considerarlo ayudará a que entender en qué nivel de QDD estamos y proseguir de acuerdo a ello.

Use pero no abuse de los prejuicios, los prejuicios sirven porque ayudan a establecer el contexto, úselos para eso pero no para "encasillar" y suponer un nivel de QDD.Si bien el contexto que se mencionó antes es importante, el mismo no es determinante.

No trate de resolver una Duda o Desacuerdo si hay Preguntas antes. Si hay preguntas significa que hay carencia de información, si la hay primero resuelva eso y luego siga porque esa carencia muchas veces son la raíz de las Dudas/Desacuerdos.
Lo mismo aplica a trabajar sobre Desacuerdos cuando aún hay Dudas, muchas veces la raíz del Desacuerdo es la Duda.

La clave acá es la "escucha empática", sobre todo escuchar antes de hablar, por algo Dios (o la evolución) nos dio dos oídos y una boca.

No trate de resolver una Duda en ese nivel, llévela a Pregunta/s primero, la raíz de las dudas suelen ser preguntas. Acá creo que ayuda los "5 whys" de Toyota

Esta dinámica es mucho más productiva si es conocida/compartida por todos los que participan porque se entenderá bien la idea de la misma y es más fácil su aplicación.

Cuando de grupos se trata, la dinámica es la misma solo que hay que seguir un orden de participación. Tener práctica en la dinámica en grupos reducidos y comunicaciones de a dos, ayuda a que cuando se aplica en grupos más grande sea más fácil de seguir.

Comentarios

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en