Falacia ad carpentum

A la hora de la puesta en marcha eficaz de una instalación informática hay muchos aspectos que pensar, evaluar, discutir y concretar con varias personas.  Estoy acostumbrdao a reunirme o dialogar con compañeros, usuarios finales, responsable de alguna parcela, empresarios, asesores, colaboradores y hasta amigos.

Así que es habitual que intercambiemos argumentos a fin de tomar algunas decisiones.

Pues bien, y sobre todo cuando hablo con comerciales, me encuentro a menudo un 'argumento' que me resulta chocante.  Tantas veces lo he vivido que al final hasta le he puesto nombre.  Lo he llamado 'Falacia ad carpentum'.  El que lleve el título de falacia indica que me parece un argumento erróneo.

Recuerdo una de las primeras veces que lo viví.  Intentaba mejorar un proceso en la empresa, eliminando una práctica anterior, pero había una cierta inercia a continuar como antes. Comentaba el tema con el comercial que había gestionado la operación y él apostaba por no cambiar el sistema.  Argumentaba que era bueno el que tenían.  En mi opinión  no había por dónde cogerlo, así que le pregunté porque opinaba así.

Su respuesta fue llamativa:

Este hombre sabe lo que hace porque tiene un Mercedes que vale más de 90000 euros.

Desde entonces he oído lo mismo en más de una ocasión.  Bueno, lo mismo, lo mismo, no.   Parecido.   Otras veces era un Audi y en ocasiones ignoro la marca del vehículo, pero siempre son coches con precios muy altos.  

O sea, si te compras un coche de más de 40000 euros tus pensamientos adquieren una validez superior a los pensamientos  de personas con coches del montón.  Por ejemplo los dueños de coches de unos 15000-20000 euros no razonan tan bien como los de coches de 50000-60000 euros.

Parece que me estoy cachondeando del tema.  Bueno, en parte sí, es verdad. Pero en realidad lo estoy sufriendo. Todos los años me encuentro algunos de estos casos y me cuesta llevar la persona a un terreno más objetivo.  

La Falacia ad carpetum (no sé si me darán el honor de ser su inventor) es una variante de la llamada Falacia ad hominem en la que la verdad o falsedad de una afirmación se asume por la persona que lo enuncia. En este caso es, más concretamente, por el coche que tiene la persona que lo anuncia.

Dejo aquí mi explicación.  Ahora tengo que explicarle a un cliente que implanten el uso de pistolas de códigos de barras porque evitariamos bastantes errores de los que tiene y ahorraría tiempo y costes.   No sé si llevarle una hoja escrita con las ventajas o alquilarme un mercedes para visitarlo.

El primer paso para resolver un problema es enunciarlo

Intento en este artículo explicar una idea que transmito a menudo al personal de soporte de aplicaciones y otras necesidades informáticas.  A veces lo hago con éxito y a veces sin éxito.  Por eso espero que este texto pueda ayudarme en los casos difíciles.

La idea es simple.  El primer paso que debemos dar cuando recibimos un mensaje de un cliente con un problema informático es 'precisar el problema'

Antes de darte algunas nociones concretas te voy a poner un ejemplo de un problema mal informado y bien informado.  Seguro que sin decirte nada te das cuenta de ello:

• Problema 1: El programa no funciona
• Problema 2: Al imprimir una factura sale un mensaje de que 'Falta papel en la impresora' y la factura no se imprime.

No, no me lo he inventado.  El problema 1 fue una llamada que atendí hace unos años. El problema 2 es la misma llamada una vez que le pregunté al clientelo que ocurría.

Por cierto, a ver si adivinas como resolví el problema del cliente.  Bueno, te lo digo:  Le dije que pusiera papel en la impresora.  Que listo soy, ¿verdad?

¿Y tú como eres de listo?  Espera te lo voy a preguntar de otra forma.   Te hago dos preguntas

• Pregunta 1. ¿Sabrías resolver el siguiente problema?: El programa no funciona
• Pregunta 2. ¿Sabrías resolver el siguiente problema?: Al imprimir una factura sale un mensaje de que 'Falta papel en la impresora' y la factura no se imprime.

Algo me dice que el primero es complicado y el segundo no. Pues la diferencia está ni más ni menos que en lo que dice el título de este artículo: En enunciar el problema.

Y ahora vamos a dar algunas reglas.

No uses frases que no dicen nada

Lo primero es evitar enunciados vagos que no digan nada.  Los más habituales son cosas como:

• El programa no funciona
• El programa no me deja facturar
• No sale el listado de ventas

Concreta lo que pasa

En su lugar precisa el punto de la aplicación y lo que ocurre.  Si aparece un mensaje de error es evidente recogerlo.    A veces con leerlo se encuentra la solución.  No terías que pasa más de lo que piensas.  El caso que he citado antes (y que es verídico) es un ejemplo.  El mensaje de error te dice lo que pasa (falta papel, en nuestro ejemplo)

