Freitag, 31. Juli 2015

Die Angst vor dem Kunden.

These: Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software.

Stellen Sie sich vor, Sie sind Programmierer in einer Softwarefirma und bekommen die Aufgabe, eine Anforderungsspezifikation zu schreiben. Nach der Spezifikation droht dann die Umsetzung. Deshalb möchten Sie die Anforderungen möglichst genau analysieren und beschreiben, und auch, weil Sie wissen, dass das Spezifizieren von Anforderungen der erste Entwicklungsschritt ist und zudem ein sehr bedeutender. 70 Prozent aller Projekte, die scheitern, leiden an fehlenden oder fehlerhaften Anforderungsanalysen.

Grundvoraussetzung für eine gute Anforderungsanalyse ist der Kunden- bzw. der Nutzerzugang. Innerhalb der Kontextanalyse erfolgt die Erfassung verschiedener Kontextobjekte. Durch das Studium dieser Quellen dringen Sie in den Fachkontext der umzusetzenden Aufgabe ein. Zu den wichtigsten Kontextobjekten zählen die Stakeholder. Stakeholder sind all diejenigen, die ein irgendwie geartetes Interesse an der zu erstellenden Software haben. Kunden und Nutzer stechen aus dieser Gruppe noch einmal heraus. Der Kunde bezahlt ein Produkt, das er sich für einen ganz spezifischen Zweck anschafft, und der Nutzer muss mit diesem Produkt arbeiten. Oft wird die Bedeutung dieser Gruppen noch dadurch erhöht, dass sie über das eigentliche Fachwissen in Bezug auf die zu erschaffende Software verfügen.

Im Beitrag Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung? habe ich dargestellt, welche unterschiedlichen Wissensformen es in der Softwareentwicklung gibt: das fachliche Wissen, das analytische Wissen und das technische Wissen. Diese Wissensformen sind oft über mehrere Personen verteilt. Der Bankmitarbeiter verfügt über das fachliche Wissen im Bankwesen. Er weiß, wie Überweisungen getätigt werden, wo sie gebucht werden und wie im Fehlerfall damit umzugehen ist. Der Requirements Engineer kann mit verschiedenen Techniken dieses Wissen mithilfe des (in Zusammenarbeit mit dem?) Bankmitarbeiters ermitteln. Eine seiner Hauptaufgaben ist jedoch die analytische Aufarbeitung dieses Wissens für die Programmierung. Der Programmierer wiederum verfügt über das Wissen, wie er diese Spezifikation mithilfe einer Programmiersprache in ein lauffähiges Programm umzusetzen hat.

Natürlich können alle drei Wissensformen in einer Person vorliegen. Das ist jedoch höchst selten der Fall. Im oben beschriebenen Fall vereint unser Programmierer die Rolle des Requirements Engineer und die der Programmierung. Dadurch ist der Kommunikationsbruch zwischen analytischen und technischen Wissen auf ein Minimum gesenkt. Ein und dieselbe Person versteht sich besser als zwei Personen. Zwei Personen verfügen über unterschiedliche Erfahrungshorizonte und treffen somit oft unterschiedliche Interpretationen zu gleichen Aussagen. Deshalb kann zwischen dem fachlichen Wissen und dem analytischen Wissen dieser Bruch durch äußere Randbedingungen auf ein Maximum steigen.



Es wird durch die verhinderte Kontaktaufnahme mit dem Kunden selbst herbeigeführt. Für dieses Verhalten gibt es die verschiedensten Gründe. Die tiefgründige Diskussion mit dem Kunden oder mit dem Nutzer soll vermieden werden. Man glaubt, sich in der Diskussion mit dem Kunden als ahnungslos zu enttarnen und damit die Glaubwürdigkeit als Ersteller von technisch hochwertiger Software zu verlieren. Ein anderer Grund ist die oft anzutreffende Meinung, dass der Kunde bzw. der Nutzer sowieso nicht formulieren kann, was er will. Diese Form der direkten Anforderungsermittlung sei also reine Zeitverschwendung. Man weiß doch eigentlich schon alles und den Rest wird man sich schon zusammenreimen. Diese beiden Formen der Kundenabwehr können gesteigert in einer seltsamen narzisstischen Form vorliegen. Man hält sich für den Größten, hat aber Angst, Unwissenheit zugeben zu müssen. Man toggelt zwischen den Extremen.

