De datos en bruto a informes listos para financiador en 2–4 semanas

Es el último mes del proyecto. Los datos existen — en algún sitio. La doctoranda los tiene en su portátil, el postdoc tiene una copia parcial, el centro de campo tiene su propia versión con columnas adicionales que nadie documentó. El financiador espera el informe en la semana 4. Nadie del equipo ha producido un entregable estilo memoria desde datos en bruto en menos de tres meses, y aun así las figuras de aquella vez ahora todos preferiríamos que fueran mejores.

Aquí es donde vive el informe de proyecto de investigación. La mayoría de proyectos de investigación generan datos mucho antes que entregables reportables. Cerrar esa brecha — limpiamente, de forma reproducible, en plazo — es el trabajo que la mayoría de equipos infravalora. También es el más probable de descarrilar el cierre si se deja para la última quincena.

Este artículo es una pipeline práctica de 4 fases para convertir datos en bruto en un informe listo para financiador. Es la misma estructura que usamos en nuestros Sprints de datos a informe para consorcios europeos y colaboraciones académicas.

Qué significa realmente "listo para financiador"

Antes de definir alcance, hay que nombrar qué revisará el evaluador. La frase "listo para financiador" hace mucho trabajo y conviene desempaquetarla.

Una memoria lista para financiador tiene, como mínimo:

• Una versión limpia y canónica de los datos subyacentes, con esquema y procedencia documentados
• Figuras y tablas generadas desde una pipeline reproducible, no capturas de Excel
• Una sección narrativa que responde a las preguntas específicas del plan de trabajo, con lenguaje mesurado sobre hallazgos y limitaciones
• Trazabilidad clara de dato a afirmación — cada porcentaje citado en la narrativa se enlaza a una tabla o figura concreta
• Cumplimiento de la plantilla del financiador — número de páginas, estructura, anexos requeridos

La mayoría de estos requisitos son obvios en principio y se omiten en la práctica. El arrepentimiento de cierre más común es "deberíamos haber resuelto esto en el mes 18".

La pipeline de 4 fases

Cada proyecto de datos a informe sigue las mismas cuatro fases. La duración varía; la estructura no.

Fase 1: Limpieza y estructuración (semana 1)

Objetivo: una única versión canónica del dataset, con esquema documentado, lista para análisis.

Tareas concretas:

• Inventaria cada fuente de datos. Lista los archivos, las ubicaciones y quién los ha estado tocando.
• Reconcilia esquemas entre centros o lotes. Documenta cada discrepancia y la resolución.
• Aplica filtros de calidad explícitamente — las exclusiones se registran como código, no como borrados.
• Produce un dataset versionado y estructurado en formato abierto (CSV, Parquet) con diccionario de datos.
• Define un clean.py (o equivalente) que tome crudo → limpio, ejecutable de extremo a extremo.

Salida de la fase 1: alguien externo al equipo puede re-derivar el dataset limpio desde los datos crudos con una sola comanda. La gestión de datos de investigación sin este paso es frágil.

Fase 2: Análisis (semana 2)

Objetivo: la evidencia analítica que responde a las preguntas del plan de trabajo.

Tareas concretas:

• Traduce cada pregunta de la plantilla del financiador en una afirmación cuantitativa específica.
• Para cada afirmación, escribe el script de análisis que produce la respuesta. Los notebooks valen si están en repositorio y son ejecutables; las celdas ad-hoc en el Jupyter local de alguien no.
• Produce salidas intermedias (definiciones de cohorte, estadísticos por grupo, comparaciones) como artefactos con nombre, no como celdas puntuales.
• Aborda las decisiones metodológicas explícitamente — umbrales de significación, manejo de datos faltantes, correcciones por comparaciones múltiples — y documenta la decisión.
• Ejecuta análisis de sensibilidad sobre las afirmaciones más consecuentes.

Salida de la fase 2: un conjunto estructurado de salidas analíticas que mapean 1-a-1 a las afirmaciones del informe. Re-ejecutar la pipeline contra un dataset actualizado produce números actualizados automáticamente.

Fase 3: Visualización (semana 3)

Objetivo: figuras y tablas listas para publicación y regenerables.

Tareas concretas:

• Para cada figura que aparecerá en el informe, escribe el script que la produce desde la salida del análisis. Usa una librería de visualización que tu equipo pueda mantener (matplotlib, seaborn, ggplot, plotly).
• Aplica un estilo visual consistente entre figuras — paleta de colores, tamaños de fuente, tratamiento de ejes.
• Produce tablas en un formato que la plantilla del informe acepte (LaTeX, Markdown compatible con Word, CSV formateado).
• Para cada visualización, comprueba: ¿un revisor que no ha visto los datos entendería qué se muestra sin el texto que la rodea?

Salida de la fase 3: un directorio figures/ y un directorio tables/, cada uno poblado por la pipeline, cada uno regenerable. La visualización de datos de investigación que sobrevive a la revisión es regenerable; los gráficos ad-hoc de Excel no.

Fase 4: Narrativa (semana 4)

Objetivo: el texto del informe, con cada afirmación trazable a los datos.

