Archivo por meses: septiembre 2014

Adaptación a los cambios normativos en la Administración: el ENI.

Esta semana he leído el último post que ha escrito José Antonio García García en su blog. En esta entrada, propiciada por el lanzamiento del sistema Cl@ve, José Antonio plantea la cuestión del marketing político en las Administraciones Públicas y la diferencia temporal que existe entre que se anuncia una medida por parte de la Administración y ésta es llevada a cabo. Me parece un tema muy interesante que conlleva problemas de implementación de soluciones TIC dentro de la Administración.

Como supongo que ya sabréis, la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, constituyó un hito en lo relativo a las relaciones electrónicas entre el ciudadano y la Administración y entre las propias Administraciones. Al amparo de esta ley y, con objeto de regular los intercambios electrónicos, se desarrolló el Esquema Nacional de Interoperabilidad (ENI), aprobado por Real Decreto 4/2010, de 8 de enero. En el desarrollo normativo del ENI, se han incluido una serie de normas técnicas (NTI) que vienen a regular en detalle aspectos concretos de la interoperabilidad: NTI de documento electrónico, NTI de expediente electrónico, NTI de digitalización, NTI de intercambio de asientos registrales, NTI de gestión de documentos electrónicos, etc.

Tradicionalmente, los intercambios electrónicos entre administraciones públicas se han desarrollado como acuerdos individuales entre las dos administraciones que intercambiaban datos. El ENI, admitiendo dichos intercambios individuales, viene a establecer normas generales para los intercambios de forma que todos los organismos puedan utilizar modelos comunes y se reutilicen los protocolos y sistemas. Esto, muy útil sobre el papel, requiere de una adecuación de los sistemas ya existentes y la creación de nuevos sistemas a tal propósito, con el esfuerzo presupuestario que dichas adaptaciones y desarrollos conllevan. En concreto, los sistemas de la Administración General del Estado debían estar adaptados al ENI antes del 30 de enero de 2014.

Este último año, he participado en un grupo para la elaboración de una política de gestión de documentos electrónicos común a todos los organismos del Ministerio de Hacienda y Administraciones Públicas (MINHAP). El grupo de trabajo, con representación de múltiples organismos y con un gran esfuerzo en dirección y participación, se ha reunido con mucha asiduidad hasta que se ha elaborado y aceptado una política común. Este acuerdo entre los organismos no ha sido sencillo, ya que muchos teníamos implementaciones propietarias adaptadas a nuestro negocio, así como intereses futuros muy diferentes . En todo caso, se ha hecho un gran esfuerzo y se ha llegado a un consenso. En concreto, un tema bastante complejo de acordar han sido los metadatos complementarios (aquellos que no son obligatorios y se pueden usar a criterio de cada organismo) del documento y el expediente electrónico que van a ser incluidos en todos los intercambios entre organismos del MINHAP. Estos metadatos tienen por objeto mejorar la gestión de los documentos electrónicos y la transferencia de los mismos al archivo.

En el seno de este grupo pude comprobar como, lejos de estar adecuados al ENI, muchos de los organismos implicados estaban implementando sus sistemas de intercambio y gestión de documentos y expedientes electrónicos. Muchos de ellos, aún están lejos de lograrlo, ya que el intercambio es el último de los pasos. Previamente, se requiere de la implantación de sistemas de gestión de documentos y expedientes, de digitalización, de archivo, etc.

Pues bien, no estamos adaptados completamente al ENI cuando ya se vislumbran nuevos cambios y adaptaciones. En concreto, parece que los sistemas de firma electrónica van a cambiarse en un futuro inminente. Comparto la opinión de José Antonio, hemos tardado en darnos cuenta de que el DNI electrónico no era el sistema que la gente demandaba. Sí, muy seguro, pero en comparación con las claves concertadas por ejemplo, muy poco utilizado. Los sistemas de firma electrónica contemplados en el ENI son los basados en certificado electrónico y el Código Seguro de Verificación. Ahora, con la aparición de Cl@ve y la futura ley de procedimiento administrativo, que aunará las actuales leyes 11/2007 y 30/1992, parece que se abre un nuevo escenario de firma electrónica en la Administración que requerirá de nuevos cambios, nuevas inversiones y un nuevo periodo de adaptación incomprensible para el ciudadano.

 

 

 

