Fase 4 - Seguiment, Control i Presentacio (27h)

Objectiu de la fase

La Fase 4 correspon al RA4 - Defineix procediments de seguiment i control. Es la fase final del projecte C088, on l'alumnat estableix els indicadors de qualitat, els procediments d'avaluacio i gestio d'incidencies i canvis, elabora la documentacio final i presenta el projecte davant del tribunal.

En 27 hores l'alumnat ha de produir: - El Quadre de Comandament (KPIs) del projecte - El Pla de Monitoratge del sistema en produccio - Els Procediments de Gestio d'Incidencies i Canvis - L'Informe Final (executiu + tecnic) - La Presentacio Oral (slides + demo)

Resultats esperats al finalitzar la Fase 4:

Quadre de KPIs complet (tecnics, operatius, de negoci)
Pla de monitoratge amb eines configurades (MLflow, Evidently, Grafana)
Circuit de gestio d'incidencies documentat
Politica de gestio de canvis per al sistema IA
Informe final executiu i tecnic
Presentacio oral de 10-15 minuts amb demo

KPIs per a projectes IA

Els KPIs (Key Performance Indicators) permeten mesurar objectivament si el sistema funciona correctament i si el projecte assoleix els seus objectius de negoci.

Quadre de comandament complet

Categoria	KPI	Metode de mesura	Target	Frequencia
Model	Accuracy	Avaluacio sobre conjunt de test	> 88%	Setmanal
Model	F1-Score (macro)	sklearn.metrics.f1_score	> 0.83	Setmanal
Model	Latencia inferencia p50	Prometheus histogram	< 150ms	Continu
Model	Latencia inferencia p99	Prometheus histogram	< 500ms	Continu
Produccio	Uptime del servei	Blackbox Exporter	> 99.5%	Continu
Produccio	Error rate (5xx)	Nginx/FastAPI logs	< 0.1%	Continu
Produccio	Requests per segon	Prometheus counter	Baseline + 20%	Continu
Produccio	Data drift score	Evidently AI	< 0.1 (PSI)	Diari
Qualitat de dades	Completesa del dataset	Great Expectations	> 98%	Diari
Qualitat de dades	Anomalies detectades	Pipeline validacio	0 critiques	Diari
Negoci	ROI del sistema	Calcul manual/trimestral	> 150%	Trimestral
Negoci	Temps estalviat	Comparativa antes/despres	- 40%	Mensual
Negoci	Satisfaccio usuaris	NPS / enquesta	NPS > 40	Trimestral
Negoci	Tasques automatitzades	Comptador del sistema	> 80% del target	Mensual

Com calcular el ROI d'un sistema IA

El ROI (Return on Investment) es el KPI de negoci mes important per justificar un projecte IA davant d'inversors o la directiva:

Formula basica:

ROI = (Benefici net / Cost total) × 100
Benefici net = Estalvi total - Cost total

Exemple per a un sistema RAG de gestio documental:

Concepte	Calcul	Import
Temps estalviat per empleat	1h/dia × 50 empleats × 22 dies/mes	1.100h/mes
Cost de l'hora treballada	Salari mitja 42.000 €/any → 20 €/h	20 €/h
Estalvi mensual	1.100h × 20 €/h	22.000 €/mes
Estalvi anual	22.000 × 12	264.000 €/any
Cost total del projecte (un cop)	Fase d'implementacio	45.000 €
Cost operatiu anual	Infraestructura + manteniment	18.000 €/any
Cost total any 1	45.000 + 18.000	63.000 €
ROI any 1	(264.000 - 63.000) / 63.000 × 100	319%
Payback period	63.000 / (264.000/12)	2.9 mesos

Monitoratge en produccio

MLflow Tracking

MLflow es l'eina estandard per al monitoratge d'experiments i models de ML. Permet registrar:

Que registra MLflow: - Parametres: hiperparametres del model (learning_rate, n_estimators, etc.) - Metriques: accuracy, F1, MAE, RMSE, etc. (per epoch/iteracio o final) - Artefactes: model serialitzat, grafics, datasets de validacio - Tags: versio del codi, dataset usada, entorn

Exemple de codi d'integracio:

import mlflow
import mlflow.sklearn

