El espiritu de un desarrollo informático debe ser la busqueda del ahorro del tiempo del usuario, eliminando tareas monótonas y repetitivas: ¿puedes conseguir que el trabajo se convierta en un juego?

Una vez en un contexto un poco variopinto me preguntaron que a qué me dedicaba, esto es algo que siempre me ha costado responder teniendo en cuenta que venimos del sector del recauchutado de neumáticos, la empresa familiar nació como agencia inmobiliaria y soy socio de un hospital veterinario... aunque desde hace varios años he estado centrado en los "desarrollos informáticos" pese haber estudiado Jurídico Empresarial.

El caso es que respondí que me dedicaba a conseguir que la gente ahorrara tiempo y creo que ese debe ser el Leitmotif de casi cualquier aplicación, al menos es la parte de la informática que a mi más me gusta y con la que más disfruto: la que consigue que procesos manuales tediosos se conviertan en tareas automatizadas que sólo requieran un par de clicks de ratón (o ni eso).

Para automatizar un proceso, es imprescindible conocerlo y entenderlo... esto puede que sea lo que más tiempo lleva. Poniendo por ejemplo "un mailing de recordatorio de vacunas a animales" es necesario saber entre otras cosas que:

...existen muchos tipos de vacunas, algunas para perros otras para gatos, que algunas se administran trimestralmente, otras anualmente, que otros tratamientos son estacionales. También tienes que entender que a un mismo animal puede ser necesario administrarle varias vacunas el mismo mes y que un propietario puede tener más de una mascota... y que queda muy mal enviarles varias cartas en lugar de una sólo con toda la información resumida y ordenada. Llegados a un punto, también tienes que saber que muchos propietarios pasan por el hospital a vacunar a sus animales antes de que tú les envíes la carta y que a esos propietarios no se les debe notificar tratamientos que ya les han sido administrados...

Todo esto es un proceso largo de aprendizaje, donde la tarea en cuestión es observada con "visión de programador". No obstante, para hacerla realmente bien, el análisis de la tarea se tiene que observarse desde un punto de vista empresarial, ya que llegado el momento puede que el proceso inicial del que partió la necesidad de automatizar tenga que ser modificado o depurado para que pueda automatizarse.

Aquí nos encontramos con una paradoja, ya que en las empresas grandes si bien la necesidad parte en muchas ocasiones del área de "negocio/comercial", el desarrollo de cualquier aplicación es gestionado por "el departamento informático/técnico" que a su vez suele externalizar muchos de estos desarrollos. Así negocio habla con informática que a su vez habla con el desarrollador final.

En las empresas grandes de verdad en ocasiones ni siquiera "negocio" habla con el "departamento informático" ya que existe una figura intermedia que se dedica a transmitir y dar cera a cada una de las partes: que como bien es conocido friccionan con demasiada regularidad.

Idílicamente el desarrollador de una aplicación debería poderse empapar del sistema sin intermediarios, pero esto es difícil que ocurra porque o el "programador/analista" llegará "sin galones", lo que propiciará que le hagan perder el tiempo de manera innecesaria.... o el programador será un cenutrio a nivel empresarial y/o emocional con lo que pronto saldrá escaldado de ese contacto estrecho con el frenesí realista de algunas áreas de negocio.

La mayor parte de esos pasos intermedios se han creado para evitar estas situaciones de shock, si bien con ello se ha corrompido el proceso creativo de tal manera que los plazos se alargan eternamente y los resultados a veces no son tan buenos como deberían, es decir, las aplicaciones terminan haciendo que se pierda tiempo en lugar de ahorrarse.

Por otra parte el sistema de estas empresas es escalable y la programación "de guerrilla" que es la que a mi me gusta no lo es, porque depende excesivamente del talento, la tenacidad y el compromiso de las partes implicadas.