import pandas as pd

Ciclo di Deming (PDCA) e miglioramento continuo

Molti team fanno retrospettive e test, ma non chiudono davvero il ciclo tra piano, azione, misurazione e apprendimento. Questa lezione collega PDCA e HADI a un ritmo decisionale che rende l’apprendimento cumulativo invece che episodico. Leggila come il sistema operativo del miglioramento: ogni ciclo deve produrre una decisione documentata su cosa abbiamo provato, cosa abbiamo imparato e cosa cambia nel ciclo successivo.

Perché serve un ciclo di apprendimento

Il problema non è conoscere il PDCA in astratto. Il problema è decidere cosa fare quando il team ha dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura del fenomeno. Un buon ciclo separa il segnale dal rumore, sceglie una baseline credibile e indica quale azione diventa più difendibile dopo l’analisi.

La prima domanda non è “quale metrica calcolo?” ma “quale decisione dovrà essere presa grazie a questa analisi?”. Una dashboard, una query o un modello hanno valore solo se riducono incertezza decisionale. Se non cambiano una scelta, sono documentazione o teatro analitico.

Il ciclo PDCA

Le quattro fasi del ciclo di Deming si tengono insieme così. In Plan si identifica il problema, si formula un’ipotesi e si definiscono le metriche di successo. In Do si implementa la modifica su piccola scala, per esempio un test A/B o una modifica a un modello. In Check si analizzano i risultati: l’ipotesi era corretta, le metriche sono migliorate? In Act, se ha funzionato si standardizza e si scala, altrimenti si impara e si ricomincia.

HADI: la versione moderna per startup

Il ciclo HADI (Hypothesis-Action-Data-Insights) è l’adattamento startup del PDCA. Si parte da un’ipotesi falsificabile, per esempio “se semplifichiamo il checkout, il tasso di conversione aumenta del 5%”. Poi si implementa il minimo indispensabile per testare l’ipotesi, cioè un MVP. Si raccolgono i dati per validare o falsificare. Infine si traggono gli insight, e anche un’ipotesi rivelatasi falsa lascia qualcosa da imparare.

La differenza chiave è la velocità. Il ciclo HADI è progettato perché ogni iterazione duri giorni e non mesi: più cicli significano più apprendimento.

Applicazione ai modelli dbt

Un modello dbt non si scrive e si abbandona, e il PDCA aiuta a tenerlo vivo. In Plan si progetta il modello con una granularità chiara. In Do si implementa in dev. In Check arrivano i test automatici, la validazione dei dati e il confronto con il modello precedente. In Act, se i test passano si fa il merge in produzione, altrimenti si itera; dopo 30 giorni si verifica che le metriche a valle siano davvero migliorate.

Un modello di lavoro per impostare l’analisi

Per non trasformare un ciclo tecnico in un rituale vuoto, conviene seguire una sequenza. Prima si definisce il problema in linguaggio business. Poi si identifica l’unità di analisi corretta: utente, account, evento, sessione, ordine o campagna. Si controlla se i dati misurano davvero il fenomeno o solo una sua ombra. Si costruisce una metrica interpretabile. Si segmenta per evitare che la media nasconda pattern opposti. Infine si trasforma il risultato in una raccomandazione verificabile.

La stessa logica serve a formalizzare ogni ciclo come relazione tra decisione, evidenza e rischio. La tabella seguente fissa gli elementi minimi.

Elemento	Definizione operativa	Controllo minimo
Unità di analisi	Oggetto su cui misuri il fenomeno	Utente, account, evento, ordine o periodo
Variabile osservata	Segnale che rappresenta il comportamento	Definizione stabile e tracciabile
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che può restare anche dopo l’analisi	Sensitivity check o revisione qualitativa

La formalizzazione è solida quando un altro analista riesce a riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione partendo dagli stessi dati. Un esempio concreto aiuta: un processo di onboarding migliora a piccoli cicli fatti di ipotesi, intervento, misura, retrospettiva e nuova azione. PDCA e HADI servono proprio a evitare due errori opposti, cambiare tutto senza imparare nulla oppure misurare a lungo senza intervenire mai.

