Ese uno por cien o uno por mil que complica las aplicaciones

¿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.

Los usuarios y la especificación del sistema de información

Si el área usuaria para en la definición del sistema lo mejor es parar el proyecto hasta que la situación se reconduzca. Esto tiene muchos inconvenientes, entre otras cosas porque puede deshacer al equipo de desarrollo y dar al traste con planificaciones generales de parte del Departamento de Informática y con las expectativas de los responsables funcionales cuyas necesidades dieron lugar a este trabajo.

Pero por mucho inconveniente que nos encontremos ninguno será superior a desarrollar un sistema de espaldas al usuario por mucho que hayan sido los propios usuarios designados para definirlo los que se hayan puesto de espaldas al mismo.

La tentación de liarnos la manta a la cabeza y continuar es muy grande porque probablemente encontremos presiones que nos empujen a ello (si somos un proveedor de servicios de desarrollo de software tendremos a los responsables de turno protestando porque el taxímetro se ha parado, si eres el responsable técnico del cliente tendrás al proveedor protestando por el motivo anterior, etc…), sin embargo la solución no debe pasar por ahí, sino por intentar reconducir la situación y si no se consigue, negociar una salida digna para todas las partes.

Cuando las aplicaciones se convierten en ciudades fantasmas

En muchas organizaciones hay sistemas de información o herramientas (más de uno, más de dos y más de tres) que tras una inversión importante en tiempo y esfuerzo se quedan en una simple url o en un icono de escritorio accesible por sus potenciales usuarios pero olvidada y abandonada por estos.

Otras veces nos encontraremos con sistemas y herramientas que ni siquiera llegaron a terminar de construirse, quedando en simples ruinas cuyos vestigios puedan ser consultados, con suerte, en un sistema de control de versiones o en alguna máquina de un entorno de desarrollo o de un programador.

¿Qué nos lleva a esto? Generalmente el hecho de que se haya desarrollo o adquirido un sistema que no cumple con las expectativas del usuario a nivel funcional y/o de experiencia de usuario o bien que no cubra una necesidad real en la organización.

Hay aplicaciones que de un número potencial alto de usuarios y de uso, nos encontramos con que están infrautilizadas, para mi son tan ciudades fantasma como las anteriores, solo que en este caso hay unos cuantos héroes que de manera voluntaria u obligada hacen uso de las mismas.

Hay ciudades fantasmas recuperables pero para ello se requiere un esfuerzo importante y un compromiso de todas las partes: desarrolladores y área usuaria. Los primeros para tratar de ir mejorando de manera progresiva las condiciones de habitabilidad y los segundos para ir priorizando sus necesidades y soportar durante un tiempo unas condiciones de vida duras dentro de la ciudad.

Habrá veces donde lo mejor será buscar otro emplazamiento para la ciudad. Esta decisión es muy complicada de tomar ya que hay una inversión importante detrás y otra inversión importante que se tendrá que hacer de nuevo. No obstante si hay una necesidad que cubrir cuanto antes se tome la decisión mejor porque se corre el riesgo de seguir invirtiendo en algo que tarde o temprano se terminará convirtiendo en un montón de escombro.

Desarrollo de software. Sistemas de información grandes, puesta en marcha, metodologías clásicas

Lo he vivido ya en más de una ocasión y lo he sufrido no durante semanas, sino meses y en algún caso hasta años.

Poner en marcha un sistema de información en su totalidad o en gran parte sin que ningún usuario lo haya utilizado en un entorno o contexto real es una condena para el propio sistema de información y para quienes lo gestionan.

Llegarán peticiones de mejora e incidencias superiores a la capacidad que se tendrá para dar respuesta (si es que dispones de esa capacidad, ya que pocas veces se prevé que lo que se desarrolla hay que mantenerlo, de hecho los responsables o directores funcionales del sistema es lo que pensarán si no se les explica de manera adecuada y con carácter previo qué es un desarrollo de software y qué consecuencias tiene los cambios en las especificaciones sobre el coste del proyecto) y la puesta en marcha del sistema se convertirá en una cuesta arriba que no parece tener fin a la vez que no termina de aflojar su pendiente.

