Redmine para la gestión de la contratación de un organismo

En una entrada anterior, “Redmine como herramienta para la gestión de un departamento TIC”,  comenté como el uso de aplicativos de gestión de procesos o tareas puede ayudar en la gestión de las actividades de una unidad TIC. Igualmente, estos gestores de tareas pueden ampliarse fácilmente para utilizarlos como herramientas más específicas del control del trabajo de un área determinada del negocio. En este caso, comentaré como se puede utilizar Redmine para la gestión de la contratación de un organismo.

Todo organismo público tiene una unidad o área dedicada a la contratación o a la coordinación de la contratación del resto de unidades. Comúnmente, esta unidad o área es también la responsable de la gestión presupuestaria del organismo ya que son tareas que van muy unidas. Es común también que estas unidades o áreas utilicen, para la gestión de los expedientes de contratación y la gestión presupuestaria de los mismos, las aplicaciones que informática de la Intervención General del Estado pone a disposición de los organismos. Siendo estás aplicaciones muy adecuadas para la gestión desde el punto de vista de la parte contable y presupuestaria, no es posible en ellas realizar un seguimiento de las tareas propias del organismo o unidad. En el caso de la contratación y la gestión presupuestaria, las tareas a realizar son en muchos casos labores de intermediación entre la unidad que realiza el contrato y los organismos fiscalizadores o que actúan como órgano de contratación, por lo que es muy importante para el aumento de la eficiencia llevar un control preciso de esas tareas de intermediación y de los tiempos de las mismas. La respuesta a toda mejora organizativa no es siempre una herramienta informática pero es cierto que algunas herramientas informáticas permiten una mejora de los flujos de trabajo, y este es uno de esos casos.

En este caso y después de analizar varias opciones, nos hemos decidido de nuevo por Redmine como sistema de seguimiento de las tareas de contratación en la Dirección General del Catastro. Dado que la herramienta estaba implantada en el área de informática con muy buenos resultados, la implantación de la misma para la Secretaría General, responsable de la contratación y los presupuestos del organismo, era una tarea muy abordable y con un rápido retorno.

En primer lugar, fue necesario crear un área específica de trabajo en el ámbito de la contratación, obviamente con acceso restringido a los usuarios apropiados. En este caso, se ha establecido un acceso a distintos niveles:

  • Área de contratación de la Secretaría General: responsable de la tramitación contable y presupuestaria de los expedientes de contratación
  • Área de presupuestos de la Secretaría General: responsable del seguimiento presupuestario de los expedientes.
  • Áreas de negocio de otras subdirecciones, responsables del negocio de los contratos e impulsoras de los mismos. Estas áreas pueden iniciar los expedientes, así como realizar el seguimiento del estado de tramitación de los mismos.

 

Área de contratación en Redmine
Área de contratación en Redmine

Posteriormente y quizás el trabajo más importante de configuración, hay que establecer los tipos de peticiones que vamos a ser capaces de gestionar con el sistema. En nuestro caso son variados:

  • Procedimientos abiertos y negociados (y sus prórrogas) en los que el órgano de contratación es la Junta de Contratación del Ministerio.
  • Procedimientos abiertos y negociados (y sus prórrogas) en los que sí somos órgano de contratación.
  • Acuerdos Marco.
  • Contratos menores.
  • Contratos de gestión centralizada, es decir, aquellos que nos prestan servicios pero son llevados por otros órganos, como el de correos postales por ejemplo. Nos interesa reflejar duración y pliegos en este caso.
  • Encomiendas de gestión.
Vistazo del área de SG en Redmine
Vistazo del área de SG en Redmine

Para cada una de estas peticiones es necesario definir campos customizados en Redmine y flujos de estado. Este es un trabajo que requiere gran esfuerzo y debe ser realizado con minuciosidad. Sirve, en nuestro caso y creo que en el de muchas organizaciones, para definir correctamente los estados y flujos de la tramitación de los diferentes expedientes, lo cual es un gran avance para una unidad que vive de la tramitación de expedientes de contratación. Es sorprendente como habitualmente los flujos de contratación no son conocidos al detalle por la totalidad del personal dedicado a estas labores por lo que el trabajo de definición y documentación es un gran paso para la unidad y permite realizar una simplificación de algunas tareas internas relacionadas con estos procesos de contratación.

Flujo de trabajo para un procedimiento abierto
Flujo de trabajo para un procedimiento abierto

En el caso de los campos, nosotros hemos definido, a través de campos fecha, toda interacción que se realiza con unidades y organismos externos a la Secretaría General, generalmente fecha de ida y fecha de vuelta. Esto nos permite tener muy controlados las siguientes tareas a realizar, en el tejado de quién está la pelota y cuanto tiempo lleva en manos de otro o en nuestras manos un trabajo. Así hemos economizado mucho los tiempos de tramitación.

Campos de tipo fecha para un expediente de contratación
Campos de tipo fecha para un expediente de contratación

Obviamente, también hemos tenido que definir campos propios de la contratación que nos permiten el control presupuestario o el enlace con aplicaciones externas que llevan también temas de contratación, como Sorolla2 o la Junta de contratación. Esto último es muy útil para el personal que se ve obligado a trabajar con varias aplicaciones y permitirá, a la larga, una redirección automática.

Campos propios de la contratación
Campos propios de la contratación

