• Home
  • Blog
  • Come si parla di Kata di miglioramento

Come si parla di Kata di miglioramento

Girando per il nostro ufficio in una normale giornata di lavoro si possono sentire (o leggere su Slack) molte di queste frasi: "Dobbiamo fare una RCA". "Sai qual è la condizione target per questo processo?". "Penso che abbiamo bisogno di una nuova sfida per questo processo". Posso immaginare che non sappiate di cosa stiamo parlando. Continuate a leggere per imparare.

Postato il
29 giu 2020
Tempo di lettura
15 Minuti
Scritto da
Jeroen - Fondatore / CEO

Praticiamo il Kata di Miglioramento da un bel po' di tempo, ma siamo ancora alle prese con il significato dei vari termini e con la loro applicazione. Dopo aver letto questo articolo dovreste avere una visione chiara delle parti del Kata di miglioramento, del loro significato e di come applicarle.

Iniziamo!

Processo vs. Risultato

Prima di immergerci nei dettagli del linguaggio del Kata del miglioramento, dobbiamo iniziare a fare una distinzione tra processo e risultato. Questa è forse la parte più difficile del Kata del miglioramento. Siamo abituati a pensare a obiettivi e risultati e a ciò che vogliamo ottenere. Vogliamo raggiungere i nostri numeri di produzione. Siamo concentrati sul risultato. Con il Kata di miglioramento ci concentriamo sul processo che porta al risultato. Dobbiamo mettere in primo piano il processo e il risultato è l'esito del processo. Cerco sempre di spiegarlo in questo modo:

  • Non è possibile portare a termine un obiettivo o un risultato.

  • Ma si può portare a termine un processo.

Perché è difficile?

Questo cambiamento di mentalità è la parte più difficile del Kata del miglioramento. Fin dall'inizio ci è stato insegnato a pensare ai risultati e agli esiti. Dobbiamo fissare obiettivi audaci e raggiungere le stelle. Non è radicato nella nostra cultura pensare al processo. Dobbiamo quindi cambiare mentalità per imparare a fare questa distinzione e concentrarci sul processo.

Il miglioramento del lavoro quotidiano è più importante del lavoro quotidiano. Ma non può sostituirsi al lavoro quotidiano.

Prima di iniziare, una panoramica

Questa è una panoramica schematica del processo di Improvement Kata. In questo articolo tratterò le diverse parti, ma potete usare questa immagine come riferimento.

Target condition proces

Il vero nord: la nostra visione dell'azienda

Vogliamo essere un'azienda tranquilla. E crediamo che l'impegno per questi quattro aspetti nei nostri processi ci permetta di raggiungere questo obiettivo:

  • Flusso di singoli articoli, in sequenza e su richiesta.

  • Zero difetti.

  • 100% di valore aggiunto.

  • Sicurezza per le persone.

Esaminiamoli ulteriormente.

Flusso di singoli articoli, in sequenza e su richiesta

Questo è uno dei principi fondamentali del Kata del miglioramento. Prima di fare qualsiasi altra cosa, dobbiamo avvicinare un processo, qualsiasi processo, al flusso di un singolo elemento, in sequenza e su richiesta. Ma perché?

Vogliamo un processo stabile e prevedibile. Vogliamo un processo scalabile e senza molti sprechi. Per riuscirci, dobbiamo individuare i colli di bottiglia del processo. Il passaggio a un flusso a singolo elemento mostra questi colli di bottiglia il prima possibile. E in modo più chiaro. È necessario risolverli, altrimenti nulla potrà fluire attraverso il processo.

Se abbiamo un processo di flusso di un singolo elemento, in sequenza, non possiamo tagliare gli angoli e accelerare le cose per portarle a termine. Dobbiamo eliminare un collo di bottiglia nel processo prima di poter andare avanti. Finché non siamo lì, possiamo imbrogliare. Se si riesce a vedere chiaramente il collo di bottiglia di un processo, si può iniziare a risolverlo e a migliorare il processo che porta a risultati migliori.

Zero difetti

Ogni volta che un processo non funziona come definito, abbiamo un difetto. Quindi, un difetto si concentra sul processo, non sul risultato. Ogni difetto deve essere analizzato per trarne insegnamento.

