Introducción

En la entrega 4 constatamos que los activos sin código se convierten en legados negativos para el futuro. Aquí conviene replantear la pregunta: ¿sirve el desarrollo ciudadano para construir sistemas de producción?

La respuesta es no. Su esencia es convertir la definición de requisitos desde la perspectiva de la persona usuaria en un “borrador que funciona”.

Si se confunde esta idea y se cree que “desarrollo ciudadano = herramienta mágica con la que cualquiera arma un sistema”, la historia volverá a repetirse y produciremos más legados negativos. Veamos qué significa este “desarrollo en borrador” y cómo aprovecharlo.

Serie completa

¿Cuál es el valor del desarrollo en borrador?

Las aplicaciones o herramientas que construye el equipo en el terreno suelen tildarse de “incompletas” o “toscas”. Pero esa “tosquedad” es precisamente lo valioso.

Los requisitos desde la mirada del usuario se hacen visibles

Imaginemos una app de gestión de clientes creada por el área comercial con una plataforma low-code. Refleja la intuición cotidiana de quienes sienten “si no es así, es incómodo”.

  • Grado de detalle de los campos de entrada
  • Qué quieren ver en las listas
  • Ubicación de botones y fluidez en la navegación

Nada de esto se transmite en una “especificación” escrita. Aunque se describan requisitos, el matiz del trabajo diario se diluye. Un prototipo que funciona permite reacciones reales: “así sí lo usaría”, “en realidad es incómodo”.

Se detectan antes los malentendidos y las carencias

Cuando existe un borrador en funcionamiento resulta más fácil descubrir pronto que “falta un buscador aquí” o que “el flujo de aprobación debería tener dos etapas y no tres”.

Tradicionalmente la ingeniería dependía de especialistas que leían el documento de requisitos e imaginaban el diseño. El resultado era que, una vez entregado, la gente del frente decía “no era lo que esperábamos”, generando retrabajo. El desarrollo ciudadano puede reducir drásticamente esa espiral improductiva.

La trampa de llevar el borrador a producción

Aun así, no hay que convertir el borrador en sistema de producción. Ahí se esconde un gran peligro.

  • Escalabilidad: funciona en un departamento pequeño, pero al desplegarlo en toda la empresa el rendimiento toca techo enseguida.
  • Seguridad: el control de accesos o la gestión de logs son débiles y no cumplen auditorías ni normativas.
  • Mantenibilidad: la personalización avanza y, si la persona autora se mueve o se va, todo se vuelve una caja negra.

“Que el borrador tenga valor” no significa “llevarlo tal cual a producción”. Ese camino reproduce la historia de Kami Excel: salvador momentáneo que acaba como legado negativo.

Reparto de roles con las personas especialistas

¿Cómo tratar entonces los resultados del desarrollo ciudadano? La respuesta es clara.

  • Ciudadanía = crea el borrador: concreta la perspectiva del usuario y presenta un prototipo.
  • Especialistas = escriben la versión final: reconstruyen para cumplir requisitos no funcionales (escalabilidad, seguridad, mantenibilidad).

Al separar así las funciones, cada grupo maximiza su fortaleza. La ciudadanía lleva la sensación real del trabajo al prototipo. Las personas especialistas garantizan la calidad y la sostenibilidad de la versión final.

Antes la práctica habitual era “diseñar imaginando solo con el documento de requisitos”. Con un borrador disponible, la conversación arranca ya con un nivel de detalle alto. Eso hace más eficiente el desarrollo y mejora la calidad del resultado.

Qué debe proteger la gobernanza

Para usar el desarrollo ciudadano de forma sana, la organización necesita reglas.

  • Claridad: definir que “los resultados del desarrollo ciudadano se quedan como prototipos” y limitar su alcance.
  • Inventario: revisar y depurar periódicamente apps o RPA abandonados.
  • Proceso de traspaso: estipular que todo borrador útil se entregue al departamento de TI, que hará la versión final antes de llevarlo a producción.

Con esta gobernanza disminuye el riesgo de reproducir legados negativos al estilo Kami Excel. Sin esas reglas, el desarrollo ciudadano se convierte en una fábrica de “apps callejeras” y solo agranda la deuda técnica.

Conclusiones

El desarrollo ciudadano no es “una vía con la que cualquiera construye sistemas de producción”. Pero usado como “borrador”, reduce errores en la definición de requisitos y permite diseñar sistemas que reflejan la perspectiva de la persona usuaria.

La producción queda en manos de especialistas; la ciudadanía dibuja el borrador.

Cumplir esta división del trabajo transforma el desarrollo ciudadano en un punto de partida para elevar la productividad en lugar de un legado negativo.

La verdadera importancia del desarrollo ciudadano reside en “democratizar el proceso de definición de requisitos”. Solo con esta comprensión se convierte en un poder sostenible para la organización.

Próximo: Cómo las perspectivas desalineadas producen legados negativos en serie 6/7