Es la consecuencia de la aplicación de metodologías clásicas y del efecto bola de cristal donde se piensa que todo lo definido hace meses (cuando no años) por personas que lo mismo ya no trabajan en la organización o están en otro departamento sigue siendo válido cuando se pone en marcha el sistema. Esto sucederá en la mayoría de los casos incluso habiendo realizado un análisis muy riguroso (en todo caso, la calidad del análisis reducirá los problemas, algo que, sin duda, se agradece, pero que no resuelve el problema de fondo).

Desarrollo de software. Trabajar con buenos juegos de datos

Una costumbre poco aconsejable es trabajar con un desarrollo en el que la base de datos no tiene un buen juego de datos (tanto en volumen como en posibles casuísticas), lo que provoca que después nos encontremos con sorpresas desagradables cuando el producto llegue a producción.

Cuando se trabaja sobre un sistema en producción es muy recomendable trabajar en los entornos de desarrollo y preproducción con unos juegos de datos similares a producción, a ser posible en preproducción casi iguales y, si no es posible, trabajar como mínimo con una foto reciente de los mismos disociando los datos que se consideren sensibles.

Como es lógico hay que evaluar el volumen y la criticidad/sensibilidad de los datos que puede hacer que no sea posible y/o aconsejable su replica en más entornos, en estos casos, tocará por lo menos, tal y como decía al principio disponer de un juego de datos que responda a las diferentes situaciones que se puedan producir en el uso del sistema de información y con un volumen adecuado para evaluar el comportamiento y rendimiento de la aplicación.

Desarrollo de software. El software no resuelve problemas de organización dentro de una entidad

El software nunca resolverá problemas relacionados con la organización y sus procesos. Cada problema debe arreglarse en el nivel que le corresponde y por las personas y departamentos que tienen la responsabilidad adecuada.

No se puede esperar que un sistema de información resuelva los problemas que las personas no quieren o no pueden solucionar.

Si en una organización no se ponen de acuerdo sobre cómo debe ejecutarse un determinado proceso o existiendo unas normas específicas se incumplen de manera sistemática no se debe esperar que el software solucione ese problema por mucho que se defina en él las acciones que se tienen que realizar y los datos que se tienen que grabar.

Salvo que la organización se ponga muy seria y de instrucciones precisas y tome medidas en caso de incumplimiento de las mismas o los usuarios o determinados grupos de ellos terminarán haciendo exactamente lo mismo que hacían antes de tener el nuevo sistema de información.

Se han tirado muchos millones de euros en muchas organizaciones por no resolver el problema de fondo antes de buscar una solución informática que gestione el proceso o procesos.

Desarrollo de software. Jef Raskin. Pensando en el usuario

Hace poco hice unas reflexiones sobre una cita de Olin Shivers en la que venía a expresar mi opinión de que la automatización de tareas o funciones en los sistemas de información debía medirse dentro de los parámetros coste/beneficio y dentro de los recursos existentes en el proyecto.

Jef Raskin tiene también una cita que puede parecer similar a la de Olin Shivers, pero que tiene un importante matiz a tener en cuenta: “Un ordenador no debería hacerte perder el tiempo o requerirte más trabajo que el estrictamente necesario”.

El matiz principal es “el estrictamente necesario” y tiene una orientación tanto hacia el usuario como hacia el desarrollador o la tecnología:

- Hacia el usuario: No se trata de automatizar todo lo automatizable sino de orientar las funcionalidades desarrolladas a mejorar en lo posible la productividad del usuario.

- Hacia el desarrollador o la tecnología: Se trata de dar la mejor solución posible dentro de las restricciones existentes en el momento (presupuesto, contexto, avances tecnológicos, etc…).

En cualquier caso, esta cita, como el trabajo en general de Raskin está orientado a que las TIC, los ordenadores y las aplicaciones deben prestar un servicio al usuario el cual no se entiende si la experiencia de usuario o la productividad en el uso del producto no es adecuada.

Desarrollo de software. Grandes problemas requieren respuestas rápidas

Si un sistema de información requiere importantes ajustes sin los cuales los usuarios no pueden trabajar de manera adecuada es necesario dar una respuesta lo más rápido posible, no solo para ir solucionando esos problemas sino para que los usuarios vayan ganando confianza y pongan menos reparos a utilizar una aplicación en esas condiciones.

