Pensare per sistemi

Thinking in Systems mi ha introdotto al pensiero sistemico molti anni fa, che ha cambiato il modo in cui vedevo il mondo e ha modellato alcune delle mie prospettive sulla risoluzione dei problemi. Questa mentalità va oltre l'uso tipico di "sistemi" come sostantivo familiare agli ingegneri del software in contesti di programmazione o di sistemi distribuiti.

All'inizio della mia carriera di ingegnere, questo mi ha spinto a modellare la connessione di input e output del mio team di ingegneri come parte di un sistema più ampio, composto da un'organizzazione di ingegneri, una funzione di ingegneria, una divisione di sviluppo interfunzionale, un'azienda , e un'economia. Mi ha fatto pensare alle probabili reazioni ai vincoli imposti dalla scarsità, dove era probabile che si verificassero fallimenti interfunzionali o come incentivi e risultati rafforzassero i comportamenti tra le funzioni nell'organizzazione di sviluppo.

Da Sistemi :

Come sapere se stai guardando un sistema o solo un mucchio di cose:

A) Riesci a identificare le parti?

B) Le parti si influenzano a vicenda?

C) Le parti insieme producono un effetto diverso dall'effetto di ciascuna parte singolarmente?

D) L'effetto, il comportamento nel tempo, persiste in una varietà di circostanze?

Questa mentalità promuove una sorta di curiosità su tutti gli eventi e le circostanze che vivo nel mio lavoro. Mi spinge a pensare agli effetti di primo, secondo, terzo ordine, e oltre, delle decisioni o dei cambiamenti.

Ad esempio, capita spesso che gli ingegneri si imbattano in "cattivo codice" e concludano frettolosamente che il codice errato è stato prodotto da un "cattivo ingegnere". Un pensatore di sistemi, tuttavia, potrebbe indagare ulteriormente:

Perché è stato eseguito il commit di codice errato? (Il team di produzione era sotto pressione per spedire rapidamente)

Perché il team ha deciso di prendere scorciatoie piuttosto che tornare indietro sulla linea temporale e mantenere gli standard? (Il team ha perso tutti i suoi ingegneri senior)

Perché la squadra ha perso tutto il suo talento senior o esperto? (Hanno sentito una mancanza di fiducia perché i loro tentativi di respingere in passato sono stati respinti)

Perché l'organizzazione non ha ascoltato o si è fidata dei suoi ingegneri senior? (Il direttore responsabile dell'organizzazione non ha rispettato gli impegni per più trimestri)

Perché l'organizzazione non è riuscita a consegnare? (Troppo debito tecnico e "cattivo codice" rendono difficile per i team l'iterazione nella base di codice)

E così via. Queste domande possono portare a risposte sorprendenti, come " l'ambito dell'organizzazione non è attraente per direttori tecnici esperti ".

Alcuni lettori paragoneranno questo processo di pensiero alla tecnica di indagine 5 Whys , spesso utilizzata per l'analisi della causa principale dell'incidente . RCA è un'applicazione pratica del pensiero sistemico che cerca di scoprire una singola causa di disturbo in un sistema. Ancora, dal libro:

Le interazioni tra ciò che penso di sapere sui sistemi dinamici e la mia esperienza del mondo reale non mancano mai di essere umilianti. Continuano a ricordarmi tre verità:

1) Tutto ciò che pensiamo di sapere sul mondo è un modello

2) I nostri modelli hanno solitamente una forte congruenza con il mondo

3) I nostri modelli non riescono a rappresentare pienamente il mondo

Questa citazione aiuta a spiegare perché anche gli ingegneri senior ed esperti possono essere colti alla sprovvista da grandi guasti del sistema software, derivanti da cause alla radice che sembrano banali all'inizio.

Conoscere e adottare questa mentalità aiuta a costruire un apprezzamento per l'insieme più ampio di circostanze che influiscono sul tuo lavoro e ti aiuta a capire la connessione del tuo lavoro con il mondo.