A raiz de este post de @alorza en su blog Administraciones en Red se ha creado mucha controversia y diversidad de opniones, tanto en el propio blog como en meneame.
Me estaba planteando añadir un comentario en el post de Alberto, pero finalmente he optado por publicarlo aquí, por he llegado un poco tarde al post y porque me voy a extender bastante.
Sólo llevo dos años trabajando para la Administración, pero sólo unos meses fueron suficientes para darme cuenta de la ineficiencia con la que se gestionan los recursos, sobre todo en el ámbito relacionado con las TIC. Llevo tiempo planteándome cuáles son los principales problemas del modelo existente que hacen que proyectos cuyo coste de desarrollo en ningún caso superaría los 50.000€ lleguen a suponer a los ciudadanos, entre costes directos e indirectos, cientos de miles (e incluso millones) de euros.
En mi opinión, existen distintas causas que llevan a este tipo de situaciones. Muchas de ellas son inherentes al modelo de gestión y contratación pública (burocracia, rigidez en la contratación, amiguismos, etc.), y otras a la propia naturaleza de los proyectos TIC (cadenas de subcontrataciones, repetidas ampliaciones de presupuestos debidas a modificaciones de requisitos durante el desarrollo, proyectos que no terminan nunca, etc.). Sin embargo, voy a intentar centrame en el problema al que hace referencia el título del post:
¿La administración necesita incorporar programadores?
Esta pregunta hace referencia a dos cuestiones fundamentales sobre el modelo de desarrollo de aplicaciones para la administración pública:
- ¿Externalizar o Desarrollar en casa? Es decir, ¿la adminstración debe contratar programadores para llevar a cabo sus desarrollos, o debe externalizar esta tarea?
- ¿Centralizar o Descentralizar? Es decir, ¿debe centralizarse la gestión del desarrollo de aplicaciones, o cada necesidad debe ser abordada de manera individual (independientemente de que se externalice o se haga desde dentro?
La cuadrícula resume un modelo de gestión mixto, en el que la administración mantiene las competencias en las que aporta valor, mientras que delega (externaliza/outsourcing) aquellas labores en las que no es experta y otros pueden hacer mejor. Voy a entrar en cada una de las grandes zonas de este cuadro, para explicarlas en detalle:
1) Competencias con Gestión Centralizada, abordadas desde Dentro
En este punto incluyo todas las cuestiones que la Administración debería realizar por ella misma (no subcontratar) y de manera centralizada (abordarlas como un todo, no individualmente en cada proyecto). En general, se trata de aquello que forma parte del "core" del negocio y es difícilmente trasladable de un proveedor a otro sin que ello suponga un alto coste o pérdida de conocimiento/control:
- La definición de las herramientas/productos a utilizar, así como la definición horizontal de la arquitectura de las aplicaciones, para darles homogeneidad y permitir la mantenibilidad. Aquí es donde en la administración deberían existir excelentes arquitectos técnicos que marcasen las pautas a seguir por los proveedores (no programadores, pero sí una especie de "hackers" o "gurús" técnicos que definan las líneas a seguir por el resto y que se encarguen del desarrollo del framework base).
- Junto con el desarrollo del framework, los arquitectos deberían definir una normativa de desarrollo de obligado cumplimiento por los proveedores. Con esto garantizarían, además de homogeneidad y mantenibilidad, que los proyectos cumplen con los mínimos de calidad, ya que se centraliza el otorgar el "sello de calidad" imprescindible para que un proyecto se considere finalizado
- Para no dejar el desarrollo y soporte en completas manos del proveedor sin control alguno, se deberían de abordar de manera centralizada auditorías selectivas/aleatorias de los procesos de desarrollo y soporte al usuario final.
En este punto incluyo todas las cuestiones que en mi opinión se deberían abordar de manera centralizada (abordarlas como un todo, no individualmente en cada proyecto), pero se podrían subcontratar a algún proveedor externo:
- El desarrollo de aplicaciones horizontales a la administración. Por ejemplo aplicaciones de gestión presupuestaria, control financiero, recursos humanos, etc.
- La gestión centralizada de compras (incluido hardware y software). Aunque no es parte "core" del negocio, si se hace de manera centralizada se consiguen mejores precios y se evitan redundancias. Se podría externalizar esta competencia, dejando esta gestión en un proveedor que fuese "a comisión" en función de los precios conseguidos (siempre manteniendo el requisito de calidad exigido).
- La gestión de las infrastructuras tecnológicas. Gestión centralizada de servidores, redes, telefonía, etc.
- El soporte horizontal de primer nivel, tanto a nivel hardware como software. Los problemas de soporte de aplicaciones no horizontales se derivarían a la gestión vertical del soporte de nivel 2 del apartado 4).
En este punto incluyo todas las cuestiones que en mi opinión la Administración debería realizar por ella misma (no subcontratar) y de manera descentralizada, es decir, abordar la problemática concreta de cada proyecto/área de la administración:
- El conocimiento funcional del negocio. Lo que se llama comunmente el "know-how", debería mantenerse en manos de la administración, para que un posible futuro cambio de proveedor no acarrée la pérdida del conocimiento intrínseco del negocio (y evitar demasiada dependencia de un proveedor en concreto). Por esto creo que la fase de análisis de los proyectos debería realizarla el proveedor externo, pero con participación de personal propio de la administración.
En este punto incluyo aquellos temas que por no formar parte del "core" del negocio o no resultar críticos si se realizase un cambio en el proveedor que los proporciona, podrían externalizarse y tratarse de manera descentralizada:
- Desarrollo de aplicaciones verticales: Aplicaciones a medida para necesidades concretas de áreas de la administración, pueden ser desarrolladas en su totalidad por el proveedor externo (siempre siguiendo las directrices marcadas en cuanto a arquitectura y productos/herramientas a utilizar).
- Uso de metodologías de desarrollo: Dejaría a elección del proveedor la metodología de desarrollo a utilizar (metodologías ágiles o no, en función de la naturaleza del proyecto). Sólo exigiría estándares de calidad al producto final, no interferiría en el proceso de desarrollo (salvo las auditorías aleatorias arriba mencionadas).
- Soporte para aplicaciones verticales: El proveedor se encargaría también de dar soporte (y desarrollar evolutivos) sobre las aplicaciones verticales desarrolladas.
Mi conclusión general es que la administración no necesita programadores, porque esto derivaría en los problemas típicos de la Administración, aumentados si cabe por los ya inherentes a la naturaleza de los proyectos TIC (burocracia, falta de agilidad, mucha resistencia ante el cambio/innovación por las grandes inercias, proyectos que se dilatan en el tiempo, etc.). El tipo de programadores que hace falta para realizar proyectos tecnológicos satisfactorios (e innovadores) no se ve atraído por las ventajas que pueda aportar el trabajar para la administración. Lo que necesita la administración es delegar el desarrollos y centrarse en contar con profesionales en los siguientes ámbitos:
- Arquitectura de Aplicaciones (área horizontal): Para definir normativas y frameworks de desarrollo y comprobar estándares de calidad. Esto podría ser lo más parecido a "programadores de alto nivel" o "hackers" que necesita la administración: Arquitectos de Software.
- Análisis funcional y conocimiento del negocio (áreas verticales): Para conservar en la administración el conocimiento funcional del negocio y no delegar por completo este conocimiento en el proveedor externo, la administración debería tener en plantilla expertos funcionales en cada uno de sus negocios (sanidad, educación, etc.).
- Auditoría de procesos (horizontal): La administración debería contar con expertos auditores que revisasen selectivamente los procesos de desarrollo y soporte de los proveedores externos, para permitir la externalización pero a la vez mantener las riendas sobre el control final de estos procesos (y no permitir que el proveedor se relaje con estas cuestiones).
Me dejo muchas ideas en el tintero, sobre todo ideas sobre posibles soluciones a los problemas no relacionados con la externalización o centralización de los desarrollos (y por tanto no relacionados con la pregunta planteada en este post): burocracia en la contratación, amiguismos, cadenas de subcontrataciones, etc... En mi opinión la solución de la mayoría de estos problemas como bien menciona @alorza en su blog pasa por la total transparencia en la gestión. El problema es que a muchas personas que ocupan cargos políticos en los que recae el poder de estas decisiones no les interesa que exista dicha transparencia porque son los primeros en beneficiarse de ella. La presión popular en España tendría que ser muy alta para acabar obligando a los gobernantes a apuntarse al carro de la transparencia (igual que sucedió en el Reino Unido).
¿Qué te parece el modelo propuesto? ¿cuáles crees que son sus puntos fuertes/flojos? ¿qué echas en falta?
4 comentarios:
Ciertamente es un tema sumamente interesante, y coincido contigo en mucho de los temas que comentas. Como trabajadora de una empresa externa, que colabora estrechamente con la administración desde hace varios años, creo que puedes encontrar algo similar a lo que planteas en la actividad que actualmente realiza la Sociedad Informática de Gobierno Vasco (EJIE), en particular en lo que se refiere al control de calidad y auditoria de software, arquitecturas, etc.
Sobre lo de contar con expertos funcionales por Departamentos, lo veo difícil. Más que nada por la forma en que cada uno amarra el conocimiento en su silla, que hace difícil que una o pocas personas tengan una visión global lo suficientemente amplia como para asumir ese rol que comentas. En el caso del proyecto en el que estoy actualmente, lo que hacemos es, con independencia de contar con los habituales analistas funcionales, disponer de un nuevo perfil, más vinculado a los procesos de gestión del cambio, que actúa como bisagra entre los funcionarios y los analistas, y de esta forma digamos que traduce a un lenguaje comprensible por todos, las necesidades reales. De esta forma se ahorra tiempo y recursos.
Ya siento la chapa, pero es un tema muy interesante, debería dar para unas jornadas o algo, ¿no?
Hola Sonia, desde ICM (Informática de la Comunidad de Madrid) tratamos también de cubrir las necesidades de las distintas Consejerías a través de la externalización y la centralización de la gestión.
Sin embargo hay muchas de las competencias que no coinciden con el modelo que planteo, bien por temas históricos, bien por diferencia en el modelo de gestión planteado o bien por temas políticos.
Concretamente yo trabajo en el Área de Arquitectura de Aplicaciones, desde donde definimos metodologías, estandarizamos desarrollos (tenemos nuestro propio framework java/j2ee) , controlamos la calidad final de los productos y damos soporte a desarrolladores externos.
En ICM sí que tenemos perfiles verticales por consejería que conocen el negocio (jefes de área y jefes de proyecto que llevan muchos años pegados al cliente), y la verdad es que son fundamentales en ese papel "bisagra" que planteas.
Totalmente de acuerdo contigo, da para tratar largo y tendido en unas jornadas sobre el tema. Yo estaría dispuesto a colaborar a título personal en la organización, pero desde mi posición actual veo difícil promoverlas a nivel corporativo :-(
Es alentador saber que tenéis jefes de proyecto realmente conocedores de la realidad de las Consejerías. Porque existir existen, y se preocupan, eso lo sé con conocimiento de causa, por la realidad de las Consejerías a nivel funcional, pero esa bisagra muchas veces se parte si quiere ir sola, y necesita externalizar un servicio del tipo del que damos nosotros, para canalizar la comunicación con los funcionarios, con los usuarios finales.
En mi opinión, muchas veces es un tema de falta de comunicación, de barreras creadas entre "lo informático" y el negocio, que costará superar.
Y sobre las jornadas, si hay alguien por ahí interesado, yo me apunto a co-organizarlas. La peque no me deja ahora mucho tiempo, pero es cuestión de conciliar :-)
Yo también estoy de acuerdo en varias de las cosas que planteas.
A mi gusto quizás habría que tener en cuenta también el coste de algunos de los proyectos, pues externalizando muchas veces se incrementa bastante, he visto proyectos que se han externalizado que han costado varios millones (de las antiguas pesetas) y que podría haberlo hecho una persona de dentro hasta incluso mejor y por mucho menos dinero.
Publicar un comentario