Das Problem mit Problembeschreibungen

„Wenn ich eine Stunde habe, um ein Problem zu lösen, dann beschäftige ich mich 55 Minuten mit dem Problem und 5 Minuten mit der Lösung.“ soll Albert Einstein einmal gesagt haben. An sich eine sehr schlaue Aussage und doch gibt es genügend Projektmanager, die gerne beim Bekanntwerden von Problemen sofort loslegen. Sie krempeln Ärmel hoch, spucken in die Hände und stürzen sich auf die Arbeit. Sie empfinden Probleme als schlecht, die direkt gelöst werden müssen. Ich habe andere Erfahrungen gemacht und das irritiert den einen oder anderen Projektleiter, besonders wenn ich nicht sofort loslegen und zunächst nichts von seinen Lösungen hören möchte.

Probleme oder Problembeschreibungen

Es gibt Projektleiter, die haben für jedes Problem eine schnelle Lösung parat. Ob die Lösung aber auch eine gute Lösung ist, das ist nicht immer klar. Häufig werden Lösungen auf dem Rücken von Entwicklern ausgetragen, die Überstunden oder gar Zusatzschichten am Wochenende einlegen müssen. Oft verdient eine solche Lösung den Namen nicht. Natürlich ist das Wort „Problem“ vorbelastet. Eine bessere Bezeichnung sind vermutlich „Problemstellung“ oder „Problembeschreibung“. Denn darum geht es: Um eine Lösung überhaupt bemessen zu können, muss diese gegen Etwas bemessen werden. Nur wenn eine Frage klar und bekannt ist, lässt sich beurteilen, ob eine Antwort darauf richtig oder falsch ist. Das kann jeder bestätigen, der schon mal im Mathematik-Unterricht abgeschrieben hat, um später festzustellen, dass der Lehrer zwei Versionen der Klausur mit unterschiedlichen Aufgaben gestellt hatte. Im täglichen Leben gibt es zahlreiche Beispiele für Lösungen, die an sich zwar funktionieren, aber sicherlich noch besser ausgestaltet werden könnten wie beispielsweise Fahrkartenautomaten, automatische Drehtüren oder die Fernbedienung für den Fernseher.

Der Kontext des Problems

Eine gute Problemstellung beschreibt die zu lösende Aufgabe so allgemein wie möglich. Allerdings werden Sie irgendwann an die Grenzen des Sinnvollen und Machtbaren folgen. Es gibt eine kleine Anekdote eines Handwaffenherstellers, der ein neues Gewehr für die britische Armee entwickeln sollte. Nachdem er bereits mehrfach seine Anforderungen umformulieren musste, weil diese angeblich zu lösungsspezifisch waren, schrieb er schließlich folgende Anforderung auf: „Die Queen und das Vereinigte Königreich verteidigen“. Diese Anforderung war sicherlich richtig, aber bei einer solchen Formulieren wird natürlich ein wesentlicher Teil des Kontextes außer Acht gelassen, denn schließlich sollte ein Gewehr als Handfeuerwaffe entwickelt werden. Eine solche Information muß mit in Betracht gezogen werden. Der Kontext, also die Rahmenbedingungen, kann für viele Entwicklungen sehr unterschiedlich sein: Für ein elektrisches Gerät können dies zum Beispiel die zulässigen Betriebstemperaturen sein, für ein Auto die gesetzlichen Abgasnormen, für eine Brücke das zulässige Gesamtgewicht oder für eine Unternehmensbuchhaltung eine zehnjährige Nachweispflicht.

Schritt für Schritt zur Lösung

Nur bei den kleinsten Problemen kommen Sie mit einem Schritt zur Lösung. Ein Bild können Sie relativ leicht mit einem Nagel, einem Hammer und gegebenenfalls einem Klebestreifen an die Wand hängen. Solche Probleme werden meist auch nicht als Problem, sondern als Aufgabe empfunden. Bei tatsächlichen Problemstellungen aber findet eine Lösungsfindung in zwei Stufen statt:

• Das Problem wird analysiert, um einen Lösungsansatz zu finden.
• Dieser Lösungsansatz stellt die Rahmenbedingungen für die nächste Problemstellung dar.

Dazu ein Beispiel aus der Automobilindustrie: Ein Hersteller entscheidet sich, eine Diebstahlsicherung zu entwickeln. Ein Teil der Lösung soll das Erkennen von Bewegungen im Innenraum sein. Ab diesem Punkt wird der Innenraum zum Kontext und es kann nach einer Lösung für das Problem „Überwachung“ gesucht werden. Mögliche Lösungen sind dann Überwachung mit Kamera, Radar, Ultraschall, Infrarot oder einem Wachhund. Möchte ein Garagentorhersteller einen Diebstahlschutz für Autos anbieten, wird er hingegen den Fahrzeuginnenraum nicht als Kontext verstehen.

