Wir brauchen zuerst das Problem, nicht die Lösung

Wer in der Produktentwicklung arbeitet, kennt die Herausforderung, dass in Besprechungen mit Stakeholdern idie Diskussion schnell in Richtung Lösung abrutscht. Das ist verständlich, denn Menschen wollen schnell das Problem lösen. Doch zu früh in die Lösung springen ist gefählrich, verstehen wir häufig nicht sauber genug, welches Problem wir eigentlich lösen wollen.

Das Thema ist nicht neu. Im Requirements Engineering und im Systems Engineering gehört es seit Langem zum Grundverständnis. Trotzdem ist es in der Praxis nach wie vor erstaunlich selten wirklich verankert. Gerade außerhalb der engeren Systems-Engineering-Blase wird das Problemverständnis oft eher als kurzer Pflichtteil betrachtet (oder übersprungen), bevor „endlich etwas Konkretes“ passiert. Dabei entscheidet sich genau an dieser Stelle häufig, ob ein Entwicklungsvorhaben später klar und wirtschaftlich läuft oder ob unnötige Komplexität und Reibung entstehen.

Das Problem mit der Lösung

Der Drang zur Lösung ist ein Ausdruck von Handlungsorientierung. Schwierig wird es dann, wenn die Lösungsdiskussion das Problemverständnis verdrängt. Dann wird nicht mehr offen untersucht, worin das eigentliche Anliegen besteht, sondern es wird implizit bereits eine Richtung vorgegeben.

Das zeigt sich oft an der Sprache. Aussagen wie „wir brauchen einen Kompressor“, „wir müssen die Schnittstelle erweitern“ oder „wir sollten einen zusätzlichen Review-Schritt einführen“ klingen zunächst plausibel und professionell. In Wirklichkeit beschreiben sie aber meist keine Probleme, sondern bereits vermutete Antworten. Damit wird der Lösungsraum früh verengt, bevor überhaupt geklärt ist, worin die Ursache des Problems liegt. Oder schlimmer, es werden Symptome therapiert, während das eigentliche Problem ungelöst bleibt.

In der Praxis führt das oft dazu, dass nicht die beste Lösung gefunden wird, sondern die erstbeste. Doch eine frühe, schlecht verstandene Lösung kann langfristig hohe Kosten erzeugen. Sie kann Architektur unnötig verkomplizieren, Teams zusätzlich koordinationsintensiv machen oder bestehende Schwächen mit neuen Artefakten überdecken.

Lösungsdenken führt zur erstbesten, nicht zur besten Lösung

Besonders in komplexen Entwicklungsumgebungen ist das problematisch. Wenn mehrere Disziplinen zusammenarbeiten, wenn Lieferanten beteiligt sind oder wenn ein Produkt sowohl physische als auch digitale Anteile hat, werden Fehlentscheidungen früh teuer. Eine unpräzise Problemformulierung bleibt dann nicht lokal. Sie wandert durch Spezifikationen, Modelle, Schnittstellen und Prozesse und verfestigt sich mit jeder weiteren Konkretisierung.

Ein zeitloses Beispiel von Joel Spolsky

Dass dieses Problem nicht neu ist, zeigt ein älterer, aber nach wie vor lesenswerter Text von Joel Spolsky von 2000: Painless Functional Specifications – Part 1: Why Bother? Joel beschreibt dort sehr anschaulich, warum Teams ohne saubere funktionale Beschreibung häufig direkt in die Umsetzung springen und sich damit unnötig früh auf eine konkrete technische Lösung festlegen. Sein Punkt ist dabei weniger „mehr Dokumentation“ als vielmehr „bessere Problemklärung“. Erst wenn klar beschrieben ist, was ein System aus Sicht seiner Nutzung leisten soll, entsteht überhaupt die Möglichkeit, zwischen mehreren Lösungen sinnvoll abzuwägen.

Das ist auch heute wichtiger denn je. In vielen Organisationen ist der Reflex zur direkten Lösung sogar stärker geworden. Agile Arbeitsweisen, schnelle Iteration und hoher Druck führen zu der Versuchung, die Problemanalyse zu überspringen. Wenn Analyse allerdings bedeutet, das Problem sauber zu verstehen, dann ist sie ein Mittel zur Risikoreduktion.

Ein klassisches Missverständnis besteht darin, dass frühe Problemanalyse als „langsam“ wahrgenommen wird, während frühe Lösung als „schnell“ gilt. In Wirklichkeit ist es oft genau andersherum. Solange wir uns noch im Denk- und Sprachraum bewegen, sind Änderungen billig. Sobald eine Idee konkret in die Umsetzung geht, steigen die Änderungskosten deutlich.

Systems Thinking als Gegenmittel

