archivo

Archivo de la etiqueta: aplicación

¿Cuántas veces hemos diseñado un sistema que aparentemente era simple y que por el hecho de querer contemplar una casuística que se produce en raras ocasiones se ha complicado casi exponencialmente?.

Demasiadas, ¿verdad?.

En el caso de que ese uno por ciento (o similar) se produzca y no esté contemplado en el sistema de información, ¿se pone en peligro la vida de alguien?, ¿puede suponer un perjuicio económico (tangible o intangible) que ponga en cuestión la supervivencia de la organización? Si la respuesta es que sí, ese uno por ciento debería estar, de manera indudable contemplado, cueste lo que cueste.

Ahora bien, ¿y en el resto de los casos? En mi opinión, si merece la pena se puede diseñar una “puerta trasera” o “desván” para estos casos, en los que de alguna manera se registre su información en el sistema y así, por lo menos, tenemos almacenada su información, pero yo no complicaría el sistema más allá de eso por contemplarlos.

Es cierto que casuísticas puede haber muchas y que incluso en sistemas no críticos interese contemplar esos casos. Como siempre digo, cada aplicación es un mundo y requiere ser analizada y los responsables técnicos y del área funcional son los que deben tomar las decisiones sobre la dirección que debe tomar el sistema.

Comenta un desarrollador con mucha más experiencia que yo que la aplicación debe entrarle por el ojo al usuario ya que de lo contrario manifestará rechazo desde el primer momento y será complicado hacerle cambiar de opinión. Si nos ponemos a pensar ejemplos, no está muy lejos de la realidad, ya que en las aplicaciones para smartphones los primeros segundos o minutos de uso de las mismas determinarán el éxito que tendrán las mismas en nuestro terminal.

No se trata exclusivamente de interfaces de usuario, sino también de la dinámica o lógica de funcionamiento de la misma. En resumidas cuentas, se trata de la usabilidad.

En la usabilidad hay buenas prácticas, sin embargo, hay que tener en cuenta un factor importante y que influye mucho a la hora de que un usuario exprese rechazo o no en primera instancia al sistema y no es otra que el tipo de aplicación o sistema que venía utilizando hasta ahora, ya que será la referencia con la que van a comparar el nuevo sistema.

Me he encontrado con casos donde los usuarios ponen por las nubes, sistemas que meses antes pisoteaban. Y no ha sido necesariamente porque el nuevo sistema empeore al anterior, sino porque les ha cambiado la rutina con que hacían sus tareas y existe otra nueva.

Los criterios de usabilidad son importantes, sin embargo, al final la práctica con el uso de la herramienta es la que rompe determinadas barreras que la propia aplicación ha puesto al usuario, ya lo dice la siguiente cita: “con suficiente práctica, cualquier interfaz es intuitiva”.

Muchas veces la puesta en marcha de un nuevo sistema de información se ve afectada por la existencia de una solución previa basada en recursos ofimáticos.

El problema es que los usuarios tardan en comprender (y otros ni siquiera intentan hacer el esfuerzo) las ventajas de tener una aplicación con un modelo de datos normalizado por detrás. Generalmente se suelen decir cosas como esta: “Esto lo hacía antes en diez segundos y ahora tengo que entrar en tres pantallas…”.

Y es que competir en “velocidad de hacer las cosas” contra una base de datos ofimática que tiene todo en una tabla es imposible.

Los usuarios tendrán recelos ante el nuevo sistema y también lo tendrán aunque estén utilizando previamente otra aplicación y la hayan puesto a parir, ¿cómo convencerles? con hechos, ofreciéndoles un sistema en el que se encuentren cómodos, con alta disponibilidad y que les permita extraer la información que necesitan en el momento que precisen. Para eso se necesita tiempo, recursos y que los usuarios se sientan partícipes y ayuden a definir sus necesidades en el mantenimiento del sistema de información.

