Ciclo di Deming (PDCA) e miglioramento continuo

Ogni giro del ciclo di Deming si chiude con una tabella, una metrica e una decisione documentata. Il metodo è antico, ma resta il modo più onesto di migliorare un processo: Plan, Do, Check e Act trasformano ogni intervento in un esperimento con ipotesi, baseline e apprendimento per il giro successivo. Qui lo applichi al lavoro analitico, con HADI per le iterazioni veloci e PDCA per consolidare ciò che ha funzionato.

L’idea in una frase

Il ciclo Plan, Do, Check e Act trasforma ogni intervento in un esperimento con ipotesi, metrica e decisione documentata per il giro successivo.

Il percorso in cinque passi

1. Scrivi l’ipotesi falsificabile con metrica, baseline e miglioramento atteso.
2. Implementa l’intervento minimo su piccola scala con finestra temporale fissa.
3. Misura la metrica per segmento contro baseline e gruppo di controllo.
4. Decidi se standardizzare, correggere o archiviare in base alla soglia scritta prima.
5. Documenta cosa hai imparato e cosa cambia nel ciclo successivo.

Il ciclo PDCA

Le quattro fasi del ciclo di Deming formano un giro chiuso. In Plan identifichi il problema, formuli un’ipotesi e definisci le metriche di successo. In Do implementi la modifica su piccola scala, per esempio un test A/B o una modifica a un modello. In Check analizzi i risultati: l’ipotesi era corretta e le metriche sono migliorate. In Act standardizzi e scali se ha funzionato, altrimenti impari e ricominci.

HADI: la versione moderna per startup

Il ciclo HADI unisce Hypothesis, Action, Data e Insights ed e l’adattamento del PDCA per i team veloci. Si parte da un’ipotesi falsificabile, del tipo “se semplifichiamo il checkout il tasso di conversione sale del 5%”. Poi si implementa il minimo indispensabile per testarla. Si raccolgono i dati per validarla o falsificarla. Infine si traggono gli insight, e anche un’ipotesi falsa lascia un apprendimento. La differenza chiave e la velocita: ogni iterazione dura giorni e non mesi, e piu cicli significano piu apprendimento.

Tra PDCA rigoroso e HADI veloce, scegli HADI per esplorare e PDCA per consolidare cio che ha funzionato.

Applicazione ai modelli dbt

Un modello tabellare non si scrive e abbandona: il ciclo lo tiene vivo. In Plan progetti il modello dbt con granularita chiara. In Do lo implementi in ambiente di sviluppo. In Check applicchi test automatici, validazione dei dati e confronto con il modello precedente. In Act fai il merge in produzione se i test passano, altrimenti iteri, e dopo 30 giorni controlli che le metriche a valle siano davvero migliorate.

Elemento	Definizione operativa	Controllo minimo
Unita 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 puo restare anche dopo l’analisi	Controllo di sensitivita o revisione qualitativa

La vista di controllo in SQL

Per confrontare il prima e il dopo di ogni ciclo, il pattern seguente crea una base analitica con metrica, segmento e finestra temporale.

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;

La query rende ogni ciclo confrontabile con trend, segmenti e differenze tra canali.

Il controllo di stabilita in Python

Una metrica di ciclo resta stabile per orientare le decisioni e sensibile per segnalare i cambiamenti reali.

# 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 controllo corrisponde alla fase Check e segnala quando una variazione merita una retrospettiva.

Gli errori tipici da evitare

Il primo errore e cambiare tutto senza imparare nulla. Salta la fase Check e perde l’apprendimento. Il secondo e misurare a lungo senza intervenire mai. Resta fermo in Plan per paura di sbagliare. Il terzo e leggere medie aggregate senza segmentare. Nasconde i gruppi che si muovono in direzioni opposte. Ogni ciclo deve includere definizione esplicita della metrica, confronto per segmento e controllo contro un periodo precedente o un gruppo di controllo.

Un caso reale: il Fire Phone e la fase Check saltata

Nel 2014 Amazon lancia il Fire Phone nonostante i dati mostrassero un mercato saturo di smartphone con poca differenziazione. Il prodotto si rivela un fallimento da 170 milioni di dollari di perdita, riconosciuto da Jeff Bezos nella lettera agli azionisti del 2015. La lezione per il ciclo e diretta: senza una fase Check onesta che confronta ipotesi e baseline, il processo salta ad Act e scala un errore. Un ciclo chiuso avrebbe imposto una soglia scritta prima, un test su piccola scala e una decisione di stop documentata.

Verdetto: tra PDCA rigoroso e HADI veloce, scegli HADI per esplorare e PDCA per consolidare ciò che ha funzionato; senza una fase Check onesta con soglia scritta prima, ogni ciclo salta ad Act e scala un errore.

Domande per verificare la tua comprensione

1. Quale ipotesi falsificabile guida il tuo prossimo ciclo di miglioramento?
2. Quale metrica e quale baseline useresti per la fase Check?
3. Quale soglia scritta prima ti farebbe standardizzare o fermare l’intervento?
4. Cosa documenteresti per rendere utile il ciclo successivo?