Molti problemi equivalgono a un capo felice.

100% valore aggiunto

Tutto ciò che facciamo in un processo deve aggiungere valore al risultato finale del processo. Se nel nostro processo facciamo cose che non aggiungono valore, non dovremmo farle. Questo si chiama anche eliminare gli sprechi da un processo.

Molte discussioni sul concetto di "lean" si concentrano sull'eliminazione degli sprechi. Il presupposto è che l'eliminazione degli sprechi sia un obiettivo dell'essere lean, mentre l'eliminazione degli sprechi è in realtà un risultato del Kata del miglioramento. Non è un obiettivo a sé stante.

Sicurezza per le persone

Tutte le cose che facciamo devono rispettare questo principio. Quando impostiamo una sfida, una condizione obiettivo o la descrizione di un processo, dobbiamo sempre verificare che rientri in questo limite.

Le persone commettono errori. I sistemi che abbiamo in funzione dovrebbero aiutarci a prevenirli o, se si verificano, a ridurre le conseguenze di un errore. Gli errori dovrebbero essere sicuri. Non dovrebbero provocare eventi catastrofici. E se si verifica un evento catastrofico o meno, dobbiamo migliorare i sistemi.

Sicurezza per le persone significa anche che ognuno può essere se stesso sul lavoro. Dobbiamo essere in grado di parlare, dare feedback e condividere le conoscenze. È così che impariamo come persone e come organizzazione.

Stato attuale

Se parliamo della condizione attuale, parliamo del processo che vogliamo migliorare. In un mondo perfetto, questo processo dovrebbe avere una descrizione chiara. Questa descrizione dovrebbe dire come vorremmo che il processo funzionasse. La descrizione dovrebbe contenere:

  • Tutte le fasi del processo.

  • Il tempo che ogni fase può richiedere.

  • Quante persone lavorano su una fase.

  • Eventuali metriche di qualità di questa fase.

  • Quanto inventario è consentito per ogni fase.

  • Il tempo totale di ciclo del processo.

Può anche contenere una descrizione delle caratteristiche di questo processo. Si devono menzionare eventuali preoccupazioni relative alla sicurezza delle persone e, infine, si deve includere una metrica di risultato.

Per un nuovo processo, questa descrizione può essere fatta durante il percorso. Mentre lavoriamo per migliorare il processo, scopriamo come dovrebbe funzionare. Questo può e deve essere scritto, in modo da poter essere utilizzato come documentazione del processo. Inoltre, mentre cambiamo e miglioriamo il processo, questa documentazione deve essere aggiornata. Vedrete che più a lungo lavorate su un processo, più il processo si perfeziona.

Perché è difficile?

Per poter passare al flusso di un singolo elemento e non ritrovarsi con ottimizzazioni locali, dobbiamo puntare a un unico processo. Attenzione a non descrivere come processo a sé stante un processo che in realtà fa parte di un processo più ampio e quindi è un sottoprocesso a sé stante.

Quando abbiamo iniziato ad applicare il Kata del miglioramento, avevamo un processo di sviluppo, un processo di test e un processo di documentazione, traduzione e comunicazione. Ho avuto difficoltà a convincere lo sviluppo che dovevamo includere il processo di test come parte della pipeline di sviluppo totale. Perché migliorando il ciclo di sviluppo, ma non essendo in grado di testare e distribuire le storie, avevamo creato uno spreco.

Dobbiamo ottimizzare l'insieme.

Esempio

Utilizziamo un esempio per illustrare questo aspetto. Il nostro processo per fornire valore ai clienti è composto dai seguenti sottoprocessi per mettere online una funzionalità:

  • Decidere cosa costruire - 3 settimane

    • Raccogliere informazioni sulle richieste di funzionalità (su richiesta).

    • Classificare le richieste di funzionalità per ottenere una priorità (in sequenza).

    • Descrivere questa funzionalità e pianificarne lo sviluppo.

  • Sviluppare una storia - 3 giorni

    • Discutere con il proprietario del prodotto.

    • Definire i criteri di accettazione.

    • Progettare, costruire, rivedere il codice.

    • Riformulare il codice.

    • Testare con il team.

  • Testare e distribuire una storia - 3 ore

    • Costruire la storia in staging.

    • Eseguire i test di accettazione.

    • Testare una storia.

    • Mergere la storia.

    • Espandere in produzione.

  • Tradurre - 1 giorno

    • Creare un pacchetto di singoli elementi per questa storia per i traduttori.

    • Inviare il pacchetto ai traduttori.

    • I traduttori traducono le etichette per questa storia.

  • Documentare e comunicare - 3 giorni

    • Scrivere le note di rilascio.

    • Scrivere, aggiornare e pubblicare articoli di aiuto.

    • Comunicare con i clienti rilevanti.

