Freitag, 25. September 2015

Die geltende Geschäftspraxis steht einem guten Requirements Engineering entgegen.

These:Gute Software benötigt gute fachliche Anforderungen.

Im Requirements Engineering sollen Anforderungen an eine Software möglichst genau aufgenommen werden. Auf dieser Grundlage wird dann eine Anwendung erstellt, die zum größtmöglichen Nutzen eingesetzt wird. Soweit der Anspruch. In der Wirklichkeit schlägt dieses Unterfangen oft fehl. Die Welt ist zu oft in Auftraggeber und Auftragnehmer aufgeteilt, die nicht am selben Strang ziehen. Gegensätzliche Interessen verhindern das Ziel zu erreichen. Auf der einen Seite steht das Softwareunternehmen. Es versucht möglichst viel Geld zu verdienen mit möglichst wenig Arbeit. Der Austausch eines Logos für 10.000 € wird so zum Sieg. Der Kunde wurde ausgetrickst und wenn alles gut geht, dann merkt er es auch nicht. Leider kommen immer wieder Geschichten an die Oberfläche, in diesen Tagen auch in anderen Bereichen der Wirtschaft, in denen das Austricksen von Kunden Bestandteil der Geschäftspolitik ist.

Damit ist der Grundstein zum Misstrauen gelegt. Auf der Kundenseite versucht man nun für möglichst wenig Geld möglichst viel Software zu bekommen. Der Auftragnehmer möchte also möglichst wenig für möglichst viel verkaufen und der Auftraggeber möchte möglichst viel für möglichst wenig erstehen. Einen größeren Antagonismus kann man sich eigentlich kaum vorstellen. In diesem Widerspruch steckt jedoch auch die Triebkraft der Ökonomie. Der Auftragnehmer, der dem Kunden das größte Stück Software verkaufen kann, gewinnt in diesem Wettkampf den Auftrag und die anderen Teilnehmer gehen leer aus. Soweit die einfache Wahrheit, die in der Praxis nicht stattfindet. Dazu müssten die Teilnehmer das Geschäft überblicken können, dass meist zu einem Zeitpunkt abgeschlossen wird, zu dem nur eine Prophezeiung verkauft wird, andere würden sagen eine Lüge.



Schon sehr früh im Geschehen wird ein Vertrag unterzeichnet, in dem ein Preis und ein Funktionsumfang festgelegt wird. Der Preis ist eine feste, gut lesbare Summe. Unter dem Funktionsumfang kann sich zu diesem Zeitpunkt kaum jemand etwas vorstellen. Je früher der Zeitpunkt auf der Zeitachse, um so weniger ist klar, was eigentlich gemacht werden soll. Die wirklichen Fachleute, die wüssten wozu diese Software eingesetzt wird und in welchen Zusammenhängen, werden in diesen politischen Spielchen oft genug nicht an den Verhandlungstisch gebeten. Es entsteht ein fantasiertes Vertragsgebilde mit einer Fülle von unklaren Aussagen. Jede der beiden Seiten glaubt die andere Seite übers Ohr gehauen zu haben oder sie hoffen wenigstens in späteren Zeiten, wenn klar auf den Tisch kommt was umgesetzt werden soll, das eine oder das andere abwehren zu können und dabei durch sprechblasenartige Sätze geschützt zu sein.

Dieses Verhalten, Glaskugelsätze und Unklarheiten zu beschreiben, besser zu umschreiben, wird von den Protagonisten dieses Treibens bis in die Phase des Requirements Engineering fortgesetzt. Dort, wo eigentlich Klarheit, Verständlichkeit und Vollständigkeit gefordert sind, wird das Spiel mit schlimmen Folgen weiter betrieben. Oft genug ist es nicht die Unfähigkeit des Kunden oder des Programmierers, die in der Zukunft zu wenig oder nicht zu gebrauchender Software führt, allzu oft ist es ein politisches Ränkespiel, in dem man den Geschäftspartner übers Ohr hauen will oder muss. Das muss nicht einmal bewusst passieren, schließlich muss ein Unternehmen Geld verdienen. Je mehr ein Unternehmen einnimmt und je weniger es ausgibt, um so besser geht es dem Unternehmen. Über den Zustand der Menschen im Unternehmen ist damit natürlich nichts gesagt.