Además, hemos definido otros campos de texto o tipo link para diferentes utilidades, como enlaces a la plataforma de contratación, adjudicatarios, controles internos o simplemente  observaciones del tramitador.

Obviamente, una parte fundamental para nosotros es guardar todos los documentos que componen el expediente y tenerlos accesibles a un solo click, así como la historia de su tramitación a través de las notas de las peticiones.

Documentos anexos a un expediente de contratación
Documentos anexos a un expediente de contratación

Respecto a los documentos, inicialmente no guardamos los documentos contables ya que estos los tenemos en Sorolla2, pero posteriormente y por comodidad de los tramitadores, se han ido incorporando. Se ha creado un flujo de digitalización de entrada y archivo  de todos los documentos que nos llegan en papel para que dichos documentos sean puestos a disposición de los tramitadores en formato electrónico a través de la herramienta según nos llegan y no circulen físicamente por las mesas, dado que en alguna ocasión se ha producido algún extravío de la documentación. De esta forma, la unidad de archivo gestiona el flujo de documentos en papel y realiza la custodia y expurgo de los mismos.

Un aspecto muy útil para nosotros que viene incorporado al sistema es la personalización de búsquedas sobre las peticiones, los cuales nos permite definir diferentes avisos o consultas para el seguimiento de las tareas. Algunos ejemplos son:

  • Expedientes en trámite (agrupados por subdirección, por aplicación presupuestaria, etc),
  • Tramites de la Secretaría General pendientes: solicitud de inicio, envío a fiscalización, solicitud de insuficiencia de medios, etc.
  • Trámites de otros organismos que están pendientes.
  • Siguientes solicitudes de comprobación que debemos realizar.
  • Etc.
Avisos sobre trámites de contratación en Redmine
Avisos sobre trámites de contratación en Redmine

Además de estos avisos, Redmine dispone de su propio sistema de alertas ante eventos de las peticiones, que permite seguir por email, mediante suscripciones a la petición, los expedientes que interesen. Sin embargo, aunque el sistema de alertas y avisos de Redmine cubre todo lo principal, en la Secretaría General se requería de alguna actuación complementaria más avanzada que permitiese realizar un control sobre los expedientes incorporados, generar avisos más sofisticados o cambiar el estado e importe de las peticiones según se van tramitando.  En concreto, requeríamos realizar las siguientes acciones de forma automática:

  • Cambiar el estado de un expediente  cuando se producen ciertos eventos registrados en campos de tipo fecha que indican un estado de tramitación diferente. Por ejemplo, al rellenar el campo de aprobación del expediente, éste pasa automáticamente a estado “Aprobado”.
  • Comprobar automáticamente la corrección de los importes, las fechas de inicio y fin y las anualidades reflejadas, las aplicaciones presupuestarias consignadas, etc.
  • Generar avisos por correo de ciertas actuaciones que la dirección quiere conocer, como envíos realizados al Secretario de Estado, finalización e inicio de contratos, etc.
  • Calcular el importe facturado. En una segunda fase de evolución del sistema hemos incluido los pagos como otro tipo de petición hija de un expediente de contratación. En este caso, nos interesa actualizar en el expediente padre la información agregada de los pagos realizados.

Para ello, hemos desarrollado una sencilla aplicación que realiza todas estas comprobaciones, genera los avisos y actualiza las peticiones en función de los campos de tipo fecha que se han rellenado.

Código de la aplicación
Código de la aplicación

La aplicación está escrita en Java con maven como gestor de despliegues. He publicado su código en mi página de Bitbucket por si le quieres echar un ojo.

La aplicación se ejecuta tantas veces al día como queramos a través de un sencillo proceso Jenkins.

Trabajo en Jenkins
Trabajo en Jenkins

Por último, indicar también que dentro del proyecto de digitalización de procesos en la Secretaría General nos ha sido de gran utilidad el módulo wiki de Redmine, ya que nos ha permitido definir colaborativamente las principales tareas de contratación de la unidad. Cada usuario de la Secretaría General involucrado en contratación y presupuestos puede insertar o editar las entradas de la wiki que versan sobre materias como las siguientes:

  • Aplicaciones utilizadas en la contratación.
  • Principales trámites para la gestión de contratos.
  • Principales documentos gestionado y requeridos en los expedientes de contratación.
  • Agenda de contacto con otras unidades.
  • Instrucciones dadas por organismos externos.
  • Etc.
Wiki de la Secretaría General
Wiki de la Secretaría General
Detalle wiki Secretaría General
Detalle wiki Secretaría General

En conclusión, la implantación de Redmine en la Secretaría General de la Dirección General del Catastro ha sido un completo éxito. Todos los expedientes de contratación “vivos” en 2017 han sido incorporados al sistema y han sido tramitados electrónicamente a través de él. La herramienta ha tenido una gran aceptación y nos ha permitido mejorar la eficiencia de los trabajos realizados. En concreto, destacaría los siguientes puntos de mejora:

  • Permite tener registro histórico de todas las actuaciones realizadas de forma que es posible la utilización de esa experiencia en tramitaciones similares.  El conocimiento queda ampliado a través de la
  • Permite ver el grado de avance de la tramitación de los expedientes, tanto por el personal directivo del área de contratación y presupuestos como por las unidades de negocio.
  • Permite el acceso sencillo a la documentación de los expedientes.
  • Permite la implementación de controles automáticos más fiables que los humanos.