La siguiente lista te ayuda a concretar:

• En qué punto del programa estás
• Qué haces
• Qué pasa

Si te cuesta trabajo concretar ...

A veces el problema es que la persona con la que hablas no te concreta y no responde tus preguntas (por lo general por torpeza). En ese caso lo mejor es ir reproduciendo el proceso con el cliente desde el principio

Prestaciones Chernóbil

Una parte importante de nuestro trabajo con las aplicaciones informáticas es estudiar las prestaciones que nos piden los clientes, las que se nos ocurren, las que vemos en otras aplicaciones y las que se deducen de algunos procesos o problemas que nos encontramos.

Como es de suponer, surgen ideas muy interesantes, pero también  surgen ideas algo nefastas.  Por lo general nos gusta tomarnos con humor las segundas, pero desde luego tenerlas vigiladas.

Hace un tiempo hablé en este blog de las prestaciones leperas.  Hoy les toca a las prestaciones 'chernóbil'.

La definición de las prestaciones chernóbil son peticiones que hacen algunos usuarios de anular avisos o elementos de seguridad que les resultan molestos porque aparecen más veces de las que consideran adecuadas o en momentos que dicen no se deben tener en cuenta

Y ... ¿sabes porque le llamamos chernóbil?  Sí, justo, por eso ... porque luego explotan.

O sea, en realidad no llamamos así a las peticiones de quitar mensajes que sobran, sino las de eliminar los que no sobran porque pueden ser muy importantes.

Dos soluciones para un problema

Problema

Un usuario se encuentre sentado delante de una mesa con un ordenador.  El problema es que no llega al teclado y no puede trabajar.

Solución 1

Para que la persona llegue cómodamente a usar el teclar es necesario acercar la mesa algo más de 1,5 mts.  Pero al separar la mesa de la pared surgen varios problemas.  El primero que el cable de alimentación no llega al enchufe de la pared.  El de red tampoco.  

Habrá que sustituirlos, así que es necesario medir con más exactitud la distancia que hay que desplazar la mesa.  Medimos 1,60 mts.  

Compramos cable de alimentación y de red más largos, pero hay un problema, no descansan en el suelo, con lo cual al pasar por detrás de la mesa (al separarla de la pared se ha creado un pasillo de casi dos metros de ancho) alguien puede tropezar y tirar el ordenador.  

Podemos colocar el ordenador en el suelo y pegar el cable de alimentación y de red con una regleta al suelo.  La pega es que entonces el teclado no llega a la torre.  Una de dos o compramos un teclado con un cable o lo sustituimos por uno inalámbrico.

La solución de la regleta en el suelo no resulta óptima, provoca algún que otro tropiezo además de que estéticamente resulta inadecuada.  Lo solucionamos con un albañil que realiza un cambio en el suelo permitiendo entrar el cable por un sitio y salir más cercano a la pared.

Ya casi está listo.  Ahora la luz de la pared no incide adecuadamente en la mesa.  Pero basta con comprar una nueva lámpara y listo.  Eso sí como necesita una alimentación eléctrica el albañil debe intervenir de nuevo.

Ha quedado un problema importante.  No aprovechamos bien la luz de la ventana.  No queda más remedio que asumirlo y gastar un poco más de luz eléctrica porque si no el coste de mover la ventana es grande. En todo caso dejamos como mejora de futuro el traslado de la ventana.

Listo.  Hemos resuelto el problema en pocos días y un coste de unos pocos cientos de euros.

Solución 2

Acerca la silla a la mesa.

Listo.  Solución inmediata y sin coste

Conclusiones

Pensarás que estoy de broma y aunque en una parte es verdad, lo que comento es el día a día de mi trabajo.   Soluciones complejas contra soluciones sencillas.  No solo los usuarios optan a menudo por acercar la mesa a la silla, sino que encima cree que con eso demuestra que la solución no era tan sencilla como se le decía ... ¡y no está dispuesta a probar lo de la silla!

De forma más exacta yo llamo a esto las dos vías de soluciones: La complicada y la sencilla.  Empleo mucho tiempo intentando convencer a la gente que pruebe la solución sencilla.  A veces lo consigo y a veces no.

Y de una forma más metafórica y abreviada le digo a la gente que opte por acercar el taburete al piano o el piano al taburete.  De momento la mayoría vota por lo segundo.

El que no me crea, que vea los resultados de las elecciones en España.

La importancia de los problemas

En nuestros procedimientos del servicio de soporte tenemos que tomar algunas decisiones según las importancia de los problemas.  Y más de una vez me han preguntado como evaluar la importancia de un problema.  Llaman dos clientes con problemas distintos y uno puede ser importante y el otro no.  ¿Cómo saberlo?