Gestión de proyectos con SCRUM

A lo largo de mi experiencia laboral en la empresa privada y en la Administración Pública, he visto pocos equipos y proyectos que se gestionen adecuadamente.
Adecuadamente, para mi, significa cumplir una serie de condiciones que considero básicas en la gestión de proyectos:

  • Existe control del estado de avance del proyecto.
  • Existe capacidad de planificación y cumplimiento de plazos.
  • Se extrae el máximo rendimiento de los miembros del equipo.
  • Se genera un producto mantenible y de calidad.
Algunos equipos consiguen de forma aislada algunos de estos puntos, pero es complicado encontrar equipos que cumplan con todos. Quizás yo haya tenido mala suerte, pero creo que es fiel reflejo de lo que ocurre en la mayoría de centros de desarrollo software en España.
Aunque cada vez son más comunes los proyectos que se gestionan con metodologías ágiles, la tendencia hasta hace poco ha sido aplicar ciclos de vida en cascada a los pocos desarrollos que seguían algún tipo de metodología. En la administración pública española, la metodología recomendada es Métrica 3, la cual plantea un modelo de ciclo de vida en cascada.
Desde mi punto de vista, pocos son los proyectos a los que este tipo de ciclos de vida en cascada son aplicables. La principal razón de esto radica en que los requisitos rara vez pueden establecerse y congelarse, sino que tienden a variar. La metodología de gestión de nuestro proyecto debe proporcionar flexibilidad en este sentido.
Por eso, y tras varias experiencias fallidas con otras metodologías, hace tres años que utilizo en mis proyectos SCRUM como metodología de gestión y, a día de hoy, puedo decir que pocas veces he acertado tanto en una decisión. Las metodologías ágiles te puede ayudar a conseguir varias cosas, para mí, de vital importancia en la gestión de proyectos:
  •  Flexibilidad ante cambios en los requisitos. 

La variación de los requisitos es algo mucho más común de lo que querríamos dado que el usuario del negocio no suele saber lo que quiere hasta que lo ve. Incluso aunque se establezcan largas tareas de análisis de requisitos, habrá que realizar cambios y nuestra metodología de gestión debe dar soporte a estos procesos.

El objetivo de las metodologías ágiles es la liberación frecuente (un mes como mucho) de entregables que el usuario puede utilizar, de forma que no es necesario esperar a tener todo el producto para corregir posibles desviaciones. Esta característica está muy en consonancia con el tipo de software que se desarrolla en estos tiempos: productos que se implantan y se hacen evolucionar adaptándolos a nuevas necesidades hasta que quedan obsoletos.
  • Alineación con una estrategia corporativa de despliegues periódicos. 
La mayoría de organizaciones de cierto tamaño realizan actualizaciones frecuentes de las aplicaciones para corregir incidencias o sacar nuevas funcionalidades siguiendo un calendario de paradas. En mi organización, por ejemplo, la periodicidad es mensual. Una metodología ágil, como SCRUM, se adapta perfectamente a estos escenarios.
  • Priorización de objetivos por el usuario de negocio.
La sensación que tenemos ahora mismo en la Administración es que cada vez somos menos, tenemos que hacer más cosas y de una forma más eficiente. Desde el negocio cada vez se nos pide más y se nos dan menos recursos para ello. SCRUM te puede ayudar, a través de la figura del dueño de producto (en este caso el usuario de negocio), a definir prioridades y a calcular cuanto puedes hacer en cada entregable. De esta forma, es el propio usuario el que debe decidir que quiere tener el próximo mes y de qué funcionalidades puede prescindir.
  • Control diario del avance del proyecto y del trabajo del equipo.
