archivo

Archivo de la etiqueta: atención a usuarios

No hace mucho escribí un artículo denominado “Un sistema de información sin mantenimiento” en el que especifico las características que debe tener una aplicación para no requerir tareas de mantenimiento continuo y lo que podría ocurrir en el caso de que necesitándolo no se pongan a su disposición los recursos que precisa.

Dentro de muy poquito uno de los sistemas de información que gestiono se queda sin presupuesto para mantenimiento. Es una aplicación grande, con muchos usuarios, con bastante uso, que afecta a varios departamentos, que está desarrollada en la tecnología prácticamente obsoleta, que tiene ya casi siete años de puesta en producción (aunque su concepción y análisis se remonta prácticamente cuatro años atrás) y que a lo largo de este tiempo ha sufrido numerosas modificaciones y ampliaciones funcionales, correcciones, etc… incrementándose su complejidad de forma paulatina.

¿Deberían haber sido siete años suficientes para dejar medianamente estable el sistema? La respuesta es que en condiciones normales sí, pero esas no han sido las circunstancias que han rodeado al mismo, ¿qué lo podíamos haber hecho mejor? También, y soy consciente de ello.

¿Por qué se queda sin presupuesto? Principalmente (y lo pongo por encima de la crisis económica, aunque de no existir ésta se hubiese encontrado financiación) porque los gestores de los departamentos a los que presta servicio no ven crítico que no haya dinero para mantenimiento, en unos casos porque probablemente no terminen de verle la utilidad al sistema y en otros porque en el fondo piensan que se encontrará una solución por parte de informática para que el sistema no quede sin soporte. No voy a entrar a juzgar esto, ya que cada cual tiene que hacer frente con sus presupuestos a sus áreas de gestión y nadie mejor que ellos saben dónde deben gastar e invertir.

Como miembro del departamento de desarrollo todo este asunto me podría dar un poco igual ya que sería en todo caso el departamento de explotación el que tendría que hacer frente a las demandas de los usuarios en cualquiera de los niveles de atención a usuarios ya que desde desarrollo no se podría dar respuesta a las incidencias y peticiones que nos escalen, la cual quedarían sin resolver de forma indefinida, debiéndose buscar alternativas en el programa para sortearlas (a veces será posible, otras no).

Sin embargo, cuando uno ha trabajado en un sistema tanto tiempo, le ha dedicado tanto esfuerzo y ha sufrido muchísimo desgaste, no puede abandonarlo como tal, por lo que en previsión de lo que podía pasar (y era algo que se veía desde hace prácticamente un par de años ya que el presupuesto ha ido disminuyendo paulatinamente hasta quedar en la actualidad y hasta dentro de muy poco, una cantidad simbólica) he intentado buscar alternativas para que el impacto sea el menor posible (muchas de ellas no salieron).

Entre ellas (y es de las primeras que se logró) es que se distinguiera claramente las tareas que correspondían al CAU de las tareas de desarrollo, por lo que el presupuesto de atención a usuarios de la aplicación se desvió a la bolsa general de atención a usuarios de mi organización. Esto que puede parecer lógico y que ya está implantado en mi organización, estaba todavía en fase muy embrionaria cuando se llevó a efecto. De esta forma la atención a usuarios de primer y segundo nivel estaba garantizada y además con unos niveles de calidad muy buenos porque el equipo de personas que está detrás también lo es.

Una vez que la atención a usuarios estaba cubierta quedaba otra parte y es tener la posibilidad de dar respuesta ante incidencias en el uso del sistema que necesiten la participación del departamento de desarrollo así como al mayor número de peticiones relacionadas con alguna modificación funcional.

Sobre esto he tenido mucho menos margen de maniobra y los resultados, como es lógico, no han podido ser muy significativos. Dado que una parte de la aplicación está construida en Java (una parte muy pequeña) y algunos de los componentes que utiliza (y que son parte de la aplicación) también lo están, dada la precariedad de los recursos económicos de mantenimiento del sistema, se tomó la decisión de que entrasen dentro del proyecto de mantenimiento global de sistemas de información desarrollados en Java, por lo que por lo menos una parte de la aplicación (aunque mínima) estaba cubierta ante posibles incidencias.

¿Qué pasa con el resto (que es casi todo)? Pues en estos últimos meses en colaboración con el CAU y con el soporte todavía vigente de la aplicación, se han desarrollado funcionalidades en el área de administración del sistema para incrementar la casuística de incidencias que puede atender el CAU. También se ha trabajado en aquellas funcionalidades de la aplicación que presentan más problemas. Todo esto sigue siendo insuficiente para poder prestar un servicio de calidad a los usuarios cuando nos quedemos sin mantenimiento pero siempre será mejor que nada.

¿Qué pasará? Todavía tengo la esperanza de que se consiga algo de financiación que nos permita alargar el soporte algunos meses más, pero en el caso de que no se llegue a ella, probablemente algunas de las consecuencias indicadas en el artículo al que hacía referencia en el primer párrafo se producirán, teniendo cada vez una comunidad de usuarios más molesta que dará lugar a una disminución paulatina en el uso de la herramienta, así como en la calidad de las tareas que se realizan a través de ella.