De cara al futuro, la herramienta tiene un gran potencial de mejora. Desde conectarse a otros sistemas de tramitación de la intervención, Junta de contratación o Plataforma de Contratación del Estado hasta extender la herramienta a otras áreas del negocio.

Redmine como herramienta para la gestión de un departamento TIC

En los últimos años, uno de los proyectos más interesantes en los que he participado es la implantación de un sistema de gestión de proyectos TIC en la unidad en la que prestaba servicios.  Las unidades TIC son, en general, complejas de organizar debido sobre todo a la variedad de aplicaciones y tecnologías existentes, a la gran demanda que las unidades de negocio hacen de dichos aplicativos y a lo complejo que es compaginar los proyectos que el negocio demanda con los proyectos que son requeridos por la propia organización TIC y por la evolución de la tecnología.

Existen muchos modelos de unidades TIC pero, además de lo comentado anteriormente, todas ellas comparten cierta complejidad derivada del modelo de contratación y del modelo de gestión de la demanda implantado. Podemos destacar los siguientes puntos a este respecto:

  • Gestión de la contratación con proveedores y acompasamiento de la misma con las necesidades de las unidades de negocio. La contratación en general, y la contratación TIC en particular, es compleja y requiere de una gestión muy pormenorizada para obtener la máxima eficiencia.
  • Gestión de los objetos de la contratación, los cuales pueden variar a lo largo de la vida del contrato a demanda de las unidades de negocio. Existen fórmulas de contratación que permiten este modelo de demanda cambiante, aunque tradicionalmente no ha sido así y las unidades han estado muy restringidas por la definición de los objetos de un contrato, realizada con mucha antelación y sin los datos adecuados (fallo del modelo tradicional de desarrollo en cascada).
  • Implicación y descripción funcional. Es complejo implicar a las unidades funcionales en el propio ciclo de desarrollo (por ejemplo como Product Owners si hablásemos de SCRUM) de forma que participen en las pruebas y evolución de los requisitos. Normalmente los requisitos llegan muy poco formalizados (lo cual no es un problema en un modelo iterativo cuando la implicación funcional posterior es alta pero si lo es en un modelo de definición previa de entregables) y , casi siempre, en el último momento y con poco margen de maniobra.

Es por todo esto que es necesario dotar a la unidad TIC de los más eficientes mecanismos de gestión que minimicen toda esta complejidad y, es ahí, donde alguna herramienta nos puede ser de gran utilidad. Creo que las organizaciones se dividen en dos tipos: las que cambian cuando lo hace su entorno y, por tanto, se ven obligadas a cambiar, o las que se adelantan al entorno para propiciar y gestionar sus propios cambios. Sin duda, las organizaciones tipo 2 son más eficientes por lo que no se deben posponer este tipo de proyectos internos para “cuando haya un hueco”, sino que deben ser acometidos como parte estratégica de la unidad. Como he comentado antes, no es fácil compaginar estos proyectos estratégicos internos con el despliegue de nuevas funcionalidades demandadas por el negocio pero es la labor del profesional TIC saber hacerlo porque de eso depende el éxito de la unidad ya que, inevitablemente, el desarrollo de negocio no podrá sostenerse en el tiempo sin una evolución continua en los métodos de gestión y en el aprovisionamiento de nuevas infraestructuras tecnológicas.

Centrándonos en el tema de las herramientas, muchas son las opciones disponibles. Lo que buscamos es un sistema que nos permita enlazar todas nuestras tareas de desarrollo (y explotación y sistemas) con los requisitos del negocio e incluso con la gestión de la configuración. De esta forma, es muy fácil obtener ventajas y resultados a corto plazo:

  • Alineamiento de cada actividad de la unidad con los objetivos de la organización. Su visualización en cuadros de mando puede ser de gran impacto para la dirección.
  • Seguimiento y gestión de las tareas desde un nivel de agregación propio de la dirección (TIC y no TIC) hasta el nivel más detallado posible.
  • Gestión de los objetos de la contratación e incluso, seguimiento de un contrato gestionado basado en unidades de trabajo (facturación, recepción, etc.). Esto puede ser de gran importancia incluso en contratos de servicios en los que el equipo de la empresa no está en nuestras instalaciones.
  • Gestión de la configuración como paso previo y necesario en la integración o despliegue continuo.
  • Etc.

El proyecto que describo partía de la utilización de unos ficheros Excell, de tratamiento muy complicado, en los que se reflejaban los principales proyectos e hitos de la Subdirección. Estos ficheros se revisaban en las reuniones mensuales que tenían lugar dentro de la gestión de las diferentes áreas de desarrollo y sistemas y eran la herramienta básica de control para la Oficina de Gestión de Proyectos, de reciente creación. Es cierto que se disponía, en algunas áreas, de la herramienta Team Foundation Server de Microsoft para la gestión de ciertos proyectos de desarrollo en tecnología .NET pero, claramente, estas herramientas no proporcionaban lo que la unidad demandaba por lo que optamos por realizar un proyecto de implantación y distribución al negocio de una herramienta para la gestión de procesos de la unidad TIC.

La herramienta que elegimos nosotros, después de sondear el mercado, fue Redmine, por ser software libre y, sobre todo, por ser sencilla y altamente configurable. Sobre la versión inicial del producto, que puedes instalar en una máquina física o virtual e incluso, de una forma más cómoda, como contenedor Docker, hicimos algunos cambios para “customizar” la aplicación a nuestro entorno corporativo. Para ello, lo primero que hicimos fue cambiar el tema y crear una división basada en las sub-unidades que componían la Subdirección TIC.

