Sprechi 3 e 4: Passaggi di consegne e Attese

Ogni volta che il lavoro passa da una persona o un team a un altro, il contesto viene perso.

Il product manager scrive i requisiti. Conosce il problema dell'utente, i vincoli di business, i compromessi di priorità. Li passa a un designer.

Il designer legge i requisiti, fa domande di chiarimento (ad alcune delle quali il PM non può più rispondere perché il contesto è svanito), e crea i mockup. Li passa agli sviluppatori.

Gli sviluppatori leggono i requisiti e i mockup, fanno domande di chiarimento (ad alcune delle quali né il PM né il designer possono più rispondere), e costruiscono qualcosa. Lo passano al QA.

Il QA testa rispetto ai requisiti, trova problemi, e lo rimanda agli sviluppatori.

Ad ogni passaggio di consegne, le informazioni vengono perse. Quando la funzionalità raggiunge gli utenti, assomiglia appena a ciò che il PM aveva originariamente compreso sui bisogni degli utenti. E ogni passaggio ha richiesto tempo—a volte giorni di attesa nelle code.

I passaggi di consegne sono dove il contesto va a morire.

La maggior parte del lead time è tempo di attesa, non tempo di lavoro. Un'attività che richiede 2 ore di lavoro effettivo potrebbe avere 2 settimane di lead time. Dove va il resto?

• Tempo in coda: In attesa nei backlog per la prioritizzazione
• In attesa di revisione: PR che restano senza revisione
• In attesa di approvazione: Decisioni bloccate nel management
• In attesa di dipendenze: Bloccati su altri team
• In attesa di ambienti: Impossibile testare perché lo staging è rotto
• In attesa di informazioni: Domande senza risposta
• In attesa di pianificazione: Riunioni che non possono avvenire fino alla prossima settimana

Ogni attesa introduce ritardo e spesso richiede di rifamiliarizzare quando il lavoro riprende. Leggi il codice, comprendi il contesto, vieni distratto, e devi ricostruire quel contesto più tardi.

L'efficienza di flusso misura il tempo a valore aggiunto come percentuale del lead time. Nella maggior parte delle organizzazioni software, è del 5-15%. Ciò significa che l'85-95% del tempo, il lavoro è in attesa, non viene lavorato.

Team cross-funzionali: Riunisci tutte le competenze necessarie per fornire valore in un unico team. Product, design, sviluppo, testing—tutti insieme. I passaggi di consegne diventano conversazioni.

Specialisti generalizzanti: Persone che hanno competenze approfondite in un'area ma possono contribuire in altre. Quando il lavoro si accumula nelle revisioni, gli sviluppatori possono aiutare a revisionare. Meno code.

Pair e mob programming: Due o più persone che lavorano insieme eliminano i passaggi di consegne all'interno del lavoro. La revisione è integrata. Il trasferimento di conoscenza è continuo.

Collaborazione in tempo reale: Sostituisci i passaggi di consegne asincroni con collaborazione sincrona. Invece di scrivere una specifica, fai una conversazione. Invece di segnalare un bug, vai e mostralo allo sviluppatore.

Elimina le approvazioni: La maggior parte dei passaggi di approvazione non aggiunge valore—sono meccanismi di controllo da ambienti a bassa fiducia. Metti in discussione ogni approvazione: Che valore aggiunge? Potremmo ottenere lo stesso beneficio in un altro modo?

Automatizza i passaggi di consegne: Se il lavoro deve essere trasferito, automatizza la coda. Pipeline CI/CD che deployano automaticamente. Bot PR che notificano immediatamente i revisori. Integrazioni Slack che fanno emergere il lavoro bloccato.

L'obiettivo non è lavorare più velocemente—è aspettare meno. Attacca l'85%, non il 15%.