Das Problem mit dem Problem

„Mir ist noch nie ein Problem begegnet, für das ich nicht sofort eine Lösung hatte,“ prahlte der Projektmanager. Überhaupt war er ein großer Fan davon, immer sofort loszulegen: Ärmel hochkrempeln, in die Hände spucken, und ran an die Arbeit. Insofern war er etwas irritiert, dass ich nicht ebenfalls sofort loslegen und zunächst nichts von seinen Lösungen hören wollte. “Probleme sind schlecht! Lass Sie uns direkt lösen!” meinte er. Doch ich habe andere Erfahrungen gemacht.

Warum Probleme gut sind

Der Projektleiter hatte sicher recht, dass er für jedes Problem eine Lösung parat hatte. Nur war es leider selten eine gute Lösung. Und wenn die „Lösung“ auf dem Rücken der Entwickler ausgetragen wurde – etwa durch erforderliche Wochenendarbeit – dann war sicher nicht alles so, wie es sein sollte.

Zugegeben, das Wort „Problem“ ist etwas vorbelastet. Eine bessere Bezeichnung ist vielleicht „Problembeschreibung“. Denn darum geht es: Um eine Lösung überhaupt bemessen zu können, muss diese gegen Etwas gemessen werden. Ob eine Antwort richtig oder falsch ist, kann nur beurteilt werden, wenn die Frage bekannt ist. Das kann jeder bestätigen, der schon mal in Mathe abgeschrieben hat und später feststellen musste, dass der Lehrer zwei Versionen der Klausur mit unterschiedlichen Zahlen hatte! Auch aus dem täglichen Leben gibt es viele Beispiele für Lösungen die zwar funktionieren, aber nicht sonderlich gut sind: Von Fahrkartenautomaten, über automatische Drehtüren bis zur Fernbedienung für den Fernseher.

Den Kontext nicht vergessen

Eine gute Problemstellung beschreibt die zu lösende Aufgabe so allgemein wie möglich. Allerdings wird man dabei irgendwann an die Grenzen des Machbaren – oder Sinnvollen – stoßen. Dazu gibt es die Anekdote eines Waffenherstellers, der ein neues Gewehr für die britische Armee entwickeln sollte. Nachdem er mehrfach seine Anforderungen umformulieren musste, weil diese angeblich zu lösungsspezifisch waren, schrieb er schließlich die Anforderung auf: „Die Queen und das vereinigte Königreich verteidigen“. Sicherlich richtig, aber nun wurde ein Teil des Kontextes außer Acht gelassen: In diesem Fall die Tatsache, dass er nun einmal für eine Firma arbeitete, die Handwaffen herstellt. Diese Information darf und sollte mit in Betracht gezogen werden.

Der Kontext, also die Rahmenbedingungen, kann auch andere Dinge beinhalten. Für ein elektrisches Gerät können dies zum Beispiel die zulässigen Betriebstemperaturen sein, für ein Fahrzeug die gesetzlichen Vorgaben.

Schritt für Schritt zur Lösung

Nur bei den kleinsten Problemen kommen wir in einem Schritt zur Lösung. Wenn Sie ein Bild an die Wand hängen wollen, dann ist dies leicht möglich. In einem Schritt entscheiden Sie sich dann für Nagel, Schraube, Nylonfäden, Klebestreifen, Wäscheleine, Projektion, Nadeln, Heftzwecken oder Kaugummi, um das Bild zu fixieren.

In den meisten Fällen aber findet eine Lösungsfindung in mehreren Stufen statt: Das Problem wird analysiert, um einen Lösungsansatz zu finden. Dieser Lösungsansatz stellt dann die Rahmenbedingungen für die nächste Problemstellung dar. Dazu ein Beispiel aus der Industrie: Ein Automobilhersteller hat sich dafür entschieden, eine Diebstahlsicherung zu entwickeln (Problemstellung). Ein Teil der Lösung soll die Detektion von Bewegungen im Innenraum sein. Ab diesem Punkt ist der Innenraum als Kontext  gegeben und es kann nach einer Lösung für das Problem „Überwachung“ gesucht werden. Mögliche Lösungen sind dann Überwachung mit Ultraschall, Radar, Infrarot, Kamera oder einem Wachhund.

Löcher anstatt Bohrmaschinen

Erinnern Sie sich noch an das Beispiel „Die Queen und das vereinigte Königreich verteidigen“? Auch wenn der grobe Lösungsweg vorgegeben ist, kann es gar nicht verkehrt sein, sich die elementare Problemstellung trotzdem noch einmal anzuschauen. Denn die traurige Wahrheit ist: Ihre Kunden interessieren sich nicht für Ihr Produkt. Nicht wirklich. Ihre Kunden interessieren sich für das, was man mit Ihrem Produkt machen kann. Vielleicht kennen Sie die Marketingaussage „Baumärkte verkaufen keine Bohrmaschinen, sondern die Möglichkeit Löcher in eine Wand zu machen“. Die Kernaussage ist es, nicht zu vergessen, was dem Kunden eigentlich wichtig ist. Selbst wenn Sie Bohrmaschinen herstellen, muss berücksichtigt werden, dass der Kunde eigentlich nur an den Löchern interessiert ist.

„Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt schnellere Pferde.“ (Henry Ford)

In anderen Worten: Probleme auf unterschiedlichen Ebenen sollten unterschiedlich betrachtet werden.  Bei dem Beispiel eben (und dem Zitat von Henry Ford) geht es um die Kundenebene. Das ist eine der wichtigsten Ebenen, denn die Kunden sollen das Produkt ja schließlich bezahlen.

Nicht irgendeine und nicht die beste Lösung. Die richtige Lösung!

Inzwischen sollte verständlich sein, warum eine gute Problembeschreibung Gold wert ist. Die Frage ist nun, wie kommen wir zur Lösung? Dazu gibt es unterschiedliche, oft komplementäre Ansätze. Hier sind die meiner Meinung nach wichtigsten, ohne Anspruch auf Vollständigkeit:

Stakeholder einbeziehen: Auch wenn der Nutzer oft als wichtigster Stakeholder wahrgenommen wird, ist dies nicht der einzige. Nicht selten ist der Nutzer nicht gleich der Käufer – der muss jedoch überzeugt werden, das Portemonnaie zu öffnen. Auch Stakholder für Betrieb, Wartung und Entsorgung, sowie der Gesetzgeber, sollten nicht vergessen werden.

Workshops: Bezüglich Anforderungserhebung ist das Buch „Workshops in Requirements Engineering“¹ für mich ein hervorragendes praxistaugliches Referenzbuch. Wie der Name schon sagt, ist das Mittel der Wahl der Workshop. Zu Workshops gehören natürlich auch verwandte Formen wie Interviews oder Fokusgruppen. Oft stellt sich ja die Frage, wie es nach dem Workshop weitergeht. Dieses Buch gibt einen leichten, robusten Prozess vor, um vom Workshop zu belastbaren Anforderungen zu kommen.

Beobachten und Reverse-Engineering: Bei Bestandssystemen bietet sich an, die aktuell gehaltenen Anforderungen und Dokumentation als Ausgangsbasis zu nutzen. Wie bitte? Die gibt es nicht? Dann muss Reverse-Engineering betrieben werden. Das Beobachten der Nutzer beim Einsatz des Systems ist auch ein hilfreiches Mittel. Hier müssen wir aber aufpassen, da wir hier bereits mit einer Lösung konfrontiert werden. Wichtig ist es, das der Lösung zugrunde liegende Problem zu erkennen.

An dieser Stelle möchte ich noch einmal auf eine Gefahr hinweisen: Oft wird versucht, die „beste“ Lösung zu finden. Das ist gut. Leider wird oft die „qualitativ hochwertigste“ Lösung mit der „besten“ Lösung gleichgestellt. Und das ist selten der Fall, denn die hochwertigste Lösung ist oft auch die teuerste. Die meisten Kunden haben ein Budget und erwarten daher ein vernünftiges Preis-Leistungs-Verhältnis. Die beste Lösung ist daher diejenige, die Anforderungen unter Berücksichtigung der Rahmenbedingungen am besten erfüllt. Und das kann durchaus eine Lösung von geringer Qualität sein. Wenn Sie im Schnellrestaurant einen Salat zum Mitnehmen bestellen, würden Sie sich bestimmt wundern, wenn ein Silberbesteck im Lieferumfang enthalten wäre. Und Sie würden sich sicher weigern, dafür auch noch zu bezahlen.

Fazit

Probleme sauber zu erfassen, ist der erste Schritt hin zu der für die jeweilige Situation passenden Lösung. Investieren Sie etwas Zeit, um ein Problem in Zusammenarbeit mit Ihren Stakeholdern sauber zu formulieren, denn so haben Sie wesentlich bessere Karten bei der Entwicklung der Lösung. Und nicht nur das: Sie werden feststellen, dass ein „offensichtliches“ Problem plötzlich gar nicht mehr so klar ist, wenn Sie versuchen, es sauber zu fixieren. Auch das hilft, den Weg zur „richtigen“ Lösung zu finden – oder kann sogar verhindern, dass Sie ein Problem lösen, das es gar nicht gibt. Und das freut bestimmt auch den zu Beginn erwähnten Projektmanager.

 

Hinweise

Dr. Michael Jastram finden Sie in seinem wöchentlichen, deutschsprachigen Blog System Engineering Trends und dem englischsprachigen Formal Mind Blog. Sein Wissen zu Anforderungsaustausch und dem offenen Standard ReqIF teilt er in seiner Online-Bibliothek ReqIF.academy.

[1] https://www.dpunkt.de/buecher/12024/9783864902314-workshops-im-requirements-engineering.html