An dieser Stelle kommt Systems Thinking ins Spiel. Systems Thinking ist keine Spezialtechnik für Methodik-Fans, sondern eine sehr praktische Denkhaltung. Es hilft dabei, eine Situation zunächst als Zusammenhang zu betrachten, bevor einzelne Maßnahmen diskutiert werden. Genau darin liegt sein Wert.

Ein guter systemischer Blick fragt nicht sofort, welche Lösung implementiert werden soll. Er fragt zunächst, welche Akteure betroffen sind, welche Wechselwirkungen bestehen, wo Systemgrenzen verlaufen und welche Ursachen und Wirkungen voneinander zu unterscheiden sind. Das klingt abstrakt, ist aber in der Praxis oft genau der Unterschied zwischen oberflächlicher Symptombehandlung und belastbarer Problembearbeitung.

Ein aktueller Beitrag auf IO+ bringt das gut auf den Punkt: Systematic Thinkers seien diejenigen, die in der Lage sind, Komplexität zu strukturieren, Wechselwirkungen sichtbar zu machen und technische Herausforderungen nicht vorschnell auf isolierte Maßnahmen zu reduzieren. Genau diese Fähigkeit wird in Entwicklungsorganisationen immer wichtiger, weil Produkte, Teams und Abhängigkeiten stetig komplexer werden.

In diesem Sinn ist Systems Thinking auch kein Gegensatz zu Pragmatismus. Es ist vielmehr eine Voraussetzung für sinnvollen Pragmatismus. Wer nicht sauber zwischen Problemraum und Lösungsraum unterscheidet, wird zwar schnell aktiv, aber nicht zwangsläufig wirksam.

Needs und Requirements sind nicht dasselbe

Im Requirements Engineering gibt es für diese Unterscheidung eine gut etablierte Begrifflichkeit. Der INCOSE Guide for Writing Requirements unterscheidet zwischen Needs und Requirements. Diese Unterscheidung ist keineswegs nur akademisch.

Ein Need beschreibt den Bedarf oder das Anliegen aus Sicht eines Stakeholders. Der Blick richtet sich nach außen: auf Nutzung, Betrieb, Wertbeitrag oder Einschränkungen aus dem Umfeld. Ein Requirement richtet sich dagegen stärker auf das System und beschreibt, was dieses System leisten oder einhalten soll. Damit bewegt man sich bereits näher an der Lösung. INCOSE formuliert diese Beziehung explizit: Requirements werden aus Needs und weiteren Quellen abgeleitet.

Das ist ein wichtiger Punkt, weil in vielen Projekten genau dieser Zwischenschritt übersprungen wird. Dann werden Anforderungen formuliert, obwohl der zugrunde liegende Bedarf noch unscharf ist. Das Resultat sind häufig sehr konkrete Sätze, die zwar technisch eindeutig wirken, aber das eigentliche Problem nur unvollständig repräsentieren.

Ein einfaches Beispiel macht den Unterschied deutlich. Die Aussage „Das System soll einen PDF-Export bereitstellen“ ist eine typische Requirement-Formulierung. Sie ist konkret, aber bereits stark lösungsorientiert. Dahinter könnte aber ein ganz anderes Need stehen, etwa: „Nutzer müssen Ergebnisse außerhalb des Systems nachvollziehbar und revisionssicher weitergeben können.“ Erst aus einer solchen Beschreibung lässt sich begründet ableiten, ob ein PDF-Export tatsächlich die richtige Antwort ist oder ob eine andere Form der Bereitstellung sinnvoller wäre.

Diese saubere Trennung ist deshalb so wertvoll, weil sie den Lösungsraum zunächst offen hält. Sie verhindert nicht, dass man zu konkreten Anforderungen kommt. Sie sorgt lediglich dafür, dass diese Anforderungen besser begründet und stabiler sind.

Black Box vor Glass Box

Ein sehr nützliches Denkmodell aus dem Systems Engineering ist in diesem Zusammenhang die Unterscheidung zwischen Black Box und Glass Box. Auch sie hilft dabei, Problem und Lösung sauber auseinanderzuhalten.

Die Black-Box-Sicht betrachtet ein System zunächst von außen. Im Mittelpunkt stehen dabei nicht die inneren Bestandteile oder die technische Realisierung, sondern die Interaktionen mit der Umgebung. Welche Eingänge gibt es? Welche Ausgänge? Sind Akteure oder Nachbarsysteme relevant? Welche Informationen, Energien, Materialien oder Signale überqueren die Systemgrenze?

Diese Sicht ist deshalb so wertvoll, weil sie die Lösung zunächst bewusst ausblendet. Die Frage lautet nicht: „Wie baut das System das?“ Sondern: „Was muss das System in seinem Kontext leisten?“ Genau das ist eine präzise Form der Problembeschreibung.

