Herramientas para la democracia (II): Bug Tracking Systems

En informática, estamos acostumbrados a enfrentarnos a problemas de gran escala, tanto en volumen de información tratada (millones de líneas de código) como en número de usuarios a los que atender. Esto ha hecho que los propios programadores hayan desarrollado sus propias metodologías y herramientas con las que lidiar con dicha complejidad. Uno de éstos campos es el de la relación con los usuarios y la gestión de los informes de error.

Cuando un proyecto tiene un volumen de usuarios equivalente a un país pequeños (por ejemplo, se calcula que Ubuntu Linux tiene al menos 12 millones de usuarios), no se puede seguir la estrategia de "si ves algún error, mándame un correo". No al menos si eres un proyecto de código abierto, en el que no tienes nada que ocultar, y sí te interesa minimizar el esfuerzo del procedimiento (de gestión de la incidencia) para dedica la mayor parte de los recursos disponibles al trabajo (a la corrección del error en sí).

La herramienta que realiza ésta función es un proyecto software es la llamada Bug Tracking System (BTS) o en español, Sistema de Seguimiento de Errores. Como es una buena idea, se ha generalizado a otras áreas y en ese caso se emplea el término más general Issue Tracking System o Sistema de Seguimiento de Incidencias, pero en esencia siguen siendo iguales (los BTS se centran en los errores que un usuario encuentra en el software, pero también incorporan extensiones y tareas, mientras que los ITS la "unidad de trabajo" es el más general problema, petición de soporte o incidencia). También se les conoce —tanto BTS como ITS— como sistemas de tickets, ya que una petición al sistema genera de vuelta lo que se conoce como ticket: un indicador (normalmente un número) con la que el sistema se refiere al error —o problema— a partir de ese momento, y a lo largo del ciclo de vida en el sistema.

La analogía es clara: si un sistema puede ser usado con éxito para la gestión de millones de usuarios —equivalente a la población equivalente a la de un país no tan pequeño—, tal vez pueda ser interesante aplicarla también en la relación de los habitantes de un país con su administración. Algunas ventajas que aportan los BTS/ITS y que pueden ser interesantes:

• Transparencia: uno de las principales motivaciones del surgimiento de los BTS es que el usuario se sienta atendido. Por un lado, el usuario tiene una constancia de que el problema "está" apuntado en algún sitio, y su número de ticket es una especie de garantía de que se ha informado del problema o la reclamación. Sí, ahora también hay números de entrada de instancias a la administración, selladas y demás, pero la diferencia es que la información del BTS es pública, y cualquiera puede consultar que efectivamente esa incidencia existe. Y no sólo eso, sino que la página de la incidencia recoge automáticamente información que permite seguir a cualquiera el progreso de la resolución de esa incidencia públicamente también.
• No duplicados: otra de las principales motivaciones de la función de los BTS es evitar que miles de usuarios reporten el mismo error una y otra vez, cuando el equipo ya es consciente de que dicho error existe (y probablemente están trabajando en ello). En ese caso, es mucho más útil sumarse a una incidencia ya abierta, especialmente si se tiene algo adicional que aportar. Cuando se detecta una incidencia ya abierta en el sistema (a veces no es directa la relación), lo que se hace es marcarla como duplicada, indicar al usuario el ticket de la incidencia original, y cerrarla. De ésta forma el usuario se siente atendido, pero el sistema evita duplicidad de trabajos. Para que esto sea posible, obviamente es imprescindible que el sistema sea transparente (punto anterior)
• Priorización: un usuario inteligente lo primero que haría, antes de abrir una incidencia, es comprobar si esa incidencia ya ha sido reportada por alguien más al sistema. Lo más probable es que sí, con lo que esta breve consulta previa nos sirve para a) evitarnos tener que abrir una incidencia b) evitar a los que atienden el sistema tener que cerrar la incidencia por duplicado. Pero hay otro motivo más para actuar de esta forma, y es sumarse a una incidencia. Obviamente el sistema ideal es aquel en el que se resuelven todas las incidencias, pero la práctica nos dice que normalmente hay más tareas pendientes que tiempo disponible para realizarlas. Lo más interesante es realizar primero aquellas tareas que puedan resolver problemas a más usuarios —esto es, aquellas que resuelvan las incidencias de más usuarios—. Para que esta priorización de tareas ocurra, es imprescindible saber de qué se quejan más los usuarios. Un BTS/ITS, gracias a la transparencia, permite que más usuarios se "quejen" sin tener que gestionar nuevas incidencias, simplemente sumándose a una ya abierta —y siendo atendidos a través de la misma todos ellos—. Los BTS/ITS modernos han añadido entre otras cosas la característica de poder hacer comentarios precisamente por esta razón. A su vez, los gestores, pueden indicar en una incidencia el grado de "gravedad" (severity) o importancia que tiene para ellos, lo que en principio es una manera de informar al usuario si el problema va a ser resuelto pronto, porque es urgente, o "cuando haya un rato libre", porque es trivial (ojo que la gravedad es una indicación subjetiva y no garantiza nada). El hecho de poder consultar las incidencias por prioridad nos permite por otro lado controlar de forma transparente las prioridades de atención que se están imponiendo los gestores, y ver si éstas son las más adecuadas.
• Archivo: una vez que una incidencia ha sido resuelta —o no— y cerrada, ésta no desaparece, sino que toda la información de lo que sucedió con ella permanece a la vista. Esto nos permite a) si el problema vuelve a reproducirse, tanto gestores como usuarios están al tanto de ello b) si no fue resuelta en su día, puede reabrirse la indicencia, no hace falta crear una nueva c) si fue resuelta, nos referimos desde la nueva incidencia a la antigua, con lo tenemos las bases para resolver una nueva incidencia —tenemos "memoria" del problema— d) y si la resolución esta vez es distinta, tenemos un "histórico" del problema y sus soluciones a lo largo del tiempo, recorriendo las incidencias.

El ámbito de aplicación de un sistema así es amplio. Aplicar un BTS sobre el cuerpo legal de un estado o unidad política menor es sólo una de las posibles aplicaciones. Puede aplicarse desde para grandes líneas de actuación, hasta para las cosas más cotidianas. Por ejemplo, un BTS/ITS de una localidad podría usarse para que los usuarios reportasen que una acera tiene unas cuantas baldosas rotas, que hace falta una papelera en un parque o una calle, una farola que no se ilumina, o que en cierto paso de cebra debería ser colocado un semáforo por su peligrosidad.

Otra característica interesante de los BTS actuales (de la que creo que carecen los ITS) es que se han convertido en algo más, se han convertido en herramientas de gestión de proyectos. Según las nuevas metodologías, son las necesidades de los usuarios las que en cierta forma guían el desarrollo de un proyecto, aunque luego éstas estén en cierta forma filtradas por los gestores. De ésta forma, se establecen milestones, u objetivos —hitos o metas— en el tiempo, que en un BTS se traducen en cerrar —se supone que satisfactoriamente— un conjunto de incidencias relacionadas con dicho milestone (y normalmente a partir de cierta  gravedad o importancia). Esto también sirve como una forma de transparencia y control, ya que si nuestro milestone "Plan de Iluminación austero" en nuestra localidad comprende tener el 90% de los semáforos con LED, existe una manera objetiva y verificable de ver si dicho plan se ha cumplido, más allá de una simple proclamación municipal del tipo "lo hemos vuelto a conseguir".