Denken in Systemen

„Thinking in Systems“ führte mich vor vielen Jahren in das Systemdenken ein, was meine Sicht auf die Welt veränderte und einige meiner Sichtweisen auf die Problemlösung prägte. Diese Mentalität geht über die typische Verwendung von „Systemen“ als Substantiv hinaus, das Softwareentwicklern im Zusammenhang mit der Programmierung oder verteilten Systemen vertraut ist.

Zu Beginn meiner Karriere als Ingenieur veranlasste mich dies dazu, die Verknüpfung der Inputs und Outputs meines Engineering-Teams als Teil eines größeren Systems zu modellieren, das aus einer Engineering-Organisation, einer Engineering-Funktion, einer funktionsübergreifenden Entwicklungsabteilung und einem Unternehmen bestand , und eine Wirtschaft. Es brachte mich dazu, über die wahrscheinlichen Reaktionen auf durch Knappheit auferlegte Einschränkungen nachzudenken, wo es wahrscheinlich zu funktionsübergreifenden Ausfällen kam oder wie Anreize und Ergebnisse das Verhalten in allen Funktionen der Entwicklungsorganisation verstärkten.

Von Systems :

So erkennen Sie, ob es sich um ein System oder nur um eine Menge Dinge handelt:

A) Können Sie Teile identifizieren?

B) Beeinflussen sich die Teile gegenseitig?

C) Erzeugen die Teile zusammen eine Wirkung, die sich von der Wirkung jedes Teils für sich unterscheidet?

D) Hält der Effekt, das Verhalten über die Zeit, unter verschiedenen Umständen an?

Diese Denkweise fördert eine Art Neugier auf alle Ereignisse und Umstände, die ich in meiner Arbeit erlebe. Es bringt mich dazu, über die Auswirkungen erster, zweiter, dritter Ordnung und darüber hinaus von Entscheidungen oder Veränderungen nachzudenken.

Beispielsweise kommt es häufig vor, dass Ingenieure auf „schlechten Code“ stoßen und voreilig zu dem Schluss kommen, dass der schlechte Code von einem „schlechten Ingenieur“ erstellt wurde. Ein Systemdenker könnte jedoch weiter nachforschen:

Warum wurde fehlerhafter Code übernommen? (Das Produktionsteam stand unter dem Druck, schnell zu liefern)

Warum hat sich das Team entschieden, Abstriche zu machen, anstatt den Zeitplan zu verschieben und Standards aufrechtzuerhalten? (Das Team hat alle seine leitenden Ingenieure verloren)

Warum hat das Team alle hochrangigen oder erfahrenen Talente verloren? (Sie verspürten einen Mangel an Vertrauen, weil ihre Versuche, in der Vergangenheit zurückzudrängen, überstimmt wurden.)

Warum hörte die Organisation ihren leitenden Ingenieuren nicht zu und vertraute ihnen nicht? (Der für die Organisation verantwortliche Direktor ist seinen Verpflichtungen über mehrere Quartale hinweg nicht nachgekommen.)

Warum hat die Organisation ihre Leistungen nicht erbracht? (Zu viele technische Schulden und „schlechter Code“ erschweren es den Teams, in der Codebasis zu iterieren.)

Usw. Diese Fragen können zu überraschenden Antworten führen, wie zum Beispiel „ Der Umfang der Organisation ist für erfahrene technische Leiter unattraktiv “.

Einige Leser werden diesen Denkprozess mit der 5-Warum- Untersuchungstechnik vergleichen, die oft für die Ursachenanalyse von Vorfällen verwendet wird . RCA ist eine praktische Anwendung des Systemdenkens, die versucht, eine einzelne Störungsursache in einem System aufzudecken. Nochmals aus dem Buch:

Die Wechselwirkungen zwischen dem, was ich über dynamische Systeme zu wissen glaube, und meinen Erfahrungen in der realen Welt sind immer wieder beeindruckend. Sie erinnern mich immer wieder an drei Wahrheiten:

1) Alles, was wir über die Welt zu wissen glauben, ist ein Modell

2) Unsere Modelle haben normalerweise eine starke Übereinstimmung mit der Welt

3) Unsere Modelle können die Welt nicht vollständig abbilden

Dieses Zitat erklärt, warum selbst hochrangige und erfahrene Ingenieure von großen Softwaresystemausfällen überrascht sein können, deren Ursache zunächst trivial erscheint.

Das Kennenlernen und Annehmen dieser Denkweise trägt dazu bei, eine Wertschätzung für die größeren Umstände zu entwickeln, die sich auf Ihre Arbeit auswirken, und hilft Ihnen, die Verbindung Ihrer Arbeit mit der Welt zu verstehen.