Gestión Documental Para Gente (Casi) Normal

O la importancia de los pequeños detalles

Hace tiempo que quería escribir este artículo y ahora que he vuelto de las vacaciones creo que es un buen momento. En realidad llevo mucho tiempo hablando de «ésto», por ejemplo en mis videos sobre gestión documental o las 5 patas de un proyecto. ¿Recuerdas las dos columnas con lo que «Tiene» que tener un programa frente a lo que «Debe» tener? Al final es lo mismo: los pequeños detalles que no son imprescindibles y con frecuencia se desprecian pero que pueden marcar la diferencia entre un buen programa y uno que, simplemente, fracasa.

Pero voy a empezar por el principio. Por la década de los 70 nada menos. En aquellos años, que yo llegué a conocer aunque no soy tan viejo, los programadores iban con bata blanca, como los físicos y los matemáticos (algo que nunca he entendido bien; entiendo a los químicos, para que no se manchen la ropa con los ácidos y demás potingues, pero no entiendo de qué se protegen los matemáticos). El caso es que los informáticos eran una élite que se movía con sigilo por las amplias y bien iluminadas salas en las que los ordenadores ocupaban muchos metros cúbicos a pesar de no tener más que unos KBytes de memoria.

En aquella época la imagen más representativa de un ordenador era una especie de armario en el que dos grandes cintas parecidas a los rollos de películas giraban a toda velocidad mientras los operadores cambiaban otras cintas en los armarios alineados. El «jefe» estaba sentado delante de un teclado y una pantalla verde, o naranja, con una impresora al lado que escupía papel continuo sin parar (por cierto, jamás he utilizado papel continuo en mis programas, lo odiaba).

Era la era del popular System 360 de IBM, que entonces era una empresa de hardware básicamente (no de servicios como ahora). Y los ordenadores eran tan caros que solo había alguno en grandes empresas o Administraciones y el software ¡lo regalaban! Esos ingenieros de bata blanca visitaban al cliente, o al revés, y le hacían un programa a medida para sus nóminas, gestionar sus bases de datos, hacer los cálculos de estructuras y demás procesos repetitivos con cálculos intensivos.

Pero a lo que voy es que eran ingenieros y hacían un trabajo «muy complicado» que afectaba a grandes volúmenes de datos. La prioridad era que aquello funcionase y a nadie importaba que el manejo fuese extraordinariamente complicado, que el resultado fuese una lista de números y letras sin mucho orden que salían por unas impresoras que más bien eran máquinas de escribir rápidas sin otro interés que el contenido allí impreso.

Lo importante era el resultado, no la estética.

Y los programadores eran ingenieros. Y las carreras universitarias eran técnicas. Primero eran ingenieros de Telecomunicaciones y luego, cuando empezó a crecer el mercado de las TICs, aparecieron las facultades de informática que se convirtieron más tarde en ingenierías también. Un perfil técnico para un trabajo técnico.

Y aquí está el origen del problema.

Desde que el Windows se empezó a popularizar los programas de ordenador no son lo que eran. Ya no son programas de cálculo numérico para desarrollar la bomba atómica, la trayectoria del Apollo XIII o el esfuerzo en las vigas de un puente. Ahora hay programas para todo y para todos. Los usuarios son oficinistas, contables, diseñadores de ropa… y camareros en un bar o mi suegro conectándose por Facebook con sus cuñados (de más de 70 años). Los ingenieros, físicos y matemáticos son solo una fracción mínima del total de usuarios.

Entonces, ¿porqué siguen haciendo los programas los ingenieros informáticos? ¿Qué saben ellos de los gustos de los nuevos usuarios? ¿Qué saben de ergonomía? Muchas veces he hablado de ésto con los programadores de la empresa y siempre me sorprendo de que no estudien estas materias en la carrera. Están 5 años estudiando para ser buenos programadores y no aprenden nada de lo más importante: los gustos del usuario.

Hoy, con los años 70 y el System 360 allá, en la prehistoria, lo más importante de un programa es que sea fácil de usar, agradable para el usuario, bonito, cómodo, ágil…

¿Y qué pasa con las características clásicas: preciso, exacto, funcional…? Por supuesto que también debe tenerlas, pero estas se dan por supuestas. A nadie se le ocurre cuestionar hoy que un programa de gestión calcula bien el IVA. ¡Faltaría más! O que las filas o columnas de una hoja de cálculo se suman correctamente. ¡Por supuesto!  A estas alturas no es una cualidad deseable que un programa haga bien esta parte de sus obligaciones: se da por supuesto.

Ahora se le pide más, mucho más. La diferencia entre un buen programa y uno malo, o no tan bueno, no es lo que hace sino cómo lo hace. Esas cualidades secundarias que al principio ni se consideraban y que ahora son las que marcan la diferencia. Para los programas en general, pero para los de gestión documental mucho más (en los videos comento porqué). Cuando el monitor era monocromo, ¿a quién le importaba que las letras fueran todas iguales? Ahora una hoja de cálculo tiene colores, tipos de letra, líneas, gráficos… y encima es intuitiva. Es decir, es tan fácil de usar que no necesito leer el manual. Esta, por cierto, es una de las claves, no ya de la informática actual, sino de la electrónica en general: ¿quién se lee el manual del móvil? ¿Qué usuario de iPhone ha leido más de unas líneas del manual de usuario? ¡Pero si no trae manual de usuario!

¡Este es el éxito de Apple con su iPod, iPhone, iPad y seguro que varios iLoquesea futuros!

¿Y qué saben los programadores, ingenieros informáticos, de todo ésto? Nada que hayan aprendido en la carrera.

Así que, por resumir, si quieres hacer un buen programa para un PC, un iPhone o un Android, o formas un equipo con un diseñador, grafista, psicólogo y otros artistas del diseño, o te pasas muchas horas con tus futuros usuarios discutiendo de colores, tamaños y formas. De tipos de letra. De colocación de los campos y botones. De flujo de trabajo (esta parte siempre me ha gustado mucho). En definitiva, te sumerges en la experiencia del usuario. Dejas de ser ingeniero y pasas a ser diseñador.

NOTA: tenía intención de comparar el diseño de programas con el de los coches, poniendo a un lado los antiguos coches rusos y al otro los deportivos italianos, pero bastante me he alargado ya. También me habría gustado comparar el diseño de programas con la arquitectura, pero tampoco me cabe. Vendrá más adelante, si veo interés en los lectores.