Systemdenken
Gelegentlich arbeite ich mit Kunden, die ein gro\u00dfes Problem haben, p\u00fcnktlich und in der vereinbarten Qualit\u00e4t zu liefern. Wenn ich beginne, die Ursachen zu untersuchen, stelle ich fest, dass das Produktteam sagt, das Problem sei, dass die Entwicklung nicht schnell genug ist und/oder zu viele Fehler produziert, und wenn ich mit der Entwicklung spreche, sagen sie mir, dass sie unvollst\u00e4ndige Spezifikationen vom Produkt erhalten, was bedeutet, dass sie mehr Zeit f\u00fcr die Entwicklung aufwenden m\u00fcssen, und manchmal \u00c4nderungen r\u00fcckg\u00e4ngig machen m\u00fcssen, weil sie nicht das waren, was der Kunde wollte. Es ist \u00fcblich, dass diese Organisationen sich als eine Reihe von Silos betrachten und glauben, dass die L\u00f6sung darin liegt, eines dieser Silos zu \u201ereparieren\u201c (z.B. die Entwicklung). Aber das ist eine reduktionistische Sicht des Problems und hilft selten, es zu l\u00f6sen. Um die Wurzel des Problems anzugehen, m\u00fcssen wir \u00fcberdenken, wie wir die Organisation verstehen, und hier kann Systemdenken helfen. Wie Einstein sagte: \u201eWir k\u00f6nnen Probleme nicht l\u00f6sen, indem wir auf die gleiche Weise denken, wie wir sie geschaffen haben.\u201c
Vor einigen Jahren bin ich auf das Buch Team Topologies (von Mathew Skelton und Manuel Pais) gesto\u00dfen, das \u00fcber Organisationen als Softwaresysteme spricht. Das Buch stellt Conways Gesetz vor, das besagt, dass Organisationen Systeme produzieren, die ihre Kommunikationsstrukturen widerspiegeln. Beispiele f\u00fcr dieses Gesetz in der Praxis k\u00f6nnen beobachtet werden, wenn wir ein Team aufteilen, das an derselben Komponente oder demselben Microservice arbeitet: Es ist \u00fcblich, dass sich diese Komponente am Ende aufspaltet, da die Kommunikationsstruktur zwischen den Teams sich teilt und die enge Zusammenarbeit, die f\u00fcr die Arbeit an derselben Komponente erforderlich ist, komplizierter wird. Das Buch spricht \u00fcber Conways umgekehrtes Man\u00f6ver, das uns einl\u00e4dt, unsere Organisation entsprechend der Architektur zu gestalten, die wir erreichen wollen. Dies stellt viele der organisatorischen Entscheidungen in Frage, die in Unternehmen getroffen werden, wo die Architektur nicht ber\u00fccksichtigt wird oder eine untergeordnete Rolle bei der Gestaltung der Organisation spielt. Und es l\u00e4dt uns ein, Menschen und die von ihnen produzierte Software als Teile desselben Systems zu betrachten.
Unternehmen sind Systeme, aber sie werden oft nicht als solche gesehen. Und obwohl wir uns des Systems, das unsere Organisation bildet, m\u00f6glicherweise nicht bewusst sind, ist dieses System real und es ist da. Manchmal ist die einzige visuelle Darstellung des Systems eines Unternehmens ein traditionelles Organigramm, aber das ist eine sehr begrenzte Sicht, die nur die Personen, Teams und Berichtslinien zeigt. Es spiegelt weder den Informationsfluss noch die dynamischen Verbindungen noch die Kultur noch die realen und komplexen Beziehungen wider, die sich \u00fcber das gesamte Organigramm erstrecken.
Linearit\u00e4t und Nichtlinearit\u00e4t
Wir sind es gewohnt, linear zu denken: wenn X, dann Y. Systeme k\u00f6nnen jedoch nicht auf diese Weise verstanden werden. Die Anzahl der Komponenten und Beziehungen zwischen ihnen w\u00e4chst exponentiell, und Systeme werden nichtlinear. Ich f\u00fchre st\u00e4ndig Gespr\u00e4che, in denen Menschen versuchen, Probleme auf \u00fcbervereinfachte Weise anzugehen. Zum Beispiel fragte mich ein Manager vor einigen Monaten bei einem Gespr\u00e4ch \u00fcber die Notwendigkeit, in die Modernisierung seiner Cloud-Infrastruktur zu investieren, nach dem erwarteten ROI \u2013 in Bezug darauf, wie viele Stunden pro Woche jeder Entwickler im Verh\u00e4ltnis zu den Kosten der Infrastruktur-Modernisierung einsparen w\u00fcrde. Er wollte dies wissen, um zu entscheiden, ob er die Investition genehmigt oder nicht. W\u00e4hrend wir die Einsparungen an Entwicklerstunden sch\u00e4tzen k\u00f6nnen, l\u00e4sst die Berechnung des ROI auf diese Weise und das Treffen einer Go/No-Go-Entscheidung viele andere wichtige Aspekte au\u00dfer Acht. Wenn wir in Systemen denken und daran arbeiten, die Auswirkungen einer veralteten Infrastruktur zu identifizieren, er\u00f6ffnen sich neue Perspektiven, in denen wir sehen k\u00f6nnen, dass dies nicht nur die Produktivit\u00e4t beeinflusst, sondern auch die Menschen, den Betrieb und die Kunden. In diesem Diagramm kann dies als Beispiel deutlich gesehen werden:
Wenn wir in Systemen denken, werden wir uns der verschiedenen Teile bewusst und wie sie die Ergebnisse des Systems beeinflussen. Aber je tiefer wir in das System eintauchen, desto mehr werden wir uns bewusst, wie viele Variablen es gibt und wie die Suche nach der richtigen Entscheidung immer ferner r\u00fcckt. Das Paradigma \u00e4ndert sich, und statt nach der endg\u00fcltigen Entscheidung zu suchen, experimentieren wir, sammeln Feedback und justieren die Richtung nach. Wir lernen. Agile Methoden funktionieren auf diese Weise und erkennen die Unm\u00f6glichkeit an, ein Projekt zu entwickeln, das vollst\u00e4ndig zu Beginn konzipiert und geplant wird, um auf die komplexen Bed\u00fcrfnisse eines Kunden ad\u00e4quat zu reagieren. Startups funktionieren so: Statt Fabriken werden sie als Motoren f\u00fcr Experimentation und Lernen konzipiert. Facebooks Motto war \u201eMove fast and break things\u201c, was als Anerkennung gesehen werden kann, dass die Welt ein komplexes System ist, und um die richtige L\u00f6sung zu finden, ist es am besten zu experimentieren, keine Angst vor dem Scheitern zu haben und empirisch zu lernen.
Systemdenken erfordert einen Mentalit\u00e4tswandel, es erfordert, einen reduktionistischen Ansatz hinter sich zu lassen, bei dem wir, wenn wir X tun, Y bekommen. Es erfordert, die verschiedenen Teile eines Problems und die Beziehungen zwischen ihnen zu identifizieren. Es erfordert, die verschiedenen Teile zu identifizieren, die ein Problem beeinflussen, und die Beziehungen zwischen ihnen. Es erfordert eine Ursachenanalyse durchzuf\u00fchren, nicht beim Symptom stehen zu bleiben, zu akzeptieren, dass wir oft nicht genug Informationen haben, um eine Entscheidung zu treffen, und dass wir dann experimentieren, lernen und die Entscheidung neu bewerten m\u00fcssen. Das Werkzeug f\u00fcr Systemdenken ist die Modellierung, die Darstellung der Teile, der Beziehungen, des Ganzen und der Ergebnisse. Dies kann mit einem Offline- oder Online-Whiteboard (z.B. Miro) erfolgen, wie im obigen Diagramm gezeigt.
Obwohl die Verwendung von Systemdenken in der Softwareindustrie noch nicht weit verbreitet ist, glaube ich, dass es nur eine Frage der Zeit ist, bis dies geschieht. Wir sehen st\u00e4ndig, wie die klassischere Mentalit\u00e4t und Vision zur Bew\u00e4ltigung von Problemen an der Realit\u00e4t scheitert. Mit Systemdenken zu beginnen ist nicht kompliziert, vielleicht gibt es ein Problem, das Ihnen im Kopf herumgeht, und f\u00fcr das Systemdenken Ihnen helfen kann, Fortschritte zu machen.
Referenzen
Ich arbeite derzeit daran, Unternehmen und Technologieteams zu helfen, ihr Potenzial besser zu nutzen. Ich helfe ihnen, sich ihrer Ineffizienzen bewusst zu werden und daran zu arbeiten, wie sie konkrete Ma\u00dfnahmen zur Verbesserung in ihrem Kontext ergreifen k\u00f6nnen, und das auf kontinuierlicher Basis. Wenn Sie das Gef\u00fchl haben, dass in Ihrem Unternehmen Verbesserungspotenzial besteht, aber der Alltag Sie auffrisst, k\u00f6nnen wir gemeinsam nach L\u00f6sungen suchen. Buchen Sie einen Termin hier.