Ayudar a la productividad. Un análisis teórico-crítico del problema.

En el año 1945, Lord Keynes, de quien los economistas dicen que para cada problema económico existen cuatro soluciones, tres de ellas obra de Keynes, dijo ...si por un triste error geográfico las fuerzas aéreas americanos (es demasiado tarde esperar algo del enemigo) destruyeran cada fábrica en la costa noreste de Inglaterra y en Lancashire (estando presentes sólo los consejos de administración), no tendríamos que temer (la competencia de otros países.) Bastaría con sustituir ....todas las instalaciones grandes, estando presentes sólo los comités de informática... y se solucionarían muchos de los problemas actuales de nuestro bajo rendimiento.

Keynes no odió ni despreció (mucho) a la clase dirigente inglesa, pero vio que su falta de visión, de capacidad de liderazgo, de entender tanto a sus empleados a como a sus clientes, añadido a un parque de máquinas de producción ya anticuado, era una receta para un desastre. (Que no tardó en llegar.) Tampoco odio yo a los pisoteados directores de departamentos de informática, ni a los ordenadores mastodónticos, pero creo que la desaparición de ambos ayudaría a superar algunas de las dificultades actuales. Por un lado, demasiados de los Señores de la informática (excluyendo los que leen esta revista, claro) son reacios a lo nuevo, prefiriendo arroparse en lo antiguo, lo ya conocido: y todavía las máquinas grandes suelen imponer unas necesidades espantosas en cuanto a su programación o el uso de la información que contienen.

Me quedé muy impresionado siendo joven (se trata del siglo pasado) de una obra literaria inglesa en la cuál hablaba de una persona que cada día antes de desayunar creyó en dos nuevas cosas imposibles.

Al parecer, podría ser pariente mío, porque yo también soy capaz de creer en cosas imposibles. Por ejemplo, creo en todas las pretensiones de todos los vendedores de soluciones a los problemas de bajo rendimiento de nuestros tan queridos programadores y analistas. (Hay que decir que sumando todos los ahorros que nos cuentan llegaríamos a hacer programas en un tiempo negativo, o tal vez virtual: pero, ¡creo!) En este Número Especial de ComputerWorld, hay muchas empresas honradas y serias ofreciendo productos bien pensados, bien hechos, y, además, a precios ajustados al mercado y a las necesidades de los clientes, que pretenden solucionar los problemas de rendimiento de analistas y programadores. (Pero ninguno trata de solucionar los problemas de los usuarios a la hora de definir qué demonios quieren.) Sus clientes potenciales, en su gran mayoría, no comprarán ningún producto, por bueno que sea. Sí, yo también me presento en plan dudoso ante tal oferta, ¿por qué? Déjeme cogerle a Vd. por las solapas y decírselo.

Desde hace milenios el hombre (sí, sí, la mujer, el homujer, la muombre, la persona, llámelo cómo quiera) ha sentido la necesidad de tener un techo sobre la cabeza. Por ello nacieron las especialidades de arquitecto, de albañil, de carpintero, de fontanero, entre otros quehaceres; para satisfacer tan difícil deseo. Quien, como un servidor, se ha metido en la locura de diseñar y edificar su propia casa (en mi caso, más de una vez, lo que demuestra que soy gilipollas) sabe que:

1. Edificar la casa es algo que nunca se acaba 2. El edificio terminado no tiene nada que ver con lo soñado 3. El edificio, antes de terminarse, empieza a caerse 4. Cuesta dos riñones más de lo pactado 5. A la señora respectiva, no le gusta en absoluto.

¿Les suena? Basta con sustituir sistema para casa y usuario para señora y todo sigue siendo igual. O sea, tenemos que sentir vergüenza por nuestra actuación, pero no porque lo que hayamos hecho no sea perfecto. Si después de no sé cuantos siglos, no podemos edificar una pobre vivienda sin infinitos problemas, es lógico que nuestros sistemas informáticos sigan siendo desastrosos desde el punto de vista de nuestros amos, los usuarios.