Tareas concretas:

• Redacta cada sección del informe contra la plantilla del financiador.
• Inserta figuras y tablas con sus pies y referencias.
• Para cada afirmación numérica en la prosa, enlázala explícitamente al artefacto que la produce (p.ej. "ver Tabla 3" o una nota al pie apuntando al script).
• Añade el anexo metodológico — fuentes de datos, pasos de procesamiento, decisiones estadísticas, enlace al repositorio.
• Ejecuta una comprobación en máquina nueva del código de soporte: ¿un revisor puede clonar el repositorio y reproducir las figuras?

Salida de la fase 4: un entregable que tu financiador acepta, con una trazabilidad de auditoría defendible.

Dónde fallan los equipos en la práctica

Las cuatro fases no son donde fallan los equipos. Los equipos fallan en las costuras entre fases.

• Fase 1 → 2: el análisis empieza antes de que la limpieza esté completa, luego hay que re-ejecutarlo contra un dataset actualizado, y luego re-ejecutarlo otra vez. Disciplina: no pasar a la fase 2 hasta que la fase 1 tenga una versión etiquetada.
• Fase 2 → 3: las figuras se producen ad-hoc según las necesita el borrador, desligadas de la pipeline de análisis. Disciplina: cada figura tiene un script productor, incluso las simples.
• Fase 3 → 4: quien escribe la narrativa es distinto de quien hace el análisis, y los números derivan entre la prosa y las figuras. Disciplina: una pasada final de consistencia donde cada afirmación numérica de la narrativa se verifica contra el artefacto que la produce.

La mayoría de equipos conoce la pipeline conceptualmente. La parte difícil es la disciplina en las costuras.

Decisiones de herramientas que sobreviven

El stack correcto no es fijo — pero algunos patrones funcionan mejor que otros para proyectos de investigación.

| Fase | Elección fiable | Por qué | |---|---|---| | Limpieza | Python (pandas) o R (tidyverse), scripts versionados | Ambos están bien soportados, hay perfiles disponibles y producen código auditable | | Análisis | Mismo lenguaje que limpieza, con paquetes estadísticos (scipy / statsmodels / R base) | La continuidad de lenguaje reduce fricción de traspaso | | Visualización | matplotlib / seaborn / ggplot2 / plotly | Establecidas, personalizables, formatos de salida que tu plantilla acepta | | Orquestación de pipeline | Make / Snakemake / nf-core para pipelines complejas; un script bash para las simples | Reproducibilidad sin sobrecarga empresarial | | Plantillas de documento | Quarto / Rmarkdown / Pandoc | Embebe salidas de código directamente en el documento |

La respuesta honesta para la mayoría de proyectos: un único repositorio Python o R con un run.sh de nivel raíz que produce cada figura del informe desde datos crudos. Cualquier cosa más sofisticada tiene que justificar su complejidad.

Una autoevaluación de 60 minutos

Bloquea 60 minutos. Abre el drive del proyecto. Puntúa con honestidad.

| Comprobación | Puntuación 0–2 | |---|---| | Versión canónica única de los datos limpios identificada | | | La limpieza es reproducible desde datos crudos | | | El script de análisis produce cada afirmación citada en el borrador del informe | | | Las figuras se generan desde la pipeline, no son capturas | | | Las afirmaciones de la narrativa trazan a tablas o figuras concretas | | | Cumplimiento de plantilla del financiador (páginas + estructura) verificado | | | El repositorio de código pasaría una prueba de reproducción en máquina nueva | | | Anexo metodológico redactado con datos + procesamiento + decisiones estadísticas | |

Total sobre 16. Por debajo de 10: riesgo serio de carrera de última hora. Por debajo de 6: pide ayuda.

Cuándo incorporar capacidad externa

Un Sprint de datos a informe de 2–4 semanas es la colaboración correcta cuando:

• Los datos existen pero la pipeline analítica no
• El equipo tiene el criterio científico pero le falta capacidad de ingeniería
• La plantilla del financiador tiene requisitos estructurales específicos con los que tu equipo no ha trabajado antes
• El plazo está más cerca de lo que la capacidad disponible del equipo permite

Para esto está construido nuestro Sprint de datos a informe. Lo hemos entregado para consorcios europeos, colaboraciones de investigación académica y grupos de investigación clínica. La salida es un repositorio versionado, figuras regenerables, un borrador del informe y el anexo metodológico — tu equipo lo lleva desde ahí.

Tres cosas para hacer esta semana

1. Ejecuta la autoevaluación de 60 minutos. Puntúa con honestidad.
2. Para el ítem con menor puntuación, escribe una frase con la definición de "hecho". Esa es tu mayor palanca.
3. Si tres o más ítems están a 0 y el plazo es inferior a 8 semanas, solicita una revisión de proyecto. Mejor saberlo ahora que en la semana menos uno.

Los datos están ahí. La memoria es alcanzable. La pipeline entre ambos es ingeniería — finita, definible y más rápida de lo que la mayoría de equipos espera cuando se trata como código en lugar de como trabajo ad-hoc.