Documentos.

Introducción y justificación

Como ya ha quedado dicho en entradas anteriores de este blog, la creación de documentos es fundamental en el trabajo de los SEO. Lo es por múltiples causas, unas más respetables (y respetadas) que otras, pero el hecho es tozudamente evidente: cerca del 80% del trabajo se nos va en crear, completar y cumplimentar documentos, muchos ellos de carácter prescriptivo o próximos a esta categoría.

icons.iconarchive.com

Posiblemente no debiera ser así desde otros planteamientos de intervención, y sería un buen indicador de por dónde van los progresos en ese sentido el que se redujera dicho porcentaje. Y digo posiblemente por ser una posibilidad real, en coherencia con propuestas prácticas (no meramente retóricas) de cambio de modelo.

Aun con todo, no veo posible, ni necesariamente conveniente que el trabajo con documentos deje de consumir una parte importante de nuestro tiempo y esfuerzo, ya que va asociado, en deferentes formas, a nuestras funciones y al desarrollo de nuestras actuaciones. Incluyo en esto a los referidos documentos prescriptivos, que también tienen su lado positivo, como lo tiene la formalización de los procesos y su publicitación: la alternativa no tiene por qué ser un avance, es muy probable que  en realidad constituyera un retroceso: en calidad y en claridad.

Dejando esta temática para otros momentos y espacios de discusión, para centrarme en el tema que nos ocupa en esta sección, diré que, incluso en el peor de los casos, dado que la queja no resuelve el problema (en la medida que lo es, que puede que no tanto como algunos plantean), la buena noticia es que disponemos de recursos para, cuanto menos, reducir la carga de trabajo que la cumplimentación de esta abundante documentación nos provoca.

En realidad de novedoso este planteamiento tiene bien poco, ya que las "soluciones" están disponibles desde hace mucho tiempo; pero cierto es que no lo parece. Y lo está como desarrollo y concreción de la competencia ofimática, esa de la que ya hable [en otro momento] en el que defendí que era necesario desarrollar dicha dimensión de la competencia digital de los SEO en función de la especificidad de sus funciones y prácticas profesionales.

Desde ella (esto es: sin necesidad de salirse del estrecho pero conocido mundo de las suites ofimáticas) es posible crear soluciones que, aun no siendo maravillosas, sirvan perfectamente al objetivo básico de semi-automatizar la cumplimentación de la mayor parte de la documentación que generamos, especialmente de esos documentos que llamo prescriptivos por venir dados como de obligado uso por parte de la Administración educativa: de hecho, cuanto más formalizados estén, más viable y sencilla es su automatización.

Como digo, las funcionalidades están a nuestra disposición desde hace mucho tiempo, y se llaman Combinar correspondencia y Grabar macro. Ambas pueden considerarse de nivel usuario avanzado, pero es de esperar y exigir que un colectivo que hace necesariamente uso continuado de las suites ofimáticas alcance ese calificativo, y no precisamente al final de su carrera profesional.

Algo más difícil y menos espontáneo (consecuencia de la práctica) es que incorporemos el uso de un "lenguaje de macros" como parte de nuestras competencias, pero tampoco es un sueño inalcanzable: con el ejemplo de la propia Administración y un pequeño esfuerzo formativo podría ser suficiente. Y mucho más inmediata e instrumentalmente útil que otras formaciones.

Aunque LibreOffice dispone de varios lenguajes de programación embebidos (1), posiblemente el más  funcional y simple es OOo Basic (2), así que por él deberíamos empezar. Como todo lenguaje de programación, por simple y limitado que sea, requiere desarrollo de la lógica de programación (a la vez que potencia este desarrollo), lo que conlleva tiempo y esfuerzo... y práctica. La ventaja es que la práctica puede relacionarse directamente con la creación de soluciones ajustas a nuestras necesidades: como aprendizaje competencial y directamente útil, a modo de proyecto de trabajo, podemos orientar directamente el proceso de aprendizaje a la creación de soportes que llamaremos documentos-aplicación (docap) pensados para dar respuesta a necesidades inmediatas y concretas. A partir de ahí el objetivo es generalizar su uso como herramienta de trabajo.

Aunque parezca simplista, una barrera que funciona más bien como una muralla, es la exigencia que este uso conlleva de trabajar desde el IDE, espacio de trabajo tan desconocido como intimidante. Pero es ambas cosas por el escaso (o nulo) conocimiento que como colectivo tenemos de la lógica de programación (3).

Cierto que incorporar OOo Basic como herramienta supone un esfuerzo de aprendizaje, pero también debemos poner en la balanza el rendimiento que vamos a obtener inmediata y directamente de él: en lo que ahora nos toca (pero no sólo) ser capaces de crear script, subrutinas y funciones que semi-automaticen el manejo de la documentación es una buena recompensa.

Además OOo Basic y el modo de trabajo que conlleva no es la única opción; también podemos plantearnos el uso de Python como lenguaje (y procedimiento de trabajo) alternativo (o complementario), ganando posiblemente en potencia y aprendizaje, así que no podemos renunciar a ello. Pero como primer paso parece más lógico y sencillo empezar por el lenguaje que ya incorporan los servicios ofimáticos que empleamos habitualmente. La funcionalidad es más inmediata

Es más, podemos empezar por aprender a crear macros y a manipular el código que Grabar macro genera, para pasar a generar código directamente con OOo Basic en un segundo momento y nivel de aprendizaje-práctica. Quedaría para un tercer nivel el recurso a Python y sus librerías especializadas.

Con estas metas, en Documentos retomaremos (en caso necesario profundizaremos) en lo ya visto en [OOo Basic], [Python] y [Procedimientos], secciones que anteceden a ésta, ya que necesitamos esos conocimientos para desarrollar nuestro cometido, pero desde una perspectiva aplicada: la generación de docap y herramientas para la semi-automatización del trabajo con los documentos que utilizamos en la práctica habitual: documentos de gestión y aplicación de procedimientos, documentos prescriptivos (Informe, Dictamen y Acreditación, por poner ejemplos de gran relevancia en cuanto carga de trabajo) y documentos de planificación y seguimiento de la intervención. Y todos aquello que vayan surgiendo como potencial motivo de trabajo.

La utilidad que esperamos es inmediata y el ajuste a nuestras necesidades (funcionalidad) queda garantizado por ser recursos que creamos nosotros mismos desde nuestro conocimiento y experiencia. No obstante no podemos (ni debemos) aspirar a crear soluciones maravillosas y definitivas ya que éstas no existen (dicho sea de paso) ni es un planteamiento correcto: debemos aspirar a mejorarlas en función de las limitaciones que detectemos a consecuencia de su uso, y adaptarlas a los cambios, los que impone la Administración, tan dada a "novedades" continuas, pero también a los cambios que nosotros mismos deseemos producir en nuestra práctica.

Disponer de conocimientos y herramientas como las que proporcionan los conocimientos que aquí se pretende desarrollar nos permite afrontar estos procesos con autonomía y seguridad; sin esperar a que alguien lo haga por nosotros. Nadie lo va a hacer, puedes estar seguro, pero es que nadie mejor que nosotros mismos para hacerlo, especialmente para hacerlo bien.

NOTAS

(1) Incluyendo Python.

(2) Visual Basic For Applications (VBA) para MO

(3) Supuestamente competencia genérica a la que no es necesario dedicar esfuerzos específicos de formación, al menos no de forma prioritaria.