Pla de gestió de dades: del requisit a un sistema mantenible

Vas escriure un Pla de Gestió de Dades a la proposta. La convocatòria de l'AGAUR o de Horizon Europe ho exigia, hi vas dedicar un parell de tardes, el vas entregar, et van concedir el projecte. Han passat dos anys. El PGD viu en una carpeta del Drive del coordinador. Ningú no l'ha tornat a obrir. La realitat de les dades del projecte no s'assembla al que deia aquell document. La revisió final arriba d'aquí a sis mesos i la pregunta de l'avaluador serà: on pot un revisor accedir a les teves dades netes?

El pla de gestió de dades que sobreviu al projecte no és el que escrius una vegada. És un sistema operatiu que el teu equip pot mantenir — un pont entre el que vas prometre al finançador i el que de debò passa amb les dades durant 36 mesos.

Aquest article és una guia narrativa del cicle complet del PGD per a projectes de recerca, amb especial atenció al context català: AGAUR, SGR-Cat, ICREA, eiNa DMP del CSUC, i el dipòsit a CORA Repositori de Dades de Recerca. El marc subjacent val per a Horizon Europe, ERC, MSCA, AEI / Plan Estatal i ajuts de la Generalitat — els requisits formals varien, la lògica operativa no.

Què espera realment el finançador del PGD

La majoria de PGDs s'escriuen per superar l'avaluació de la proposta. Això és legítim, però deixa fora tres coses que l'avaluador final sí que revisarà:

• Traçabilitat tècnica: els revisors poden accedir a les dades netes? Existeix una versió canònica? Està dipositada amb DOI citable a CORA o repositori equivalent?
• Coherència entre PGD i realitat: el document descriu el que l'equip fa realment, o el que es va prometre fa dos anys?
• Mantenibilitat: algú podria continuar operant les dades del projecte si el postdoc que les gestiona se'n va demà?

Les plantilles oficials d'AGAUR, Horizon Europe, eiNa DMP del CSUC i les biblioteques universitàries cobreixen la primera capa: seccions, continguts mínims, calendaris de revisió. El que no cobreixen és la traducció operativa — com convertir cada compromís del PGD en una pràctica de treball concreta que l'equip pugui sostenir.

La pregunta útil quan escrius el PGD inicial: aquest compromís és una cosa que complirem, o una cosa que estem prometent perquè queda bé? Si és la segona, val més reformular-ho ara que defensar-ho a la revisió final.

Les quatre fases del PGD que sobreviu al projecte

Fase 1: Lectura de la convocatòria (setmana 0)

Abans de començar a redactar, llegeix la convocatòria amb el PGD al cap. Identifica:

• Quina plantilla espera el finançador. AGAUR i la Generalitat utilitzen estructures pròpies per a SGR-Cat, ajuts ICREA i Beatriu de Pinós; Horizon Europe fa servir la plantilla actualitzada de la Comissió Europea; AEI/Plan Estatal té el seu format. CSUC ofereix l'eiNa DMP per generar plans alineats amb requisits multi-finançador.
• Quan és el primer lliurable formal del PGD. A Horizon Europe normalment al mes 6; a AGAUR depèn de la modalitat. Marca la data al calendari abans de redactar res.
• Què s'espera respecte a FAIR i ciència oberta. Les convocatòries actuals són cada vegada més explícites: "as open as possible, as closed as necessary" a Horizon Europe, mandat de dipòsit a repositoris públics a moltes modalitats AGAUR i AEI.
• Què diu la convocatòria sobre dades sensibles. Si el projecte treballa amb dades personals, sanitàries o sotmeses a CEIm/IRB, el PGD necessita una secció de protecció de dades coherent amb la base legal del tractament.

Aquesta lectura és de 30 minuts i estalvia dues setmanes de redacció a cegues. La majoria de PGDs febles s'escriuen sense haver llegit la convocatòria amb aquesta mirada.

Fase 2: Redacció inicial (setmanes 1–3)

El PGD inicial ha de ser específic, no genèric. Les seccions clàssiques són:

• Descripció de les dades (tipus, volum estimat, formats)
• Estàndards i metadades (esquemes, vocabularis controlats, alineació FAIR)
• Emmagatzematge i seguretat durant el projecte
• Compartició i accés (què es comparteix, quan, sota quina llicència)
• Conservació a llarg termini (dipòsit final, DOI, manteniment)
• Responsabilitats (qui fa què, amb quin pressupost)

