看板 — Tabella di segnalazione
Kanban (看板) è giapponese. I caratteri si dividono in: 看 (kan), vedere, osservare, & 板 (ban): tavola, pannello, segnale. Insieme: una lavagna di segnali visivi.
La parola risale ai secoli prima del sistema di gestione. Ogni negozio in Giappone durante il periodo Edo aveva un kanban: una tavoletta di legno fuori che indicava cosa era in vendita dentro. Il segnale visivo era la pubblicità, l'indicatore di inventario e il segnale di richiesta di nuovo ordine tutto insieme.
Intuizione di Taiichi Ohno sul Supermercato
Negli anni '50, l'ingegnere Toyota Taiichi Ohno visitò i supermercati americani. Ciò che vide cambiò la storia della produzione.
In una tradizionale fabbrica, il modello push, la produzione funzionava secondo un calendario. Un forecast diceva "avremo bisogno di 500 unità il prossimo mese", quindi la fabbrica ne produsse 500 e li spostò su un ripiano. Se la domanda era sbagliata, il ripiano traboccava. Se la domanda superava il forecast, il ripiano era vuoto. In entrambi i casi, qualcuno aveva torto.
I supermercati funzionavano diversamente. I ripiani tenevano una quantità fissa di ogni articolo. Quando un cliente prendeva l'ultima scatola di marmellata, lo spazio vuoto era a sua volta il segnale di richiesta di nuovo ordine. Gli addetti allo stoccaggio non avevano bisogno di un manager che gli dicesse di riassestare: il ripiano glielo diceva. Questo è il modello pull: le richieste di fine linea segnalano la ricostituzione in alto.
Ohno portò questa intuizione a Toyota. La scheda fisica (kanban) attaccata a un carrello di pezzi divenne il segnale: "questo carrello è vuoto: prodotti di più". Nessun forecast necessario. Nessun pianificatore centrale. Il lavoro si tirò avanti da solo.
Push vs. Pull
La distinzione tra push e pull è la base di tutto ciò che segue.
Colonne come Stati
Una lavagna Kanban rende il lavoro visibile. Ogni pezzo di lavoro è una carta. Le carte si spostano da sinistra a destra attraverso colonne che rappresentano stati.
Le colonne classiche sono: Backlog → Selected → In Corso → Revisione → Fatto
Ma le colonne precise non importano. Ciò che conta è che ogni carta abbia esattamente uno stato corrente, e tale stato sia visibile a tutti coloro che lavorano in quel sistema.
Cos'è che una carta rappresenta
Una carta rappresenta un unità di lavoro che può essere completata indipendentemente. Non un progetto. Non un obiettivo. Una cosa specifica, limitata con una chiara definizione di fatto.
Buona carta: Ruotare le chiavi SSH sui server produttivi: fatto quando tutti i server mostrano la nuova chiave in authorized_keys e la vecchia chiave è rimossa.
Cattiva carta: Migliora la sicurezza. (Questo è un progetto, non una task. Dividilo.)
Limiti WIP
Nella colonna In Corso nell'immagine è mostrato un limite WIP: 3. Questo significa che non più di tre carte possono essere In Corso nello stesso tempo. Se vuoi estrarre una quarta carta, devi completarne una prima.
Questo sembra un vincolo. Lo è: di proposito. I limiti WIP ti costringono a completare ciò che hai iniziato prima di iniziare qualcosa di nuovo. Nei paragrafi successivi si parlerà del perché ha importanza.
Aggiungere Carte di Lavoro
L'abilità più difficile del Kanban non è disegnare la lavagna. È scolpire le carte. Troppo grande e una carta rimane In Corso per settimane, bloccando altri lavori. Troppo piccola e la lavagna si riempie di rumore.
I Settori Funzionano Bene
Ogni operazione multidisciplinare ha centri di lavoro funzionali: una panetteria ha pasticcere, pane, saporito e conto inferiore. Uno studio di prodotto ha design, contenuti, costruzione e operazioni. Un progetto di costruzione ha montaggio, idraulica, elettricità e finitura. Questi centri esistono per ottime ragioni: la specializzazione profonda richiede un proprietario focalizzato.
Il Kanban non dissolve queste divisioni. Rende i passaggi tra di esse visibili ed espliciti.
La scheda di trasferimento
Quando un'unità di lavoro passa da un centro di lavoro all'altro, ad esempio un asset di progettazione che richiede una copia scritta prima che l'assemblatore possa comporre la pagina, una scheda di trasferimento la segue. Il centro a valle vede comparire la scheda nella loro Pila. Loro la tirano quando hanno capacità. Nessun e-mail richiesto. Nessuna riunione per coordinare. La scheda è il segnale.
Cosa mostra il diagramma
Il ★ ticket inizia in Design (In Corso: asset visivi). Quando Design completa la loro parte, viene creata una scheda di trasferimento e il ★ ticket compare nella Pila del centro Build. Build lo tira. Poi Ops lo tira. Ogni centro ha il proprio tabellone. Ogni tabellone mostra solo il lavoro corrente di quel centro. Ma il ★ attraversa tutti loro e tutti possono vedere dove si trova.
Questo è l'insight del supermercato applicato alle organizzazioni: ogni centro di lavoro è un ripiano. Le schede vengono rifornite solo sui ripiani a valle quando il lavoro viene tirato e consumato a monte.
Progettazione di un Trasferimento
La scheda di trasferimento è il contratto tra i centri di lavoro. Dovrebbe contenere abbastanza contesto affinché il team ricevente possa agire senza una riunione.
Smetti di iniziare. Inizia a finire.
WIP sta per Work In Progress. Un limite di WIP è un tetto sul numero di schede che possono essere nella stessa colonna contemporaneamente.
Sembra una restrizione. E' proprio quello che vogliamo.
Perché gli limiti aiutano
Ogni volta che inizi un nuovo compito senza completare il precedente, paghi un tributo per la transizione di contesto. Il tuo cervello carica il contesto del nuovo compito e scarica parzialmente il vecchio. Quando torni al vecchio compito, lo ricarichi. Per il lavoro cognitivo, scrivere, bug fixing, progettazione, revisione, questo costo di ricarica viene misurato in ore, non secondi.
I limit WIP evitano l'accumulo di lavori non completati. Hanno anche un effetto più importante: portano alla luce i punti critici.
I punti critici diventano visibili
Se la colonna Revisione ha un limite WIP di 2 e sempre è a 2, è un segnale: la revisione è più lenta della produzione. Più lavoro viene completato in Corso di lavoro rispetto a quanto può essere consumato dalla Revisione. In assenza di un limite WIP, la tabella si riempie di carte 'completate ma in attesa di revisione' e il punto critico è invisibile. Con un limite WIP, la colonna Corso di lavoro non può accettare nuove carte e tutto il team vede la restrizione.
Questo non è un fallimento. È informazione. Il sistema ti sta dicendo di risolvere la Revisione, assumere, lavorare in coppia, ridurre la dimensione del lotto, piuttosto che spingere più lavoro senza senso.
Legge di Little (informalmente)
Tempo di lead (quanto tempo una carta richiede per passare dall'inizio al completamento) = Lavori in corso ÷ Throughput (carte completate per unità di tempo). Se vuoi tempi di lead più corti senza assumere, riduci il WIP. Meno cose in volo significa che ogni cosa si completa più rapidamente.
R = (W × C) + T
I limiti WIP proteggono tre variabili. L'efficienza consulente Brian Tracy le ha nominate nel 1986.
R = (W × C) + T
- R: Risultato: l'outcomes che vuoi
- W: Chiarezza del obiettivo: quanto precisamente sai cosa vuoi (0-10)
- C: Concentrazione: intensità di sforzo focalizzato (0-10)
- T: Tempo lavorato senza distrazioni (ore non interrotte)
Perché W e C moltiplicano
Chiarezza e concentrazione non sono indipendenti. Alta concentrazione su un obiettivo vago produce un movimento rapido nella direzione sbagliata. Chiarezza perfetta dell'obiettivo senza concentrazione produce nulla. Si interagiscono: per cui Tracy li ha scritti come un prodotto, non una somma. Un 9/10 su ciascuno dà R = 81 + T. Un 3/10 su ciascuno dà R = 9 + T. La differenza non è additiva.
Perché T aggiunge
Ogni ora senza distrazioni aggiunge linearmente al risultato. T non può moltiplicare W e C: può solo sovrapporsi. Questo spiega perché la prima mossa è sempre migliorare W e C, non lavorare più ore. Più T su un prodotto basso (W × C) è ancora un risultato povero.
Cosa fa il tabellone kanban a ciascuna variabile
- W: Una carta ben definita (titolo chiaro, criteri di accettazione misurabili, unico proprietario) aumenta W prima del lavoro. Le carte vaghe lo fanno automaticamente diminuire.
- C: I limiti WIP forzano la concentrazione. Una carta in Attiva significa attenzione completa su un unico problema. Tre carte in Attiva significano che C viene diviso in tre parti.
- T: Blocchi Pomodoro & protezione calendario creano le ore senza distrazioni che T misura. Il timer del tabellone non è un ornamento: segue T in tempo reale.
Tracy ha affermato che qualsiasi problema potesse essere risolto in 30 minuti quando W, C, & T erano ottimizzati. Il tabellone kanban è lo strumento per ottimizzare tutti e tre contemporaneamente.
Leggere il Tabellone
Esercitarsi a leggere i bottleneck dallo stato del tabellone.
Non Agile. Non Waterfall.
Agile è un metodo. Waterfall è un metodo. Kanban è un sistema.
I metodi prescrivono come lavorare. I sistemi descrivono cosa è vero sul lavoro. Kanban non ti dice di avere sprints di due settimane, riunioni quotidiane o retrospettive. Ti dice una cosa: rendi il lavoro visibile, limita il WIP & tira.
Il problema con i metodi
Agile funziona bene per i team che costruiscono prodotti iterativamente, software, principalmente. Waterfall funziona bene per i progetti con requisiti fissi e unknown noti, costruzione, produzione di hardware. Nessuno si mappa chiaramente su lavori interdisciplinari dove una task di progettazione e una task di esecuzione hanno tempi di ciclo completamente diversi e definizioni di 'fatto.'
Forzare un centro di progettazione e un centro di operazioni nello stesso ritmo di sprint è un errore di categoria. Un sprint di due settimane che funziona per la creazione di contenuti produce urgenza artificiale nel lavoro logistico. Un rituale di standup costruito per team collocati vicini crea overhead per solisti indipendenti.
Trovare un terreno comune sul lavoro da fare
L'approccio un: trovare il lavoro che deve essere fatto. Trovare le persone o i partner meglio posizionati per farlo. Non imponi un processo sopra a quello: lascia che il lavoro porti alla luce il proprio processo attraverso un sistema di visibilità condivisa.
Questo non è l'assenza di processo. È la giusta quantità di processo: abbastanza per coordinare, non abbastanza per creare overhead di coordinamento che supera il valore del lavoro.
Non costruisci ciò che puoi acquistare. Non acquistare ciò che puoi crescere.
Prima di creare qualsiasi card di lavoro, chiedi: dovrebbe esistere questo? Ogni pezzo di lavoro che costruisci, possiedi per sempre. Ogni SaaS a cui ti iscrivi, dipendi per sempre. Ogni dipendenza open-source che fai proprio, mantieni per sempre.
Il albero delle decisioni: Possiamo crescere questo? Un processo, una competenza, una relazione che produce la capacità in modo sostenibile, preferisci questo. Se il crescere non è fattibile: Possiamo comprare questo? Uno strumento off-the-shelf che risolve il 80% del problema senza lavoro personalizzato, preferisci questo. Se l'acquisto non è fattibile: Costruiscilo. E costruiscilo sapendo che ora lo possiedi.
La maggior parte delle organizzazioni inverte questo ordine. Costruiscono infrastrutture personalizzate per problemi che gli strumenti di commodity risolvono bene, poi si agitano per mantenere ciò che hanno costruito. Kanban lo rende visibile: ogni card nella tua Backlog è una cosa che hai scelto di costruire. La domanda onesta è se dovrebbe essere lì.
Build / Buy / Grow
Applica il framework delle decisioni.
Progetta un Tabellone
Raccogli le tessere. Progetterai un sistema Kanban per uno scenario cross-funzionale specifico.
Scenario
Una piccola azienda di produzione di prodotti è in rilancio del loro prodotto con un nuovo marchio. Il lavoro riguarda quattro centri:
- Design: nuovo logo, identità visiva, fotografie del prodotto, pagine di layout
- Content: nuove descrizioni del prodotto, copertina della pagina, annuncio via email
- Build: aggiornamento del sito web, nuovo flusso di checkout, redirect dai vecchi URL
- Ops: impostazioni aggiornate del processore di pagamento, briefing per il partner di consegna, riconfigurazione degli analytics
Il rilancio ha un termine ultimo: una fiera commerciale in 45 giorni in cui il nuovo marchio va in pubblico.
Solos Rimangono Silos
In quasi tutte le organizzazioni, il kanban esiste per rendere il lavoro visibile attraverso una gerarchia di gestione. I manager coordinano tra i silos. Il kanban riduce l'overhead di coordinamento.
Nel modello un, non ci sono manager. Ci sono solo soli. Un solo gestisce un'impresa indipendentemente: un designer solo, un costruttore solo, uno scrittore solo, un solo operazioni. Ogni solo è, di definizione, un silo. Non c'è alcogramma organizzativo che li colleghi. Nessuna relazione di reporting. Nessun manager per forzare la coordinazione.
Il kanban diventa la strato di coordinamento. Non riducendo i silos, i soli rimangono completamente indipendenti, ma rendendo le consegne tra loro visibili ed esplicite. Un solo non invia un'e-mail o programma una riunione per consegnare il lavoro. Mettono una carta su un tabella condivisa. Il solo ricevente la prende quando ha capacità.
Questo spiega perché il kanban si adatta meglio al modello un rispetto che agile o waterfall: non richiede alcun calendario condiviso, nessuna retrospettiva congiunta, nessun piano sincronizzato. Ogni solo stabilisce i propri limiti di lavoro in corso, il proprio tempo ciclo, la propria definizione di fatto. La coordinazione avviene a livello di carta, non a livello di processo.