Todo lo que voy a comentar viene derivado de mis casi 20 años de profesión en el ámbito de las nuevas tecnologías en el sector público y de mi experiencia actual, al “otro lado de la barra”, como suelo decir… “ahora poniendo copas” en el sector privado durante los últimos 4 años. Por lo tanto, no dudo que la visión pueda ser sesgada y endogámica, pero quizás pueda aportar algo positivo a este tipo de proyectos y con esa intención lo escribo…
Me gustaría comenzar estableciendo las principales características (objetivas) que conlleva el desarrollo de software para el sector público:
- Se suele tratar de una tarea que está prácticamente externalizada al 100%, en un proceso incremental durante los últimos años.
- En el cliente (sector público), suelen quedar las tareas de dirección técnica del proyecto, que la suele desempeñar alguien del departamento TIC y las de dirección funcional del proyecto, que suele recaer en alguien de la unidad administrativa que será la principal usuaria del mismo.
- Por lo tanto, los proveedores (compañías de desarrollo de software) suelen tener una doble interlocución. Por una parte con la dirección técnica, del departamento TIC, y por otra con la dirección funcional, de la unidad administrativa usuaria.
- Los proyectos se contratan por medio de un procedimiento administrativo común que ha de cumplir fielmente la rígida Ley de contratos del Estado
- La Administración Pública, fiel a su base procedimental dura, fundamenta la gestión de los proyectos en metodologías muy poco ágiles e inflexibles
- Al tratarse de proyectos largos (y, a veces, costosos), se ven penalizados por la capacidad financiera y de pago de la administración Pública que sabemos, especialmente hoy en día, que es muy limitada y dilatada en el tiempo
- El hecho de que haya “tantas Administraciones Públicas” en nuestro Estado provoca que se repliquen muchas soluciones entre ellas, con sustanciales diferencias
En el segundo post de la serie trataré cada una de estas circunstancias por separado, pero ya se pueden sacar algunas consecuencias de las premisas expuestas.
En primer lugar tenemos una gran diferencia y distancia entre los equipos de desarrollo de software (proveedor) y los equipos de trabajo del cliente (Administración Pública), donde el nexo de unión suele ser un comercial del proveedor que, muchas de las veces, tiene un gran desconocimiento (a veces insensibilidad) de entorno y situación concreta, por lo que la mayoría de las ocasiones nos encontramos equipos de trabajo hablando idiomas diferentes.
Después nos encontramos la rigidez de un procedimiento administrativo y de una ley de contratos que, desde luego, no está pensada para este tipo de proyectos. Esto provoca una gran inflexibilidad que impide replanteamientos rápidos y ágiles y la imposibilidad de adaptar el proyecto a nuevas situaciones que seguro surgen en el ciclo de vida del mismo.
Para acabar este primer post de la serie, hacer referencia al enorme sobrecoste financiero que tiene para los proveedores el hecho de que cobren a 10-12 meses desde que se emiten las facturas, siendo que los hitos de facturación suelen ser muy dilatados (por ejemplo cada trimestre), lo que provoca que las empresas que se atreven con estos proyectos han de asumir un tiempo de latencia de unos 12-14 meses entre que pagan una nómina y cobran la correspondiente factura y eso no es transparente para un proyecto.