Caso reale: Netflix e la disciplina delle metriche

Netflix è un esempio utile perché ha costruito molte decisioni di prodotto intorno a segnali comportamentali osservabili: completamento degli episodi, tempo di ricerca prima della riproduzione, abbandono dopo pochi minuti, ritorno nella settimana successiva, efficacia delle raccomandazioni. Il punto non è che ogni azienda debba copiare Netflix, ma che il dato non viene trattato come ornamento bensì come infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni, una diversa immagine di copertina o un algoritmo di ranking, non misura solo il click immediato. Guarda anche i segnali di qualità: l’utente guarda davvero il contenuto, torna nei giorni successivi, riduce il tempo speso a cercare. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve periodo ma erodono valore nel lungo. Lo stesso principio vale per ogni ciclo di miglioramento: va collegato a un outcome, e se non aiuta a scegliere tra due azioni alternative resta incompleto.

Esempio SQL: costruire una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. Crea una base analitica con metrica, segmento e finestra temporale, così da confrontare periodi e gruppi senza riscrivere la logica ogni volta.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

Questa query non pretende di essere la risposta finale. Serve a creare una superficie di osservazione fatta di trend, segmenti, differenze tra canali e variazioni nel tempo. Da qui l’analista formula ipotesi più precise per il ciclo successivo.

Esempio Python: controllare stabilità e anomalie

Una metrica utile deve essere stabile abbastanza da orientare decisioni e sensibile abbastanza da segnalare cambiamenti reali. In Python si possono controllare le variazioni anomale settimana su settimana.

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il valore di questo controllo è pratico. Evita di reagire a ogni oscillazione casuale e segnala quando una variazione merita un’indagine. In azienda questo tipo di analisi alimenta alert, review settimanali e retrospettive di prodotto, che sono esattamente la fase Check del ciclo.

Errori comuni da evitare

Il primo errore è lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo è confondere correlazione e causalità. Se gli utenti che usano una feature convertono di più, non significa che la feature causi la conversione: potrebbero usarla perché erano già più motivati.

Per ridurre questi rischi, ogni ciclo dovrebbe includere almeno tre controlli: la definizione esplicita della metrica, il confronto per segmento e la verifica contro un periodo precedente o un gruppo di controllo. C’è poi l’errore più sottile, quello di usare il PDCA come etichetta invece che come processo. Succede quando il team mostra un grafico senza decisione, una metrica senza baseline o una conclusione senza dire quale assunzione la invaliderebbe. La domanda di controllo è: se questo risultato fosse instabile, quale scelta sbaglierei?

Lab: chiudere un ciclo per intero

A livello base, scrivi una scheda di una pagina su un ciclo di miglioramento reale: la decisione da supportare, la metrica primaria, la baseline, il rischio principale e l’azione se il segnale è confermato. Se non riesci a nominare la decisione, il ciclo è ancora troppo astratto.

A livello intermedio, costruisci una tabella con tre segmenti, periodi o scenari. Per ciascuno indica cosa cambia, quale spiegazione alternativa è plausibile e quale controllo useresti prima di raccomandare un’azione. Includi almeno un caso in cui il segnale non basta per decidere.

A livello research-grade, prepara un decision memo con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione. Come materiali usa OKR, decision log, roadmap, retrospettive, interviste e survey interne. Se non hai dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Per fissare i concetti, prova a rispondere a queste domande. Quale decisione concreta dovrebbe migliorare grazie al ciclo? Quale unità di analisi rende il problema misurabile? Quale baseline eviterebbe una lettura ingenua? Quale errore tipico cambierebbe la conclusione? Quale output consegneresti a uno stakeholder non tecnico?

Riepilogo

Il ciclo di Deming va trattato come uno strumento decisionale, non come un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione, e quando ogni iterazione lascia una decisione documentata. Una buona analisi non termina con “il numero è salito” o “il numero è sceso”, ma con una frase operativa: quale decisione prendiamo, con quale livello di confidenza e quale metrica useremo per sapere se avevamo ragione. PDCA e HADI rendono questo apprendimento cumulativo solo se ogni ciclo è abbastanza breve da poterne fare molti.