Abbiamo molta documentazione per ogni fase che descrive la qualità da rispettare, il numero di storie che possono essere inserite in una determinata fase, il numero di iterazioni consentite e il numero di difetti ammessi in una storia. Questo sarebbe un articolo a sé stante.

L'aspetto più importante è che per ottimizzare l'insieme è necessario avere tutte le fasi di un processo e misurarle. Se non si procede in questo modo, l'ottimizzazione di una fase comporterà uno spreco in un'altra fase.

Metrica di risultato

La metrica di risultato descrive ciò che un processo produce. È il risultato del processo. Misuriamo la metrica di risultato di tanto in tanto per verificare se il processo è ancora sulla buona strada per fornire il risultato desiderato all'azienda. È ciò che le altre aziende utilizzano come obiettivi o target.

Perché è difficile?

Ciò che ci risulta difficile è fare una chiara distinzione tra risultati (metriche di risultato) e processo. E una volta definita una metrica di risultato, tutto d'un tratto sembra essere un obiettivo. Che dobbiamo raggiungere e che siamo delusi di non aver raggiunto. L'unico scopo della metrica di risultato è quello di poter misurare se ci si è avvicinati al punto in cui si vuole arrivare.

Esempio

Il risultato del nostro processo di sviluppo è che vogliamo rilasciare una funzionalità da 100 dollari ogni tre mesi per team. Riteniamo che la creazione di una funzionalità di questo tipo, che offra valore ai nostri clienti ogni mese, ci fornirà la crescita di cui l'azienda ha bisogno per diventare un'azienda tranquilla.

Sfida

La sfida descrive lo stato futuro del processo che si vuole raggiungere. La parte difficile è tenere a mente che stiamo parlando del processo, non del risultato. Dovete descrivere come vorreste che funzionasse il processo e non un obiettivo o un risultato. Una sfida può essere lanciata lontano, con una tempistica lunga, da sei settimane a un anno. Se sapete già come arrivarci, è troppo vicina. La sfida dà una direzione e sarà suddivisa in condizioni più piccole.

Il punto migliore per iniziare a definire la sfida è arrivare al flusso di un singolo articolo. Poi si dovrebbe puntare alla sequenza e l'ultima parte dovrebbe riguardare la domanda. Per arrivare al flusso di un singolo articolo e alla sequenza ci sono voluti due anni.

Perché è difficile?

Ancora una volta si tratta di pensare ai processi e non ai risultati. Per molte persone è difficile affrontare l'incertezza di non sapere come arrivarci.

Esempi

Quando abbiamo iniziato con il Kata di miglioramento, abbiamo avuto la sfida di passare a un flusso a singolo elemento per il rilascio di una storia. Quindi, quando una storia era pronta, doveva essere messa online.

Un altro esempio riguarda il sottoprocesso per le traduzioni. Abbiamo definito la sfida in questo modo:
Entro tre mesi arrivare a un flusso di singoli elementi per le traduzioni, con un tempo di ciclo di un giorno, senza spendere tempo per rispondere alle domande.

Condizione target

Una condizione obiettivo è il primo passo che vi avvicina alla vostra sfida e che è raggiungibile entro tre-sei settimane. È lo stato futuro del processo a cui stiamo puntando. La condizione obiettivo ci darà un senso di direzione per i nostri miglioramenti. Come? Misuriamo il nostro processo di lavoro mentre lavoriamo. Ogni volta che si verifica una deviazione dal processo descritto nella condizione target, dobbiamo esaminarla. La chiamiamo "analisi delle cause" (RCA). L'esecuzione delle RCA ci fornirà informazioni sul nostro collo di bottiglia.

