En el primer post de esta serie se establecieron las principales características del desarrollo de software para la Administración Pública. En este segundo se van a analizar las mismas enfocándolas como “luces y sombras” de dicho proceso, expresando las consecuencias que conllevan dichas luces y sombras.
Para comenzar a analizar éstas “luces y sombras”, vamos a intentar vincularlas con las características comentadas en el anterior post. Evidentemente se trata de una lista resumen que no pretende, ni mucho menos, ser exhaustiva ni completa (harían falta muchos más post como este y horas escribiendo…).
Las luces
+ Desarrollos grandes, ambiciosos. Generalmente se trata de proyectos, que contrata la Administración Pública, de un gran tamaño. Suelen ser desarrollos a medida donde lo usual es ocupar a un gran equipo de trabajo y permite garantizar el trabajo durante bastante tiempo.
+ Proyectos innovadores, que normalmente conllevan el desarrollo de muchos componentes en los que se aprende mucho y para los que conviene hacer las cosas de otra manera, innovando
+ Empleo de tecnologías actuales. Los desarrollos para la Administración Pública suelen requerir el empleo de las últimas tecnologías, generalmente son muy exigentes en ese sentido, por lo que permiten adquirir mucho conocimiento, tanto al equipo de desarrollo como al del cliente.
Las sombras
+ Se trata de un servicio totalmente externalizado en un alto porcentaje de los casos, pero no se suele tratar y gestionar como un verdadero servicio externalizado, lo que lleva a muchas contradicciones y situaciones difíciles de tratar, como, por ejemplo, cuando el cliente exige que esté tal o cual profesional en el proyecto o es capaz de adjudicar un concurso de desarrollo a una empresa porque determinado/a profesional está en ella. ¿Qué hará cuando ese/a profesional deje de estar en esa empresa?
+ Al haber multitud de niveles de interlocución entre el proveedor y la Administración Pública, muchas veces se producen errores y fallos debido a factores de incomunicación efectiva y a que cada nivel del proyecto acaba hablando su propio idioma, muchas veces de espaldas a otros niveles del mismo
+ A veces se producen situaciones francamente difíciles entre la tríada: “proveedor del desarrollo+dirección funcional del cliente+dirección técnica del cliente”, llegándose a casos en los que las dos direcciones del cliente acaban yendo en sentido contrario y materializándose “alianzas” antinaturales que nada benefician al proyecto.
+ Las leyes que rigen en la contratación de la Administración Pública (contratación del Estado y procedimiento administrativo común) no tienen la suficiente flexibilidad para adaptarse a este tipo de proyectos, por lo que los inevitables cambios, modificaciones, etc. en el sistema en desarrollo suelen llegar cuando, muchas veces, ya no son necesarios o han surgido otros más imperativos.
+ Los estándares o metodologías adoptadas por las Administraciones Públicas y que rigen el desarrollo de estos proyectos, suelen ser también muy tediosas y rígidas, lo que desemboca en modelos de desarrollo en los que es realmente difícil introducir evoluciones o mejoras.
+ Todas las Administraciones Públicas tienen procesos comunes y problemas similares, por lo que las soluciones deberían ser muy parecidas o iguales, pero no se da esa replicación o reutilización de soluciones ya operativas porque cada Administración quiere ser la primera y mejor en informatizar un determinado procedimiento o proceso, así que, lo que podría ser una gran fortaleza (por ejemplo usar el mismo sistema de atención primaria o de gestión de centros educativos de Galicia en Valencia o viceversa) se convierte en una debilidad, porque cada una de las Administraciones vuelve a desarrollar de nuevo prácticamente todos sus procedimientos.
+ Los plazos de pago de las Administraciones Públicas provocan que las compañías (algunas veces premeditadamente...) tengan que hacer ciertas argucias para que un proyecto acabe saliendo rentable, como es bajar el nivel de los técnicos adscritos al proyecto, dar prisa al equipo de desarrollo, etc.
+ Lo anterior se une con el peso específico que tiene la oferta económica en la selección de un proveedor u otro por parte de la Administración Pública, lo que provoca que las empresas presenten ofertas a unos precios imposibles, con la consiguiente merma en la calidad de los equipos de trabajo (cualificación, experiencia, etc.).
+ Por último, quisiera comentar un factor que, aunque ajeno a la tecnología y al desarrollo, tiene una enorme influencia en los grandes desarrollos de software y me refiero a los cambios en el estamento político. Y no me refiero solamente a un cambio de signo político (partido en el poder), sino a simples cambios de personas de nivel político en una misma legislatura. Estos cambios, algunas veces, conllevan parones o reorientaciones en los desarrollos que ponen en serio peligro estos proyectos.
Si se observa este “sol y sombra”, puede verse que aparecen muchos más espacios de sombra que de sol, de penumbra que de luz y esto tiene como consecuencia que el desarrollo de software para las Administraciones Públicas resulte realmente complicado y, en muchas ocasiones, con unos niveles de calidad, plazos, eficencias, etc. muy inferiores a los esperados y a los ofertados por las compañías de desarrollo y a los que se suelen dar en otros sectores como el privado.
Hace mucho tiempo que esto viene sucediendo y que, con mayor o menor rigor y precisión, es sabido por todas las partes involucradas, pero parece que lo más cómodo es que todos miremos hacia otro lado y sigamos contratando y vendiendo proyectos de desarrollo de los que sabemos que, en otro entorno o contexto diferente, acabarían calificándose de verdaderos fracasos.
En el tercer y último post de la serie (cuando tenga tiempo ;)) aportaré algunas ideas que pueden servir para paliar algunos de estos efectos adversos o nocivos, evidentemente no hay panaceas y existen condiciones (aspectos legislativos, políticos, etc.) que no se pueden, por mucho que lo deseemos, cambiar... ¿o sí?...