Si utilizas una metodología ágil, como SCRUM, realizarás una revisión diaria del estado del proyecto. Podrás saber diariamente cuál es el grado de cumplimiento de lo planificado y qué trabajo ha realizado cada miembro del equipo. La información fluye con rapidez y las malas decisiones se corrigen muy rápidamente.
  • Mayor implicación del equipo de desarrollo
Otras de las grandes máximas que he sacado en mi experiencia desarrollando software es que los equipos grandes no funcionan. Muchos son los motivos de esto (información que no fluye, gestión compleja de muchas personas, etc.) pero en mi opinión, uno de los factores importantes es la poca implicación de los componentes del equipo de desarrollo. Es más complicado mantener motivadas a 15 personas que a 6.
La gestión ágil se basa en trabajar con equipos  pequeños, no jerarquizados y autogestionados  en los que la información se comparte con periodicidad diaria. Cuando un miembro del equipo conoce los objetivos del desarrollo, es participe del proceso de gestión del proyecto y de la toma de decisiones y debe exponer su trabajo con periodicidad, su motivación y su rendimiento aumentan muy significativamente.

La utilización de SCRUM como metodología de trabajo ha sido, en perspectiva, un gran acierto para el correcto desarrollo de los proyectos en los que trabajo. La implantación no ha sido fácil. Hemos tenido que definir nuevas formas de trabajo y adaptar la metodología a lo que nosotros necesitábamos para nuestros proyectos (situaciones de análisis, BUGs, manuales de usuario, eliminación de burocracia interna, sistemas de estimación, tablón de SCRUM, etc…).

En posteriores entradas detallaré cómo hemos resuelto nosotros algunos de los aspectos más conflictivos de la implantación de SCRUM por si pueden serte útiles.

Catálogo Documental

Todos los proyectos que he dirigido en la organización en la que actualmente presto servicios han estado vinculados al Esquema Nacional de Interoperabilidad (ENI) y a la administración electrónica.

El primero de ellos, en lo que respecta al desarrollo de software, ha sido la construcción e implantación de un gestor documental acorde al ENI, donde la organización almacene todos los documentos electrónicos que gestiona en sus procedimientos.

El proyecto contaba con grandes dificultades iniciales, no sólo las propias del objeto del desarrollo sino también algunas derivadas del contexto en el que se ha llevado a cabo.

En primer lugar, en el entorno de desarrollo de aplicaciones en la organización es bastante variado e incluye tecnologías de muy diversa índole, como Oracle PL/SQL, Cobol, Forms, .NET, Java,…
Esta variedad tecnológica complicaba el desarrollo del interfaz de servicios a prestar, ya que debía dar soporte a todas las aplicaciones de la organización. La creación del gestor documental ha supuesto un cambio con respecto a la forma de programar de la organización ya que ha sido el primer sistema interno de uso masivo creado con orientación a servicios.

En segundo lugar, el volumen de documentos que maneja la organización es muy elevado y el gestor debe ser muy eficiente en su funcionamiento, ya que las operaciones de catalogación y recuperación constituyen una parte fundamental de la operación diaria de catastro.

En tercer lugar, hasta la creación del gestor, cada aplicación almacenaba sus propios documentos, algo que cambia con la implantación del sistema. Esto supone que no se puede pensar sólo en el desarrollo del gestor documental, sino que hay que ir acompasándolo con la adaptación del resto de aplicativos, con la dificultad que esto conlleva.

A lo largo del desarrollo de este proyecto (aún en continua evolución) hemos tenido que enfrentarnos a algunas cuestiones que me parecen interesantes dentro del desarrollo de software y que comentaré en otras entradas.

Después de la instalación e implantación en enero de 2012 del Catálogo Documental se han ido incorporando documentos y tipos documentales al Catálogo Documental. Este proceso concluyó en enero de 2014, con la incorporación de las digitalizaciones que se realizan de documentos en soporte papel.

A fecha de hoy, el sistema alberga más de 70 millones de documentos, incorpora 50.000 nuevos documentos al día y realiza más de 200.000 operaciones diarias.