Esempio

Per la sfida sulle traduzioni abbiamo definito questa prima condizione obiettivo:
Definire e misurare il tempo necessario per tradurre un singolo articolo in tutte le lingue. Vogliamo misurare per lingua.

Collo di bottiglia

A volte ci siamo riferiti a questo fenomeno come a un ostacolo. Ma la parola collo di bottiglia è molto più adatta a descrivere ciò che è. Un processo può avere un solo collo di bottiglia (ma molti ostacoli). Il collo di bottiglia è ciò che ci impedisce di raggiungere la condizione desiderata.

Se si osserva una clessidra, la parte più piccola è il collo di bottiglia. Aumentare le dimensioni della clessidra prima o dopo il collo di bottiglia non aumenta il flusso. Migliorare qualsiasi cosa che non sia il collo di bottiglia è uno spreco. Il collo di bottiglia impedisce all'articolo di fluire attraverso il processo senza interruzioni, oppure è la parte del processo con il rendimento più basso.

Solo migliorando il collo di bottiglia ci si avvicina alla condizione target. Risolviamo il collo di bottiglia con un ciclo PDCA (di cui parleremo più avanti).

Bottleneck

Perché è difficile?

La parte più difficile è definire il collo di bottiglia. Quando si inizia a migliorare e si prende la mano, si vedono molti aspetti che possono essere migliorati ma che non rappresentano il collo di bottiglia. È difficile resistere all'impulso di risolvere questi aspetti, soprattutto quando si tratta di piccole cose che si possono fare. Attenersi alla soluzione del collo di bottiglia è difficile e richiede una certa disciplina. D'altra parte, anche se la teoria dice che esiste un solo collo di bottiglia, risolvere qualcosa è sempre meglio che cercare il collo di bottiglia e non risolvere nulla. La realizzazione di un miglioramento vi porta a mettere in pratica i cicli RCA e PDCA.

Migliorare ciò che deve essere migliorato, non ciò che può essere migliorato.

Esempio

Per il nostro esempio di traduzione abbiamo definito il primo collo di bottiglia come segue:
Non sapere in cosa consiste un articolo. Non abbiamo definito un articolo e non sappiamo quali etichette e pagine da tradurre fanno parte di quell'articolo.

RCA

Come ho spiegato, RCA è l'acronimo di "analisi delle cause profonde". Ogni volta che c'è una deviazione dalla nostra condizione target, facciamo una RCA per trovare la causa principale. L'individuazione della causa principale indica il collo di bottiglia.

Perché è difficile?

Una deviazione dalla condizione target non si verifica mai in un momento opportuno, il più delle volte bisogna disturbare le persone per riunirsi e fare la RCA. Ci piace fare la RCA il più vicino possibile al momento in cui si verifica la deviazione, in modo che la scia di informazioni non si raffreddi. Quindi, fare la RCA è un compromesso tra il non lavorare nel flusso e il migliorare quotidianamente.

L'altro giorno ho avuto una discussione con Maarten, sviluppatore Front-End & UX Designer, su una funzionalità che ha richiesto molto tempo per essere messa online. La situazione si è svolta in questo modo:

Maarten: Finalmente abbiamo la storia che genera automaticamente le immagini per la documentazione online. Ci sono volute due RCA e molto lavoro per riuscirci.
Mi: Non preoccuparti che ci sia voluto più tempo del previsto, perché abbiamo imparato molto durante il processo.
Maarten: Sì, le RCA che abbiamo svolto hanno spostato la mia mentalità da "questo processo è instabile" a "perché questo processo è così instabile".

Con questo cambio di mentalità si può iniziare a guardare alla causa principale e pensare alle soluzioni. Con la mentalità precedente, invece, ci si infastidisce e ci si sente frustrati e non si migliora nulla.

Dobbiamo rallentare per andare più veloci.

PDCA

