Esta publicación está escrita por Benjamin Seibel, director de CityLAB Berlin, y Yi Jun Huang, asistente ejecutivo de CityLAB Berlin.


  • El problema: la contratación pública a menudo no ofrece soluciones de TI viables para las administraciones.

  • Por qué es importante: en la mayoría de los casos, el desarrollo de productos administrativos digitales no les permite abordar los requisitos específicos de las autoridades individuales.

  • La solución: las autoridades públicas deben adaptarse a los procesos ágiles y hacerse cargo del desarrollo de software.

"La mayoría de los productos administrativos digitales están hechos a medida con respecto a los requisitos específicos de las autoridades individuales, ya sea adaptando ampliamente una solución de mercado existente o encargando un nuevo desarrollo".

Simple, rápido y seguro: esto es lo que la mayoría de los proveedores de TI prometen al ofrecer sus soluciones de TI del sector público a las administraciones. Sin embargo, la realidad de los proyectos de TI en la administración pública suele ser muy diferente: demasiado caro, demasiado largo, demasiado complicado. Aunque las administraciones a menudo invierten miles de millones al año en la compra y el desarrollo de infraestructura y software de TI, los resultados suelen ser pobres y tienen mala reputación. Pero ¿por qué es así?

Demos un paso atrás y observemos el proceso de adquisición. Las administraciones generalmente consideran el software como un producto que se puede adquirir en el mercado. En consecuencia, las autoridades públicas proceden de manera similar a como lo hacen cuando adquieren productos convencionales: el servicio deseado se describe de la manera más completa posible en una licitación pública, el licitador más económico se adjudica el contrato y entrega un resultado un tiempo después. La propia administración se limita a la adjudicación y gestión de contratos pero se mantiene al margen del desarrollo de productos en la medida de lo posible.

Puede haber situaciones en las que este enfoque tenga sentido, por ejemplo, cuando se adquieren programas de oficina disponibles comercialmente o se utilizan ofertas de software como servicio (SaaS), pero seamos realistas: en la mayoría de los casos, no existe una solución perfecta para todos los usos. casos esperando en un estante. En otras palabras, los productos administrativos digitales en su mayoría están hechos a medida con respecto a los requisitos específicos de las autoridades individuales, ya sea adaptando ampliamente una solución de mercado existente o encargando un nuevo desarrollo.

Por qué la agilidad es clave

Esto nos lleva a la pregunta de por qué las administraciones deben familiarizarse con los principios del desarrollo ágil de software que durante mucho tiempo han sido comunes en otros lugares, asumir más responsabilidad por sus productos digitales y desempeñar un papel mucho más activo en todo el proceso de desarrollo.

En primer lugar, es un principio del desarrollo ágil de software que los productos digitales no pueden describirse de manera integral por adelantado y luego solo necesitan desarrollarse. En cambio, el software se crea en ciclos iterativos estrechamente cronometrados en los que un prototipo inicialmente rudimentario se prueba, adapta y refina paso a paso y en estrecha consulta con los clientes y usuarios.

El principio de la contratación pública de productos deja poco espacio para un enfoque tan exploratorio de la mejor solución. Ocurre regularmente que las autoridades públicas describen meticulosamente un producto deseado por adelantado (e invierten una gran cantidad de tiempo y esfuerzo en hacerlo), pero que el camino previsto en el desarrollo resulta impracticable después de poco tiempo. El hecho de que surjan circunstancias imprevistas durante el proceso extremadamente dinámico del desarrollo de productos digitales difícilmente puede evitarse. La única pregunta es cómo lidiar con ellos.

En segundo lugar, es una práctica común en el desarrollo ágil de software incluir la perspectiva del cliente no solo al principio y al final, sino durante todo el proceso. En los equipos ágiles, esta perspectiva está representada por el rol del "propietario del producto" que describe los requisitos funcionales del producto desde la perspectiva del usuario, prueba los resultados intermedios y prioriza los objetivos respectivos para el próximo sprint de desarrollo.

“En los procesos ágiles, el fracaso de un enfoque previamente elegido se puede anticipar mucho antes, por lo que todavía hay tiempo para cambiar de rumbo”.

Conocimiento y experiencia

Dado que el propietario del producto es una parte integral del equipo del proyecto y en gran parte responsable del éxito del proyecto, es crucial que este puesto sea ocupado por una persona empleada en la administración correspondiente. Si bien el conocimiento y los métodos necesarios para esta función se pueden aprender en el camino, el propietario del producto idealmente debe tener experiencia en el desarrollo de productos digitales o al menos tener cierta pasión por las aplicaciones digitales. La buena noticia es que los conocimientos técnicos profundos no son absolutamente necesarios para el puesto, ya que el punto es ver el producto a través de los ojos del usuario. Lo que es más importante es la voluntad y la capacidad fundamentales para participar en un trabajo de proyecto ágil, que requiere mucho tiempo pero es muy rentable.

En tercer lugar, si la administración asume un papel activo y formador en el desarrollo de aplicaciones digitales, la perspectiva también cambia con la posición: en lugar de ver el software como un producto que debe adquirirse en el mercado, ahora aparece como el resultado de un desarrollo. proceso que implementan las administraciones y son responsables de ellas mismas, y en el que, por supuesto, aún pueden recurrir a soporte externo (por ejemplo, servicios de programación, UX o diseño).

Al invertir en capacidades de desarrollo en lugar de en un producto terminado, los empleados de la administración no tienen que especificar de antemano todos los detalles imaginables de la aplicación deseada, sino entrar en un proceso de desarrollo con un equipo de programadores para encontrar la mejor solución posible a un problema. dentro de un plazo y presupuesto determinados.

Riesgos y recompensas

Uno podría preguntarse si es arriesgado no definir claramente todas las funcionalidades del producto por adelantado, pero en realidad es una forma de reducir el riesgo. En los procesos ágiles, el fracaso de un enfoque previamente elegido se puede anticipar mucho antes, por lo que todavía hay tiempo para cambiar de rumbo. Incluso un proveedor de servicios, una vez elegido, teóricamente puede ser reemplazado en el proceso si la administración como propietario del producto se encarga de la documentación transparente del proceso e insiste en la apertura de los códigos fuente desarrollados (lo que debería hacerse de todos modos).

En vista de la escasez de recursos, la idea de una administración que persigue activamente el desarrollo de productos digitales puede no parecer muy realista para algunas autoridades. Sin embargo, cuando se trata de digitalización, ya no es dinero lo que ha faltado en muchos lugares durante mucho tiempo, sino las habilidades y capacidades para usar este dinero de manera efectiva. Pero las habilidades se pueden aprender y las capacidades se pueden crear. Debería valer la pena el esfuerzo, ya que sería una inversión en el futuro de una administración digitalmente capaz.

👋 ¡Puedes crear una publicación como esta! Comparta sus pensamientos con una comunidad de servidores públicos. Aprende más

(Crédito de la imagen: Unsplash)


Asegúrate de compartir tus propias ideas con el autor dejando un comentario abajo