Gestión Documental Para Gente (Casi) Normal

Hace unos días un nuevo cliente de ArchivaTech nos pidió el manual de usuario. Nos puso en un pequeño aprieto. La versión más reciente del manual tiene un par de años y el programa ha cambiado bastante. Y, lo que es peor, el manual es francamente malo. Es uno de esos manuales que pone: Capítulo 3.- Crear un nuevo expediente. Pulse el botón «nuevo expediente» o la opción de menú «nuevo expediente» para crear un nuevo expediente.

Nunca me gustó ese manual, pero nunca encontré el momento de revisarlo y mejorarlo.

Pero en esta ocasión no podía dejarlo estar y decidí resolver de una vez el problema.

Normalmente esta situación la resuelvo diciendo que el programa es muy intuitivo y que con una sesión formativa de media hora los usuarios aprenden todo lo importante del programa y no necesitan el manual. Y es cierto. De hecho es la tendencia del software (y todos los gadgets electrónicos modernos) y es uno de los motivos por los que ha triunfado el iPhone y el iPad.

¿Quién tiene tiempo, y ganas, de leerse un manual técnico? Creo que no conozco a nadie al que le guste hacerlo. A mí me solía gustar cuando era pequeño, pero hace años que perdí esa afición. Y tampoco podría continuarla porque los manuales de 400 páginas en papel han pasado a la historia.

Pero, volviendo a mi problema, a pesar de todo esto, necesitaba un manual. Y ahí surgen dos dudas, o dos decisiones:

1.- Quién lo escribe.

2.- Qué tipo de manual escribimos.

Lo ideal es que el manual lo escriba alguno de los programadores que ha desarrollado el software. Lo conocen bien, sus opciones principales, sus atajos, sus requisitos técnicos… Pero no es tan fácil. En primer lugar, no conozco ningún programador al que le guste escribir manuales. En segundo lugar, su tiempo es muy valioso (literalmente). Y en tercero no siempre tienen la habilidad de escribir un texto inteligible.

La segunda opción es que lo escriba alguno de los técnicos que instala el software y da la formación. El problema, en mi caso, es que eran los que habían escrito la versión anterior, la que no me gusta nada, por lo que me parecía que repetir la tarea iba a ser una pérdida de tiempo.

Así que miré a mi alrededor, no vi a nadie más y decidí escribirlo yo, que soy medio programador, medio técnico y medio comercial (sí, valgo por uno y medio ;). La principal ventaja de hacerlo yo es que seguro que a mí me iba a gustar. El principal problema, que tampoco a mí me gusta esta tarea. Por eso llevaba dos años retrasándola.

Una vez decidido el autor, viene la segunda decisión. Hay muchos tipos de manuales y antes de empezar es imprescindible decidir el tipo, el estilo de manual a redactar.

No se trata de un manual técnico de instalación, dirigido a los técnicos que lo montan al cliente. Esos manuales sí que los tenemos completos, al día y muy detallados. Son imprescindibles para nosotros y para nuestros distribuidores por lo que los tenemos actualizados.

Tampoco es un «manual de referencia» con una lista de todas las funciones y opciones del programa. Este tipo de manuales son muy útiles para programadores y técnicos como libro de consulta. O para los usuarios, ante una duda puntual, aunque estos últimos lo resuelven normalmente llamándonos por teléfono directamente.

Lo que tenía que escribir es  un «manual de usuario» dirigido a las personas que se enfrentan por primera vez al software. Un documento de 10 a 20 folios, sencillo de leer, suficientemente corto como para no desanimar a los lectores / usuarios y con un lenguaje sencillo para llegar a todo el «público» objetivo, que puede ser muy variado.

Entonces recordé perfectamente a un viejo colega que decía que había que hacer manuales «inteligentes». Manuales que te expliquen lo que debes hacer y la «filosofía» del software, no «guías paso a paso». Estas últimas son muy corrientes y son muy útiles, pero en el ámbito técnico. Un amigo inspector de Hacienda las llamaba «guía burros» porque describen todos los pasos a dar en un proceso concreto. Son muy apropiadas para tareas complicadas en las que no puedes saltarte ningún paso, al estilo de las «check list» de, por ejemplo, los astronautas o pilotos de avión antes de empezar un vuelo. Pero no es lo que yo buscaba.

Un «manual inteligente» le dice al usuario cómo empezar a utilizar el nuevo software, cuáles son las opciones principales y cual es la disposición básica de los elementos del interfaz gráfico. Le «explica» cómo usar su nuevo programa, no le enumera los botones y opciones de menú. Da por supuesto que el usuario sabe usar un programa en Windows y tiene ojos y es capaz de entender lo que hace un botón como «Salir» o «Guardar». No le tienes que explicar «TODO».

Y un buen «manual inteligente» tiene otra ventaja: es mucho más corto que una guía de usuario o manual paso a paso. Y eso es muy bueno para los usuarios que tienen que leerlo, y para mí, que tuve que escribirlo en solo un par de días.