El elemento más lento de tu aplicación puede ser... una persona.
Cuando una empresa dice que su aplicación es lenta, la primera reacción suele ser muy técnica. Hay que revisar el servidor. La base de datos. La API. Las consultas SQL. La caché. La infraestructura. El tamaño de los archivos. JavaScript. El tiempo de respuesta de los distintos servicios.
Y con razón. El rendimiento técnico es de enorme importancia.
Solo que a veces todos los gráficos se ven bien, el servidor responde rápido, la aplicación carga en un tiempo razonable y, aun así, los usuarios siguen diciendo: "Esto tarda demasiado."
Y entonces surge una pregunta más interesante. Quizá la aplicación en realidad no es lenta. Quizá simplemente obliga a la persona a esperar.
2 segundos de respuesta, 20 minutos de trabajo
Imaginemos a un empleado que tiene que preparar una oferta para un cliente.
El sistema funciona bien. Cada pantalla se abre rápido. No hay errores. El servidor responde casi al instante.
Solo que para preparar la oferta, el empleado tiene que: abrir al cliente, ir al pedido, copiar el número de producto, abrir otro módulo, buscar el producto, volver a escribir los datos, regresar a la primera pantalla, elegir la categoría, ir a la siguiente pestaña, obtener los precios, comprobar manualmente el descuento, copiar el resultado a Excel y, después, volver a introducirlo en el sistema.
Cada operación individual puede tardar unos segundos.
Técnicamente todo funciona de maravilla. Solo que todo el proceso lleva 20 minutos.
Y precisamente aquí la comprensión clásica del rendimiento deja de ser suficiente.
Porque al usuario no le interesa principalmente el tiempo de respuesta de la API. Le interesa el tiempo necesario para completar una tarea.
El rendimiento técnico es solo el comienzo
El rendimiento de un sistema se puede medir de muchas maneras.
Podemos analizar el tiempo de respuesta del servidor, el tiempo de carga de la vista, las consultas a la base de datos, el uso de memoria, la carga de CPU o las latencias entre servicios.
Estas son métricas muy importantes. Pero existe también una segunda capa.
Perceived performance, es decir, el rendimiento percibido por el usuario.
Y todavía más ampliamente se puede mirar el operational performance, es decir, lo rápido y eficazmente que una persona puede completar una tarea real usando el sistema.
Y precisamente en esta última capa las empresas muy a menudo pierden más tiempo. Porque se puede construir una aplicación extremadamente rápida que siga siendo una herramienta de trabajo lenta.
El sistema más lento a veces son siete pantallas
Supongamos que un empleado gestiona una reclamación.
El sistema requiere siete pasos.
Primero abrir al cliente.
Luego el pedido.
Después el producto.
Más tarde el formulario de reclamación.
Luego la categoría del problema.
Después la decisión.
Al final la confirmación.
Cada pantalla carga en 0,5 segundos.
Desde el punto de vista del desarrollador, todo puede parecer muy bien. Pero el usuario realizó siete transiciones, cambió de contexto siete veces y tuvo que pensar siete veces qué hacer después.
Si hace docenas de estas operaciones al día, el problema deja de ser una cuestión de comodidad. Se convierte en un coste. Y no se trata solo del tiempo frente a la pantalla. Se suman el cansancio, el número de errores, la necesidad de corregir datos, las tareas interrumpidas y la creciente carga del empleado.
Un formulario con 40 campos no es rápido solo porque se abra enseguida
Este es uno de los ejemplos clásicos.
El formulario se abre al instante. - Genial.
Solo que el usuario tiene que rellenar 40 campos.
Parte de la información la empresa ya la tiene.
Parte se puede obtener del CRM.
Parte se puede calcular.
Parte depende de respuestas anteriores.
Y aun así el sistema vuelve a preguntarle todo a la persona.
Entonces el problema no es el rendimiento de la aplicación.
El problema es el diseño del proceso y de la interfaz.
Un buen sistema debería aprovechar los datos que ya posee.
Si el cliente proporcionó la dirección de entrega en un pedido anterior, ¿por qué el empleado tiene que volver a introducirla? Si el sistema conoce la empresa del cliente, ¿por qué el usuario tiene que volver a seleccionar sus datos? Si la respuesta a la primera pregunta excluye la mitad de los campos siguientes, ¿por qué todos están visibles desde el principio?
A veces la mejor manera de acelerar una aplicación no es optimizar el código. Es eliminar el trabajo que el usuario no debería hacer.
Lo más caro es el tiempo de una persona multiplicado por la escala
Un minuto extra puede parecer nada.
El empleado realiza la operación 5 veces al día. - 5 minutos.
A escala mensual, eso suma más de 1,5 horas.
¿Pero qué pasa si lo hacen 20 personas? ¿Qué pasa si la operación ocurre 30 veces al día? ¿Qué pasa si afecta a todo el departamento? ¿Qué pasa si el sistema se va a usar durante los próximos cinco años?
Entonces un solo minuto deja de ser un minuto. Se convierte en un coste operativo.
Por eso, al diseñar un sistema para una empresa, conviene preguntar no solo: "¿Cuánto tarda en responder el servidor?"
sino también: "¿Cuánto tiempo necesita una persona para terminar la tarea?"
Son dos preguntas completamente diferentes.
El sistema puede ser rápido y el proceso lento
Este es un problema aún más amplio.
Imaginemos un proceso de compra en una empresa.
- El empleado presenta una solicitud.
- El sistema la guarda de inmediato.
- Pero después tiene que esperar la aprobación de su superior.
- El superior recibe un mensaje.
- Abre el sistema.
- Revisa el documento.
- Lo pasa a finanzas.
- Finanzas comprueba el presupuesto.
- Después alguien tiene que aprobar el pedido.
Técnicamente la aplicación puede funcionar a la perfección. Y el proceso dura tres días.
¿Podemos decir que la aplicación es rápida?
Técnicamente, tal vez.
En términos de negocio, el empleado espera tres días.
Y precisamente por eso diseñar sistemas empresariales requiere mirar más allá de la interfaz. Hay que ver todo el flujo de trabajo.
"Por favor, espere" también es un elemento del UX
Hay otro caso interesante.
A veces el sistema realmente ejecuta una operación larga.
Genera un informe.
Procesa un archivo grande.
Sincroniza datos.
Envía muchos registros a una API externa.
Ejecuta un proceso complicado.
No siempre se puede conseguir que dure un segundo. Pero sí se puede lograr que el usuario sepa lo que está pasando.
Es una diferencia enorme.
El mensaje: "Cargando..."
es algo completamente distinto de: "Estamos preparando el informe. Se ha procesado el 72% de los datos. Puedes cerrar la ventana: el informe estará listo en segundo plano."
En el segundo caso, el usuario recibe información, control y previsibilidad.
Ese es precisamente uno de los elementos de la percepción del rendimiento.
El sistema puede seguir realizando la misma operación durante 20 segundos. Pero la experiencia del usuario es completamente distinta.
Lo peor es esperar sin información
La persona percibe mucho peor la espera cuando no sabe si el sistema hace algo en absoluto.
Hacemos clic. - Nada.
Hacemos clic por segunda vez. - Sigue sin pasar nada.
¿Está funcionando el sistema?
¿Se ha bloqueado?
¿Hay que actualizar?
¿Se ha enviado el formulario?
¿Podemos cerrar la ventana?
Ese es el momento en el que el usuario empieza a luchar con la aplicación.
Y cuando el usuario empieza a luchar con el sistema, aparecen más problemas.
Actualización de la página.
Reenvío del formulario.
Duplicados.
Llamadas al soporte.
Errores.
Incidencias innecesarias.
Y tiempo de trabajo de otras personas...
Por eso informar al usuario sobre el estado de la operación no es un añadido estético. Es parte del diseño de un sistema eficiente.
Y a veces la aplicación espera por la persona
Ese es probablemente el caso más interesante.
El sistema exige que la persona realice una acción que la tecnología podría ejecutar automáticamente.
El empleado extrae datos de un sistema.
Los transfiere a otro.
Comprueba una condición.
Copia el resultado.
Envía un mensaje.
Cambia el estado.
Espera.
Confirma.
Pasa los datos más adelante.
Y lo hace varias decenas de veces al día.
No hay avería.
No hay error.
El sistema funciona según lo previsto.
Solo que las previsiones eran incorrectas.
La automatización no tiene por qué significar inteligencia artificial.
A veces la mayor automatización consiste simplemente en hacer que los sistemas dejen de exigir a la persona que traslade manualmente la información entre ellos.
La arquitectura influye directamente en cuánto espera el usuario
En esta etapa llegamos a los aspectos técnicos.
Si la aplicación se compone de muchos servicios, cada llamada puede introducir retraso. Si el sistema obtiene cada vez los mismos datos de una API externa, se puede considerar una caché. Si el informe recalcula cada vez millones de registros desde cero, quizá se necesite otra estrategia de generación de datos. Si el usuario tiene que esperar una operación que no necesita ejecutarse de inmediato, se puede considerar el procesamiento asíncrono. Si varios procesos realizan el mismo trabajo, quizá el problema esté en la arquitectura.
Es precisamente aquí donde UX, rendimiento y arquitectura de software empiezan a conectarse.
El diseñador ve el problema del usuario.
El analista ve el proceso.
El programador ve el código.
El arquitecto ve las dependencias.
Un buen sistema debería unir las cuatro perspectivas.
No todas las operaciones necesitan acelerarse
Eso también es importante.
A veces una empresa invierte mucho dinero en optimizar una operación que ocurre una vez al día.
Mientras tanto, otra tarea, realizada por 50 personas decenas de veces al día, permanece prácticamente intacta.
Por eso, antes de optimizar, conviene saber: ¿qué estamos optimizando exactamente y para quién?
No se trata de que cada pantalla se abra en 100 milisegundos.
Se trata de que el sistema sea rápido donde la velocidad tiene importancia para el negocio.
Si un informe financiero puede generarse durante 15 segundos una vez al día, quizá no sea un problema. Si el buscador de clientes responde durante 4 segundos en cada operación del comercial, la situación es completamente distinta.
El rendimiento debe evaluarse en el contexto de la frecuencia, la criticidad y el coste de una determinada acción.
¿Cómo encontrar el verdadero cuello de botella?
En lugar de preguntar solo a los programadores: "¿Por qué la aplicación va lenta?"
conviene empezar por los usuarios: "Muéstrame cómo realizas tu trabajo."
No: "¿Qué te resulta incómodo?"
Solo:
"Muéstrame cómo preparas una oferta."
"Muéstrame cómo gestionas una reclamación."
"Muéstrame cómo das de alta a un nuevo cliente."
"Muéstrame cómo cierras un pedido."
Y entonces, a menudo, salen a la luz cosas que no se ven en el código.
Excel.
Bloc de notas.
Segundo monitor.
Copiar datos.
Comprobación manual.
Llamadas telefónicas.
Abrir cinco pestañas.
Actualizar la página.
Esperar un correo.
Preguntar a un compañero.
Ahí es precisamente donde a menudo se encuentra el verdadero cuello de botella.
Una buena aplicación no solo responde rápido
Una buena aplicación permite hacer el trabajo rápidamente.
Es una diferencia sutil, pero fundamental.
Se puede tener una aplicación técnicamente muy eficiente que exija al usuario una docena de clics. Se puede tener una interfaz preciosa que oculte un proceso complejo. Se puede tener una arquitectura excelente que no resuelva el problema real del negocio. Y se puede tener un sistema que técnicamente no sea un récord de rendimiento, pero que permita al empleado hacer en cinco minutos algo que antes llevaba media hora.
Por eso una software house no debería mirar la aplicación solo a través del prisma del código.
El código es un medio. El objetivo es un negocio que funcione bien.
Antes de optimizar el servidor, mide a la persona
Conviene recordar esta frase.
Si los usuarios se quejan de que la aplicación va lenta, no empieces automáticamente aumentando la potencia del servidor.
Primero revisa todo el proceso.
¿Cuánto tiempo lleva la tarea?
¿Cuántas pantallas hay que recorrer?
¿Cuántos datos introduce el usuario manualmente?
¿Cuántas veces reescribe la misma información?
¿Entre cuántos sistemas tiene que cambiar?
¿Cuántas veces espera?
¿A qué espera?
¿Sabe que el sistema sigue trabajando?
¿Parte del trabajo puede realizarse automáticamente?
¿Los datos que ya tenemos se vuelven a solicitar a la persona?
Solo entonces merece la pena bajar un nivel y revisar la API, la base de datos, la infraestructura, la caché, las colas o la arquitectura de la aplicación.
Porque a veces el problema realmente está en el código.
Pero a veces está entre la pantalla y la silla.
Y entonces la mejor optimización no es un servidor más rápido.
Es un sistema mejor diseñado.
El elemento más lento de tu aplicación puede ser una persona.
Y la función de una buena software house no es hacer que la persona haga clic más rápido.
La función de una buena software house es hacer que tenga que hacer menos clics.