Áreas en Redmine

Obviamente, hubo que realizar un gran trabajo de instalación, configuración de roles y permisos, tipos de peticiones y campos de las mismas, parametrización de áreas, etc, y sobre todo, un gran trabajo de concienciación y gestión del cambio implantando la herramienta área por área. Destaco lo poco que tuvimos que invertir en optimización de la herramienta siendo un único nodo el que puede dar servicio a toda la subdirección sin ningún tipo de problema.

Configuración de Redmine

Es importante señalar que, como ocurre muchas veces en este tipo de proyectos, el principal escollo del proyecto no fue la parte tecnológica, sino la gestión del cambio. Hubo que realizar una gran labor de comunicación, formación y persuasión interna para minimizar la resistencia al cambio y conseguir llevar a cabo el proyecto con éxito implantándolo a nivel global dentro de toda la unidad.

Vistazo en el panel de Redmine

Mediante el uso de Redmine logramos dar un gran vuelco a la forma en la que se gestionaban los proyectos en la unidad consiguiendo llevar un control más exhaustivo y, por tanto, corrigiendo desviaciones mucho más rápido, así como dotando de transparencia a los diferentes procesos de la unidad.

Los usos principales que le dimos nosotros al sistema son los siguientes:

  • Gestión de proyectos de desarrollo y operación. Esto comprende la definición de requisitos (incluso con documentos adjuntos), la gestión de tiempos y calendarios, la gestión de sub-tareas y su asignación, etc. Esta gestión era especialmente útil en las diferentes reuniones de seguimiento que se llevaban a cabo en la unidad.
  • Seguimiento del trabajo por la dirección. A través de la herramienta es muy fácil ver en qué está la unidad y cual es su grado de avance de cara a presentar resultados a la dirección del organismo (no TIC). Igualmente, es muy fácil clasificar proyectos y alinearlos con la estrategia de la dirección del organismo obteniendo una alineación perfecta de la unidad TIC con los objetivos de la organización.
  • Seguimiento del trabajo por las unidades de negocio. A través de la herramienta las unidades de negocio pueden aportar requisitos, seguir la evolución de los desarrollos y comprender la complejidad y diferentes partes que entran en juego en el desarrollo de sistemas de información.  El sistema de avisos de Redmine, basado en el envío de correos, resultó muy útil para avisar de cambios en el estado de un desarrollo a una unidad de negocio, de forma que puede implicarse en la definición de objetivos, realización de pruebas y corrección de desviaciones. Destaco lo importante que puede ser para las unidades no TIC tener visibilidad y participación en el desarrollo, ya que reduce tensiones y aumenta la sinergia entre las unidades.
  • Gestión de la configuración. Cualquier cambio en código debe ser asociado a una petición (historia de usuario, tarea o error) de Redmine, permitiendo un seguimiento preciso de los requisitos de negocio que propiciaron un cambio. De cara a la implantación de un sistema de integración o despliegue continuo, esta conexión del código (que se despliega automáticamente) con el requisito es fundamental.
Conexión Redmine – Git
  • Seguimiento de la contratación. Los diferentes objetos fruto de la contratación de servicios, son seguidos y gestionados por la unidad desde esta herramienta, asociando proyectos a contratos.

Además de esto, la unidad hizo gran uso del módulo Wiki que incluye Redmine como herramienta colaborativa para la reducción de la documentación en la Subdirección, dentro de un desarrollo mucho más ágil y no basado en documentación.

Wiki en Redmine

Por último, añadir que esta herramienta puede ser utilizada para otros propósitos más generales, especialmente para la gestión de incidencias a modo a como actualmente se utiliza de forma muy extendida Jira (muy parecida a Redmine). La utilización de la herramienta  también para la gestión de las incidencias  de los aplicativos permite cerrar completamente el ciclo de desarrollo, es decir, permite tener enlazada una incidencia con  el código que la corrige y la historia de usuario que generó la funcionalidad a corregir, avisando de un evento a los distintos roles (funcionales o TIC) involucrados en el proceso cuando se produce una corrección.

Agilidad en las Administraciones Públicas

Como os comenté, en febrero dí una charla sobre Agilidad en las Administraciones Públicas dentro de la comunidad Managment 3.0.

En la charla, tratamos los principales problemas que presenta la aplicación de metodologías ágiles dentro de la Administración Pública. Surgieron temas como contratación pública, cesión ilegal de trabajadores, establecimiento de objetos en los pliegos, etc. En definitiva, creo que quedó clara la idea entre los asistentes (muchos del sector público) de que la Administración es un sitio diferente y que, por tanto, la aplicación de técnicas de agilidad requiere de una visión algo diferente.

Os dejo la presentación aquí por si queréis echarle un ojo.

Retos del Peopleware y el Agile Management en la Administración Pública española

Hace poco asistí a un curso sobre desarrollo ágil dado por Javier Garzás. Lo cierto es que era el segundo curso de este tipo que recibía de este mismo ponente y, como el primero, me resultó muy productivo.