Aquellos que lleven más tiempo siguiéndome en este blog, saben que he sido bastante crítico con los usuarios. También he destacado su papel fundamental para que un proyecto salga adelante. No se trata de una relación de amor/odio, sino de una relación profesional entre ellos y las áreas de desarrollo y producción que no termina de ser fácil generalmente por el desconocimiento por parte de los usuarios de los trabajos que se realizan en el departamento de informática y por el desconocimiento de estos departamentos respecto a las necesidades e inquietudes de los usuarios.

Es cierto que a nivel personal y profesional por regla general hay buenas relaciones entre usuarios y técnicos de dichos departamentos, sobre todo en aquellos casos donde hay trato directo, cuando éste no es directo, no es tan sencillo (que no imposible) mantener buenas relaciones.

En este articulo voy a dar la razón a los usuarios en una circunstancia que paradójicamente es del todo injusta para los responsables del mantenimiento de aplicaciones. Se trata de cuando se pone en producción una nueva aplicación o se realiza un cambio significativo en una funcionalidad esencial de un sistema que ya está en producción y tiene una serie de errores que impiden el normal desempeño con la herramienta, es decir, lo mismo la aplicación se puede utilizar y está cogida con alfileres, lo que provoca que sea bastante incómodo su uso o bien existen funcionalidades importantes (esenciales o no) que no terminan de funcionar.

En este tipo de circunstancias los usuarios por regla general se enfadan y mucho. En función de su personalidad se pueden dar diversas circunstancias: 1) quejarse ante el responsable temático de la aplicación. 2) quejarse ante el responsable técnico de la aplicación (suele pasar que el responsable temático redirija rápidamente la responsabilidad al responsable técnico) 3) quejarse ante sus jefes de que no pueden trabajar, para que estos a su vez lo escalen. Ante estas circunstancias, los usuarios tienen toda la razón, no comparto la forma y tono en que, a veces, se dirigen a nosotros, pero evidentemente se encuentran con obstáculos que les impiden desarrollar su trabajo en condiciones y es normal que lleguen a molestarse, primero porque no lo puedan hacer y segundo porque a veces no tienen por parte de los responsables técnicos de la aplicación el tiempo de respuesta que esperan.

¿Dónde está la injusticia para el personal responsable del mantenimiento de la aplicación? Pues porque pese a que se esté poniendo todo el empeño posible por corregir cuanto antes los problemas, a veces se tarda más de lo que a uno le gustaría, sobre todo para evitar los mismos problemas que dieron lugar a que la aplicación o ese parche importante se pusiera en producción en ese estado. Es decir, se anda con mucho más cuidado en el desarrollo y en la revisión de la aplicación, ya que es mejor tardar un poco más (salvo que el sistema en su estado actual no se pueda utilizar) y asegurarnos que todo va a funcionar mejor, a saltar sin red y correr el riesgo de poner en producción una versión peor que la actual o que siga sin cumplir las expectativas demandadas, lo que daría lugar a una vuelta atrás, más molestias para los usuarios y todavía más tiempo para poder darles lo que ellos quieren.

Este tiempo que se tarda de más es en muchas ocasiones (sobre todo si no se conoce al equipo que está trabajando en ello) interpretado como que no se les está echando cuenta en sus demandas o que simplemente, siendo suave, nos estamos rascando el ombligo.

Conforme vaya incrementando la interacción entre los usuarios del sistema y el equipo de mantenimiento y van viendo como la aplicación va mejorando (aunque sea lentamente), va creciendo la confianza de estos (también se puede dar la situación contraria, que llegado un punto, puede ser bastante complicada de revertir).

Independientemente de que las relaciones entre usuarios y equipos de desarrollo dependen de muchos factores para que terminen de ser buenas en un proyecto concreto, estoy convencido de que todo sería bastante más fácil si las distintas partes llegasen a conocerse mejor y se estableciera una comunicación con la mayor fluidez posible.

El día a día nos come, eso es lo que me comentó un compañero de otra organización refiriéndose a que en los mantenimientos de los sistemas de información, dedicamos gran parte de tiempo a resolver incidencias y muy poquito a atajar los problemas. Es decir, los árboles nos impiden ver el bosque.

La gestión de problemas puede ser reactiva o proactiva y tiene como objetivo encontrar las causas o posibles causas de incidencias y las incidencias pueden definirse como un hecho o circunstancia que afecta al funcionamiento de una aplicación o al uso de un sistema de información por parte de un usuario. Un ejemplo de incidencias relacionadas con el mismo problema: “No consigo guardar en la aplicación el documento X”, “Intento recuperar una serie de documentos que almacené ayer y el programa no me deja”, “Me sale un error cuando utilizo el buscador de documentos”, ¿cuál podría ser el problema? Pues que por ejemplo que los servicios del gestor documental estén caídos.

