Es liegt in der Natur der Ingenieurswissenschaften in Lösungen statt in Problemen zu denken. Jemand hat ein Problem und konsultiert einen Ingenieur, damit dieser ihm eine Lösung liefert. Die Frage nach dem „Wie?“ ist wesentlich präsenter als die nach dem „Wozu?“. Dies könnte einer der Gründe sein, weswegen der gemeine Stakeholder dazu neigt lösungsorientiert zu arbeiten. Wichtig ist es jedoch, dass man zunächst das Problem versteht, abstrahiert und sich fragt:
– Wozu benötige ich etwas?
– Welchen Mehrwehrt habe ich davon?
Das Ingenieurswesen ist bekanntlich die Königsdisziplin der Deutschen, daher ist uns diese Denke vermutlich ein Stück weit in die Wiege gelegt. In Systems Engineering Projekten stellt dies für uns häufig eine Hürde dar, die wir gemeinsam mit unseren Stakeholdern bewältigen müssen.
Zunächst stellt sich die Frage „Wozu überhaupt abstrahieren, wenn man doch bereits eine Lösung kennt?“. Die Frage impliziert hier bereits das Problem. Denn der Fakt, dass bereits eine Lösungsvariante existiert, bedeutet nicht, dass diese die effizienteste bzw. die beste Lösung für das zugrundeliegende Problem darstellt. Aus genau diesem Grund ist es, als Requirements Engineers, unsere Aufgabe, zusammen mit unseren Stakeholdern den fachlichen Wert einer Realisierungsmöglichkeit zu identifizieren und als lösungsneutrale Anforderung zu dokumentieren.
Diese Herangehensweise spiegelt sich bereits in unserer Firmenphilosophie wieder. Denn wir SOPHISTen agieren frei nach dem Motto „Die Infagestellung des Althergebrachten führt zur Suche nach etwas besserem“. Transferiert auf unseren Projektalltag bedeutet das, dass wir nur, wenn wir das eigentliche Problem – also die eigentliche Anforderung – ermitteln, unsere Kunden dabei unterstützen ihr Produkt oder ihre Prozesse zu optimieren. Gelingt uns diese Abstraktion nicht, so verharren wir im „Wir machen das schon immer so!“ und limitieren uns selbst dabei uns zu verbessern.
Um Ihnen zu veranschaulichen, wie gewinnbringend die Abstraktion einer Lösung zum Problem ist, ein kleines Beispiel. Denken Sie an ihr Auto. Nun möchten Sie, um losfahren zu können, natürlich den Motor starten. Über einen langen Zeitraum war es Gang und Gäbe dies mittels eines Zündschlüssels zu tun, den man im dazugehörigen Zündschloss dreht. Aus dieser allgemeingültigen Praxis hätten die meisten Stakeholder vermutlich eine Anforderung formuliert wie „Das System muss ein Zündschloss und einen Zündschlüssel haben.“ Aus welchem Grund – also wozu – das System diese „Eigenschaften“ aufweisen soll, bleibt dabei außen vor. Was der Stakeholder eigentlich mit seiner Anforderung ausdrücken möchte ist: „Das System muss dem Fahrer die Möglichkeit bieten den Verbrennungsmotor zu starten.“ Die Art und Weise wie er dies tut, ist wiederum eine Architekturentscheidung und sollte, insofern nicht explizit benötigt oder gewünscht, nicht Teil der Anforderung sein. Durch diese Bereinigung der Anforderung um die Lösung hat die Entwicklung den Freiraum sich andere Lösungsmöglichkeiten zu überlegen und z.B. ein Keyless-Go-System zu entwickeln.
In der Literatur wird Ihnen diese Abstraktion auch als Essenzbildung begegnen.
Schärfen Sie also Ihren Blick dafür, an welchen Stellen es sich lohnt vom Konkreten ins Abstrakte zu wechseln und wann eine Konkretisierung notwendig ist. Wir hoffen unsere Blogserie konnte Ihnen Denkanstöße liefern und vielleicht sogar in Ihrem Projekt weiterhelfen.
Beste Grüße
Ihre SOPHISTEN