Oft werden diese Annahmen nicht durch die betroffenen Requirements Engineers oder die zuständigen Programmierer selbst getroffen. Die Entscheidung wird stattdessen durch das mittlere oder höhere Management gefällt. Dort herrscht die Meinung vor, eine tiefgründige Anforderungsanalyse ist unnötig und zu teuer. Alles soll schnell, schnell gehen und am Ende steht dann urplötzlich der maximale Gewinn. Wenn diese Entscheidungsträger jedoch ein tiefes Wissen zur Anforderungsanalyse besitzen oder ihren Fachleuten vertrauen, sieht diese Entscheidung ganz anders aus. Das Verhindern eines Kundenkontakts wird also meist aus Unwissenheit heraus getan.

Genauso kann der Kundenkontakt von der Kundenseite her verhindert werden. Man hat eine seltsame Gläubigkeit in die Zauberfähigkeit von Software. Man klickt ein bisschen was zusammen und alles ist fertig. Dieser Glaube wird nicht einmal durch die jahrelange Nutzung fehlerhafter Software erschüttert. Ein andere Grund ist, dass künftigen Nutzern keine Möglichkeit gegeben wird, mit der Entwicklung zu kommunizieren. Man steckt in den eigenen Aufgaben so fest, dass die gemeinsame Entwicklung einer optimalen Software nicht ermöglicht wird. Auch hier erkennt manches Management die Chance dieser zeitlichen Investition nicht.

Beide Seiten sollten also einsehen, dass sie Fachleute auf ihrem Gebiet sind. Beide Seiten sollten einsehen, dass sie die Fähigkeiten der anderen Seite ergänzen müssen, damit am Ende eine brauchbare Software entsteht. Nichts ist schlimmer in der Softwareentwicklung als unterbrochene Kommunikation. Außerdem sollte dieser Prozess durch ein fähiges Management flankiert werden.

Ideal für beide Seiten wäre die Erweiterung des Entwicklungsteam durch den Kunden bzw. den Nutzer. Mit modernen Kommunikationsmethoden ist diese Erweiterung auch möglich, wenn das Team über mehrere Orte verteilt wäre. Nur gemeinsame Diskussionen über den Fachgegenstand führen zu einer gemeinsamen Fachsprache. Nur ein gemeinsames Verständnis des Fachgegenstandes führt zu Anforderungen, die beide Seiten verstehen. Ohne diese tiefgründige Kommunikation ist das Ergebnis oft eine unangenehme Überraschung für beide Seiten. Die Entwickler ärgern sich darüber, dass ihre guten Ideen nicht anerkannt werden. Schließlich hat man sich in harter Selbstinterpretation Anforderungen ausgedacht. Auf der Seite des Kunden und der Nutzer ist man ebenso enttäuscht. Man hat sich alles viel einfacher vorgestellt. Jetzt hat man das Gefühl einen einzigen Bug geliefert bekommen zu haben.

Die Lösung für mich ist die gemeinsame Problemlösung. Meist werden in der Softwareentwicklung Prozesse des Kunden bzw. der Nutzer optimiert. Deshalb sollte man den Kunden nicht nur befragen, man muss ihn an der Lösung beteiligen.

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

1 Kommentar:

  1. Eigentlich ist das Thema echt nicht zum Lachen, und zum Thema "Angst" könnte ich da noch einiges dazusteuern. Aber bei der geschickten Wortwahl musste ich doch das eine oder andere Mal amüsiert schmunzeln. Sehr sehr treffend und wirklich "hübsch" formuliert. KT :D

    AntwortenLöschen