En los proyectos de software a veces se tiende a dividir demasiado las responsabilidades y eso hace que, en lugar de trabajar como un equipo, se intenten echar balones fuera. Es frecuente que los que desarrollamos no queramos saber nada de los tester ni mucho menos comprender lo que requieren las tareas de soporte.

Pero de todos los implicados en el proyecto, el rol que acaba asumiendo gran parte de las culpas cuando aparecen los problemas es el de los usuarios. Esto no es algo específico del desarrollo de software y pasa en casi todas las áreas (tecnológicas o no): cuando algo falla, es porque algo habrá hecho mal el usuario.

Esos curiosos seres

El usuario es la persona que acabará intentado sacar partido de alguna forma a esa aplicación tan chula que estás desarrollando, pero que con su torpeza lo único que conseguirá es infrautilizar y estropear tu magna creación.

Hay muchos tipos de usuarios, desde el que parece que jamás ha tocado nada que funcione con electricidad hasta el que se cree 1337 h4x0rd, pero en general todos tienen una capacidad especial para hacer que nuestras aplicaciones no funcionen como deberían y sacarnos de quicio.

A lo mejor no eres tan infalible, escucha lo que te dicen

Cuando un usuario dice que algo no funciona, para muchos de nosotros la primera impresión es siempre la misma: ya está otro torpe que no sabe manejar mi estupenda aplicación, seguro que ha hecho algo mal y por eso falla.

Esta mentalidad no lleva a nada. Si tratas al usuario desde la perspetiva de que es culpa suya sólo lograrás enfadarle y frustrarle, pero no conseguirás que el problema desaparezca ni que te ayude a resolverlo.

En lugar de eso, planteáte si puede tener razón. No es la primera ni la última vez que se le echa la culpa al usuario cuando el error realmente está en la aplicación. Aprovecha la queja del usuario para intentar averiguar qué está fallando.

Todos decimos que nos gusta tener feedback sobre lo que hacemos para mejorar, pero cuando llega la hora del feedback de verdad, el de «esto que has hecho no funciona», ya no tenemos tantas ganas de escucharlo, y sin embargo los comentarios negativos son especialmente valiosos para construir un producto de calidad.

Hay que dejar la soberbia de lado, escuchar al usuario (por muy torpe que sea) y aprender de él. Parece que escuchar durante el «análisis de requisitos» está muy bien porque es de «analistas», pero que escuchar durante el soporte no es tan bonito porque es para «teleoperadores».

El usuario no suele tener la culpa

Incluso cuando la aplicación funciona correctamente, o mejor dicho, según lo diseñado, si un usuario tiene problemas parte de la culpa es tuya.

El usuario es como es. Puede que sepa poco, puede que crea que sabe mucho, da igual. La aplicación tiene que estar desarrollada para él, no para ti.

Cuida la experiencia de usuario y la usabilidad y asegúrate de proteger al máximo la información que han introducido los usuarios para evitar que pierdan sus datos. Trata de eliminar, o al menos ocultar, todas las opciones de configuración que puedan hacer que la aplicación deje de funcionar.

Por supuesto, hay casos en los que realmente el usuario ha ido a romper el sistema, pero son los menos. Aun así, incluso en esos casos es importante proteger a los usuarios legítimos de los usuarios «saboteadores» para evitar que estos puedan provocar denegaciones de servicio.

Conclusión

Los usuarios son un mal necesario en todo proyecto de desarrollo de software y, sin duda, una de las piezas más importantes en todo el proceso.

Alguno puede pensar que lo que importa es el cliente, que a fin de cuentas es el que contrata (y paga) el desarrollo, y que muchas veces no es el mismo que el usuario, pero en realidad es muy difícil tener un cliente contento si los usuarios no lo están. No te olvides de que los usuarios pueden acabar por tirar abajo un proyecto.

Además, no tiene sentido cuidar la calidad del código que escribimos si no pensamos en quién lo va a utilizar. A casi nadie le importa el código que escribes o la arquitectura que utilizas, lo que importa es que el resultado sirva para algo.