El curso tenía por objeto formar a nuestro departamento de desarrollo en frameworks ágiles y, en general, en prácticas ágiles. Desde hace tiempo, estamos intentando implantar métodos más ágiles de desarrollo que nos permitan avanzar más rápido y nos parecía que todo debe partir de una visión al exterior y de un cambio cultural de nuestro propio personal de desarrollo.

Como digo, el curso resultó muy productivo en cuanto a contenidos y exposición de los mismos pero, según iba avanzando, nos dimos cuenta de que las mismas preguntas surgían una y otra vez. Todas ellas tienen que ver con cómo se hacen las cosas en la Administración y con el encorsetamiento en el que viven nuestros procesos internos.

Comentando esto con Javier me propuso dar una charla sobre la implantación de metodologías ágiles en la Administración, algo que llevo intentando hacer desde hace tiempo. La idea me pareció buena y, por eso, os animo a que asistáis si podéis.

El evento, que tiene lugar dentro de la comunidad Managment 3.0, se llevará a cabo el último jueves de febrero.

Nos vemos allí.

Documento y tramitación electrónica en Catastro

Cuatrimestralmente se publica la Revista de la Dirección General del Catastro. Esta revista, especializada en la gestión catastral y la tributación inmobiliaria, constituye un foro de discusión y análisis  de los principales problemas de la citada gestión y recoge los intereses de la Administración Local relacionados con el Catastro.

En el último número de la revista, correspondiente a agosto de 2014, se incluye un artículo del proyecto de documento y tramitación electrónica en Catastro. Este proyecto, como ya he comentado en anteriores entradas, ha supuesto un antes y un después en la gestión catastral, transformando una administración en papel en una “oficina sin papeles”. Actualmente, todos los expedientes catastrales se digitalizan y se tramitan electrónicamente, permitiendo el intercambio electrónico de los mismos entre dependencias de la Dirección General del Catastro y con otros organismos que colaboran en el mantenimiento de la información catastral.

El proyecto tiene un amplio soporte en las tecnologías de la información y las comunicaciones. Ha requerido de importantes desarrollos y de un gran esfuerzo en la gestión del proyecto, sobre todo de cara a su despliegue en las 54 oficinas de la Dirección General del Catastro.

Enlace al artículo: Documento y tramitación electrónica en Catastro.

Primeros pasos en SCRUM

De cara a poner en marcha un proyecto gestionado con SCRUM son muchas las cuestiones a tener en cuenta. Algunas de las más importantes, en mi opinión, son las siguientes.

El primer punto a considerar es el equipo de desarrollo del que se dispone. Las metodologías ágiles recomiendan la utilización de equipos pequeños que se autogestionen. Esto, en realidad, no es algo nuevo de las metodologías ágiles, sino que parte del sentido común y la experiencia. Los equipos con pocos miembros (4-6) son más sencillos de controlar y la información fluye mejor entre los componentes.

En segundo lugar hay que tener en cuenta el espacio en el que se ubica el equipo. Es muy aconsejable que todos los componentes estén juntos y que tengan la lista de tareas visible en todo momento. En mi opinión, no hay herramienta más potente  para recoger la lista de tareas de un sprint que un tablón visible por todos los miembros del equipo y ante el que realizar el SCRUM diario. Yo utilizo este:

Además del tablón, es útil emplear una herramienta informática en la que registrar toda la lista de tareas (pila de producto y pila de sprint) y poder asociarla a cambios de código. Son muchas las herramientas disponibles en el mercado para ello.  Yo utilizo Microsoft Team Foundation Server porque es el gestor de configuración del que disponemos.

En tercer lugar, hay que definir cómo tratar las diferentes clases de tareas que intervienen en el desarrollo de software y definir el concepto de terminado para cada una de ellas. Cuando digo los diferentes elementos del desarrollo me refiero a análisis, bugs, tareas de configuración de los sistemas, pruebas, manuales de usuario, etc. Cómo gestionar estos elementos depende del tipo de proyecto en el que se esté trabajando e incluso puede ser conveniente realizar adaptaciones a medida que se avanza. Te cuento cómo tratamos nosotros algunos elementos, por si te sirve de ayuda:

  • Los bugs los gestionamos como cualquier otro elemento no planificado que surja en un sprint, es decir, se registra, se valora su importancia y se estima el esfuerzo necesario para resolverlo. En base a esto se decide qué hacer con él. Un error muy común en el desarrollo, y al que tienden todos los equipos irremediablemente, es abandonar el trabajo que estaban haciendo cuando aparece un error, por poco importante que sea.
  • La inclusión de tareas de análisis en SCRUM es complicada. Son elementos complicados de estimar y que tienden a retrasarse. No hay una regla para incluir estos elementos. Una buena idea puede ser demorar el inicio del sprint algunos días realizando tareas de análisis con el objetivo de poder estimar mejor posteriormente el esfuerzo de cada tarea y no tener que incluir en el sprint elementos de análisis. Esta demora también puede servir para romper (no por mucho tiempo porque también es un riesgo) el alto ritmo de desarrollo en el que se encuentra un equipo durante un sprint y proporcionarle un respiro.
  • Las pruebas de cualquier elemento desarrollado se incluyen dentro del concepto terminado de la tarea, es decir, para que una funcionalidad esté terminada tiene que incluir sus diferentes pruebas (unitarias, integración, aceptación, etc.).
  • Los manuales o guías de usuario los considero un elemento más de una funcionalidad, por lo que se añaden y planifican como el resto de elementos. Cuando no lo hemos hecho así, este tipo de tareas tiende a dejarse para última hora, con mucho riesgo de no hacerse al final.

