Original de las yemas/vida de
Wardog------------------------------------------------
El
Tendero ha escrito
este post en el que dice que muchas veces cuando programamos nos olvidamos de que el usuario final puede que no tenga los conocimientos necesarios para hacer funcionar toda la aplicación. Dice que nos tenemos que centrar más en la usabilidad y no confiar en la capacidad del usuario final. Y no le falta ni pizquita de razón.
El usuario final puede ser un gran profesional y conocer todos los aspectos de su trabajo, y una aplicación funcional pero con usabilidad reducida no resultará un obstáculo en absoluto puesto que si conoce procedimientos y términos, al no resultarle extraños puede comprender la lógica de la aplicación.
Muchas veces, citando también al tendero, las aplicaciones se desarrollan ateniéndose a las explicaciones que se recogen de analistas expertos en la materia que se está informatizando y se deja de lado al usuario final.
Pero puedo aseguraros que no es mi caso. Eso ocurre en grandes aplicaciones y en grandes empresas. En Killminds la cosa es como más de andar por casa. El proceso de creación de una aplicación cualquiera es pelín característico de una DLCG (Dictadura Laboral Carente de Lógica). Atended:
Lo primero es identificar una necesidad. La necesidad puede ser, automatizar una tarea, simplificar procedimientos, controlar ciclos de vida… lo que sea. En Killminds es SIEMPRE un problema informático. Cuando algo no sale adelante, sea lo que sea, todas las empresas inteligentes buscan causas y soluciones. En Killminds se buscan responsables.
-¡Cómo que no sale ese pedido!
-Es que no encontrábamos bolsas.
-¡Cómo que no encontráis bolsas! ¡Buscadlas en el ordenador!
-No, si no las encontramos porque no se han comprado…
-¡Se va a enterar este!
¡Bip bup bip! ¡Trimpititrin!¡Trimpititrin!¡Trimpititrin!
-Sistemas…
-¡Wardog! ¡Por qué no se han comprado bolsas para el pedido 21097!
-Seguramente porque Lucky está repasando el presupuesto, el pedido y la cantidad de tóner que se ha gastado para imprimir ambas cosas, está mandando una paloma mensajera al proveedor para hacer el pedido y gastar menos teléfono y/o que se ha concentrado tanto en su trabajo que se ha olvidado de respirar y ha muerto.
-¡Menos coñas! ¡Haz un programa que avise de las bolsas que hay que comprar para servir los pedidos!
-Po venga.
Que me gusta programar a mí, oiga. Bueno, pasado el primer paso, que es identificar al responsable de que las cosas no se hagan, en este caso, el informático de la empresa, los demás pasos deben ir encaminados a resolver el problema. Yo lo que hago es identificar a los usuarios que intervienen en el proceso y los entrevisto uno por uno y por separado, en plan interrogatorio para sacar toda la información que pueda y encontrar contradicciones entre sus versiones para comprender, analizando todos los datos que me ofrecen, qué cosas se hacen bien, cuáles se pueden mejorar, eliminar o simplificar y cuáles se hacen rematadamente mal.
-A ver, Piterpol. ¿Tú cuándo pides bolsas?
-Cuando pido cajas.
-Bien. ¿Y cuándo pides cajas?
-Cuando se acaban.
-¿Y si sólo se acaban las bolsas?
-Espero a que se acaben las cajas.
Cágate, lorito.
-Aham. ¿Y si se acaban las cajas antes que las bolsas?
-Pido cajas.
-¿Y no podrías pedir las cajas y las bolsas por separado?
-No veo por qué, siempre se ha hecho así.
-Porque me parece una soberana gilipollez.
-Pues no, porque siempre se ha hecho así.
-Bien, vale, muchas gracias. Ya puedes marcharte, llama a Caganidos y que venga, por favor.
Ya vemos que el procedimiento cojea un pelín. Sigamos investigando en este hecho concreto que es el pedir bolsas.
-A ver, Caganidos, dime. ¿Cuándo pides bolsas?
-Ah, yo no las pido.
-¿No?
-No, ya hace Piterpol el cálculo de bolsas y las pide.
-Me cago yo en el cálculo ese…
-¿Cómo dices?
-No, nada… A parte de bolsas y cajas, ¿qué más cosas se piden?
-Bolsas, cajas, cierres, pegatinas, láminas, palets…
-Vale, gracias.
Definitivamente el proceso es incoherente. Se deja la responsabilidad de una tarea importante en manos de alguien que no es competente en ese aspecto. Luego, dada la necesidad de informatizar algo, en este caso la compra de bolsas, buscamos la forma de llevarlo a cabo. Pero antes de ponernos a trabajar, nos damos cuenta de que podemos usar la aplicación para resolver más problemas. Ya no la usaremos sólo para saber cuándo tenemos que comprar bolsas. Podemos incluir todas las materias auxiliares en el proceso. Total, lo que vale para bolsas, con cuatro cálculos más vale para cajas, cierres, pegatrinas, láminas y palets.
Averiguamos los cálculos que hay que hacer en función del producto que se fabrica y de las dimensiones y cubicajes de las materias auxiliares y hala, a programar. Se parematriza todo en función del producto y llegamos a la conclusión de que nos podemos aproximar mucho al cálculo de necesidades si lo enfocamos, obviamente, a la cartera de pedidos pendientes. Calculamos necesidades, restamos stocks y si sale un número por debajo de un mínimo, decimos que hay que pedir tal o cual cosa. A grosso modo, es eso.
Ahora vienen las interfaces chungas. La mayoría de los programas de Killminds tienen menos botones que el salpicadero de un troncomóvil. En este caso concreto, dos campos para fechas y un botón de “aceptar” para disparar el proceso que consulta todo y te imprime (leer en pantalla les duele) las necesidades de material auxiliar que debes pedir.
-Wardog, que este programa no funciona.
-¿Qué dice?
-No, si no dice nada. Es que sale mal.
-¿Cómo que sale mal?
-Sí, no sale que hay que pedir cierres.
-¿Ah no? Dame un segundo.
Miro el stock de cierres y veo que hay entre mucho y una burrada.
-Niño, que quedan chopocientosmil cierres. ¿Seguro que hay que pedir?
-No, si no hay que pedir.
-Pues por eso no sale.
-¿Y cómo sé yo que no hay que pedir cierres?
-Porque no sale en el listadito de cosas que tienes que pedir.
-No me fío. Quiero que salgan también las cosas que no hay que pedir.
Hala, a modificar el informe. Se hace una prueba y se presenta. Conforme.
-Wardog, que no funciona el programa este.
-¿Cómo que no?
-No. Me dice no se qué de fecha no válida.
-¿Qué fechas has puesto?
-Del uno de enero al treinta y uno de feberero.
-Ole tus cojones. Febrero tiene veintiocho días, muchacho.
-¿Y qué?
-Que no te riega, y que febrero no tiene 31 días.
-¿Y tengo que saber los días que tiene cada mes?
-No, déjalo, hombre, ya soluciono yo esto…
Porque lo principal es la usabilidad del sistema. Cambio los dos campos de fecha por dos bonitos calendarios perpetuos y hala, así no se equivocan.
¡Trimpititrin!¡Trimpititrin!¡Trimpititrin!
-Sistemas…
-Que esto no funciona.
-¿Cómo que no?
-Como que no. Quiero poner una fecha del año pasado y no puedo cambiar el año.
-Pincha en el año. Se abrirá un deplegable para que selecciones el año.
-¡Vaya programa complicado!
-La verdad es que sí. Teniendo en cuenta lo que debe hacer el programa, es complicado de cojones.
En fin, que como yo no sé hacerlo más fácil, ahí se queda y a base de insistir e insistir, de echarle paciencia y amor ( a la profesión), conseguimos hacer que la gente lo use correctamente. Fijáos que es sólo un ejemplo de una aplicación extremadamente sencilla para el usuario, independientemente de los cálculos y procesos que tenga que efectuar el núcleo del programa. La interfaz es sumamente sencilla, pero resulta que periféricos orgánicos de activación mecánica de la interfaz de entrada de datos los hay de dos clases: normales y adaptables.
De los normales, sobra decir nada. Los adaptables cambian su lógica de funcionamiento para hacer cada vez más difícil lo más fácil. Si una pantalla de una aplicación tiene un campo de texto y un botón, terminarás teniendo que quitar el botón o el campo de texto. Si la interfaz tiene sólo un botón, terminarás quitándolo, no sea que lo tengan que pulsar.
Esto lo podemos interpretar de dos maneras. Una, deprimiéndonos y suicidando lusers. No conviene. La otra es aprendiendo con ellos. Como son tan bestias, puedes tomártelo como un reto y depurar tus interfaces hasta que son sencillas de usar. Integrando instrucciones oídas, dibujitos, guías lógicas, etc. Es un gran reto y hay que aceptarlo.
¡Trimpititrin!¡Trimpititrin!¡Trimpititrin!
-Sistemas…
-Oye, que el programa este me saca un mensaje y no sé qué hacer.
-¿Qué dice el mensaje?
-¿Está seguro de que desea continuar?
-Vale. Y ahora dime qué botón has pulsado.
-No sé. Uno.
-Te odio.
Enchufar VNC. En pantalla se ve una ventana que muestra el mensaje antedicho y en el título de la ventana pone Eliminar Pedido. Ejemplo perfecto de interfaz mal diseñada. Hay que cambiar esa ventana porque nadie lee el título. Hay que cambiar el mensaje de advertencia.
¡Trimpititrin!¡Trimpititrin!¡Trimpititrin!
-Sistemas…
-Que sale un mensaje y no sé qué hacer.
-Jodeeeer… qué dice el mensaaaaje…
-¡Yo qué sé, es muy largo!
Enchufar VNC. Vemos un mensajito en pantalla que dice “Vas a eliminar un pedido. ¿Estás seguro? Si pulsas en SI, lo eliminarás; si pulsas en NO, no lo borrarás” Muy largo. Cambiamos el mensaje de nuevo.
¡Trimpititrin!¡Trimpititrin!¡Trimpititrin!
-¡Qué!
-Que he borrado sin querer un pedido.
-¿Y el mensaje de confirmación?
-¿Qué mensaje de confirmación?
-El que sale y dice “¿Borrar pedido?” y salen dos botones, uno con un “O.K.” verde y el otro con un “NO” rojo.
-Ah, pues yo le he dado al verde.
Es para matarlos. Si siguen vivos es por el reto. Por cierto, si hay algún experto en usabilidad, por favor, que me de consejos porque he probado de todo. Desde ocultar los campos que dependen de otros hasta que han introducido los campos de los que dependen, hasta pedir de viva voz lo que hace falta, parpadeos, dibujitos, calambrazos… Y el otro día cuando ví en un documental chimpancés que entendían frases completas como “pon el reloj dentro de la bolsa” y ejecutaban la orden, me puse a llorar como un niño pequeño.
