TdD: Desacreditar al interlocutor

0

Hoy comienzo una nueva serie de artículos sobre técnicas de debate (TdD). Siempre me han apasionado las técnicas de debate, que sirven para que una de las partes pueda imponer su opinión o verdad al resto, sin necesidad de que realmente la tenga. Ya no tanto para utilizarlos, porque considero que es jugar sucio, sino para evitar que los usen en contra mía.

Como gestores de TI, tendremos muchas decisiones que tomar. O tendremos que moderar muchas tomas de decisiones. Así que es vital conocer estas técnicas, o si no se colarán en estas reuniones y corremos el riesgo de tomar malas decisiones.

La técnica de hoy es sobre la falacia Argumento ad hominem, o lo que es lo mismo, desacreditar al contrario.

¿Qué es una falacia?

Primer artículo sobre falacias, y es posible que el lector no sepa qué es una falacia. Una falacia es algo que parece verdad sin necesidad de que lo sea. Es una afirmación que parece lógica y que parece que conduce a la verdad, pero que si te la paras a analizar no implica realmente que sea verdad. Un ejemplo:

Un servidor comienza a aumentar el consumo de memoria enormemente. Termina cayendo y se reinicia. El administrador afirma que hay un error en el código que provoca una fuga de memoria, porque cuando hay una fuga de memoria el servidor se comporta exactamente como se ha comportado.

Estamos delante de una falacia por parte del administrador. Que una fuga de memoria provoque ese comportamiento no implica que ese comportamiento sea necesariamente debido a una fuga de memoria.

Esta es quizás muy obvia y no suele colar. Además, por mucho que le moleste al desarrollador, el admin suele tener razón (aunque no siempre).

Argumento ad hominem

Consiste en desacreditar al interlocutor para considerar falsa su afirmación. Es decir, si consigues desacreditar a alguien, todo lo que haya dicho queda en tela de juicio. Por supuesto que el interlocutor no sea confiable no implica necesariamente que su afirmación sea falsa.

Por ejemplo, imaginemos que en el caso del ejemplo anterior se demuestra que el consumo de memoria fue debido a un pico de demanda y no a un memory leak. A las tres semanas el admin detecta conexiones abiertas a base de datos. El desarrollador no está de acuerdo y saca a la mesa el fallo del admin con el aumento de memoria, para desacreditarlo y decir que él tiene razón cuando habla de las conexiones abiertas. Nada tiene que ver si el admin se equivocó o no hace tres semanas para que en este caso tenga razón o no.

Usos en TI

En TI este argumento es muy utilizado en los siguientes casos:

  • Expertise técnico.
  • Antigüedad en el puesto.
  • Negocio o TI inválido.

Expertise insuficiente

Este caso es el más común de todos. El senior impone su criterio sobre el junior, sólo por categoría. No justifica, simplemente porque el opine así, se considera la verdad o mejor opción. En estos casos el senior debería aprovechar su seniority para obtener argumentos que validen su posición, y no aprovecharse de su condición de senior.

Este caso se ve mucho y suele pasar desapercibido. No por ser senior se está en poder de la razón.

Aunque tengo que decir que en el caso de intuiciones (cuando no hay argumentos para la decisión) la condición de senior debería tenerse en cuenta.

Antigüedad en el puesto

Aquí no hablamos de ser más senior o no, hablamos del recién llegado. Es algo que yo, como recién llegado a una empresa me encuentro continuamente, y con lo que tengo que lidiar. Como eres el nuevo, no sabes “de qué va esto” o no sabes “cómo funcionan las cosas aquí”. He sido consultor, y es algo que también me he encontrado cada vez que comenzaba un proyecto con un cliente nuevo. Así que necesitas doble refuerzo de argumentos.

Negocio o TI inválido

En una conversación entre negocio y TI, es fácil que si el tema de conversación se decanta a uno de los lados, se aproveche la fuerza que se tiene para desacreditar al otro. Es el típico caso en el que por ejemplo negocio pide algo a TI y TI le contesta, sin argumentarlo, que no. Y muchas veces el argumento es vago como “no es tan fácil”. Y lo mismo puede pasar al revés. En que TI pide algo y negocio decide sin argumentar con un simple “es que no entiendes del negocio”.

Ni negocio sabe tan poco TI, ni TI sabe tan poco de negocio.

Protegernos y no abusar

La primera lección cuando identificamos esta falacia es no caer en la tentación de usarla nosotros mismos. Si hay que rebatir una hipótesis, que sea con argumentos, no atacando a quien la afirma.

La segunda es cuando al otro lado vemos que tenemos a alguien con facilidad para usarla. Es decir, cuando es más experto que nosotros o más antiguo. O cuando vamos a hablar de algo que teóricamente se escapa de nuestro ámbito. En estos casos es posible que el otro lado no nos dé la oportunidad de demostrar nuestra afirmación cortando el tema y haciendo uso de la falacia. Entonces, si vemos el riesgo, conviene comenzar por los argumentos y no por la afirmación, para evitar que nos corten antes de empezar.

Debo añadir que la gran mayoría de las veces, cuando se usa esta técnica no se sabe que se está usando. Es decir, cuando alguien nos desacredita para tirar por tierra una afirmación no lo suele hacer fríamente, sino porque le parece lógico. Este es el peligro de esta falacia. Así que si nos la usan, no debemos tomarlo a lo personal, sino aprender para que no nos vuelva a pasar.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...