Empecé a trabajar como miembro de una Horda Mongola en la época del Efecto 2000 y la adaptación al Euro. Muy pronto a alguien se le ocurrió que era un buen momento para establecer un nuevo sistema de documentación del software de la empresa, y fui el elegido gracias a que era el que más HTML sabía en el grupo. Se podría decir que diseñé un procedimiento y una metodología de trabajo por la que todos los programas que se hacían o modificaban se documentaban en forma de página HTML que, además de servir como el típico manual de usuario, incluía una pequeña simulación del proceso del programa (nada espectacular: sólo una sucesión de "pantallazos" estáticos con enlaces para pasar de uno a otro). Dado que estábamos hablando de software desarrollado en RPG III o RPG IV, hay que reconocer que la documentación resultaba bastante más vistosa que los propios programas. Sin embargo, fue entonces cuando descubrí, una vez acabada la excitación y el interés provocado al tener que elaborar todo el sistema, que realizar la documentación de usuario era un rollo. (Supongo que unos cuantos de mis compañeros también lo descubrieron, aunque quiero pensar que al menos la experiencia les sirvió para aprender algo de HTML básico, así que espero que no me guarden rencor por la parte que me toca). Incluso habíamos gente que nos dedicábamos íntegramente a documentar los programas creados por programadores más experimentados que no interesaba que "perdieran el tiempo" documentando. De ahí a que el documentar fuera casi considerado un castigo, sólo iba un paso...
Encuentro comprensible que a nadie (o casi nadie: no se puede generalizar) le guste la elaboración de la documentación de usuario. A los que nos dedicamos a esto del desarrollo de software nos gusta crear cosas que hagan algo. Tener que explicar luego en un documento de texto como utilizar nuestro software, con múltiples ilustraciones capturando todas y cada una de las pantallas del proceso (eso si no hay que retocarlas para que no muestren datos inapropiados), y listando obviedades varias (el botón de "Añadir Producto", sorprendentemente, ¡añade un producto!), es casi una tortura que resulta casi más costosa que el desarrollo de la aplicación en sí.
Un inciso necesario a raiz del último párrafo: la documentación de usuario debe ser exageradamente detallada, aún a riesgo de acabar creando un documento para tontos. Muchas cosas que el desarrollador considera obvias (y que lo son...), no las verá de la misma forma el usuario, así que vale la pena explicarlo todo hasta el más ínfimo detalle. Así, reduciremos las consultas de los usuarios o, por lo menos, no les daremos la excusa de que "en el manual no lo explica"
Por otra parte, en los propios procesos de las empresas es normal que haya previsto un tiempo insuficiente para el desarrollo de esta documentación (si es que hay previsto alguno). En el entorno de trabajo habitual, cuando un desarrollador finaliza un programa lo normal es que tenga unos cuantos esperando en cola y, una vez más, ni a él le interesar perder el tiempo en la desagradable tarea de documentar, ni a sus superiores les interesa que pierda el tiempo en vez de estar resolviendo problemas o creando nuevas funcionalidades que exigen los usuarios. Por supuesto, asumo que no se dispone de una persona dedicada exclusivamente a la redacción de documentación de usuario (Incluso si se dispone de personal especializado en la formación al usuario, la documentación se la debe proporcionar normalmente el propio desarrollador).
La consecuencia de todo esto es inmediata: montones de programas no disponen de sistemas de ayuda o manuales de usuario. O, lo que es peor todavía, disponen de ellos pero están obsoletos. Y esto hace que los usuarios ni se molesten en consultar la ayuda o los manuales: resulta mucho más efectivo llamar al departamento de Informática y consultar con el desarrollador.
Este es un problema con difícil solución, pues precisa que el desarrollador se conciencie de la necesidad de elaborar (y, más importante aún, mantener) la documentación de usuario y, por otra parte, precisa que los jefes de proyecto y similares tengan en cuenta que el manual de usuario es un entregable como otro cualquiera, y al que se le debe dedicar el tiempo necesario. Conseguir esto es donde está la principal dificultad, y aquí incluyo algunas de las razones por las que creo que es conveniente tener una buena documentación de usuario.
- Herramienta de Ventas. El manual de usuario es una buena forma de vender el software que describe, de manera que el potencial cliente se haga una idea de lo que es capaz de realizar sin necesidad de proporcionarle acceso (Aunque, obviamente, nunca va a ser tan bueno como una demo). Cuando se trata de presentar ofertas y similares, se vuelve imprescindible (además de ser una manera fácil de añadir peso a la oferta...). De hecho, no es raro que a la hora de presentar una oferta a clientes, el jefe de proyecto o de departamento se dé cuenta de la utilidad de disponer de una documentación de usuario extensa y completa.
- Reducción del Ruido Telefónico. Los que nos pasamos buena parte del día dando soporte a usuarios de nuestro software (o de software del que somos "responsables"), deberíanos arrepentirnos cada vez que suena el teléfono por no haber desarrollado un buen sistema de ayuda. Si los usuarios (o, si se dispone de ellos, el personal de soporte al usuario) tuvieran acceso a documentación que les permitiera resolver sus dudas y problemas por sí mismos, no llamarían tanto (o incluso, por utópico que suene, no llamarían nunca). De todas maneras, una vez el usuario ya no tiene confianza en la documentación y se acostumbra a resolver sus dudas por teléfono, el problema tiene mala solución...
- Recapitulación. La elaboración de la documentación de usuario tras un desarrollo o una modificación puede servir para asegurarnos de que el programa hace lo que debe, como debe, y como se pidió. No debería ser ese el momento, claro, pero el necesario repaso de las funcionalidades puede servir para descubrir lapsus y otros errores pendientes.
Reconozco que me cuesta encontrar más razones para justificar la necesidad de realizar la documentación de usuario (además de las obvias): supongo que no soy capaz de no verla como un "mal necesario". Es algo que hay que hacer, puedo racionalizar su necesidad, pero eso no hace que me guste...
Otro día hablaremos de la documentación técnica...
No hay comentarios:
Publicar un comentario