Licitaciones de proyectos digitales: acompáñame a leer esta triste historia

TL;DR: La mayoría de licitaciones en Costa Rica usan métodos prehistóricos para definir un proyecto, terminando en gasto público innecesario y proyectos deprimentes. Muy deprimentes.

¿Qué es una licitación?

Las licitaciones son concursos que entidades públicas deben hacer para comprar bienes y servicios. La entidad se encarga de seleccionar según precio y calidad el mejor oferente del concurso. Para que los oferentes puedan participar en este concurso, deben saber qué es lo que ocupa la entidad. Esto normalmente se comunica bajo un documento donde se explican los requerimientos del proyecto. Aquí es donde todo empieza a entristecerse.

¿Por qué está mal plantear los requerimientos de un proyecto en una licitación?

Puedo pensar en mil respuestas, pero quiero que se vayan con ideas claras y concretas:

1. Los requerimientos *usualmente* definen con puntos y comas cómo debería funcionar/ser el proyecto.
2. El proceso para llegar a ese documento *casi* nunca involucra a los usuarios y/o partes interesadas. *Casi* siempre es un wishlist creado por un grupo sesgado y pequeño (dentro de la misma organización).
3. Las personas encargadas de escribir este documento normalmente son los funcionarios de Informática o personal administrativo que acota lo que los puestos gerenciales creen que debe tener el proyecto y cómo debe funcionar.
4. Básicamente es poner fé en que lo planteado es la mejor solución. Que no habrán problemas en el futuro. Que todo el conocimiento del proyecto está en ese documento.

Consecuencias de un proyecto con requerimientos al pie de la letra

Los proyectos que definen esos requerimientos sagrados crean una dinámica con muchos problemas. Ya que define los roles de: Entidad pública define solución. Oferente desarrolla la solución.

Quienes diseñamos y creamos proyectos, nos encontramos con cosas que no se definieron nunca en el proyecto, por más análisis. Por más lo que sea. Uno no puede planificarlo todo. Siempre hay situaciones/problemas que surgen. Pero no estaban definidos en los requerimientos.

Este momento es totalmente deprimente. La entidad pública devuelve el proyecto al oferente porque no cumple con ciertos criterios del proyecto. El oferente dice que sí cumplió con esos criterios que fueron definidos, pero la entidad dice que no porque el oferente no entendió los criterios bien. Y así se va un arroz con mango.

Rediseño del sitio web de la Asamblea Legislativa: Puedo decir que participé como ciudadano en dos reuniones para el rediseño del sitio web de la Asamblea Legislativa (actual), donde el documento sagrado no tenía pies ni cabeza para lo que realmente se ocupaba y que luego pedían al oferente. Esto causa estrés para ambas partes: Oferente quiere hacer un buen trabajo y cumplir los requisitos del proyecto. Entidad quiere quedar bien y mover hacia delante el proyecto.

Y entonces, ¿cómo debería ser?

Las reglas del juego están mal. Por un lado tenemos a la entidad pública que diseña soluciones imaginarias y por otro lado tenemos oferentes que sólo saben ejecutar y no diseñar soluciones. Se ocupan cambios en los dos lados para cambiar el juego.

Entidad Pública:

La entidad debe entender que no se debería planificar una solución con puntos y comas. Sino que se debería plantear el marco del problema a los oferentes. Esto para que entiendan lo que significaría trabajar en el proyecto y que habrán cosas que se definirán en el camino.

Por ejemplo, una vez trabajé como consultor con el Ministerio de Cultura, para definir una licitación, es decir: hicimos talleres e investigación para estructurar y conocer a nivel interno los problemas de comunicación que tenían y cómo luego esto se podría traducir en una licitación que tuviera sentido.

Oferente:

Entender que los proyectos digitales y más los proyectos que involucren a la ciudadanía, no se deberían plantear de forma tan estricta y sencilla. Sino que debe haber un proceso mucho más flexible en el que se crean hipótesis, se prueban esas hipótesis, se definen escenarios y por último se validan.

¿Cómo lo hacen otros países?

Excelente pregunta. No tenemos que inventar la rueda. En otros países como UK [esta guía es increíble] y USA , documentan cómo las entidades públicas deberían diseñar servicios públicos. EXACTO. Servicios Públicos. No son programas informáticos o software como dicen los medios de comunicación cuando uno de estos proyectos falla, al final son servicios públicos.

Esto nos importa a todos

Si llegó hasta aquí es porque le interesa el tema, porque ha visto cómo cada vez hay más licitaciones absurdas con resultados deprimentes (caso del MEP con sus 420 millones de colones tirados a la basura) y como ciudadanos deberíamos ejercer presión a nuestros representantes.

Si conoce a alguien del sector público o privado que debería leer esto, por favor envíeselo. Su "yo del futuro" se lo agradecerá cuando pueda hacer trámites en línea sin perder el hígado o la cabeza y la eficiencia sea una cualidad del aparato estatal.