Ingeniería de software de investigación como servicio

Tu proyecto prometió una herramienta. Un dashboard que el financiador espera. Un pipeline que convierte los datos de la cohorte en algo que un revisor pueda leer. El plan de trabajo lo incluye como una partida, con su presupuesto. Lo que no tiene es una persona cuyo cometido sea construirlo. El investigador principal dirige la ciencia. Los dos doctorandos destacan en investigación, no en ingeniería. El postdoc tiene una tesis que terminar. La institución cuenta con un grupo de ingeniería de software de investigación, pero está saturado hasta la próxima primavera.

Esta es la brecha del ingeniero de software de investigación, y es uno de los motivos más frecuentes por los que un proyecto financiado llega a su fecha límite con un entregable digital a medio construir. Este artículo explica qué hace en realidad un ingeniero de software de investigación (RSE), las cuatro formas en que los equipos intentan cubrir la brecha, y cuándo recurrir a un RSE externo como servicio es la opción acertada, en lugar de contratar, esperar en cola o confiar en la suerte.

Qué hace en realidad un ingeniero de software de investigación

Un ingeniero de software de investigación se sitúa entre dos mundos. Entiende lo suficiente de la ciencia como para construir lo correcto, y lo suficiente de ingeniería de software como para construirlo de forma que perdure. El rol surgió de una observación simple, formalizada por grupos como el Software Sustainability Institute: la investigación depende cada vez más del software, y quienes escriben ese software suelen ser científicos que aprendieron a programar por su cuenta, no ingenieros que aprendieron el dominio.

En la práctica, un RSE hace un trabajo que el equipo de investigación no puede, o no debería, hacer por sí mismo:

• convierte un prototipo en una herramienta mantenible y documentada que funciona en más de un portátil
• construye el pipeline de datos, el dashboard, la API o el despliegue del modelo que comprometió el plan de trabajo
• configura el control de versiones, las pruebas y la documentación que mantienen el software utilizable después de que se marche quien lo construyó
• traduce entre lo que el financiador espera como entregable digital y lo que el equipo puede entregar de forma realista

El valor no está solo en el código. Está en que el código se construye con un estándar que un revisor puede verificar y que un equipo futuro puede continuar.

Las cuatro formas en que los equipos intentan cubrir la brecha del RSE

La mayoría de los proyectos prueba una de cuatro vías. Cada una funciona en algunas situaciones y falla en otras.

1. El grupo de RSE institucional

Muchas universidades cuentan ya con un equipo central de RSE. Cuando el tuyo tiene capacidad y tu calendario es flexible, suele ser la mejor opción: los ingenieros son excelentes, conocen los sistemas de la institución y el coste es interno. El problema: estos equipos suelen tener más demanda de la que pueden atender. Un proyecto con una fecha de cierre fija dentro de cuatro meses no siempre puede esperar en una cola que se mide en trimestres. La restricción es la capacidad, no la calidad.

2. El doctorando

La opción por defecto. El estudiante que construyó el prototipo sigue adelante y entrega también la versión de producción. Barato, disponible y con conocimiento del dominio. El problema: el estudiante destaca en investigación, la ingeniería le supone un sobreesfuerzo además de la tesis, y cuando se gradúa el conocimiento institucional de la herramienta se marcha con él. El resultado es software que funciona en una demo y se rompe la primera vez que otra persona intenta ejecutarlo.

3. La empresa de desarrollo genérica

Contratas una agencia de software. Tienen ingenieros y disponibilidad. El problema: no leen el Anexo I, no saben qué significa FAIR y no entienden qué busca un evaluador en un entregable digital. Construyen un producto competente que resuelve el problema equivocado, en un stack que el equipo no puede mantener, con un calendario que ignora la fecha de cierre. Decidir si conviene construir algo, y qué significa aquí mínimo viable, no es algo para lo que estén preparados.

4. La contratación permanente

Abres una plaza para un ingeniero de software de investigación. La respuesta correcta cuando la necesidad es continua. El problema: contratar es lento, con meses de selección, incorporación y fricciones con la escala salarial, y un único entregable finito rara vez justifica una partida salarial recurrente. Para un proyecto que necesita hacer el trabajo bien una sola vez, una contratación es desproporcionada.

