Ir al contenido
σestadistica.ar
M16 · CómputoIntermedioConcepto

Flujo de trabajo reproducible

Que cualquiera —incluido vos dentro de un año— pueda rehacer el análisis y llegar al mismo resultado: qué hace falta y qué hay que dejar de hacer.

1 · Definición

Un análisis es reproducible cuando otra persona, con los mismos datos y la documentación del trabajo, obtiene exactamente los mismos resultados.

2 · Por qué importa

Porque el “otro” sos vos. Dentro de seis meses, cuando el jurado pida rehacer un análisis con un caso más, nadie se va a acordar de qué se hizo. La reproducibilidad no es un gesto hacia la comunidad científica: es una forma de no perder el trabajo propio.

Porque los datos cambian. El INDEC corrige una serie, aparecen tres cuestionarios más, se detecta un error de carga. Si el análisis es un script, se vuelve a correr; si es una cadena de clics, se rehace a mano.

Porque es lo que permite revisar. Un resultado que no se puede verificar no se puede defender.

3 · Los cuatro requisitos

1 · La base cruda no se modifica. Es el principio del que se desprende todo lo demás. Los datos originales son de solo lectura; todas las transformaciones viven en código.

2 · Todo paso está en un script. Importar, limpiar, recodificar, analizar, graficar. Si un paso se hizo a mano, se rompió la cadena.

3 · Las rutas son relativas. read.csv("datos/base.csv") funciona en cualquier computadora; read.csv("C:/Users/jorge/...") solo en la tuya.

4 · El entorno está declarado. Qué versión del programa, qué paquetes. Es lo que más se omite y lo que explica que un script deje de funcionar dos años después.

4 · Los tres niveles

NivelQué significaCómo se logra
RepetibleVos podés rehacerloScripts en vez de clics
ReproducibleOtro llega al mismo resultado con tus datos+ datos, documentación y rutas relativas
ReplicableOtro llega a la misma conclusión con datos nuevos+ método documentado con todo detalle

El primero es el mínimo exigible en cualquier trabajo. El segundo es el estándar de una tesis seria. El tercero depende del fenómeno, no solo del método.

5 · Los enemigos

  • Copiar y pegar entre programas. Cada copia es un paso que no queda registrado.
  • Editar la planilla a mano. El cambio existe y nadie sabe cuál fue.
  • Nombres como analisis_final_v3_ESTE_SI.xlsx. Señal inequívoca de que no hay control de versiones.
  • Rutas absolutas.
  • Resultados que se guardan pero no se regeneran. Si un gráfico se hizo una vez y se pegó, nadie puede saber si corresponde a la versión actual de los datos.
  • Notebooks ejecutados fuera de orden. Un Jupyter donde las celdas se corrieron salteadas puede mostrar resultados que no se reproducen al correrlo de arriba abajo.

6 · El mínimo viable

Para una tesis no hace falta control de versiones ni contenedores. Alcanza con esto:

tesis/
├── datos/
│   ├── crudos/          ← no se toca nunca
│   └── procesados/      ← se regenera
├── scripts/
│   ├── 01-importar.R
│   ├── 02-limpiar.R
│   ├── 03-descriptivos.R
│   └── 04-graficos.R
├── salidas/             ← se regenera
└── README.txt           ← qué es cada cosa, en qué orden se corre

Y una regla: borrar datos/procesados/ y salidas/, correr los scripts en orden, y verificar que todo se reconstruya. Si funciona, el trabajo es reproducible. Si no, ahí está la parte que falta.

7 · Errores frecuentes

  • Confundir reproducible con prolijo. Un trabajo puede estar impecable y no ser reproducible.
  • Dejar la documentación para el final. Se escribe mientras se hace, o no se escribe.
  • No declarar las versiones de los paquetes. Es la causa número uno de que un script deje de funcionar.
  • Guardar resultados intermedios como si fueran datos. Todo lo que se puede regenerar se regenera.
  • Creer que hace falta saber mucho. Cuatro scripts numerados y un README ya ponen el trabajo por encima de la mayoría.

8 · En el software

# R — declarar el entorno al final del script
sessionInfo()

# O, mejor, congelar las versiones del proyecto
renv::init()      # una vez
renv::snapshot()  # cada vez que se agrega un paquete
# Python
pip freeze > requirements.txt

Herramientas de este tema

  • ScriptProyecto reproducible (R y Python)· en preparación
Cómo citar esta entrada

APA (7.ª edición)

Montivero, J. L. (2026). Flujo de trabajo reproducible. estadistica.ar. https://estadistica.ar/conceptos/flujo-de-trabajo-reproducible

BibTeX

@misc{estadistica_ar_flujo_de_trabajo_reproducible,
  author       = {Montivero, Jorge Luis},
  title        = {{Flujo de trabajo reproducible}},
  year         = {2026},
  howpublished = {\url{https://estadistica.ar/conceptos/flujo-de-trabajo-reproducible}},
  note         = {estadistica.ar. Consultado el \today},
  urldate      = {2026-09-18}
}

Última actualización: 18 de septiembre de 2026. El contenido está bajo licencia CC BY-NC-SA 4.0: se puede reutilizar citando la fuente y sin fines comerciales.