Errors que veiem sovint en aquesta fase:

• Dades descrites en abstracte: "dades clíniques del projecte" en lloc de "registres longitudinals de 200 pacients amb 32 variables fenotípiques i 4 mesures neurofisiològiques".
• Estàndards esmentats sense compromís real: "alinearem amb els principis FAIR" sense dir com. Millor: "dipositarem a CORA amb metadades Dublin Core esteses i llicència CC-BY 4.0".
• Compartició promesa però sense pla d'anonimització: si les dades són sensibles, cal dir com es comparteixen, no només que es compartiran.
• Conservació delegada a la institució: dir "la universitat mantindrà les dades" sense confirmar amb el servei de biblioteca o amb CSUC és un compromís fals.

El PGD inicial bo té una propietat: si el llegeixes amb l'equip en una reunió de 30 minuts, tothom pot dir què ha de fer la setmana següent. Si la resposta és "no ho sé", el PGD és massa genèric.

Fase 3: Revisió i lliurament formal (mes 6)

Per a Horizon Europe, el primer lliurament formal del PGD sol ser al mes 6. Per a AGAUR i AEI els terminis varien, però la lògica és la mateixa: cal entregar al finançador una versió revisada que reflecteixi el que s'ha après els primers mesos del projecte.

Aquí és on la majoria de projectes perden l'oportunitat. La revisió es fa amb pressa, copy-paste del PGD inicial i uns canvis cosmètics. El que l'avaluador espera és el contrari: evidència que l'equip ha après sobre les seves pròpies dades durant els primers sis mesos.

Què val la pena revisar abans del lliurament del mes 6:

• Volums reals vs estimats: si vas dir 200 pacients i en seran 350, digues-ho. Si vas dir 200 i en seran 80, digues-ho també — i explica per què (canvis de protocol, retards en el reclutament).
• Esquema actualitzat: els noms de variables, unitats i vocabularis que de debò estàs fent servir, no els que vas escriure abans de tocar les dades.
• Decisions de qualitat preses: criteris d'exclusió, gestió de valors faltants, deduplicació. Si el teu equip va discutir aquestes decisions al març, deixa'n constància al PGD revisat.
• Repositori confirmat: si vas dir "CORA o repositori institucional" a la proposta, ara tria'n un amb motiu. Si has provat l'eiNa DMP del CSUC, indica-ho.
• Pla de protecció de dades validat pel comitè d'ètica: si aplica, amb número d'aprovació.

Aquesta revisió és l'oportunitat de tancar la bretxa entre el promès i el possible sense quedar en mal lloc.

Fase 4: Manteniment operatiu (mes 7 fins al tancament)

Aquí el PGD deixa de ser un document i passa a ser una pràctica. Què distingeix un PGD operatiu d'un d'administratiu:

• L'esquema de dades viu en codi, no només al document. Una validació Pydantic / JSON Schema s'executa cada vegada que entren dades noves.
• Les decisions de qualitat estan en scripts, no només en actes. El pipeline de neteja és reproduïble — python clean.py porta de cru a net sense passos manuals.
• El dipòsit al repositori s'assaja aviat. Val més dipositar una versió preliminar al mes 18 que esperar al mes 36 i descobrir que CORA no accepta el format. L'eiNa DMP del CSUC pot generar el PGD en format llegible per màquina i alineat amb els requisits del repositori.
• El PGD es revisa un cop l'any, mínim. Idealment acompanyant els hites d'informe del finançador.
• El repositori de codi té un README que un revisor extern podria seguir. Aquesta és la diferència entre un projecte FAIR de debò i un que ho diu.

Errors comuns que fan que un PGD no sobrevisqui

Després de revisar PGDs de projectes AGAUR, AEI, ERC, MSCA i Horizon Europe, els mateixos errors apareixen una i altra vegada:

• Tractar el PGD com una obligació administrativa, no com una eina operativa. El PGD hauria de ser el document més útil del projecte per a l'equip, no el més invisible.
• Delegar-lo a una sola persona sense pressupost. "El doctorand farà el PGD a estones" és la frase que precedeix tots els desastres de tancament.
• No validar les afirmacions FAIR. Dir "alineat amb FAIR" sense metadades estructurades, sense DOI, sense llicència de reutilització és un compromís fals que l'avaluador detectarà.
• Oblidar la versió revisada. El finançador espera evolució del document. Una versió idèntica a l'esborrany inicial és un senyal que ningú no hi ha treballat.
• No connectar el PGD amb la justificació tècnica final. El PGD descriu les dades; la justificació tècnica del tancament hi fa referència com a evidència. Si els dos documents no es parlen, l'avaluador ho nota.

El context català: alineació amb AGAUR, CSUC i CORA

Per als equips catalans, el PGD opera en un ecosistema concret:

• AGAUR i Generalitat demanen documentació de gestió de dades en moltes modalitats (SGR-Cat, ICREA, Beatriu de Pinós), amb formats que poden no coincidir exactament amb la plantilla Horizon Europe. Vigila les diferències abans de copy-pastejar.
• eiNa DMP del CSUC és l'eina pública catalana per generar PGDs alineats amb requisits multi-finançador. Permet exportar el pla en formats estàndards i preparar el dipòsit posterior a CORA.
• CORA Repositori de Dades de Recerca és el repositori federat del sistema universitari de Catalunya. Per a equips catalans és sovint l'opció natural — confirma els requisits de format i metadades abans del primer dipòsit.
• Terminologia TERMCAT-alineada evita problemes a la revisió. Fes servir "dades", "recerca", "lliurables", "memòria", "dipòsit", "repositori", "justificació" — no anglicismes ni castellanismes innecessaris.

Si el teu projecte combina finançament europeu i català (Horizon Europe + SGR-Cat, per exemple), el PGD es pot fer servir per als dos amb una única estructura. Documentar una vegada amb traspàs múltiple en ment estalvia setmanes de feina duplicada al tancament.

La revisió anual del PGD: agenda de 60 minuts

Un cop l'any, idealment alineada amb un hite d'informe, bloqueja 60 minuts amb l'equip. Agenda concreta:

| Tema | Temps | Resultat | |---|---|---| | Repàs de l'esquema de dades vigent | 10 min | Esquema actualitzat o validat | | Decisions de qualitat noves des de la darrera revisió | 10 min | Decisions documentades al PGD | | Volums reals vs projectats | 10 min | Secció actualitzada | | Estat del repositori (CORA / institucional) i dipòsits preliminars | 10 min | Pla clar fins a la propera revisió | | Canvis a l'equip i traspàs de responsabilitats | 10 min | Assignacions actualitzades | | Pròxims hites del PGD i del finançador | 10 min | Calendari fins a la propera revisió |

Una hora l'any. És la inversió que separa un PGD viu d'un PGD que només apareix al tancament.

Quan convé incorporar ajuda externa

Un projecte de gestió de dades de recerca extern és la decisió correcta quan:

• L'equip no té un data manager dedicat i el PGD fa més d'un any sense actualitzar
• La revisió del mes 6 és a prop i la realitat de les dades no s'assembla al PGD inicial
• El tancament s'acosta i el dipòsit a CORA o equivalent no s'ha assajat
• Hi ha dades sensibles (salut, personals, sotmeses a CEIm) i el pla de protecció de dades no s'ha validat amb el comitè
• El consorci és multi-seu i els esquemes no estan alineats entre socis

Per a això està construït el nostre projecte de gestió de dades. Cobrim la implementació: validació d'esquema com a codi, pipelines de neteja reproduïbles, metadades FAIR, dipòsit a CORA o repositori equivalent, documentació de traspàs. La durada típica és 4–8 setmanes i l'equip posseeix el resultat.

Tres coses per fer aquesta setmana

1. Localitza la darrera versió del teu PGD. Si fa més de sis mesos sense actualitzar-se, agenda-li una revisió de 60 minuts amb l'equip.
2. Per a cada compromís FAIR del PGD, escriu en una frase què passa la setmana següent per fer-lo realitat. Si no pots, aquest compromís necessita reformulació.
3. Si la revisió revela una bretxa gran entre el promès i la realitat, sol·licita una revisió de projecte. Definirem el pla mínim viable per tancar la bretxa abans del proper informe.

El PGD que sobreviu al projecte no és el més detallat ni el més extens. És el que l'equip pot operar sense pensar-hi cada matí, i el que l'avaluador pot verificar sense sorpreses al tancament. La resta és paper.