Es algo similar a la labor que debe hacer el responsable de un servicio de urgencia en un hospital. Recibe un enfermo y tiene que asignarle prioridad según la importancia de la dolencia.  Quizás haya casos claros.  Alguien puede llegar con un resfriado y otra persona puede tener un infarto.  Pero en otras ocasiones puede ser algo difícil distinguir un malestar sin importancia de una dolencia grave.

Alguien puede pensar que el criterio para decidir que un problema de un cliente es importante es que el cliente te diga que es importante.  Es un dato sí, pero solo un dato.  Seguir ese criterio potenciaría los hipocondríacos en los hospitales y ocasionaría algún que otro muerto.  En informática supondría un mal servicio.  Es un dato, insisto, a tener en cuenta, no lo evites ni lo desprecies, pero no te quedes en él.

En realidad hay datos más relevantes.  El primero es el coste del problema.  El coste puede ser de tiempo o de dinero (porque se pierdan ventas) Dos ejemplos:

• 1.- La aplicación se ha vuelto lenta.  Pido el balance y tarda 2 minutos cuando antes tardaba 10 segundos
• 2.- La aplicación se ha vuelto lenta. Al meter las líneas de ventas se para y tengo que esperar 5 segundos para pasar a la siguiente.

¿Cual es el más importante? En realidad depende de las circunstancias. Pero en un caso típico una empresa típica (que no sea una asesoría) sacará un balace ese día, no más y tendrá que escribir cien, o incluso mil líneas de ventas (piensa en un supermercado).   Así que:

• 1.- Coste 2 minutos 
• 2.- Coste 500 x 5 segundos = 2500 segundos =  42 minutos 

Recuerdo un caso curioso.  Un cliente nos llamó porque no le funcionaba un proceso de importación de unas facturas de compras desde otro ordenador.  Había hecho una importación de muchos datos y todo había ido bien menos ese fichero.  Vimos que efectivamente había alguna pega porque el proceso no terminaba.  Estuvimos investigando y en un momento determinado tras varias pruebas y una conexión remota decidimos copiar el fichero para ver el motivo.  Al verlo pensamos que había algún problema en la copia.  Tenía muy pocos bytes, así que deducimos que estaba corrupto o algo parecido.  Accedimos de nuevo, pero no, parecía que todo bien.  Resulta que lo que quería importar era ... una factura con una línea.  En escribirla a mano hubiera tardado 15-20 segundos y llevábamos más de una hora solucionando el problema. Era algo que no era necesario repetir en el futuro, puesto que no habría más cambio de ordenador al menos en años.

En segundo lugar, detrás del coste, debes considerar las consecuencias. Hay errores que permiten trabajar, el usuario los considera poco importantes y sin embargo pueden tener consecuencias a largo plazo.  Ejemplo, un aviso de errores detectados en el disco duro de un ordenador.  El aviso significa que puedes seguir trabajando pero ... ¡que en un rato te puedes quedar sin información!

Una breve iniciación al uso de Linux en servidores

Me pide un compañero que le facilite algunas nociones para manejar uno de nuestros servidores en la red.  Se trata de un ordenador con Linux (concretamente Ubuntu) que se encuentra en un centro especializado en Madrid.  Mi compañero es un informático habituado al uso de Windows y otras herramientas.   Así que recojo algunas notas que aunque son elementales van orientadas a un público especializado

Acceso al ordenador

Lo primero de todo es acceder remotamente al ordenador y abrir una sesión de trabajo. La sesión será muy parecida al procesador de comando de Windows.  

Normalmente se accede por SSH, que significa 'Secure SHell' (lo traducimos como 'intérprete de órdenes seguro').   El programa más conocido para usar un acceso SSH ahora mismo es Putty.  El nombre PuTTY es una abrevitura.  Pu: Port unique TTY: terminal type. Su traducción al castellano sería: Puerto único de tipo terminal. Así que descargamos Putty y lo instalamos.

Una vez instalado PuTTY lo ejecutamos y escribimos los datos necesarios para el acceso que pueden guardarse para el futuro.  Estos datos son los siguientes:

Host Name (or IP adress): Justo lo que indica (aunque lo indica en inglés). Debemos poner o bien la IP del ordenador o bien una URL que lo identifique.  Lo mejor es usar lo que vaya a ser más estable.   Si tenemos un servidor accesible en 'nuestroservidor.com' y creemos que el dominio continuará por largo tiempo puede ser lo más cómodo.

Port: El puerto de acceso.  Por omision es el 22
 
Connection type:  Pues tal y como estamos comentando, vamos a usar una conexión SSH.

Una vez que pulsemos el botón de acceso aparecerá la pantalla del terminal, una pantalla que recuerda al llamado 'Símbolo del sistema' o 'Gestor de comandos' de Windows o el antiguo MSDOS.   

