Myślenie w systemach

Myślenie systemowe wiele lat temu wprowadziło mnie w myślenie systemowe , które zmieniło mój sposób postrzegania świata i ukształtowało niektóre moje spojrzenie na rozwiązywanie problemów. Ta mentalność wykracza poza typowe użycie „systemów” jako rzeczownika znanego inżynierom oprogramowania w kontekście programowania lub systemów rozproszonych.

Wcześniej w mojej karierze inżyniera skłoniło mnie to do modelowania powiązań danych wejściowych i wyjściowych mojego zespołu inżynierów jako części większego systemu, składającego się z organizacji inżynierskiej, funkcji inżynierskiej, działu ds. i ekonomia. Skłoniło mnie to do zastanowienia się nad prawdopodobnymi reakcjami na ograniczenia narzucone przez niedostatek, w których prawdopodobne były niepowodzenia międzyfunkcyjne lub w jaki sposób zachęty i wyniki wzmacniały zachowania w różnych funkcjach w organizacji rozwojowej.

Z systemów :

Jak się dowiedzieć, czy patrzysz na system, czy tylko na kilka rzeczy:

A) Czy potrafisz zidentyfikować części?

B) Czy części wpływają na siebie nawzajem?

C) Czy te części razem dają efekt, który różni się od efektu każdej części z osobna?

D) Czy efekt, zachowanie w czasie, utrzymuje się w różnych okolicznościach?

Ten sposób myślenia promuje swego rodzaju ciekawość wszystkich wydarzeń i okoliczności, których doświadczam w mojej pracy. To zmusza mnie do myślenia o skutkach pierwszego, drugiego, trzeciego rzędu i dalszych, decyzji lub zmian.

Na przykład często zdarza się, że inżynierowie natrafiają na „zły kod” i szybko dochodzą do wniosku, że zły kod został stworzony przez „złego inżyniera”. Myślący systemowo może jednak sondować dalej:

Dlaczego popełniono zły kod? (Zespół produkcyjny był pod presją, aby szybko wysłać)

Dlaczego zespół zdecydował się iść na łatwiznę, zamiast przesuwać harmonogram i utrzymywać standardy? (Zespół stracił wszystkich starszych inżynierów)

Dlaczego zespół stracił wszystkie swoje starsze lub doświadczone talenty? (Czuli brak zaufania, ponieważ ich próby odepchnięcia przeszłości zostały odrzucone)

Dlaczego organizacja nie słuchała starszych inżynierów ani im nie ufała? (Dyrektor odpowiedzialny za organizację nie wywiązał się ze zobowiązań na wiele kwartałów)

Dlaczego organizacja nie dostarczyła? (Zbyt duży dług techniczny i „zły kod” utrudnia zespołom iterację w bazie kodu)

I tak dalej. Te pytania mogą prowadzić do zaskakujących odpowiedzi, takich jak „ zakres organizacji jest nieatrakcyjny dla doświadczonych dyrektorów technicznych ”.

Niektórzy czytelnicy porównają ten proces myślowy do techniki dochodzeniowej 5 Whys , często używanej do analizy przyczyn źródłowych incydentów . RCA to praktyczne zastosowanie myślenia systemowego, które próbuje odkryć pojedynczą przyczynę zakłóceń w systemie. Znowu z książki:

Interakcje między tym, co myślę, że wiem o systemach dynamicznych, a moim doświadczeniem w prawdziwym świecie, nigdy nie przestają być upokarzające. Przypominają mi o trzech prawdach:

1) Wszystko, co wydaje nam się, że wiemy o świecie, jest modelem

2) Nasze modele mają zwykle silną zgodność ze światem

3) Nasze modele nie są w stanie w pełni przedstawić świata

Ten cytat pomaga wyjaśnić, dlaczego nawet starsi i doświadczeni inżynierowie mogą zostać zaskoczeni dużymi awariami systemu oprogramowania, wynikającymi z pierwotnych przyczyn, które na początku wydają się trywialne.

Poznanie i przyjęcie tego sposobu myślenia pomaga budować uznanie dla szerszego zestawu okoliczności, które wpływają na twoją pracę, i pomaga zrozumieć związek twojej pracy ze światem.