En cuarto y último lugar, lo fundamental es implicar al equipo en el proceso de gestión del proyecto. Una tarea fundamental del SCRUM master es conseguir que el equipo crea en el sistema, participe en su mejora, sea participativo en las reuniones y aprenda a utilizar las herramientas de gestión disponibles. Esto genera equipos autogestionados y mucho más productivos.

 

 

Diseño de aplicaciones web

Actualmente, el uso de la tecnología web es predominante en el desarrollo de aplicaciones informáticas. En la Administración no somos ajenos a esa tendencia y la mayoría de aplicaciones que desarrollamos, ya sean sedes electrónicas o aplicaciones de uso exclusivamente interno, son aplicaciones web.

Una parte fundamental en el desarrollo de una aplicación web es el diseño de su interfaz de usuario, es decir, aquella parte de la aplicación que interactúa con el usuario directamente. No importa lo buena que sea la arquitectura de una aplicación o lo bien que esté programada si su interfaz de usuario no es usable y no responde a lo que el usuario demanda de ella.

Mientras que en el sector privado se cuida mucho el diseño de la interfaz de usuario de las aplicaciones web, en el sector público la tendencia no es tan clara. En el caso de las sedes electrónicas, se ha hecho un mayor esfuerzo en el desarrollo de interfaces agradables y, en aún pocos casos, adaptables al dispositivo desde el que se visualizan pero, ¿es esto usabilidad?

Hay mucha confusión con respecto a lo que significa usable. Mucha gente lo asocia a nuevas tecnologías como CSS3, HTML5 o jQuery ya que estas tecnologías son las que permiten implementar controles avanzados de visualización, como menús que se despliegan y repliegan, ventanas modales incrustadas en la ventana principal, etc.  Con el auge de los smartphones y de las tablets, actualmente decir usable también es decir responsive y adaptative, dos términos que tienen que ver con poder visualizar una interfaz de usuario desde diferentes dispositivos. Esta adaptación del contenido de una página al dispositivo desde el que se visualiza se consigue aplicando media-queries, tanto Javascript como CSS.

Sin embargo, más allá de aspectos puramente tecnológicos, la usabilidad de una aplicación es el grado de efectividad en la utilización que hace un usuario de una aplicación. La usabilidad está fuertemente condicionada por el diseño previo que se haga de la interfaz. Este diseño debe tener en cuenta no sólo la adaptación del contenido al dispositivo o la utilización de unas tecnologías u otras sino, por encima de todo, cómo representar la información de la forma que sea más intuitiva y productiva para el usuario. Esto, que parece trivial, no es una tarea nada sencilla. Tampoco es una tarea que pueda ser llevada a cabo por cualquier tipo de perfil, sino que requiere de gente especializada en el diseño de interfaces y en lo que ahora se denomina la “experiencia de usuario“.

Aunque parece que la tendencia está cambiando, es muy común ver equipos de desarrollo web en los que no existe ningún especialista en el diseño y la maquetación de los contenidos, sino que son los propios programadores los que implementan la interfaz. Aunque puede haber excepciones, los programadores no tienen el perfil adecuado para hacer este trabajo por lo que las interfaces que se desarrollan no son todo lo usables que deberían ser. ¿Por qué entonces se produce esta situación?

La respuesta en mi opinión tiene que ver con la errónea concepción que se tiene de la calidad del software en España, entendida siempre como un lujo. Seguro que habéis oído frases como “si haces tantas pruebas es que te sobra mucho tiempo” o “aquí no vendemos nada, ¿por qué deberíamos invertir en una buena interfaz?”. La respuesta es sencilla, por ahorrar dinero. En una empresa esto es muy importante. En la Administración es más importante aún. Un sistema de integración continua, una buena batería de pruebas unitarias, una planificación o un buen código ahorra tiempo y dinero en el mantenimiento de la aplicación e incluso evitando errores en el mantenimiento de ciertos datos, por ejemplo, tributarios. De la misma forma, una buena interfaz de usuario en una aplicación de uso interno hace que nuestros usuarios trabajen mejor, más rápido, más eficientemente y sin errores. En una sede electrónica, nos acerca al ciudadano más y mejor.

Una buena configuración del desarrollo corporativo de una organización es la existencia de un departamento común de diseño. Este departamento deberá estar a la última en aspectos de usabilidad y deberá implantar las mismas líneas de diseño en todas las aplicaciones corporativas, de forma que el usuario de las aplicaciones tenga una misma experiencia de usuario en todas ellas. Una forma sencilla de hacer esto es utilizar plantillas de diseño. Estas plantillas son diseñadas por expertos y son fácilmente adaptables a las aplicaciones. Además, hacen uso de las últimas tecnologías en materia de interfaces de usuario (jQuery, CSS3, HTML5, Enquire.js) y se actualizan cada poco tiempo. En una entrada posterior os comentaré como hemos implantado nosotros una plantilla basada en Bootstrap.

 

Digitaliza

Como comenté en una entrada anterior, una parte fundamental del proyecto de digitalización ha consistido en el desarrollo del sistema de información DIGITALIZA, encargado de la obtención de copias electrónicas de documentos en soporte papel.

