Cómo organizar un proyecto de datos

1 · El principio

Todo el proyecto vive en una sola carpeta, autocontenida, que se puede comprimir y mandar por mail sin que nada deje de funcionar.

2 · La estructura

proyecto/
├── README.txt            qué es esto, quién lo hizo, cómo se corre
├── datos/
│   ├── crudos/           originales, solo lectura, nunca se tocan
│   └── procesados/       generados por los scripts
├── scripts/
│   ├── 01-importar.R
│   ├── 02-limpiar.R
│   ├── 03-analisis.R
│   └── 04-graficos.R
├── salidas/
│   ├── tablas/
│   └── figuras/
└── documentos/
    ├── diccionario-variables.xlsx
    ├── cuestionario.pdf
    └── informe.docx

Cuatro reglas detrás de esa estructura:

Separar lo que entra de lo que sale. datos/crudos/ es sagrado; datos/procesados/ y salidas/ se pueden borrar y regenerar.

Numerar los scripts. El número dice el orden de ejecución. Es la documentación más barata que existe.

Una carpeta por tipo de cosa, no por tema. Todos los scripts juntos, todas las figuras juntas.

El README primero. Tres párrafos: qué es el proyecto, de dónde salieron los datos, en qué orden se corre.

3 · Los nombres de archivo

Tres reglas que resuelven el 90 % de los problemas:

Sin espacios ni acentos. analisis-ingresos.R, no Análisis de ingresos.R. Los espacios rompen rutas en scripts y los acentos dan problemas al mover archivos entre sistemas.

Fechas en formato AAAA-MM-DD. 2026-09-18-informe.docx se ordena solo alfabéticamente. 18-09-2026 no.

Nombres que ordenan y describen. 01-importar.R es mejor que importar.R, y mucho mejor que script1.R.

Y una regla negativa: nada de final, definitivo, v2, ESTE_SI. Si aparecen, lo que falta no es un nombre mejor: es control de versiones.

4 · Las rutas

El error que más rompe proyectos ajenos:

# Mal: solo funciona en una computadora
datos <- read.csv("C:/Users/jorge/Documents/tesis/datos/base.csv")

# Bien: funciona en cualquiera, si se abre el proyecto
datos <- read.csv("datos/crudos/base.csv")

En RStudio eso se resuelve creando un proyecto (.Rproj): la carpeta del proyecto pasa a ser el directorio de trabajo y todas las rutas relativas funcionan. En Python, el equivalente es correr los scripts desde la raíz del proyecto.

5 · Copias de seguridad

Tres versiones en dos lugares distintos, y una de ellas fuera de la computadora. Un disco que se rompe a dos semanas de la entrega es una historia que pasa.

La nube sincronizada —Drive, OneDrive— alcanza para una tesis, con una salvedad: sincronizar no es respaldar. Si borrás un archivo por error, se borra en los dos lados. Conviene tener además una copia periódica que no se sincronice.

6 · Errores frecuentes

• Todo en el Escritorio. El proyecto tiene que ser una carpeta que se pueda mover entera.
• Rutas absolutas. El proyecto no funciona en ninguna otra computadora.
• Mezclar datos crudos con procesados. Tarde o temprano se pisa el original.
• Archivos con final en el nombre. Nunca es el final.
• No tener README. Dentro de un año, ni vos sabés qué era cada archivo.
• Guardar el informe en la misma carpeta que los scripts. Documentos aparte.
• No respaldar. El riesgo es bajo y la pérdida, total.

@misc{estadistica_ar_organizacion_de_un_proyecto_de_datos,
  author       = {Montivero, Jorge Luis},
  title        = {{Cómo organizar un proyecto de datos}},
  year         = {2026},
  howpublished = {\url{https://estadistica.ar/conceptos/organizacion-de-un-proyecto-de-datos}},
  note         = {estadistica.ar. Consultado el \today},
  urldate      = {2026-09-18}
}