Pensiero Sistemico

Un sistema è più di una collezione di parti. È costituito dalle parti più le loro interazioni. E spesso, le interazioni contano più delle parti stesse.

Considera un team di sviluppo software. Hai sviluppatori, designer, ingegneri QA, un product manager. Ogni individuo potrebbe essere eccellente. Ma se non comunicano bene, se i passaggi di consegne sono macchinosi, se gli incentivi sono disallineati—il team ha prestazioni inferiori nonostante il talento.

Il pensiero sistemico significa comprendere l'intero sistema prima di cercare di migliorare le parti. Significa chiedersi: Come interagiscono i pezzi? Quali cicli di feedback esistono? Quali comportamenti emergenti si manifestano?

La maggior parte delle disfunzioni organizzative deriva dall'ignorare il pensiero sistemico. Ogni dipartimento ottimizza per le proprie metriche mentre il risultato complessivo ne soffre. Le vendite chiudono contratti che il prodotto non può consegnare. L'ingegneria costruisce funzionalità che il marketing non può vendere. Tutti raggiungono i loro KPI mentre l'azienda è in difficoltà.

Ecco uno scenario comune: il team di sviluppo è il collo di bottiglia. Quindi il management decide di rendere gli sviluppatori più efficienti. Tracciano gli story point, misurano la velocity, riducono le riunioni. La produttività degli sviluppatori aumenta.

Ma la consegna non migliora. Perché?

Perché il collo di bottiglia non era mai stato realmente nello sviluppo. Era nel deployment—un processo manuale e soggetto a errori che solo una persona comprendeva. Accelerando lo sviluppo, hai solo creato un accumulo maggiore al deployment. Il lead time è aumentato anche se gli sviluppatori lavoravano più velocemente.

L'ottimizzazione locale migliora una parte del sistema. L'ottimizzazione globale migliora l'intero sistema. Non sono la stessa cosa—e l'ottimizzazione locale spesso danneggia le prestazioni globali.

Questa è l'intuizione di Goldratt dalla Theory of Constraints: migliorare qualsiasi cosa che non sia il vincolo è spreco. Se il deployment è il tuo vincolo, rendere lo sviluppo più veloce è teatro. Correggi prima il deployment.

Nelle organizzazioni software, ottimizzazioni locali comuni che danneggiano globalmente:

• Massimizzare l'utilizzo degli sviluppatori (distrugge lo slack, aumenta i tempi di attesa)
• Misurare la velocity individuale (incentiva il gaming, danneggia la collaborazione)
• Ottimizzare il tempo di build (irrilevante se i deploy avvengono solo mensilmente)

I sistemi contengono cicli di feedback—l'output di una parte diventa input per un'altra. Alcuni cicli sono di rinforzo (amplificanti), altri sono di bilanciamento (stabilizzanti).

Esempio di ciclo di rinforzo: gli sviluppatori tagliano gli angoli per rispettare le scadenze. Questo crea debito tecnico. Il debito tecnico rallenta lo sviluppo futuro. I team tagliano più angoli per rispettare la prossima scadenza. La spirale mortale accelera.

Esempio di ciclo di bilanciamento: un team adotta limiti WIP. Il lavoro si accumula. Le persone si mobilitano per aiutare a liberare l'accumulo. Il WIP scende. Il sistema si auto-stabilizza.

Il comportamento emergente è un comportamento a livello di sistema che non può essere previsto dalle sole parti. Un ingorgo stradale non è causato da nessuna singola auto—emerge da migliaia di piccole interazioni. Allo stesso modo, un'organizzazione disfunzionale potrebbe avere tutti individui eccellenti ma il sistema produce disfunzione.

Il pensiero Lean richiede di fare un passo indietro per vedere questi schemi. Non puoi correggere una spirale mortale di rinforzo formando gli individui. Devi cambiare le dinamiche del sistema—di solito cambiando incentivi, vincoli o meccanismi di feedback.