Als Requirements Engineer steht man also vor der Aufgabe, auf einem Sumpf gewollter Unklarheiten aufzubauen. Man muss genau das machen, was vorher nicht gewollt wurde. Nach einem guten Requirements Engineering ist es mit Hilfe eingespielter Teams ziemlich genau möglich, dem Kunden zu sagen wie viel Software er für sein Geld bekommen kann. Gibt es darüber hinaus eine Vereinbarung kleine Zeiteinheiten abzurechnen, ist sogar ein schnelles Umsteuern möglich. Solches würde jedoch vertrauensvolle Zusammenarbeit erfordern und die Gewinnspanne würde transparent werden. Daran ist kaum jemand interessiert.

Software wird wie beim Malern der Wohnung abgerechnet. Der Maler benötigt 8 Stunden und bekommt dafür 200 €. Beim Malern kann man dem Maler bei der Arbeit zusehen. Man erkennt relativ genau, wie oft er eine Zigarette raucht oder träumend aus dem Fenster sieht. Auch die Qualität der Arbeit ist recht gut sichtbar. Beim Programmieren ist das wesentlich schlechter zu erkennen. Gute Software benötigt Gedankengänge, die in sich verbessernden Kreisen zu einfacher und guter Software führen. Schlechte Software ist schnell geschrieben. Doch wie schätzt man jetzt den fragenden Blick des Programmierers ein? Sind die 5 Zeilen besser als die 20 Zeilen? Kann man die Codequalität überhaupt einschätzen? Hätte eine andere Firma dafür nur die Hälfte der Zeit benötigt. Der Kunde verfügt über kein realistisches Szenario diese Situation zu beherrschen. So etwas lädt geradezu zum übertölpeln ein.



Der Kunde fühlt jedoch oft genug, dass da etwas nicht stimmt. Er hegt ein tiefes Misstrauen, zahlt jedoch den Preis dessen, was er nicht einschätzen kann. Ein ungutes Gefühl bleibt. Damit wird weit mehr zerstört als man glaubt. Das notwendige Vertrauen, auf dem ein gutes Requirements Engineering aufbaut, wird so beschädigt. Die technische Phase der Softwareentwicklung wird von seinem ökonomischen Kontext kontaminiert. Techniker wünschen sich eine gute Zusammenarbeit, mindestens sollten sie das tun. Manchmal steht ihnen ihr eigener Narzissmus dabei im Wege, aber sehr oft beginnt auf der technischen Ebene eine gute gemeinsame Arbeit.

Könnte man diese gute Zusammenarbeit auf alle Bereiche des Verhältnisses von Auftraggeber und Auftragnehmer ausweiten? Kann man die Grundlagen so legen, dass ein gutes Requirements Engineering selbstverständlich ist und das Ziel der Arbeit eine Software, die in ihrem späteren Kontext sinnvoll und produktiv ist? Ist das Gerede von Win-Win-Situationen das Beschwören falscher Geister und im Gegeneinander der Interessen gar nicht möglich? Als Requirements Engineer und Entwickler suche ich einen Weg aus diesem Dilemma. Ich würde gerne mit Freude Software entwickeln, die an ihrem Einsatzort Menschen die Arbeit erleichtert. Wenn man jedoch, wie es mir bei einem früheren Arbeitgeber passiert ist, aufgefordert wird „quick and dirty“ zu programmieren und einem der Zugang zum Kunden versperrt wird, dann hört der Spaß schnell auf.

Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Kommentare:

  1. Ich finde diesen Artikel sehr interessant. Mit dem Autor bin ich im Großteil einverstanden.

    AntwortenLöschen
  2. Herrlich realistisch!! So ist das Leben - leider!

    Die offene Frage als "Techniker" ist nur: wie kommen wir aus diesem Dilemma? Wie überzeugen wir Management und Sales?

    AntwortenLöschen
  3. Herrlich realistisch!! So ist das Leben - leider!

    Die offene Frage als "Techniker" ist nur: wie kommen wir aus diesem Dilemma? Wie überzeugen wir Management und Sales?

    AntwortenLöschen