Erst danach lohnt sich der Schritt in die Glass Box. Dort geht es um die innere Struktur, also um Zerlegung, Komponenten, Verantwortlichkeiten, Schnittstellen innerhalb des Systems und letztlich um Architektur und Implementierung. Dieser Schritt ist notwendig, aber er ist methodisch stärker, wenn er auf einer sauberen Black-Box-Beschreibung aufsetzt.

In vielen Entwicklungsprojekten passiert leider zu oft das Gegenteil. Teams diskutieren früh über Komponenten, Module, Softwareanteile, Elektronik oder Mechanik, obwohl noch gar nicht ausreichend geklärt ist, welche Systemwirkung im Kontext eigentlich stabil benötigt wird. Dann wollen sie sehr präzise über die innere Struktur sprechen, während die äußere Aufgabenstellung noch unscharf ist. Das erzeugt oft Architekturarbeit mit schwacher Grundlage.

Ein praktischer Einstieg: Das Kontextdiagramm

Die Frage ist natürlich, wie man dieses Denken im Alltag konkret anwendet. Eine sehr praktische Antwort darauf ist: mit dem Systemkontext beginnen.

Gerade wenn Stakeholder wenig Erfahrung mit Requirements Engineering oder Systems Engineering haben, ist ein Kontextdiagramm oft der zugänglichste Einstieg. Es zwingt nicht sofort zu sauber formulierten Anforderungen, sondern zunächst zu einer gemeinsamen Sicht auf das System und seine Umgebung.

Ein Kontextdiagramm hilft dabei, das Gespräch auf Beziehungen und Interaktionen zu lenken. Wer interagiert mit dem System? Welche Informationen oder Leistungen werden ausgetauscht? Wo verläuft die Systemgrenze? Welche externen Abhängigkeiten oder Randbedingungen sind relevant? Solche Fragen führen fast automatisch näher an das eigentliche Problem heran.

Das ist in Workshops besonders hilfreich. Denn offene Fragen nach „Anforderungen“ erzeugen bei vielen Stakeholdern sofort lösungsorientierte Antworten. Ein gemeinsamer Blick auf ein Systembild führt dagegen häufig zu präziseren Beobachtungen. Dann kommen Aussagen wie: „Diese Information kommt eigentlich vom Zulieferer“, „hier entsteht das Missverständnis“, „das Problem liegt vor diesem Schritt“ oder „wir reden die ganze Zeit über das falsche System“. Solche Einsichten sind für die spätere Lösungsentwicklung deutlich wertvoller als vorschnelle Funktionswünsche oder Lösungstechnologien.

Wenn Stakeholder in Lösungen abrutschen

Natürlich wird man auch mit einem guten Einstieg nicht verhindern, dass Stakeholder immer wieder in Richtung Lösung denken. Das ist normal und auch nicht grundsätzlich falsch. Wichtig ist nur, dass man diese Beiträge methodisch wieder zurück in den Problemraum übersetzen kann.

Dabei hilft oft eine sehr einfache Moderationstechnik. Wenn jemand eine Lösung formuliert, muss man diese nicht sofort abblocken. Stattdessen lohnt es sich, sie in eine Frage nach der Systemwirkung oder der Schnittstelle zurückzuübersetzen. Wenn jemand etwa sagt: „Dann brauchen wir eben ein zusätzliches Dashboard“, dann ist die interessante Anschlussfrage nicht, wie dieses Dashboard aussehen soll, sondern welches Informationsproblem damit eigentlich adressiert werden soll. Wer braucht welche Information, wann, in welcher Form und zu welchem Zweck?

Diese Art von Rückfrage ist erstaunlich wirksam. Sie nimmt den Beitrag ernst, ohne die Gruppe vorschnell in die Umsetzung zu treiben. Gleichzeitig stärkt sie die Fähigkeit des Teams, zwischen Beobachtung, Bedarf und Lösung zu unterscheiden. Und genau das ist letztlich eine der wichtigsten Kompetenzen in guter Systemarbeit.

Fazit

Dass wir zuerst das Problem verstehen sollten, bevor wir über Lösungen sprechen, ist keine neue Erkenntnis. Neu ist höchstens, wie konsequent diese einfache Einsicht in vielen Organisationen wieder verloren geht. Unter Zeitdruck und Umsetzungsdruck wirkt Problemanalyse oft wie ein Luxus. In Wirklichkeit ist sie ein Mittel, unnötige Komplexität und teure Fehlentscheidungen zu vermeiden.

Requirements Engineering und Systems Engineering bieten dafür seit Langem geeignete Denkwerkzeuge. Die Unterscheidung zwischen Needs und Requirements, die Arbeit mit Black Box und Glass Box oder der Einstieg über Kontextdiagramme sind keine theoretischen Konzepte für Lehrbücher. Sie sind praktische Hilfen, um bessere Gespräche zu führen und bessere Systeme zu entwickeln.