Del prototipo al traspaso: software de investigación mantenible

El postdoc que construyó la herramienta de análisis se graduó el verano pasado. La app Streamlit en la que el consorcio confiaba para monitorizar el reclutamiento multi-sitio se cayó en noviembre cuando expiró la capa gratuita del cloud. La pipeline que otro equipo usa para puntuar evaluaciones de CV funciona en el portátil del postdoc y en ningún otro sitio, porque las dependencias nunca se anotaron. El financiador preguntará, en la próxima revisión, qué pasó con las herramientas que el proyecto comprometió.

Este es el modo de fallo más común en el software académico de investigación: el prototipo funciona, el desarrollador se va, el software muere. La solución no es más disciplina aplicada después. Es un pequeño conjunto de prácticas de ingeniería aplicadas en la fase de prototipo — prácticas que cuestan casi nada al añadirlas pronto y le cuestan todo al proyecto cuando se añaden tarde o nunca.

Este artículo es una guía práctica para hacer que el software de investigación sea mantenible: qué lo mata, qué lo salva, y el paquete mínimo de traspaso que mantiene una herramienta viva más allá de su desarrollador original.

Por qué muere el software de investigación

Tras trabajar con equipos de investigación en salud, neurociencia, políticas públicas y ciencias sociales, los mismos cuatro patrones matan casi cualquier pieza de software de investigación.

1. Nunca se capturó la foto de dependencias

La herramienta corre en el portátil del desarrollador con una versión específica de Python, un estado específico de virtualenv, un set específico de paquetes R. Seis meses después, en el portátil de otra persona, la mitad de las dependencias ha cambiado. La herramienta deja de importar o empieza a producir números distintos. Sin un manifiesto de dependencias congelado (requirements.txt, Pipfile.lock, renv.lock, pyproject.toml), la herramienta está implícitamente atada a una sola máquina.

2. El README era un placeholder

El repositorio tenía README. El README decía "Herramienta de análisis de investigación" y listaba los tres scripts. No decía cómo instalar dependencias, cómo ejecutar la herramienta, qué entradas acepta o qué salidas produce. Quien lo escribió sabía las respuestas; nadie más. La documentación no es una tarea separada — es el artefacto que hace legible la herramienta.

3. El despliegue era de capa gratuita desechable

La app Shiny en la capa gratuita de shinyapps.io. La app Streamlit en la capa gratuita de Streamlit Cloud. El sitio estático en Netlify gratis. Las capas gratuitas son buenas para prototipar; no son infraestructura duradera para software entregable a financiador. Cuando cambia la facturación, se alcanzan los límites de uso o la plataforma pivota, las herramientas en capas gratuitas desaparecen sin avisar.

4. El plan de mantenimiento era implícito

El plan, tal como era, era "el postdoc le echará un ojo". Cuando el postdoc se va, el plan termina. No hay nadie nombrado por escrito como responsable durante los próximos 24 meses. La institución no sabe que la herramienta existe al nivel necesario para asignarla. Las herramientas de flujo de trabajo de investigación sin un traspaso de mantenimiento por escrito son software esperando morir.

Cada uno es pequeño en el momento y devastador en conjunto. Ninguno requiere ingeniería sofisticada para arreglarse.

Qué salva al software de investigación

Cinco prácticas, aplicadas durante la fase de prototipo, cambian la tasa de supervivencia drásticamente.

Práctica 1: Fija dependencias al principio, no al final

El primer commit del prototipo debería incluir un manifiesto de dependencias congelado. pip freeze > requirements.txt para Python; renv::snapshot() para R; lockfiles versionados para cualquier ecosistema que use el proyecto. Cuesta 30 segundos en el día uno y salva el proyecto en el día 365.

Práctica 2: Escribe el README como un test de portátil nuevo

El README debe responder a cuatro preguntas en orden:

1. ¿Qué es esto? — un párrafo
2. ¿Cómo lo instalo? — comandos exactos, copiables
3. ¿Cómo lo ejecuto? — comandos exactos, con un ejemplo de entrada
4. ¿Qué produce? — estructura de archivos de salida, un ejemplo

Prueba el README ejecutándolo en otra máquina, o pídeselo a un colega que no haya visto la herramienta. Si no consigue que funcione en 15 minutos, el README está incompleto.

Práctica 3: Elige un stack que la institución pueda mantener

El stack correcto para software de investigación no es el más de moda. Es el que tu institución puede contratar o que tu equipo institucional de RSE ya soporta.

Para proyectos de investigación en 2026, las opciones duraderas son:

• Python + stack científico estándar (pandas, numpy, scipy, matplotlib) para análisis
• R + tidyverse para trabajo estadístico donde R es la lingua franca
• Node.js / TypeScript + un framework web mainstream (Next.js, FastAPI para backend) para herramientas
• Postgres para cualquier capa de datos persistente
• Despliegues containerizados (Docker) para cualquier cosa que deba correr en servidor

Evita: frameworks de nicho que dependen de un único mantenedor, lenguajes para los que tu institución no puede contratar, plataformas con capas gratuitas frágiles.

Práctica 4: Despliega a infraestructura duradera desde el principio

No prototipes en capas gratuitas. Usa:

• El alojamiento del equipo institucional de research-software-engineering (RSE) si está disponible
• Un servicio gestionado de contenedores con modelo de precios estable (Fly.io, Render, Railway, AWS App Runner) — entre 10 y 20 €/mes para una herramienta de investigación de bajo tráfico
• El cluster Kubernetes de tu institución si lo hay y tu proyecto lo justifica

La diferencia de coste entre gratis y duradero suele ser inferior a 300 €/año. La diferencia de fiabilidad es la diferencia entre "la herramienta sigue viva" y "la herramienta está muerta".

Práctica 5: Escribe el traspaso antes de que el desarrollador se vaya

El documento de traspaso no es "todo lo que sé sobre esta herramienta". Es "lo mínimo que otra persona necesita para mantener la herramienta funcionando". En concreto:

• Un runbook para tareas operativas comunes (desplegar, reiniciar, actualizar dependencias, investigar fallos)
• Un manual de incidencias para modos de fallo conocidos (autenticación rota, factura del cloud, cambios de formato del dataset)
• Una lista de todas las credenciales, cuentas y dependencias de infraestructura, con dónde se guardan
• Un sucesor con nombre — una persona concreta, con visto bueno de su responsable, que asume la responsabilidad durante los próximos 24 meses
• Un plan de retirada si no hay sucesor disponible — cuándo se retira la herramienta y qué la reemplaza

Es incómodo escribirlo porque reconoce que la herramienta sobrevivirá a la implicación del desarrollador original. Ese reconocimiento es la precondición para la supervivencia.

El paquete mínimo viable de traspaso

Cuando una herramienta de investigación pasa de "desarrollador-activo" a "mantenida por el equipo" — típicamente cuando el desarrollador original se gradúa, rota o cambia de institución — los entregables que tu equipo necesita son:

| Ítem | Qué incluye | |---|---| | Repositorio con código actual | Código fuente completo, en un hogar de largo plazo (GitLab institucional, GitHub Enterprise, Zenodo para archivo) | | Manifiesto de dependencias congelado | requirements.txt / lockfile versionado | | README que pasa el test de máquina nueva | Instalar, ejecutar, salida esperada — verificado en otra máquina | | Runbook | Procedimientos operativos: desplegar, actualizar, reiniciar, recuperar | | Manual de incidencias | Modos de fallo conocidos + procedimientos de recuperación | | Traspaso de credenciales | Acceso a cuentas, dónde se guardan, quién puede rotarlas | | Contrato de mantenimiento | Sucesor con nombre, periodo de responsabilidad, ruta de escalado | | Cláusula de retirada | Condiciones bajo las que se decomisiona la herramienta |

Ocho ítems. Ninguno es técnicamente difícil. Todos faltan rutinariamente.

El test de máquina nueva de 30 minutos

El diagnóstico de mayor palanca para cualquier herramienta de investigación: coge a alguien que no la haya construido, dale una máquina nueva, pásale el README y obsérvala intentando hacerla funcionar. Bloquea 30 minutos.

Puntuación:

• La hizo funcionar en 15 minutos: nota A — la herramienta está bien
• La hizo funcionar con uno o dos bloqueos menores: nota B — arréglalos, ya casi
• La hizo funcionar en 30 minutos tras varios bloqueos: nota C — el README necesita trabajo
• No la hizo funcionar: nota F — la herramienta no sobrevivirá al desarrollador original

La mayoría de herramientas de investigación son C o F cuando se prueban con honestidad. La mayoría de equipos nunca ha hecho el test, por eso les sorprende cuando la herramienta muere.

Cuándo incorporar ayuda externa

Un proyecto de traspaso de software de investigación es el movimiento correcto cuando:

• El desarrollador original se va en menos de 3 meses y no hay sucesor en su sitio
• La herramienta es operativamente importante (usuarios activos, flujo de datos en marcha) pero no está documentada
• El financiador espera que la herramienta siga accesible durante un periodo declarado tras el final del proyecto
• El equipo no tiene plantilla para absorber el mantenimiento y necesita un traspaso estructurado al equipo interno o al grupo institucional de RSE

El proyecto MVP de herramienta de investigación de Pragma cubre la fase de construcción; también hacemos proyectos de toma de relevo donde el objetivo es endurecer un prototipo existente hasta hacerlo mantenible. La salida es el paquete de traspaso de 8 ítems anterior más el trabajo de ingeniería necesario para que cada ítem sea real (fijado de dependencias, migración de despliegue, reescritura del README, redacción del runbook).

Si tienes un prototipo que funciona pero no es mantenible, ese es el proyecto.

Tres cosas para hacer esta semana

1. Elige una herramienta prototipo de tu proyecto. Ejecuta el test de máquina nueva de 30 minutos. Sé honesto con la nota.
2. Sea cual sea la nota, identifica la solución de menor coste que la mueva una letra arriba. A menudo son 2 párrafos de README.
3. Si la nota es C o F y la herramienta es operativamente importante, solicita una revisión de proyecto. Definiremos el paquete mínimo de traspaso y lo que cuesta entregarlo.

El software de investigación no tiene que morir. La mayoría de las prácticas de ingeniería que previenen su muerte no son sofisticadas. La disciplina es hacerlas al principio, cuando cuestan casi nada — en lugar de al final, cuando le cuestan todo al proyecto.