Lecciones de Historia

Hace ya bastantes años, veía con frecuencia a mi padre leer libros de historia. Yo, que siempre me he puesto como objetivo ser una persona lo más práctica posible, no entendía por qué en vez de dedicar tanto tiempo a leer sobre la historia, no procuraba estudiar temas más actuales o pragmáticos.

Cierto día se lo comenté, insinuándole que quizá podía aprovechar mejor el tiempo de otras formas, a lo que mi padre respondió algo así: “Qué equivocado estás hijo, de la historia se aprende mucho. Viendo como se han resuelto situaciones o conflictos anteriores, fundamentalmente ayuda a no volver a incurrir en los errores pasados que ha cometido la humanidad”.

Desde ese momento, comencé a ver la historia de otro modo. Posteriormente, me di cuenta que esa argumentación que en su día me hizo mi progenitor no era exclusivamente un pensamiento suyo, sino que eran muchos lo que defendían esa teoría.

Cuando accedí como funcionario TIC a la Administración, después de realizar el curso selectivo hace unos 7 años, estaba encuadrado en un área de desarrollo dirigiendo proyectos. En ese momento, gran parte de los que gestionaba eran de los llamados “llave en mano”. Se subcontrataban a una empresa, que realizaba toda la gestión integral del proyecto en su sede, y los TIC jefes de proyecto, interveníamos muy someramente en dicha actividad, realizando más bien labores de “gestores de contratos”. Nuestro trabajo se ceñía a asegurar que los contratos se llevasen a cabo. Esto nos impedía poder tomar ninguna decisión ni organizativa ni técnica, cediendo completamente el control del proyecto en manos de la empresa.

Era por tanto un modelo de colaboración público-privada totalmente ficticio. La Administración pública ponía el dinero y la empresa se encargaba completamente del proyecto, pero no había ningún tipo de colaboración entre ambas. Estábamos maniatados de los pies a la cabeza, y los TICs, que somos los que conocemos los entresijos de la administración, la legislación vigente en materia electrónica, los proyectos existentes, y somos los más interesados en que los proyectos salgan adelante así como que los usuarios se sientan cómodos con ellos, lo único que podíamos hacer era confiar en que la empresa realizara bien su cometido.

Afortunadamente, según mi opinión, ese modelo fue transformándose. Los TICs que trabajábamos con proyectos fuimos reivindicando la necesidad de cambio, ya que en ocasiones no éramos ni siquiera capaces de poder consultar la base de datos para obtener una estadística que nos pedían, por no hablar de la catástrofe que supondría el cambio de empresa en el contrato de mantenimiento de la aplicación. Esto último incluso ahora, supondría un grave escollo, pero eso es otro tema y algún día me gustaría argumentarlo exponiendo mi modelo ideal.

El personal externo empezó a trabajar en las dependencias de la Unidad Administrativa, y los jefes de proyecto TIC comenzaron a ejercer como tal. Tenían más control tanto técnico como organizativo de sus aplicaciones y, a la vez, se favorecía la práctica de metodologías ágiles, cuyo pilar fundamental es la unidad del equipo y distribución del conocimiento entre todos sus miembros.

Sin embargo, esa transformación no tuvo el amparo legal suficiente, sino que obedeció a cuestiones puramente prácticas. Actualmente e ignorando la historia reciente que impulsó el cambio, vuelve a resonar con fuerza la obligatoriedad de recuperar el modelo anterior, donde todo el desarrollo se realiza externamente.

Y, sinceramente, no parece ser una cabezonería de nadie importante, sino que estoy plenamente convencido que esa medida atiende a cuestiones legales y que casi todos nosotros conocemos, a fin de evitar la cesión ilegal de trabajadores. La administración debe cumplir la ley en su régimen interno sin discusión alguna.

¿Cómo afrontar dicho problema, si por un lado parece bastante evidente que el modelo anterior de proyectos llave en mano no era el idóneo, pero por otro lado hay temas legales que dificultan la implementación de otro paradigma más facilitador?

La solución pasa por modificar la legislación, permitiendo un modelo de colaboración público- privado verdadero, desarrollando aplicaciones apoyándose en un diálogo real entre ambos sectores. No tiene ningún sentido que los TIC no podamos tener contacto con el equipo de desarrollo, así como tampoco lo tiene que los requisitos establecidos en un contrato sean inamovibles, o muy rígidos en el mejor de los casos, si realmente propugnamos desarrollar siguiendo metodologías ágiles.

Yo mismo he tratado de buscar algo de flexibilidad a mis pliegos de desarrollo en aplicaciones tratando de contrarrestar la incertidumbre que siempre existe en el SW, y he obtenido alguna respuesta por parte de los Organismos intervinientes pidiéndome mayor concreción en la redacción. Establezcamos algún mecanismo de contratación que se asemeje un poco más a la realidad del SW, que todos sabemos que no es igual a lo que puede ser por ejemplo una obra y sin embargo rigen sus mismos principios.

De lo contrario, pueden ocurrir situaciones tan tremendas como desarrollar ciertas funcionalidades por el mero hecho de pasar una intervención, ya que en su día fueron definidas en un pliego, pese a que el tiempo y los usuarios detectaron ulteriormente que no tenía ningún sentido realizarla, o que había que enfocarlo de otro modo.

Concluyendo, la ley marca la actuación de la administración, y es imperativo cumplirla. Pero eso no quiere decir que la misma sea correcta o que surjan contextos nuevos que provoquen que no sea idónea y requiera ser modificada. Es necesario que, cuando estas situaciones se detecten, se actúe con celeridad, ya que de lo contrario se impide el correcto funcionamiento de todo el entramado administrativo. En este sentido, hay que ver los errores del pasado para aprender de ellos, y si es necesario cambiar la ley para solucionarlos, háganse dichos cambios.