Probleme und Blickwinkel

Erinnern Sie sich noch an das Beispiel des Waffenherstellers, der die Queen und das Vereinigte Königreich verteidigen wollte? Auch wenn der grobe Lösungsweg vorgegeben scheint, kann es gar nicht verkehrt sein, sich die elementare Problemstellung noch einmal genauer anzuschauen. Denn für viele Hersteller ist die traurige Wahrheit, dass sich die meisten Kunden nicht für die konkreten Produkte interessieren oder was sie mit den Produkten machen können. Vielleicht kennen Sie die plakative Aussage, dass „Baumärkte keine Bohrmaschinen verkaufen, sondern die Möglichkeit Löcher in eine Wand zu machen“. Für einen Hersteller bedeutet dies eine genaue Auseinandersetzung mit seinen Kunden und deren Bedürfnisse. Um es mit Henry Ford zu sagen: „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt schnellere Pferde.“ In anderen Worten: Probleme müssen auf unterschiedlichen Ebenen und aus unterschiedlichen Blickwinkeln unterschiedlich betrachtet werden. Eine der Ebenen ist die Kundeneben. Sie ist eine der wichtigsten, denn schließlich sollen die Kunden ja Ihre Produkte bezahlen.

Auf dem Weg zur richtigen Lösung!

Wenn Sie mir zustimmen, dass eine gute Problemstellung bzw. Problembeschreibung sehr wichtig ist, lautet die nächste Frage: Wie kommen Sie zur Lösung? Dazu gibt es unterschiedliche, oft komplementäre Ansätze. Hier sind die meiner Meinung nach die wichtigsten, allerdings ohne Anspruch auf Vollständigkeit:

• Die Einbeziehung der Stakeholder: Auch wenn die Nutzer oft als wichtigste Stakeholder wahrgenommen werden, sind sie nicht die einzigen Stakeholder. Nicht selten ist der Nutzer nicht gleich der Käufer – der muss jedoch überzeugt werden, für das Produkt zu bezahlen. Stakeholder für die Inbetriebnahme und den Betrieb, die Wartung und Entsorgung dürfen nicht vergessen werden. Und auch die Gesetzeslage gilt es immer zu berücksichtigen.
• Die Durchführung von Workshops: Für mich sind Workshops das ideale Mittel zur Problembeschreibung bzw. Erhebung von Anforderungen. 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. Hier kann ich Ihnen das Buch „Workshops in Requirements Engineering“¹ als sehr praxistaugliches Referenzbuch empfehlen. Es beschreibt einen leichten und dennoch robusten Prozess, um vom Workshop zu belastbaren Anforderungen zu kommen.
• Vorhandene Dokumentation, Reverse-Engineering und Beobachtungen: Bei Systemen, die sich noch in der Nutzung befinden, bietet sich an, die entsprechend beschriebenen Anforderungen und die vorhandene Dokumentation als Ausgangsbasis zu nutzen. Falls es die nicht oder nicht mehr gibt, sollten Sie ein Reverse Engineering betreiben. Zusätzlich ist auch die Beobachtung der Nutzer beim Einsatz des Systems ein hilfreiches Mittel. Hier müssen wir aber aufpassen, da Sie 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. Leider wird darunter oft die „qualitativ hochwertigste“ 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 erwarten ein sehr gutes Preis-Leistungs-Verhältnis und müssen Budgets einhalten. Die richtige 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. Sie erwarten in einem Schnellrestaurant vermutlich auch nicht, dass Silberbesteck im Lieferumfang enthalten ist. Und wenn Sie dafür noch extra bezahlen müssten, würden Sie evtl. beim nächsten Mal schnell an diesem Schnellrestaurant vorbeigehen.

Fazit

Ein Problem eindeutig zu beschreiben, ist der erste Schritt hin zu der richtigen Lösung für das Problem in der jeweiligen Situation. Investieren Sie etwas Zeit, um ein Problem in Zusammenarbeit mit Ihren Stakeholdern sauber zu formulieren, denn so erleichtern Sie die Entwicklung einer Lösung. Und nicht nur das: Sie werden feststellen, dass ein „offensichtliches“ Problem plötzlich gar nicht mehr so offensichtlich ist, wenn Sie versuchen, es sauber zu beschreiben. 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.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

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] Workshops im Requirements Engineering

Das Ishikawa-Diagramm bietet eine schöne Möglichkeit, ein Problem mit seinen Ursachen zu visualisieren.

Dr. Michael Jastram hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.