En la gestión de un sistema de información llegan incidencias de funcionamiento, peticiones de mejora y también se detecta desde el departamento de sistemas comportamientos anómalos de las aplicaciones. Todo eso supone un conjunto de tareas que tenemos que ordenar de alguna manera. Todo eso se complica si además, el mantenimiento del sistema es compartido a través de un mismo contrato con otros, es decir, el presupuesto y por tanto, la capacidad de trabajo asumible se tiene que repartir entre todas las aplicaciones que son sustentadas por el mismo. Si además el presupuesto es escaso, las rampas serán todavía más duras.

Como no es posible tratar todo a la vez es necesario priorizar. Cuanto menos nos equivoquemos al seleccionar qué tareas se realizan antes que otras conseguiremos una mayor satisfacción de los usuarios y unos sistemas más estables en la menor tiempo posible. Pese a que ese sea un objetivo es necesario ser realistas y tener presente que nos equivocaremos y muchas veces, a veces por un problema de criterio, otras porque la información necesaria para tomar la decisión no haya venido completa o sea incorrecta y otras porque la propia presión ejercida por los usuarios nos haga tomar unos caminos en lugar de otros.

Para reducir el número de errores es necesario que conozcamos muy bien los sistemas de información sobre los que tenemos que tomar decisiones y su contexto (características de los usuarios, grado de utilización de la herramienta, estado actual de la aplicación, posible evolución en cuanto a modificaciones funcionales, etc…), así como las características del contrato de mantenimiento (capacidad de trabajo asumible, duración, etc…) y conocer, en la medida en que sea posible, las disponibilidades presupuestarias futuras, ya que no es lo mismo realizar priorizaciones en un mantenimiento sabiendo que puede tener continuidad en un futuro con un presupuesto acorde a las necesidades existentes que teniendo constancia de que el presupuesto se va a reducir considerablemente o incluso desaparecer.

Muchas veces se plantean las aplicaciones como un lugar donde simplemente los usuarios graban datos (extiéndase esto a generar documentos o a sacar una serie de informes más o menos básicos).

El planteamiento en sí no es erróneo ya que cualquier software que se desarrolle para realizar mantenimiento de datos siempre me va a parecer mejor que cualquiera hecho por un usuario para realizar esa tarea y no quiero con esto restarle el más mínimo valor a esas soluciones ofimáticas, ya que a muchos les permite sacar adelante el trabajo del día a día.

Son varios los inconvenientes que plantean, me centraré en dos (aunque no hay que obviar otros, como es el mantenimiento de datos de carácter personal en ficheros que no cumplen los requisitos establecidos por la Ley o la posibilidad de pérdidas de información si los archivos no se encuentran ubicados en espacios donde se apliquen copias de seguridad):

– Este tipo de soluciones no siguen una normalización de la información, lo que provoca que la explotación de la misma resulte compleja, es decir, puedes encontrar lo que estás buscando, pero extraer otro tipo de conclusiones sobre ellas es complicado. Esto es un problema inherente a la extrema flexibilidad que ofrecen este tipo de herramientas y a que el uso que se le suele dar a las mismas es muy superficial (depósito de datos organizado de una determinada manera).

– Muchas veces este tipo de alternativas son como una caja B de las aplicaciones informáticas, donde se almacena información que el programa no contempla o bien se utiliza esta estrategia por resultarles más sencillo mantener el dato de esta manera. Esto plantea múltiples inconvenientes, ya que dará lugar más que posiblemente a una falta de coherencia en los datos, es decir, en la aplicación principal y en las “no oficiales” una misma entidad puede tener información distinta, ¿cuál es la buena?.

Este artículo no trata de criticar estas soluciones, sino de intentar exponer una de las causas que llevan a los usuarios a las mismas:

Tal vez no sea la causa más importante de la proliferación de soluciones basadas en herramientas ofimáticas, pero sí es una que da lugar a la aparición de cajas B y no es otra que el desarrollo de aplicaciones que simplemente se encargan de permitir grabarle datos. Eso ya lo tienen con su hoja de cálculo o con su base de datos ofimática y además lo pueden hacer más rápido y fácil (de hecho, como ya he dicho en otras ocasiones nada puede competir contra este tipo de herramientas salvo que las alternativas ofrezcan utilidades que ahorre trabajo) . En su lugar se les ha puesto un programa que les hace lo mismo, solo que la productividad con él disminuye ya que se tarda más en grabar los datos y es más complicado y además se encuentran con errores que no siempre se arreglan tan pronto como desearían.

Las aplicaciones no solo hay que pensarlas como almacén de datos, sino también como una colección de utilidades que realmente proporcionen un valor añadido al que las usa, si el usuario nota esa diferencia no pondrá tanto inconveniente en utilizar una herramienta más compleja y que les obliga a trabajar de una determinada manera, se trata de un “tu me das, yo doy”. Cuando se rompe el equilibrio, los usuarios (salvo instrucciones expresas que obliguen al uso de la aplicación) tenderán a los caminos alternativos (no todos, porque la ruptura del equilibrio no se produce para todos en el mismo sitio y a la vez)

Otro error muy común en el proceso de desarrollo de software (y en el que yo también he caído) es olvidar que el producto que se está implementando no es para nosotros sino para el usuario final e independientemente de que tengamos la sensación de que conozcamos perfectamente lo que quiere el usuario o que dominamos la materia, tenemos que buscar hasta donde sea posible la implicación del usuario, no solo durante el proceso de definición del sistema, sino durante el proceso de construcción.

Si los que nos dedicamos al desarrollo de software, que ya tenemos una cierta experiencia en abstraer problemas, nos encontramos con dificultades en numerosas ocasiones para llevar a un programa de ordenador un determinado proceso y nos damos cuenta muchas veces cuando se está construyendo que hay piezas que no encajan, ¿podemos pedir al usuario que tenga esa misma capacidad de abstracción?, algunos pensaréis: “era obligación del usuario leerse el análisis”, ¿de verdad pensáis que el usuario puede llegar mucho más allá del análisis de requisitos, de la descripción de casos de uso, de la revisión de las interfaces de usuario y su navegación?, salvo que el sistema no sea excesivamente grande, que los entregables que acabo de indicar se realicen de la forma más completa, exacta y clara posible, y que el usuario se esmere en repasarlos (y aún así), quedarán resquicios que cuanto más se tarden en corregir más costosos serán para el desarrollador.

Lo que acabo de comentar en el párrafo anterior no es un vale todo para el usuario, es decir, éste debe asumir su responsabilidad en el proyecto y de alguna u otra forma se lo tenemos que hacer ver. El desarrollo de software no se hace con una pizarra y una tiza, donde se puede borrar y volver a escribir libremente, es un proceso tan complejo en el que no vale la barra libre. Lo que vengo a comentar es que en el desarrollo de software se debe ser consciente de que cuanto más se tarde en detectar un error más vale corregirlo y que los usuarios en la mayoría de los casos no toman conciencia del programa y de los problemas hasta que se enfrentan a él. Como podéis ver se trata prácticamente de dos extremos, de hecho cuanto peor se hagan las cosas (por parte del desarrollador y del usuario (por no hacer frente, este último, a su responsabilidad)) se cumplirán ambos extremos, lo que provocará que el proyecto salga caro (lo cual puede repercutir sobre el usuario o sobre el desarrollador (más bien, sobre este último)) y que la calidad del mismo se vea muy perjudicada.

Por tanto, es importante que no olvidemos que las aplicaciones se desarrollan para los usuarios y que por tanto hay que buscar la mayor implicación posible por parte de los mismos en todo el proceso de desarrollo de software. ¿Qué el usuario no se implica? Hay que intentar que siempre quede patente este hecho (evidentemente hay que saber hacerlo con tacto), ya que más adelante si el proyecto no ha salido como debía y hay que empezar a parchear, que todo el gasto de ese parcheo no repercuta directamente sobre el desarrollador.