En este ejemplo que he puesto, aunque se pueda buscar una solución alternativa (que es otra de las características de las incidencias, la posibilidad de dar una alternativa aunque no se corrija la causa que lo provoca (el problema)), se terminará dando solución al problema lo antes posible porque de lo contrario no pararán de llegar incidencias ya que afecta a una funcionalidad crítica del sistema.

Es decir, nos centramos en la resolución de incidencias y en la solución de problemas cuando tienen un carácter crítico y precisamente es ahí donde se debe mejorar (si se tienen medios). Cuando a las incidencias se le puede dar una solución alternativa y no requiere mucho esfuerzo y encontrar la solución (o corregirla) no es evidente, se tenderá a aparcar la gestión del problema y a ir resolviendo el día a día, ya que al fin y al cabo los usuarios deben sacar adelante trabajo. Al final si se suman tiempos sería más rentable solucionar el problema que ir resolviendo incidencias provocadas por el mismo, sin embargo esto lo comparo con quien compra al contado (resolver el problema) o quien compra a plazos (ir resolviendo incidencias), es mucho mejor si se tiene el dinero (y te cobran intereses) pagar al contado, pero claro, para eso hay que tener dinero (en el caso de la gestión de problemas, los medios adecuados).

La gestión de problemas (en su conjunto y no sólo cuando haya que apagar fuegos) por tanto tendrá un retorno de la inversión relativamente rápido y por tanto es algo que desde mi punto de vista es totalmente recomendable abordar.

Los lectores habituales de mi blog, me habrán visto siempre muy crítico con la postura y comportamiento de los usuarios, pero también habrán tenido la oportunidad de apreciar como defiendo que el resultado final de un producto debe ser siempre satisfacer al usuario y no solo funcionalmente.

Los usuarios son unos de los mejores maestros que pueden tener los profesionales de las TIC en general y los que se dedican al desarrollo de software en general y no me refiero a los directores usuarios o usuarios que actúan de enlace para capturar los requisitos o participar en diversas fases del proceso de desarrollo de software, sino el usuario de paisano, el que no ha tenido nada que ver en el desarrollo y se encuentra delante de un programa que generalmente siempre le causa más problemas que soluciones.

Es muy enriquecedor (aunque quema bastante) trabajar con los usuarios sin filtros (Centros de atención a usuario de por medio) e incluso con filtros de por medio si de alguna manera puedes leer lo que solicitan o incluso tienes que ponerte en contacto con ellos (otra forma muy interesante de conocer a los usuarios es a través de los cursos de formación). Hasta que uno no trata con usuarios, no se tiene una percepción real de lo que es el desarrollo de software. Se puede ser un técnico excelente, extraordinario, fuera de lo común, pero sin el trato con los usuarios se pierde una pizca de realidad que considero muy importante.

Yo noto muchísimo cuando un profesional de la informática ha trabajado con usuarios y cuando no. Cada uno da importancia a cosas distintas en el proceso de desarrollo de software (la diferencia en algunos casos es inapreciable y en otros bastante significativa).

Todos hemos sufrido en nuestras carnes los nefastos servicios de atención a usuarios que tienen nuestras queridas operadores telefónicas e incluso nuestras queridas entidades bancarias. Independientemente de que al otro lado del teléfono haya personas más o menos agradebles, con más o menos paciencia, la culpa de ese nefasto servicio no es de ellos, sino de los que han establecido esa política, mirando más por un ahorro de costes que por dar un servicio de calidad a los clientes.

Se ha hecho tan habitual esta prestación de servicios que han conseguido que lo veamos como algo habitual y ya casi ni nos quejemos, o bien que solo nos quejemos en los siguientes cinco minutos al momento de colgar el teléfono en el que nos acordamos del operador/a que nos ha atendido (aunque no tenga ninguna culpa) y de la entidad de telecomunicaciones, financiera, etc… con la que nos hemos puesto en contacto.

Sin embargo, cuando se modifica el entorno y nos situamos dentro del ámbito laboral, esa “comprensión” que se tiene ante el servicio de atención a usuarios que nos ofrecen determinados operadores, se convierte en incomprensión e intolerancia en demasiadas ocasiones. Parece como si una organización y un departamento con muchos menos recursos que una gran empresa debiera por arte de magia dar un servicio prácticamente inmediato y con la varita mágica de resolver todos los problemas.

Resulta totalmente chocante, como dando un servicio infinitamente mejor al que te ofrecen las empresas que te proveen servicios en tu vida personal, se crea más ruido cuando hay algún problema en el ámbito laboral.

Independientemente de lo injusto que me parezca la actitud de muchos usuarios, es esencial darles la mejor atención, que los recursos de la organización pueda ofrecerles, ya que son el motor que utilizan los sistemas de información y son los que les dotan de información alfanumérica, cartográfica y documental, la cual debe ser de la mayor calidad posible. Igual que digo siempre que los sistemas de información deben hacerse pensando en el usuario, digo siempre que el trabajo de la organización no debe terminar en ponerles delante una aplicación donde ellos puedan grabar o consultar información, sino que hay que darles un respaldo y un soporte con la mayor calidad que sea posible.