El primer paso que se llevó a cabo en el desarrollo de la aplicación de digitalización fue la realización de un análisis de los productos existentes en el mercado para el escaneo y gestión de documentos. Después de realizar proyectos piloto con algunos productos y compartir nuestra experiencia con organismos de la Administración que contaban con estos productos, optamos por llevar a cabo un desarrollo propio. Las razones fundamentales de esta decisión fueron las siguientes:

  • Los productos analizados eran muy caros de licenciar. La mayoría de ellos se licencian por servidor y por número de páginas escaneadas al año que, en nuestro caso, son casi 40 millones.
  • Muchos de los productos eran cliente-servidor, arquitectura que complicaría el despliegue y actualización de la aplicación en una organización tan grande y tan distribuida geográficamente como la nuestra.
  • Muchos de los productos exigían “casarse” con un proveedor de escáneres, lo cual complica y encarece futuras adquisiciones de suministros.
  • La implantación de muchos de estos productos exigía un desembolso adicional (además del coste del licenciamiento) por la adaptación del software a nuestros tipos documentales y a nuestro sistema de registro y tramitación electrónica.

Como contrapartida a estas desventajas, los productos comerciales de digitalización suelen venir acompañados de un módulo, más o menos potente, para la categorización automática de documentos y la extracción de información. El desarrollo de estas funcionalidades es complejo y requiere de mucho conocimiento en la materia, por lo que, en caso de necesitarlas, merece la pena adquirir el producto. Sin embargo, en nuestro caso, debido a la diversidad de documentos que recibimos y a su escasa formalización, las pruebas realizadas no fueron del todo positivas.

Después de considerar todos estos aspectos, se optó por un desarrollo propio y a medida que nos permitiese tener un mayor control del proyecto y del software a implantar.

El producto a desarrollar debía cumplir los siguientes requisitos fundamentales:

  • Integración con la herramienta de registro y tramitación electrónica existente.
  • Adecuación al Esquema Nacional de Interoperabilidad.
  • Integración con el Catálogo Documental mediante la generación de documentos electrónicos firmados electrónicamente por el organismo.
  • Cumplimiento de nuestras normas de digitalización.
  • Adecuación al procedimiento de digitalización diseñado previamente.
  • Integración con los escáneres existentes previamente en la organización de muy diversas marcas y formatos (A4, A3 y A0).

Además de estos requisitos funcionales la herramienta debía tener un alto grado de usabilidad con el objetivo de agilizar, en lo posible, el pesado proceso de digitalización. Al apostar la organización por una tramitación electrónica, es de vital importancia que el proceso de digitalización se realice lo antes posible para, así, no penalizar los tiempos de la posterior tramitación.

Un aspecto importante a destacar de DIGITALIZA es que, al contrario que la mayoría de aplicaciones de digitalización, es una aplicación web y no cliente-servidor. Además, la conexión con el escáner se produce a través de un driver estándar TWAIN y no a través de un driver propietario, lo que permite conectar con multitud de escáneres de diferentes marcas y nos proporciona independencia total en la contratación de suministros.

Desde el punto de vista tecnológico, la aplicación de digitalización presenta la siguiente estructura:

Arquitectura de Digitaliza

Como se puede apreciar en la imagen, el servidor está desarrollado con tecnología Microsoft, en concreto MVC .NET, sobre una base de datos Oracle. Para el desarrollo de la aplicación .NET se ha implementado una arquitectura en n capas siguiendo las recomendaciones de Microsoft e incluyendo, en la capa de presentación, ciertas adaptaciones a MVC.

Respecto a la parte cliente, esta se ejecuta en cualquier navegador web, siendo Internet Explorer la opción corporativa. Se ha intentado trasladar, en lo posible, el procesamiento de los documentos al cliente, liberando al servidor de esa carga. Igualmente, se ha hecho especial hincapié en maximizar la usabilidad de la interfaz y reducir en lo posible el tiempo de la digitalización.

La interfaz de usuario está implementada con HTML5 y CSS3 sobre Bootstrap, lo que permite adaptar el contenido a la pantalla desde la que se visualiza el documento (la organización cuenta con pantallas de 17 y 19 pulgadas con formato 4:3 y 16:9). La implementación de funcionalidades en la interfaz se ha llevado a cabo usando JavaScript y JQuery, así como AJAX y JSON para la transmisión asíncrona de información entre el cliente y el servidor.

La conexión con el escáner se realiza desde la parte cliente, mediante un ActiveX (o un Plugin en navegadores distintos a Internet Explorer) que implementa la conexión TWAIN con cualquier escáner instalado en la máquina. Este componente es el encargado de obtener las imágenes electrónicas del escáner y componer el contenido del documento electrónico. El componente permite la edición de las imágenes obtenidas y su categorización automática mediante OCR y códigos de barras, lo cual agiliza el proceso de digitalización.

Al realizarse el procesamiento de los documentos en el navegador, se reduce la carga del servidor y no se compromete la seguridad de dichos documentos, al no tener que almacenarlos en local como sí ocurre con muchos productos de digitalización basados en un cliente pesado. Esto sin embargo tiene su contrapartida en las transferencias de ficheros que hay que realizar de forma continua entre el servidor y el cliente sobre http. Para reducir los problemas de memoria que esto ocasiona, se ha implementado un envío fragmentado de los documentos de forma asíncrona.

