Para finalizar esta serie de posts que tratan el desarrollo de software para el sector público, tal que en el primero se comentaron las principales características objetivas y en el segundo se analizaron las “luces y las sombras” de estos desarrollos software en concreto, propongo ahora una serie de medidas que, en mi humilde opinión, pueden ayudar a paliar las zonas de sombra mencionadas anteriormente para incrementar, poco a poco, las de luz.
Seguramente el conjunto de propuestas sea limitado y subjetivo e, incluso, algunos penséis que la mayoría no se pueden aplicar o llevar a cabo, pero ahí se dejan para que, poco a poco y según se estime, se intenten adoptar y ayuden a facilitar un proceso tan complejo como el que nos ocupa.
Para proponer algunas alternativas que nos puedan ayudar a minimizar las mencionadas zonas de sombra, seguiremos el orden de “sombras” establecido en el segundo post de la serie:
Zona de sombra | Propuestas/alternativas |
Servicio externalizado | + Incrementar y mejorar las medidas de control, estableciendo métricas de calidad, de plazos, SLA’s, penalizaciones o lo que se estime necesario para que el hecho de que esté externalizado el proceso de desarrollo no suponga un menor control de qué, cómo y cuándo lo vamos a recibir + Medir adecuadamente esos indicadores y, en caso necesario, aplicar las penalizaciones establecidas y adecuadas + Implantar entornos de aseguramiento de la calidad del software o de inspección/integración continua del software + Disponer de estándares de desarrollo y manuales de buenas prácticas completos, claros y actualizados que sean de obligado cumplimiento por parte de los proveedores |
Multitud niveles interlocución | + Fomentar el trabajo en equipo real y efectivo + Uso de herramientas y procedimientos de documentación claros y sencillos (estilo wiki, por ejemplo) + Reducir la incertidumbre en los niveles de interlocución |
Tríada “proveedor-funcional-técnico” | + Alinear visiones entre los aspectos funcionales y tecnológicos, evitando que ninguna de las partes tenga un peso excesivo en el proyecto + Potenciar el liderazgo y definir jerarquías y funciones claras |
Aspectos legislativos (leyes aplicables) | + Utilizar la imaginación y ser innovadores en la aplicación de las leyes que regulan la contratación pública + Buscar fórmulas contempladas en las leyes y de poca utilización (convenios, cesiones, etc.) |
Metodologías utilizadas | + Fomentar el uso de “técnicas y metodologías ágiles” en el ciclo de vida de los proyectos + Intentar eludir el clásico modelo de desarrollo de software basado en “cascada” o secuenciales |
No reutilización de soluciones previas | + Tener una actitud más abierta y “humilde” para ver lo que ya han hecho otros e intentar su reutilización en nuestro entorno o contexto + Concienciarnos y tener muy en cuenta la eficiencia en el gasto público para no volver a hacer algo que ya está resuelto en otro sitio. No nos debe importar reutilizar cosas hechas por otros, el liderazgo no viene por esa vía, desde luego + Evitar y concienciar a los responsables políticos de los proyectos que solamente tengan un fin mediático u oportunista, priorizando o abordando aquellos que realmente vengan a solucionar un tipo de problemas real, una necesidad identificada |
Plazos de pago | + Establecer planes de facturación con plazos cortos, por hitos pequeños o por periodos temporales breves, de forma que se vayan emitiendo facturas desde el principio y no esperar hasta el final + Buscar y aplicar fórmulas de financiación ágiles como el confirming o factoring que, a pesar de tener un coste financiero, te garantiza el pronto cobro de las facturas |
Peso del importe económico en la oferta | + Intentar redactar bien los baremos en los pliegos de condiciones y potenciar al máximo los aspectos de calidad, plazos de entrega, etc. + Hacer buenos pliegos de condiciones, claros, concisos y completos, para que no quepa duda de qué y cómo se quiere comprar + Medir los aspectos económicos con fórmulas que no le concedan tanto peso en el cómputo final del baremo |
Cambios políticos | + Intentar blindar, lo máximo posible, los desarrollos software y procurar mantenerlos lo más alejados posible de las influencias políticas + Evitar los oportunismos y concienciar al estamento político de que los proyectos de desarrollo de software son estratégicos, de muy largo recorrido, de un coste significativo y en ellos se ha de buscar la eficiencia y eficacia real en vez de la “foto” y la publicidad (para eso ya están otros tipos de proyectos) + En este caso... poco más, es lo menos controlable por nosotros. O no… |
Como ya he comentado en repetidas ocasiones en esta serie de artículos, todas estas propuestas son una humilde reflexión respecto a la situación del desarrollo de software en el sector público basada en mi propia experiencia. Se trata, pues, de una lista subjetiva, sesgada e incompleta, así como el conjunto de propuestas y medidas que aparecen en la tabla.
Sería muy interesante que ambas listas se completasen con vuestras experiencias y opiniones, así como que se pudiera hacer una crítica (constructiiiiva ;) de lo que aquí se propone… Os animo a que así sea.