Piensa en el usuario

Esto del desarrollo a veces se nos va de las manos. Estoy haciendo un ejercicio recordando algunos de los proyectos software en los que he trabajado en mi vida, identificando los temas más importantes que discutíamos entre los desarrolladores, con el jefe de proyecto o con el cliente. Me acuerdo de cosas como éstas:

  • ¿Debemos usar XSL para generar un documento o hacerlo a mano?
  • ¿Usamos Biztalk para el procesamiento en servidor o un workflow a medida?
  • ¿Entidades propias o Datasets?
  • ¿Procedimientos almacenados o sentencias ad-hoc?
  • ¿Ficheros en el sistema de archivos o en SQL Server?

Cualquiera de estos temas tienen algo en común: no le importan un pimiento al usuario. ¿Y por qué cuento esto? El otro día tuve una conversación muy interesante con el que podría ser un usuario de tu próxima aplicación. Era un enfermero de un hospital en Cádiz, mi papi está ingresado y gracias a Dios este enfermero me hablaba de lo bien que estaba evolucionando y de que pronto le darían el alta. Sin saber nada de mi trabajo me estuvo contando que con un poco de suerte a mi padre le iba a tocar inaugurar un nuevo sistema informático que no viene al caso y que están implantando por allí. ¿Pensáis que este enfermero sabía algo de las tripas del sistema? ¿Y que le importaba? Me describió perfectamente el sistema desde el punto de vista más importante: el del usuario.

Para empezar me comentaba que gracias a este sistema un ATS iría directamente a casa de mis padres con toda la información del ingreso y con los puntos más importantes que tenía que verificar. Esta información se escribe día a día desde el hospital y contiene todos los detalles que necesita para hacer su trabajo. Anteriormente este trabajo lo tenía que hacer el propio enfermo, con los problemas que eso traía. Primero, porque se perdía mucha información por el camino y segundo porque en ocasiones el enfermo ni siquiera llegaba a llamar al ATS y se quedaba sin asistencia ni seguimiento.

También me contaba su experiencia como usuario de la aplicación. Era el enfermero con más experiencia de la planta y sin embargo se avergonzaba de que le vieran los compañeros usando el sistema. Se intentaba esconder para introducir los datos porque escribía muy lento y le costaba navegar por los menús. No había recibido demasiada formación y tan agobiado estaba que estaba practicando en su casa para cogerle el tranquillo.

¿Pensamos en este enfermero y en los propios enfermos cuando desarrollamos una aplicación? No me digáis que esto es algo que tiene que hacer un analista (todavía existen?) o el arquitecto o el jefe de proyecto o leñes. Cuando desarrollamos tomamos cientos de decisiones que afectan a estas personas y con frecuencia los criterios que utilizamos son de lo más variopintos: queda bonita? es cool? es un reto para mí? aprendo algo haciéndolo? es fácil de hacer? Muy pocas veces nos ponemos en el pellejo de alquien que tiene que usar la aplicación durante todo el día, con prisas y con pocos conocimientos informáticos. Ventanas con 20 botones, comboboxes de cientos de elementos, drag and drops, lentitud de respuesta… ¿Os suena alguna aplicación así?

En estos tiempos que corren con frecuencia nos hacen olvidar la importancia que tiene nuestro trabajo. El impacto que va a tener en personas de carne y hueso, la mejora que supondrá a sus usuarios y a la gente para la que trabajan estos usuarios. Por mucho que tu entorno te haga olvidar esto recuerda que tenemos un trabajo alucinante donde podemos ayudar a mucha gente o a convertir su vida en un infierno. Y si no lo crees, ¿por qué no intentas buscar algo en un combobox de cien elementos?