PDCA è l'acronimo di "Plan, Do, Check, Act". Si tratta di un processo per migliorare un collo di bottiglia a piccoli passi. La sfida consiste nel proporre un piccolo passo per migliorare il processo. Qualcosa che potete fare oggi stesso. Per alcune cose abbiamo ovviamente bisogno di più tempo. Ad esempio, se dobbiamo sviluppare o automatizzare qualcosa. Ma dovremmo sempre cercare di ridurre le cose. Possiamo prima fare un miglioramento a mano, per vedere se ci avvicina alla condizione desiderata? In tal caso, possiamo automatizzare? Un piccolo miglioramento sposterà il nostro campo visivo e aumenterà la nostra soglia di conoscenza. Dopo il miglioramento vediamo e conosciamo di più.

Un miglioramento troppo grande può portare allo spreco, perché non ci avvicina alla sfida. Ecco perché dobbiamo mantenere i miglioramenti piccoli. Possiamo fare solo un miglioramento per processo al giorno. Altrimenti non sappiamo se il miglioramento ha effettivamente migliorato qualcosa.

Perché è difficile?

Il più delle volte vediamo molte cose che possono essere migliorate. Vogliamo eliminarli, pensando di risolvere tutti i problemi e di poter continuare il nostro lavoro. Ma non sappiamo se tutti i problemi esistono ancora quando apportiamo qualche piccolo miglioramento.

Un'altra cosa difficile è non pensare troppo avanti e vedere tutti gli ostacoli sulla strada. Non si sa se quegli ostacoli si materializzeranno davvero quando saremo lì. E se quell'ostacolo è effettivamente il collo di bottiglia. Quindi, non lo sappiamo finché non arriviamo a destinazione.

Fare piccoli passi significa massimizzare il lavoro non fatto. Ci arriviamo quando ci arriviamo.

Campo visivo o soglia di conoscenza

Il campo visivo o soglia di conoscenza è ciò che attualmente conosciamo e possiamo vedere. In questo campo visivo ci sono molti miglioramenti possibili. La sfida ci darà una direzione per i nostri miglioramenti. Se facciamo un piccolo miglioramento, spostiamo il nostro campo visivo (linea blu) e aumentiamo la nostra soglia di conoscenza nella direzione della sfida. Dopo questo spostamento, sapremo di più e potremo vedere altri miglioramenti e passi da compiere per raggiungere la nostra sfida.

How far can you see?

Perché è difficile?

Ci rimproveriamo di non aver visto prima i miglioramenti. È possibile che qualcuno dica "perché non l'abbiamo fatto l'anno scorso?".

Devo citare il famoso calciatore olandese Cruijff:

Je gaat het pas zien als je het doorhebt.

Tradotto approssimativamente in:

Lo vedrete solo quando lo capirete.

Leggi di più dal nostro blog

Caroline

Caroline

12 dic 2024

Le nostre prestazioni di lavoro secondario spiegate

Sebbene lo stipendio sia un aspetto importante nella scelta di un lavoro, non dimentichiamo i vantaggi che ne derivano. I benefici secondari possono davvero addolcire l'affare! E noi crediamo di aver messo insieme un pacchetto fantastico. Scoprite tutti i nostri meravigliosi extra!

Leggi di più
Caroline

Caroline

8 apr 2025

Lavorare e prosperare!

Lavorare per Easy LMS è gratificante! Ovviamente diamo uno stipendio competitivo, indennità di viaggio e lavoro da casa e 25 giorni di vacanze pagate all'anno! Ma siamo anche fieri di offrirti dei vantaggi che ti aiutano a sentirti migliore e a fare il meglio. Il tuo benessere fisico e mentale è una priorità assoluta! Perché i nostri dipendenti sono la colonna vertebrale della nostra organizzazione.

Leggi di più
Caroline

Caroline

22 apr 2025

Il tuo primo mese

Quando hai un nuovo lavoro, non vedi l'ora di cominciare! Allo stesso tempo, però, c'è sempre una certa dose di nervosismo. Ti chiedi che cosa puoi aspettarti, cosa farai nel corso delle prime settimane e come potrai cominciare ad aggiungere davvero valore. Quest'ultimo punto è quello su cui ci concentriamo maggiormente. Il nostro chiaro programma di onboarding per i software engineer ti aiuterà a conoscere la nostra azienda, i tuoi colleghi e i tuoi task in pochissimo tempo! Scopri come lanceremo la tua carriera!

Leggi di più