Desarrolladores

La construcción del módulo de catalogación colaborativa surge como respuesta a la gran afluencia de información acopiada por la Comisión de la Verdad. La necesidad de una clasificación y descripción pertinente que permitiera catalogar todo el acopio de archivos, fue forjando, de manera particular y exclusiva, la estructura de datos. En este sentido, el módulo de catalogación colaborativa es una herramienta hecha a medida, la cual se adaptó a esta estructura y ha permitido la administración de la información acorde con estos lineamientos particulares.

Hace parte de una arquitectura previa, por ello, en un primer momento, funcionó integrado a lo que se denominó buscador o metabuscador, motor a través del cual se navega por todos los recursos acopiados por la organización. Este hecho ha implicado, al menos en las primeras fases de desarrollo, que varios desarrolladores toquen los mismos archivos y los mismos recursos, generando algunos conflictos a nivel del manejo de branches en el GitLab.

¿Por qué se ha logrado una buena herramienta?

Según el equipo desarrollador, una buena herramienta es aquella que hace lo que tiene que hacer, y lo hace bien. El módulo de catalogación colaborativa es una buena herramienta en tanto sirve para los procesos de la Comisión y las necesidades que surgen en materia de la carga de archivos, la estructuración de datos y el coleccionamiento de los recursos acopiados por la organización; en últimas, permite solucionar el problema de catalogar un conjunto de datos muy grande, sin que, por la magnitud de la información, se deba romper o rediseñar la estructura indefinidamente.

En un primer momento se utilizó Omeka para esta labor. Omeka es un aplicativo open source, desarrollado en PHP, que cuenta con una base de datos relacional; esta arquitectura limitó el flujo de carga cuando la información comenzó a crecer de manera exponencial. En efecto, el hecho de pasar de una estructura relacional a un árbol empezó a tener limitantes importantes: renderizar el árbol en la interfaz de usuario consumía recursos de máquina que hacían muy lento el proceso, se hacía necesario rediseñar constantemente la estructura de datos para adaptarla a lo que el software ofrecía ocasionando con ello que se perdiera la esencia del proceso, entre otros aspectos que llevaron a desarrollar una herramienta a medida.

Ahora bien, la herramienta no es un software complejo, puede ser definido como un módulo sencillo para cargar información; sin embargo, y es lo que lo convierte en una buena herramienta, el módulo es un engranaje importante dentro de todo el proceso de la Comisión de la Verdad, porque permite organizar y clasificar la información, para que luego pueda ser buscada. Sin esta herramienta, los procesos de catalogación, indexación y búsqueda, posiblemente, hubieran sido lentos.

La particularidad que caracteriza la estructura de datos y los procesos que posibilita el módulo, son los que hacen a la herramienta única para la Comisión de la Verdad; sin embargo, y a través de la gestión de formularios, la herramienta puede adaptarse a otras instituciones sin que sus respectivas estructuras de datos tengan que modificarse. Ahora bien, para que la herramienta sea funcional en otras entidades, debe ir acompañada de un motor de búsqueda que permita navegar por el mar de información que se clasifica y cataloga; es decir, no tiene mucho sentido si se carga información, pero no se busca en lo que se añade.

Aprendizajes y experiencias

Los procesos misionales de la Comisión de la Verdad implican que profesionales de diferentes áreas generen diálogos y trabajo colectivo que lleven adelante las diferentes metas de cada proyecto. Implementar una herramienta para la administración de un volumen tan alto de información, requiere un trabajo colaborativo con las personas que van a usar la herramienta para la catalogación y la descripción de dicha información, y los ingenieros de software que se van a encargar de todo el proceso de desarrollo. En este sentido, los aprendizajes del equipo desarrollador vienen dados, en gran medida, por la interlocución con profesionales de otras áreas, por ejemplo, los catalogadores. Según el equipo desarrollador, la diferencia en las estructuras de pensamiento entre un equipo y otro fue un reto importante que abonó el terreno para las posibilidades de mejora que alberga la herramienta.

De acuerdo con lo anterior, y según el equipo de ingenieros, el desarrollo de la herramienta, durante sus primeras fases, estuvo cargado de varios reprocesos propiciados por la falta de una estructura común para la definición de los campos de los formularios; reprocesos que conllevaron a que el avance fuera lento y complejo: se necesitaron muchos cambios para llegar a lo que es hoy los formularios de carga para los distintos tipos de fuente de información que acopia la Comisión. No obstante, esta dificultad se convirtió en el insumo para el potencial de la herramienta: de un formulario estático, se convirtió en un formulario dinámico, estructurado a través de un pseudolenguaje, que permitió ir armando los diferentes campos. Este logro y aprendizaje del equipo, catapultó la herramienta para que pudiera ser adaptada a instituciones particulares a través de la gestión de formularios.

Finalmente, luego de haber hecho el formulario dinámico, ya si pedían cambios no era tan traumático, porque el desarrollo estaba hecho para eso precisamente: si querían otro campo, yo escribía cinco líneas y ya, estuvo el nuevo campo... y adaptado de principio a fin, desde el momento en que aparece en el formulario, hasta que llega a la base de datos tipado donde debe estar. Una dificultad que se resolvió con desarrollo, porque catalogación necesitaba ver el formulario… es un proceso de retroalimentación necesario; ellos necesitaban ver cómo operaba el formulario, para hacer los ajustes o para ver qué era lo que se necesitaba, y sobre eso reconstruir. El problema es que fueron muchas iteraciones, entonces fue un poco tedioso…

El formulario dinámico es lo que más tiempo de desarrollo ha tenido; se hizo con el fin de adaptarse a las necesidades de catalogación y al ritmo de edición que presentaba el proceso. El equipo de catalogación necesitaba ver constantemente el formulario para ir tomando decisiones: crear, eliminar o modificar campos. En este sentido, el formulario dinámico es un formulario moldeable, que permitió este flujo de trabajo.

Estas iteraciones y constantes cambios, según el equipo, ha dejado una data sucia que se va limpiando con scripts construidos en Python; no obstante, más allá de ser una data sucia, da cuenta de los procesos de retroalimentación y mejora continua que se han seguido con el módulo de catalogación colaborativa.

El módulo permitió centralizar toda la información manejada por la Comisión en una misma interfaz gráfica, lo cual facilitó muchas tareas; adicionalmente, permitió entender la necesidad del usuario más allá de las historias de usuario (ver: ¿Qué es una historia de usuario?). Este último punto, generó la posibilidad de interactuar directamente con los usuarios en un diálogo que abonó el terreno para un escenario de construcción colectiva, donde se iba desarrollando y desplegando a producción, mientras se conversaba en mesas de trabajo; algo que, generalmente, no se hace en procesos Scrum para el desarrollo de software.

Entendí que yo podría resolver y resolver historias de usuario, pero si no resolvía la necesidad del usuario, no tiene mucho sentido… entonces, uno como ingeniero es el que tiene la tarea de adaptarse al lenguaje y al discurso del otro, y eso llevado a la vida: uno es el que debe adaptarse y cambiar, y en el camino todo se transforma, todo se vuelve más tranquilo... de hecho, intenté llevar mi forma de pensar, mi discurso, mi pensamiento sistémico arraigado… pero nunca existía una comunicación tan chévere, hasta que empecé a flexibilizarme y a entender un poco la necesidad de ellos…