En el desarrollo de la aplicación se ha hecho especial énfasis en el sistema de pruebas, realizándose pruebas unitarias de distintas capas de la arquitectura e implementándose pruebas automáticas de navegación con la herramienta Selenium.

Por último, merece la pena destacar que, como en el resto de aplicaciones del área,  la gestión del proyecto se lleva a cabo con SCRUM utilizando Team Foundation Server como herramienta para el seguimiento de las tareas y el control de la configuración.

La digitalización de documentos

Otro de los grandes proyectos que hemos llevado a cabo en la organización en estos años ha sido la digitalización de la documentación en soporte papel.

La digitalización del papel ha sido el último paso dentro del proyecto de documento electrónico y se ha llevado a cabo una vez que el resto de documentos de la organización eran producidos en formato electrónico y no en papel. Ha permitido a la organización disponer de toda la documentación de los expedientes en formato electrónico, lo cual es indispensable para el posterior intercambio de documentos y expedientes electrónicos tal y como establece el Esquema Nacional de Interoperabilidad (ENI).

El objetivo fundamental del proyecto es la generación de copias electrónicas de toda la documentación recibida por la organización en soporte papel. Ésto, a su vez, permite conseguir los siguientes objetivos estratégicos:

  • Tramitación electrónica de los procedimientos.
  • Intercambio de documentos y expedientes electrónicos entre las propias dependencias de la organización y con otros organismos.
  • Destrucción del papel una vez digitalizado.

Todos estos objetivos se encuadran dentro de la denominada “oficina sin papeles“.

En nuestro caso, la digitalización de la documentación suponía un reto muy diferente al acometido por otros organismos de la Administración Pública. En primer lugar, la digitalización debía ser la base para la tramitación electrónica de los procedimientos, por lo que debe llevarse a cabo antes de la tramitación y no después. En segundo lugar, el volumen de información en papel  que recibe la organización es muy alto, pudiendo alcanzar los 40 millones de páginas al año. En tercer lugar, la documentación recibida es de muy diversa índole y formato, pudiendo ser, desde documentos manuscritos en A4, a planos o fotos en A0. Por último, la digitalización del papel debía realizarse de forma distribuida en las dependencias de la organización, cada una de las cuales se encuentra ubicada en una provincia distinta.

Una vez consideradas todas estas peculiaridades, el primer paso del proyecto fue el establecimiento de unas normas técnicas de digitalización y de un procedimiento organizativo.

Las normas de digitalización especifican aspectos técnicos de la digitalización, como los formatos admitidos, la resolución mínima, la profundidad de bit o color, el uso de OCR, los tipos de documentos a digitalizar, etc. Estas normas son de obligado cumplimiento por la propia organización, así como por los organismos que colaboran con nosotros mediante la remisión de documentos. Un aspecto interesante de estas normas, y que es bastante complejo de determinar, es el grado de separación y clasificación de la documentación a digitalizar. Una separación más exhaustiva mejora la tramitación pero dificulta y ralentiza el proceso de digitalización. Es importante llegar a un equilibrio en este sentido.

El procedimiento de digitalización recoge los cambios organizativos necesarios para llevar a cabo la digitalización del papel en cada dependencia de la organización. Uno de los puntos claves en la implantación del proyecto ha sido conseguir encajar la digitalización dentro de la operativa diaria de cada centro de trabajo. Para esto, se han creado grupos específicos de digitalización compuestos por personal especializado en el registro y clasificación de la documentación, en la digitalización y en el posterior archivo del papel.

Otro aspecto muy a tener en cuenta en este sentido es vencer la resistencia al cambio de los usuarios en lo que se refiere a la tramitación electrónica. Para vencer la resistencia es fundamental dotar a los usuarios de potentes herramientas informáticas para tramitar y digitalizar de forma que encuentren, en los medios digitales, más ventajas que inconvenientes.

Una vez fijadas las normas y el procedimiento, el siguiente paso fue el desarrollo de Digitaliza, la aplicación para la obtención de copias electrónicas de los documentos en soporte papel. Esta aplicación, de desarrollo propio, debía integrarse con las herramientas de registro y tramitación ya existentes en la organización. Es una aplicación web capaz de conectarse con casi cualquier escáner, lo cuál nos dota de mucha independencia en futuras compras de dispositivos de digitalización.

En cuanto a los dispositivos de digitalización, además de reutilizar los escáneres existentes en la organización (con el gran ahorro que esto conlleva), se ha dotado a cada centro de digitalización de escáneres A4, A3 y A0.

El último paso del proyecto fue su despliegue en los distintos centros de trabajo de la organización que, como he comentado antes, se encuentran distribuidos a lo largo de la geografía española. En primer lugar se hizo una implantación piloto en varias dependencias para asegurar el correcto funcionamiento de la aplicación y del procedimiento organizativo de digitalización diseñado. Posteriormente, y con la experiencia de la implantación piloto, se elaboró un calendario de despliegue para el resto de dependencias.

Actualmente, la organización digitaliza toda la documentación que recibe en soporte papel, lo que nos permite tramitar electrónicamente, intercambiar expedientes entre nuestros centros de trabajo por medios electrónicos y mejorar la gestión del archivo. Hemos aumentado significativamente, a través del uso de herramientas electrónicas, la eficiencia y la calidad de los servicios que prestamos y hemos avanzado un paso más hacia el intercambio de expedientes electrónicos con otros organismos de la administración.