with mlflow.start_run(run_name="xgboost_v2_tuned"):
    # Parametres
    mlflow.log_param("n_estimators", 300)
    mlflow.log_param("max_depth", 6)
    mlflow.log_param("learning_rate", 0.05)

    # Entrenament
    model = XGBClassifier(n_estimators=300, max_depth=6)
    model.fit(X_train, y_train)

    # Metriques
    mlflow.log_metric("accuracy", accuracy_score(y_test, preds))
    mlflow.log_metric("f1_macro", f1_score(y_test, preds, average='macro'))

    # Model
    mlflow.sklearn.log_model(model, "model")

    # Artefactes
    mlflow.log_artifact("confusion_matrix.png")
    mlflow.log_artifact("shap_values.png")

MLflow Model Registry:

El Model Registry de MLflow gestiona el cicle de vida dels models:

Experiment → [Millor model] → Staging → [Tests OK] → Production → [Substituit] → Archived

Staging: el model esta en proves. L'equip el valida.
Production: el model esta servint peticions reals.
Archived: model antic, no en us pero conservat per a auditoria.

Weights & Biases (W&B)

Alternativa premium a MLflow per a equips que necessiten: - Visualitzacio interactiva d'experiments - Comparativa visual entre runs - Sweeps (cerca d'hiperparametres distribuit) - Reports compartibles amb no-tecnics

W&B es gratuito per a projectes oberts i te pla academic per a estudiants.

Evidently AI - Monitoratge de Data Drift

El data drift passa quan la distribucio de les dades de produccio divergeix de les dades d'entrenament. Es la causa mes frequent de degradacio de models en produccio.

Tipus de drift:

Tipus	Descripcio	Exemple
Feature drift	Les features d'entrada canvien	Els preus d'un sector pugen sobtadament
Label drift	La distribucio de les classes canvia	Mes casos de frau durant el nadal
Concept drift	La relacio entre features i label canvia	Un client habitual canvia de comportament

Exemple d'analisi amb Evidently AI:

from evidently.report import Report
from evidently.metric_preset import DataDriftPreset

report = Report(metrics=[DataDriftPreset()])
report.run(
    reference_data=df_entrenament,
    current_data=df_produccio_ultima_setmana
)
report.save_html("drift_report.html")

Interpretacio del PSI (Population Stability Index): - PSI < 0.1: No hi ha drift significatiu - 0.1 ≤ PSI < 0.2: Drift lleu, monitorar de prop - PSI ≥ 0.2: Drift significant, considerar reentrenament

Grafana + Prometheus per a APIs FastAPI

Prometheus recull metriques de l'API en temps real. Grafana les visualitza en dashboards.

Metriques estandard per a una API FastAPI:

from prometheus_fastapi_instrumentator import Instrumentator

app = FastAPI()
Instrumentator().instrument(app).expose(app)
# Expose metriques a /metrics: latencia, error_rate, requests/s

Dashboard de Grafana recomanat:

Panels minims per a un sistema IA en produccio: 1. Requests per segon (RPS) - time series 2. Latencia p50 / p95 / p99 - gauge + time series 3. Error rate (4xx + 5xx) - stat + alert 4. CPU i RAM del contenidor - gauge 5. Predictions per classe (distribucio) - bar chart 6. Data drift score (PSI) per feature - heatmap 7. Model accuracy dels ultims 7 dies - time series

Gestio d'incidencies en sistemes IA

Circuit complet de gestio d'incidencies

El circuit de gestio d'incidencies defineix com es detecta, tracta i resol un problema en el sistema:

1. DETECCIO
   ↓ (Alerta Grafana / Report d'usuari / Monitoratge automatitzat)

2. NOTIFICACIO
   ↓ (Email + Slack + PagerDuty a l'enginyer de guardia)

3. TRIAGE
   ↓ Classificar per gravetat:
   - SEV1: Sistema completament caigut → Resposta en 15 min
   - SEV2: Funcionalitat degradada → Resposta en 1h
   - SEV3: Problema menor → Resposta en 24h
   - SEV4: Millora o consulta → Proper sprint

4. INVESTIGACIO (Root Cause Analysis)
   ↓ Revisar logs, metriques, traces, changeog recent

5. SOLUCIO TEMPORAL (Workaround)
   ↓ Restaurar el servei tan aviat com sigui possible

6. SOLUCIO DEFINITIVA
   ↓ Corregir la causa arrel (hotfix o planificació)

7. COMUNICACIO AL CLIENT
   ↓ Notificar resolucio i impacte

8. POST-MORTEM
   ↓ Document de lliçons apreses (48h despres de la resolucio)

Plantilla de ticket d'incidencia

INCIDENCIA: [ID-001]
Data/Hora deteccio: 2025-11-15 14:32 CET
Severitat: SEV2
Sistema afectat: Sistema RAG - Produccio
Descrit per: [nom]

SIMPTOMES
El sistema RAG respon "No he trobat informacio" per a totes les preguntes
des de les 14:00. El servei esta accessible pero no retorna resultats.

IMPACTE
50 usuaris no poden consultar la base de coneixement.
Impacte de negoci: mitja. Alternativa: consulta manual al document.

ACCIONS REALITZADES
14:32 - Alerta detectada per Grafana (0 results rate = 100%)
14:35 - Assignat a [enginyer]
14:45 - Revisio de logs: error de connexio a Qdrant (base de dades vectorial)
14:50 - Qdrant reiniciat. Proves de connectivitat OK.
15:00 - Sistema operatiu. Tanca incident.

ROOT CAUSE
Qdrant va quedar sense memoria (OOM) despres d'una indexacio massiva.
El contenidor de Docker no tenia limit de memoria configurat.

SOLUCIO APLICADA
Reinici del servei Qdrant. Configurat limit de RAM a 4GB al docker-compose.

SEGUIMENT
Oberta tasca per revisar el dimensionament del servidor (SEV4).

Bug de codi vs degradacio del model

Una distincio critica en sistemes IA:

	Bug de codi	Degradacio del model
Manifestacio	Error 500, excepcio, crash	Respostes incorrectes pero sense error
Detecci	Logs d'errors, alertes	Monitoratge de metriques del model
Causa	Error de programacio	Data drift, distribucio canviant
Solucio	Hotfix del codi	Reentrenament del model
Frequencia	Puntual	Gradual (setmanes/mesos)
Urgencia	Alta (SEV1-SEV2)	Mitja (SEV3, planificable)

Gestio de canvis

DVC - Data Version Control

DVC permet versionar datasets i models igual que Git versiona el codi:

# Inicialitzar DVC en un repo Git existent
dvc init

# Afegir un dataset a DVC (les dades van a S3, el pointer va a Git)
dvc add data/raw/dataset_v2.csv
git add data/raw/dataset_v2.csv.dvc .gitignore
git commit -m "feat(data): add dataset v2 with 50k new samples"

# Reproduir el pipeline amb les noves dades
dvc repro

# Comparar metriques entre versions
dvc metrics diff HEAD~1 HEAD

Beneficis de DVC: - Reproducibilitat: pots recrear qualsevol versio del model amb les dades exactes - Traçabilitat: saps exactament amb quines dades s'ha entrenat cada model - Collaboracio: l'equip treballa amb les mateixes versions de dades

Git Flow per a projectes ML

La ramificacio recomanada per a projectes ML:

main ──────────────────────────────────── (produccio, tag v1.0, v1.1...)
 │
release/1.0 ──────────────────────────── (preparacio release)
 │
develop ──────────────────────────────── (integracio continua)
 │      │            │
feature/data-pipeline  experiment/xgboost-v2  hotfix/oom-qdrant

Convencions de nomenament de branques: - feature/[descripcio] - Nova funcionalitat - experiment/[nom-experiment] - Experiment de ML (pot ser descartat) - hotfix/[descripcio] - Correccio urgent en produccio - release/[versio] - Preparacio de release

MLflow Model Registry - Gestio del cicle de vida

Politica de promocio de models:

Etapa	Criteri per a entrar	Criteri per a sortir
Staging	Accuracy > 85% en test, totes les proves passades	Aprovat per a produccio o rebutjat
Production	Supera el model de produccio actual, aprovat per l'equip	Substituit per una nova versio
Archived	Model fora d'us	Mai s'esborra (auditoria)

Procediment formal de canvi de model en produccio:

Solicitud de canvi (CR): El Data Scientist obre un CR amb metriques del nou model
Revisio tecnica: L'equip revisa les metriques, el codi i els tests
Proves A/B: Despleguem el nou model al 10% del traffic durant 48h
Aprovacio: Si les metriques son millors o iguals, s'aprova el rollout complet
Desplegament: CI/CD desplega el model aprovat a produccio
Monitoratge: 24h de monitoratge intensiu post-desplegament
Arxiu: El model antic passa a Archived al registry

Estructura de l'informe final

Informe executiu (1-2 pagines)

L'informe executiu va dirigit a la direccio de l'empresa (no tecnics). Ha de ser breu, clar i centrat en el valor de negoci:

Estructura recomanada:

INFORME EXECUTIU - [Nom del Projecte]

RESUM (3-4 frases)
[Que s'ha fet, per a qui, quins resultats]

PROBLEMA RESOLT
[Descripcio del problema inicial en termes de negoci, no tecnics]

SOLUCIO IMPLEMENTADA
[Descripcio de la solucio en un paragraf, sense tecnicismes]

RESULTATS ACONSEGUITS
• ROI: [valor]% en [temps]
• Temps estalviat: [hores/mes]
• [KPI de negoci 3]: [valor]

INVERSIO REALITZADA
• Cost total del projecte: [import]
• Cost operatiu mensual: [import]
• Payback period: [mesos]

RECOMANACIONS
1. [Proxim pas recomanat]
2. [Millora o extensio futura]
3. [Consideracio estrategica]

Informe tecnic complet

L'informe tecnic va dirigit a l'equip tecnic i al tribunal del projecte:

Estructura recomanada:

1. INTRODUCCIO
   1.1. Contexte i motivacio
   1.2. Objectius del projecte
   1.3. Abast i limitacions

2. METODOLOGIA
   2.1. Metodologia de projecte (Scrum, CRISP-DM)
   2.2. Eines i tecnologies usades
   2.3. Dades: origen, caracteristiques, preprocessing

3. ARQUITECTURA DEL SISTEMA
   3.1. Diagrama d'arquitectura
   3.2. Components i responsabilitats
   3.3. Decisions d'arquitectura clau (ADRs)
   3.4. Seguretat i privacitat

4. IMPLEMENTACIO
   4.1. Component 1: [descripcio]
   4.2. Component 2: [descripcio]
   4.3. Pipeline CI/CD
   4.4. Desplegament i infraestructura

5. RESULTATS I METRIQUES
   5.1. Metriques del model (taules + grafics)
   5.2. Comparativa amb el baseline
   5.3. Metriques de produccio (SLAs)
   5.4. KPIs de negoci aconseguits

6. GESTIO DEL PROJECTE
   6.1. Gantt real vs planificat
   6.2. Pressupost real vs planificat
   6.3. Riscos materialitzats i resolucio
   6.4. Canvis en l'abast

7. QUALITAT I PROVES
   7.1. Estrategia de tests
   7.2. Resultats dels tests
   7.3. Monitoratge en produccio

8. LLIÇONS APRESES
   8.1. Que ha anat be
   8.2. Que ha anat malament i com ho hem resolt
   8.3. Que fariamos diferent

9. CONCLUSIONS I TREBALL FUTUR
   9.1. Conclusions principals
   9.2. Funcionalitats futures recomanades
   9.3. Consideracions d'escalabilitat

ANNEXOS
A. Repositori de codi (URL)
B. Documentacio de l'API (Swagger URL)
C. Dashboards de monitoratge (Grafana URL)
D. Acords legals (NDA, DPA - sense dades confidencials)
E. Bibliogafia

Guia de presentacio oral

Estructura recomanada (10-15 minuts + 5-10 minuts preguntes)

La presentacio ha de seguir la logica narrativa problema → solucio → demo → resultats:

1. Slide d'obertura (1 min) - Titol del projecte, nom, data - Una frase que captivi l'atencio: "Sabies que les empreses perden un 20% del temps buscant informacio en documents interns?"

2. El problema (2 min) - Descripcio del problema de negoci - A qui afecta i quant els costa - Per que no s'ha resolt fins ara

3. La solucio (2 min) - Que hem dissenyat/construït - Diagrama d'arquitectura simplificat - Per que aquesta solucio i no una altra

4. Demo en viu (3-4 min) - Demo del sistema funcionant (o video pre-gravat si hi ha risc de fallada) - Ensenyar el cas d'us principal - Mostrar les metriques principals

5. Resultats (2 min) - KPIs aconseguits vs objectius - ROI i retorn de la inversio - Grafics de rendiment del model

6. Gestio del projecte (1 min) - Gantt: el que es va planificar vs el que s'ha fet - Pressupost: planificat vs real - Riscos que s'han materialitzat

7. Conclusions i futur (1 min) - Principals lliçons apreses - Proxims passos recomanats

8. Preguntes

Com fer una demo efectiva

Una demo en viu es el punt mes impactant de la presentacio, pero tambe el de mes risc:

Preparacio de la demo: - Prova la demo el dia abans i dues hores abans de la presentacio - Usa dades de demo preparades, no dades de produccio reals - Ten un video de backup preparat per si la demo falla - Tanca totes les aplicacions innecessaries (notificacions, tabs oberts) - Usa un compte de demo, no el teu compte personal

Estructura d'una demo de 3-4 minuts: 1. Context: "Ara us mostraré com un empleat pot consultar el manual de RRHH" 2. Input: mostra la pregunta o entrada de l'usuari 3. Proces (opcional): mostra brevament com el sistema processa la peticio 4. Output: mostra el resultat amb emfasi en la qualitat o velocitat 5. Edge case: mostra un cas on el sistema gestiona correctament un limit

Per a sistemes que no es poden demostrar en directe (models de ML, pipelines): - Mostra el MLflow dashboard amb els experiments - Mostra el Grafana amb les metriques en temps real - Presenta grafics de les metriques del model - Mostra el codi d'una part clau amb explicacio

Preguntes tipiques del tribunal

Prepara les respostes a les seguents preguntes:

Preguntes tecniques: 1. Per que has triat [tecnologia X] en comptes de [tecnologia Y]? 2. Com escalaries el sistema a 10x el volum actual? 3. Com has gestionat la privacitat de les dades de l'usuari? 4. Com detectes que el model s'ha degradat? 5. Quina es la complexitat computacional del teu sistema?

Preguntes de gestio: 6. Com has gestionat el canvi en els requisits que va sorgir a meitat del projecte? 7. El pressupost s'ha desviat del planificat? Per quin motiu? 8. Quins riscos s'han materialitzat i com els has resolt? 9. Quin es el cami critic del teu projecte? Per que?

Preguntes de negoci: 10. Com justificaries la inversio davant d'un directiu no tecnic? 11. Qui serian els competidors directes del teu sistema? 12. Com es pot monetitzar el projecte? 13. Quines subvencions podria sollicitar l'empresa per a implementar-lo?

Preguntes de regulacio: 14. El teu sistema esta subjecte a l'AI Act? Quin nivell de risc te? 15. Com garanteixes el compliment del RGPD?

Consells per gestionar els nervis

Prepara't be: la millor manera de reduir l'ansietat es haver practicat la presentacio almenys 3 vegades en veu alta
Cronometra't: assegura't que la presentacio no passa dels 15 minuts
Respira: fes una respiracio profunda abans de comencar
Parla pausat: tendim a parlar rapid quan estem nerviosos
Mira al tribunal: no llegeixis les slides, mirar a les persones
Si no saps una resposta: "Es una bona pregunta, no tinc la resposta ara mateix, pero puc investigar-ho i respondre per escrit" es una resposta valida
Despres de la presentacio: sigui com sigui, hauras après moltissim

Rubrica de la Fase 4

Criteri	Pes	Excel·lent (9-10)	Notable (7-8)	Aprovat (5-6)	Insuficient (<5)
KPIs i monitoratge (CA4.1-CA4.2)	25%	Quadre de KPIs complet (model, produccio, negoci). ROI calculat. Pla de monitoratge amb eines especifiques.	KPIs correctes i mesurables. Monitoratge definit.	KPIs basics. Monitoratge generic.	Sense KPIs mesurables o monitoratge.
Gestio incidencies i canvis (CA4.3-CA4.4)	20%	Circuit d'incidencies complet. Plantilla de ticket. Politica de canvis amb DVC/Git. MLflow Registry.	Procediments clars i complets.	Procediments basics.	Absencia de procediments.
Documentacio final (CA4.5)	20%	Informe executiu i tecnic professionals. Estructura completa, clara i ben redactada. Annexos complets.	Documentacio correcta i completa.	Documentacio suficient.	Documentacio deficient o incompleta.
Participacio usuaris (CA4.6)	10%	Pla UAT detallat, enquesta NPS, analisi de resultats, millores incorporades.	UAT planificada i executada.	UAT basica.	Sense mecanismes de participacio d'usuaris.
Compliment del plec (CA4.7)	5%	Checklist de compliment, matriu de traccabilitat, tancament formal amb client.	Compliment verificat correctament.	Compliment basic.	Sense mecanisme de control del plec.
Presentacio oral	15%	Demo en viu, slides professionals, estructura narrativa clara, comunicacio segura i fluida.	Bona presentacio, demo adequada.	Presentacio acceptable.	Presentacio deficient.
Resposta a preguntes	5%	Domina el tema, argumenta les decisions, respon amb precisio i seguretat.	Respon correctament la majoria de preguntes.	Respon les preguntes basiques.	No respon adequadament.

Rubrica global del projecte

Criteri	Pes	Excel·lent (9-10)	Notable (7-8)	Aprovat (5-6)	Insuficient (<5)
Qualitat tecnica del projecte	35%	Solucio innovadora, ben implementada, documentada i amb metriques excel·lents. Arquitectura professional i justificada. Stack tecnologic adequat al cas d'us.	Solucio correcta i funcional. Stack tecnologic adequat. Arquitectura coherent i justificada.	Solucio basica funcional. Arquitectura senzilla pero coherent. Tecnologies adequades.	Solucio incompleta o incorrecta. Arquitectura inconsistent o absent. Tecnologies no justificades.
Gestio del projecte	25%	Gantt professional amb cami critic. Riscos especifics IA gestionats amb pla de mitigacio complet. Pressupost real i detallat. Control de qualitat rigoris amb SLAs.	Planificacio correcta. Riscos identificats i categoritzats. Pressupost raonable. Qualitat considerada.	Planificacio basica. Alguns riscos identificats. Pressupost aproximat. Qualitat considerada superficialment.	Planificacio absent o molt deficient. Sense gestio de riscos. Pressupost irreal o absent.
Qualitat de la documentacio	20%	Documentacio professional: executiva i tecnica. Clara, completa, ben estructurada i redactada. Format professional consistent. ADRs i runbook presents.	Documentacio correcta i completa. Estructura clara. Format adequat. Principals documents presents.	Documentacio suficient per entendre el projecte. Algunes seccions mancades de detall. Format acceptable.	Documentacio deficient, incompleta o sense estructura. Format informal.
Presentacio oral	15%	Demo en viu impactant. Comunicacio clara i segura. Slides professionals. Estructura narrativa perfecta: problema, solucio, demo, resultats. ROI ben argumentat.	Bona presentacio. Slides correctes. Demo o exemple adequat. Comunicacio fluida i clara.	Presentacio adequada. Slides basiques. Comunicacio acceptable. Demostracio parcial.	Presentacio deficient. Sense demo. Comunicacio poc clara o molt nerviosa.
Resposta a preguntes	5%	Domina el tema en profunditat. Argumenta les decisions tecniques i de negoci. Respon amb seguretat i precisio.	Respon correctament. Raona les decisions principals. Algun dubte menor.	Respon les preguntes basiques. Alguna dificultat amb qüestions tecniques avancades.	No respon adequadament. No justifica les decisions. Demostra desconeixement del propi projecte.

Consells per a la Fase 4

KPIs de negoci primer: comenca pels KPIs de negoci (ROI, temps estalviat) i treballa cap enrere per definir les metriques tecniques que els suporten.
Monitoratge configurat: inclou screenshots o links als dashboards de Grafana/MLflow configurats. Aixo demostra que el sistema es real i operatiu.
Informe executiu primer: escriu el resum executiu com si l'has de llegir en 2 minuts. Si no pots resumir-ho, es que no ho tens prou clar.
Demo preparada: el dia de la presentacio, tens la demo preparada? Esta desplegada i accessible? Si el sistema es local, pots moure la demo a un video?

Errors freqüents de la Fase 4

KPIs que no es poden mesurar: "el sistema ha de ser de qualitat alta"
Informe final que descriu el que s'havia de fer, no el que s'ha implementat
Presentacio de 25 diapositives on es llegeix tot el text
Demo que falla i no hi ha pla B (video de backup)
No calcular el ROI: el tribunal voldra saber quan val el que has fet
Post-mortem de riscos sense riscos materialitzats (tots els projectes tenen imprevistos)