Hay que actuar rápido pero con cabeza, apagar fuegos pero con intención, de lo contrario estaremos condenados a seguir apagándolos durante mucho tiempo con todo el coste que eso tiene consigo, no solo por la pérdida de productividad de los usuarios (que es lo más importante), sino también por el esfuerzo invertido en tareas de desarrollo que no terminan de arreglar los problemas (o lo hace demasiado lento).

Este tipo de problemas se puede producir en sistemas de cualquier tamaño pero son muy característicos en sistemas de información de gran tamaño en los cuales no será posible actuar, desgraciadamente, con tanta rapidez: demasiados frentes abiertos, tiempos de desarrollo más elevados (mayor complejidad funcional y mayor deuda técnica), pasos a producción más complejos y más stakeholders implicados.

¿Qué hacer en estos casos? Intentar concentrar los esfuerzos en los frentes más prioritarios (obligará a abandonar determinados módulos del sistema de información para tratar de salvar a otros y en consecuencia a la propia aplicación), orientar el mayor esfuerzo posible del proyecto en realizar el mantenimiento del sistema intentando desviar las tareas de asistencia a usuarios a proyectos especializados en la organización que se dediquen a eso (si es que existen), intentar minimizar el número de errores (ya ha habido demasiados, aunque no sean culpa tuya), involucrar a los responsables funcionales en la toma de decisiones (todos ganamos o todos perdemos) e intentar reducir en lo posible los tiempos de paso a producción.

Desarrollo de software. Olin Shivers. Orientación a la productividad en el uso del sistema de información

La implantación de un nuevo sistema de información debe mejorar la gestión del proceso o procesos que informatiza y que antes se gestionaban por otros medios (incluso otro sistema de información).

Ese mejora debe ser vista como el resultado de las ventajas e inconvenientes que ha traído consigo la nueva solución y su retorno de la inversión (aunque no sea cuantificable directamente en términos económicos).

La productividad en el uso de un sistema de información es una de las variables más significativas a tener en cuenta y es un objetivo a conseguir en el desarrollo de un sistema pero, eso sí, dentro de los límites razonables del esfuerzo que se puede invertir en un proyecto, es decir, lo mismo si nos centramos en automatizar completamente una actividad del proceso lo mismo nos quedamos sin poder desarrollar otras actividades igualmente importantes.

Olin Shivers es profesor de la Northeastern University en Boston y tiene una cita que como propósito personal está bien, pero que es necesario contextualizar de manera adecuada: “Me niego a hacer cosas que los ordenadores puedan hacer”.

Precisamente frases con un sentido similar las escuchamos de los usuarios cuando pretenden automatizar tareas cuyo coste de desarrollo supera con creces los beneficios que aportará la solución.

Desarrollo de software. La problemática de la gestión de usuarios en los sistemas de información

Si hay algo sencillo, por repetitivo y simple, que nos encontramos en el desarrollo de sistemas de información, lo encontramos en la gestión de usuarios. La mayoría tiene gestión de usuarios, por lo que debería ser algo que tendría que estar solucionado de manera sencilla tanto a nivel de programación (y del generador de código correspondiente) como a nivel de la organización para la que se realiza el desarrollo.

¿Cuál es la realidad?

- Organizaciones que no tienen una política común de gestión de usuarios en las que conocer los usuarios que tienen acceso a un sistema de información o conocer los accesos de los mismos a los sistemas requiere el trabajo artesanal de prácticamente obtener ese listado de cada aplicación y después fusionarlo.

- Organizaciones que no tienen definidos procesos a nivel organizativa para el alta y baja de usuarios, lo que provoca que retrasos en la gestión de los mismos y también que no se compruebe de manera adecuada por qué un usuario ha solicitado acceso a un determinado sistema y si efectivamente requiere el acceso al mismo para realizar su trabajo.

- Políticas de usuarios que no verifican si los mismos han elegido contraseñas robustas, que obliguen a cambiarlas cada cierto tiempo (si es que el sistema permite que los usuarios la puedan cambiar, que eso es otra) y que restrinjan por sesión el número de intentos posibles. O bien la utilización de estrategias alternativas, como la utilización del certificado digital como medio para acceder a los sistemas a los que se les haya concedido la autorización correspondiente.

- Volver a implementar en cada sistema que se desarrolle las pantallas necesarias para gestionar los usuarios del sistema de información.