Qué significa "ingeniería de software de investigación como servicio"

Hay una quinta vía que se sitúa entre la cola institucional y la contratación permanente: un RSE externo contratado para un trabajo finito y acotado. La ingeniería la hace un socio que lee con naturalidad los planes de trabajo de los proyectos; el equipo es dueño del resultado y lo opera después de que el socio se retire.

En concreto:

• un encargo acotado (normalmente de 4 a 10 semanas) que lleva un entregable de "prometido en el Anexo" a "construido, documentado y traspasado"
• código entregado en los repositorios del propio equipo, en stacks para los que el equipo puede contratar y mantener
• documentación, un runbook y una prueba en un portátil limpio, para que la herramienta sobreviva al encargo
• una salida, no una iguala: el equipo opera la herramienta por sí mismo después

El modelo encaja con la forma del trabajo financiado por proyectos: entregables finitos, plazos fijos, ningún interés por un coste recurrente de proveedor.

Cuándo la opción externa es la adecuada, y cuándo no

Es la opción acertada cuando:

• el entregable está bien definido y la fecha límite es fija
• tu equipo de RSE institucional no puede asumir el proyecto a tiempo
• el trabajo tiene que perdurar más allá de un estudiante que se gradúa
• el proyecto no necesita ingeniería continua, solo esta parte bien hecha

Es la opción equivocada cuando:

• la necesidad es realmente continua (entonces contrata, o desarrolla capacidad interna de RSE)
• el alcance no está definido (delimítalo primero; un buen socio te dirá con honestidad cuándo una hoja de cálculo o una herramienta lista para usar es realmente suficiente)
• el equipo de RSE institucional tiene capacidad y tu calendario puede absorber la cola (recurre a ellos)

Un socio honesto a veces te dirá que la opción externa no es la que necesitas. Ese es el socio en quien confiar.

Qué buscar en un socio RSE externo

Cinco cosas separan a un socio con fluidez en investigación de una empresa genérica:

1. piden ver el Anexo, el plan de trabajo y la definición del entregable, no solo una lista de funciones
2. hablan en términos de evaluadores, FAIR, cierre y traspaso, no solo de "la app"
3. se comprometen a un stack para el que puedes contratar y que puedes mantener, y a entregar el código
4. acotan con honestidad la versión mínima viable, y dicen que no a las partes que no necesitas
5. planifican su propia salida desde el primer día

Dónde encaja Pragma

Pragma es un pequeño estudio con fluidez en investigación que construye los entregables digitales que los proyectos financiados prometieron. Trabajamos como ingeniero de software de investigación externo para equipos cuyo grupo de RSE institucional está completo, cuyo prototipo necesita convertirse en una herramienta mantenible, o cuyo cierre llega antes de que estén listos para entregar. El encargo es finito, el código va a tus repositorios y salimos sin iguala. Leemos el plan de trabajo, acotamos el entregable mínimo viable y entregamos en semanas, no en trimestres.

Si tu proyecto prometió una herramienta y tu equipo no tiene al ingeniero para construirla, ese es el encargo para el que existimos.

Tres cosas que hacer esta semana

1. Comprueba la disponibilidad real de tu equipo de RSE institucional frente a tu fecha límite. Si la cola es más larga que tu margen de tiempo, ya tienes la respuesta.
2. Escribe el entregable en un párrafo: qué es, quién lo usa, qué comprobará el evaluador. Si no puedes, la primera tarea es acotar, no construir.
3. Si la brecha entre lo prometido y lo que tu equipo puede entregar es más ancha de lo que el tiempo permite, solicita una revisión de alcance. Cuanto antes empiece la conversación, menos comprimido será el desarrollo.

La brecha del ingeniero de software de investigación no es un fallo de planificación. Es estructural: los presupuestos de investigación financian la ciencia, y la ingeniería queda en segundo plano hasta que de pronto se vuelve urgente. La solución es reconocer la brecha pronto y elegir la vía (interna, contratada o externa) que encaje con la fecha límite que de verdad tienes.