El primer mensaje de la pantalla será:

login as:
 
Debemos escribir el nombre de usuario.  El usuario principal de una instalación Linux es root y por lo general no debemos usarlo nada más que en caso excepcionales.   Tras el usuario se nos pide la clave y si todo ha ido bien aparecen unos mensajes informativos y el 'prompt' del sistema.  Este puede ser algo así como:

usuario@eiservidor65:~$
 
Ya tenemos listo el ordenador para escribir órdenes

Algunos comandos básicos

Los comandos de Linux recuerdan algo a los de MSDOS (bueno, históricamente la verdad es que los comandos de MSDOS recordaban a los de Unix), aunque solo ligeramente.  

Antes de nada debemos saber que nos encontramos en un ordenador con un estructura de ficheros organizados en árbol de carpetas (o directorios, que son sinónimos).  Como he dicho al principio me dirijo a una persona con ciertos conocimientos informáticos y por ello voy a prescindir de explicar lo que son ficheros, carpetas y como nombrarlos.  Lo doy por conocido.

Los comandos se teclean junto con sus opciones, que se identifican por ir precedidos de un guión y los argumentos, que en algunos casos son obligatorios y en otros opcionales.

Un ejemplo de comando es:

ls -l datos*.*
 
El comando es 'ls'.  Se ejecuta con la opción 'l'  y el argumento es 'datos*.*'.  Ahora veremos que significa.

Casi todos los comandos tienen la opción --help  que  muestra su ayuda.  Así para ver la ayuda del comando ls que acabamos de citar escribiriamos lo siguiente:

ls --help

Vamos a ver 8 comandos básicos.

ls     

El comando ls sirve para listar los ficheros del directorio en el que nos encontramos.  Se usa con la siguiente sintaxis

ls -[opciones] [ficheros]

presenta una lista de todos los ficheros que incluye [ficheros] y que puede tener comodín, por ejemplo da*.* indica todos los ficheros que comienzan por da.  *.txt todos los ficheros cuyo sufijo es .txt

las opciones más usuales son las siguientes:

l Presenta la lista en formato largo, es decir con una información adicional de los ficheros.

s Incluye el tamaño de cada fichero en bloques

p Añade el símbolo / a los directorios

R incluye el contenido de los subdirectorios en modo recursivo

t Ordena por fecha de modificación, colocando primero el más reciente.

cd

El comando cd permite cambiar de directorio.  Su sintaxis es muy simple:

cd   -[opciones] [directorio]

Como puedes imaginar nos cambia al directorio indicado.

mv

El comando mv sirve principalmente para dos cosas aparentemente distintas: Mover un fichero o conjunto de ficheros de directorio y cambiar el nombre a un fichero.

Su sintaxis es la siguiente:

mv  -[opciones] [fichero1] [fichero2]

Para renombrar fichero1 y fichero2 deben ser dos nombres exactos de ficheros (esto es sin comodines ni que sean carpetas), el fichero1 debe existir y tras ejecutar el comando su nombre será fichero2, que, lógicamente no existirá antes.

Para mover ficheros fichero1 debe ser un fichero o conjunto de ficheros (podemos usar comodines por tanto o carpetas) y fichero2 será un directorio.

cp
Su sintaxis es:
cp -[opciones] [fichero1] [fichero2]  
Copia el fichero1 al fichero2. Si existe el fichero2 será sobreescrito, en caso contrario se crea.
 

df

df facilita una información del uso del almacenamiento, indicado el espacio consumido y el espacio libre.  Es fundamental para controlar el estado del ordenador. 

service

service permite controlar los servicios  parándolos o poniendolo en marcha.

Para parar un servicio escribimos lo siguiente:

service [servicio] stop

y para ponerlo en marcha

  

service [servicio] start

sudo

Este comando permite ejecutar otro con privilegios de administrador.

sudo [comando]

apt-get

Esta utilidad permite entre otras cosas actualizar el sistema operativo.  'apt' son las iniciales de Advanced Packaging Tool (Herramienta Avanzada de Empaquetado).  Debe ejecutarse con privilegios de administrador.

Hay dos usos que conviene que sepas. Uno permite descargar las novedades y el otro instalarlas.   Normalmente se ejecuta uno y a continuación el otro, pero atento a los posibles mensajes que aparezcan
 
sudo apt-get update
sudo apt-get upgrade

du

Permite conocer el espacio ocupado por carpetas y ficheros.  du son las iniciales de Disk space
Su uso es bien simple:
du [opciones] [carpetas o ficheros]
Como opciones conviene destacar
- h muestra los datos de forma más cómoda, usando las letras K, M, G para Kilobytes, Megabytes, Gigabytes, en vez del número completo de bytes. La h es de human, para que los humanos podamos entender.
- s muestra solo el total