Sprechi 5 e 6: Cambio di Attività e Difetti

Ogni volta che cambi attività, paghi un costo.

La ricerca mostra costantemente che il cambio di contesto costa 15-25 minuti per tornare alla piena produttività. Non per iniziare a lavorare—per raggiungere la stessa profondità di concentrazione che avevi prima dell'interruzione.

Se cambi contesto 4 volte in un pomeriggio, potresti spendere più tempo a riorientarti che a lavorare effettivamente.

Nella produzione, questo spreco si chiama "trasporto" e "movimento"—spostamento non necessario di materiali o persone. Nel software, è lo spostamento non necessario dell'attenzione.

Fonti del cambio di attività:

• Troppo WIP: Destreggiarsi tra più progetti significa cambio costante
• Interruzioni: Messaggi Slack, qualcuno che ti tocca la spalla, "domande veloci"
• Riunioni: Ogni riunione è un cambio di contesto in uscita e in entrata
• Email/notifiche: Controllare costantemente frammenta l'attenzione
• Priorità poco chiare: Non sapere su cosa lavorare porta a oscillare

Il costo non è solo tempo—è qualità. Il lavoro superficiale produce risultati superficiali. Il lavoro profondo richiede concentrazione sostenuta. Il cambio di attività impedisce il lavoro profondo.

I difetti sono spreco per ragioni ovvie: richiedono rifacimento. Ma il costo reale è peggiore di quanto appaia.

I difetti trovati tardi costano esponenzialmente di più dei difetti trovati presto. Un bug individuato in sviluppo potrebbe richiedere 10 minuti per essere corretto. Lo stesso bug trovato in testing potrebbe richiedere un'ora (riproduzione, diagnosi, correzione, ri-test). Trovato in produzione, potrebbe richiedere giorni (indagine, comunicazione con il cliente, correzione d'emergenza, post-mortem).

I difetti generano difetti. Correggere un bug sotto pressione spesso introduce nuovi bug. Il codebase diventa un campo minato. Gli sviluppatori rallentano. La qualità scende a spirale.

I difetti distruggono la fiducia. Dopo abbastanza incidenti in produzione, ogni modifica richiede approvazione estesa, testing esteso, approvazione estesa. Il processo si gonfia per proteggersi dai difetti che il processo stesso crea.

Lo spreco nascosto: ispezione e testing. Se hai difetti, hai bisogno di QA esteso. Il QA è spreco necessario—non aggiunge valore, cattura solo lo spreco creato dai difetti. Costruisci la qualità, e hai bisogno di meno ispezione.

Per il cambio di attività:

Limiti WIP: L'intervento più diretto. Se puoi lavorare solo su una cosa alla volta, non puoi cambiare contesto. Finisci prima di iniziare.

Comunicazione raggruppata: Controlla email/Slack a intervalli definiti, non costantemente. Fai sapere alle persone quando sei disponibile e quando non lo sei.

Tempo senza riunioni: Designa blocchi per lavoro concentrato. Proteggili ferocemente.

Priorità più chiare: Se le persone non sanno su cosa lavorare, oscillano. Rendi le priorità esplicite e stabili.

Per i difetti:

Test-driven development: Scrivi i test prima. Costruisci la qualità dall'inizio, non ispezionala alla fine.

Pair programming: La revisione in tempo reale cattura gli errori prima che diventino bug.

Continuous integration: Trova i bug di integrazione immediatamente, quando il contesto è fresco e le correzioni sono economiche.

Ferma e correggi: Quando trovi un bug, correggilo ora. Non aggiungerlo a un backlog per farlo invecchiare. Il principio dell'andon cord di Toyota.

Postmortem senza colpe: Quando i bug sfuggono, capisci perché senza colpe. Correggi il sistema che ha permesso il bug, non solo il bug stesso.