Y ninguno de las potingues ofrecidos puede resolver este hecho. Y nunca serán capaces de hacerlo, porque la madre del cordero está en la imposibilidad de definir un sistema sin errores, ni de evitar cambios de opinión que afloren como una lógica consecuencia del uso real de un sistema.

Pero el mundo está lleno de optimistas, quienes, como yo, creen en la oferta de los vendedores de soluciones perfectas. En nombre de la honradez, no me gusta en absoluta el que algunas de las ayudas en venta se presenten como la respuesta definitiva a todos los problemas de los informáticos. No lo son, ni pueden serlo. Algunas se dirigen a una parte suelta de la problemática, otras a otra, pero ninguna al conjunto total. Todas podrán ayudar a quien las use en menor o mayor grado, pero ninguna es la solución definitiva a todos sus problemas e inquietudes. Ojalá que así fuera, porque liberaría el pobre usuario de nosotros los informáticos. (Y ojalá que nunca sea así: no quiero que los informáticos se mueran de hambre.) Pero no debo ser totalmente negativo. Dicen. Sí, estoy convencido de que existen ayudas valiosas a la programación, al diseño de sistemas y de bases de datos. Pero lo que hay, dista mucho del tipo de herramienta que un servidor ha ido buscando durante toda una vida, algo que abarque todo, desde el inicia de un sistema hasta su puesta en marcha. Por lo que, para su desgracia, ha tenido que desarrollar algo parecido, por narices.

Y digo yo, ¿qué es lo que necesitamos? Para sistemas de un cierto grado de complejidad, sobre todo para aquellos que corren en máquinas más bien grandotas, algo que nos ayudara a diseñar, programar y documentar los sistemas y programas pedidos (prefiero exigidos) por los usuarios. Algo que nos llevara desde las primeras ideas confusas de los usuarios hasta la entrega, con fuegos artificiales y champán francés (por ser más caro que el cava, no mejor), del sistema perfecto. Lo que encuentro es que hay mucha oferta para cada una de las etapas, pero ninguna que abarque todas en su conjunto. (Cuando se trata de sistemas para micros, cambio un poco de actitud. Dada la naturaleza del micro, el tipo de trabajo que normalmente ha de efectuarse, las herramientas que uno tiene a su alcance, es mejor, menester, hacer la programación de una forma interactiva con la intervención viva del usuario. Es cuando se trata de sistemas con bases de datos gordísimas, tanto en su extensión como en su complejidad, cuando hacen falta las herramientas arriba citadas.) Sería un buen momento para explicar al sufrido lector los pormenores de un sistema que lo hace todo, fraguado (en todos sus sentidos) aquí en España hace unos 20 añitos por un servidor y un español, llevado a cabo, utilizado en muchos sistemas, e ignorado por todo el mundo porque no llevaba denominación de origen extranjera. No lo haré. Me contento diciendo que no es una utopía lo que he descrito arriba como lo deseable, sino algo al alcance de quien se pare a pensar, como lo hicimos Paco y yo en la Edad Media de la informática.

Ante la oferta tan tremenda de ayudas a la productividad que actualmente existe, y tomando en cuenta lo que he dicho antes, ¿qué debe hacer un usuario?

* Primero, definir bien cuál es su problema real, no el problema que reluce bajo sus narices.

* Segundo, estudiar la oferta que existe, sin despreciar nada - por no ser totalmente automático, o en color, o con ventanas, por ejemplo.

* Tercero, considerar si el cambio que supone el uso del producto es asimilable por las personas que lo tienen que usar, y conseguir que lo acepten con entusiasmo. Caso contrario, fracasará seguro.

* Cuarto, intentar medir las consecuencias de su uso en el ambiente de la empresa.

* Quinto, por favor, querido lector, compra algo. Ningún producto puede dar peores resultados que las formas artesanales de trabajar.