“I want it all. (I want it now.)”

Freddy Mercury ist tot. Aber der Geist seiner Songs lebt. Dieser Song allem Anschein nach vorwiegend in Person des Ich-habe-hier-das-Sagen-Auftraggebers im Umgang mit Softwareentwicklern. Womit er gleich an einen Typ aus einem anderen Lied früherer Tage erinnert: I don’t know what I want but I know how to get it.

Was immer technisch möglich ist, er will es haben. Und zwar sofort. Egal, ob es sinnvoll ist oder nicht. Was den Entwickler in eine äußerst unkomfortable Situation bringt, sobald er seine Meinung dazu äußert. Er, der alles bestimmende Auftraggeber, mag das nicht.

Um es gleich zu Beginn klarzustellen: Natürlich hat der Auftraggeber das Recht, seine Anforderungen und Wünsche zu formulieren, Vorgaben zu geben, die der Entwickler ernst zu nehmen und – im echten Bedarfsfall – zu erfüllen hat. Es ist schließlich seine Aufgabe, das Geschäft seiner Kunden zu forcieren, nicht, es zu boykottieren. Aber sobald der engagierte und wohlmeinende Entwickler gegen unnötige und dadurch überflüssige Anforderungen argumentiert, läuft er Gefahr, als unwillig und ignorant disqualifiziert zu werden. Vor allem, weil er die erwartete Unterordnung vermissen lässt.

Dabei sollte nicht übersehen werden, dass auch der willfährige, unterwürfige Entwickler Gefahr läuft zu scheitern, wenn das gewünschte – und gelieferte – Ergebnis am Ende doch nicht die erhofften Effekte produziert.

Für all diese Dissonanzen gibt es verschiedene Erklärungen, von denen 4 jedoch besonders auffällig und daher im Umgang miteinander entsprechend schädlich sind:

• Unvermutete Sprachbarrieren
• Unzumutbare Erpressungsversuche
• Ständige Suche nach Defiziten
• Permanente Meinungsänderung

Unvermutete Sprachbarrieren

Auch wenn der Ich-habe-hier-das-Sagen-Auftraggeber – im Regelfall ein Manager, kein Anwender – und der Entwickler mit derselben Muttersprache aufgewachsen sind, sie sprechen nicht dieselbe Sprache. Selbst wenn sie dieselben Wörter, identische Idiome und Terminologien benutzen, sie verstehen einander nicht, werden sich nie verstehen. Recht hat am Ende sowieso derjenige, der zahlt.

Zwar ist es schon einige Jahre her, dass Joel Spolsky sich zu diesem Thema geäußert hat, sein Standpunkt hat allerdings nichts von seiner Aktualität und Gültigkeit verloren:

“I promised to tell you a secret about translating between the language of the… nontechnical managers… of your software and the language of programmers. You know how an iceberg is 90% underwater? Well, most software is like that too – there’s a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers. And if you take into account the fact that about half of your time is spent fixing bugs, the UI only takes 5% of the work. And if you limit yourself to the visual part of the UI, the pixels, what you would see in PowerPoint, now we’re talking less than 1%. That’s not the secret. The secret is that People Who Aren’t Programmers Do Not Understand This.”
Quelle: The Iceberg Secret, Revealed von Joel Spolsky

Was lernen wir daraus? Beim Dialog zwischen Auftraggeber und Entwickler sollte zumindest eine dritte Person involviert sein, die beide Sprachen – fließend – spricht und gleichzeitig das Zeug zu einem Dolmetscher und Moderator hat.

Unzumutbare Erpressungsversuche

Die mit Abstand unerfreulichste Erkenntnis für – jeden – Dienstleister lautet: Es gibt immer jemanden, der es billiger macht, der unterwürfiger ist. Dabei nicht notwendigerweise besser. Aber das zählt dann gerade nicht (dafür umso mehr am Tag der Abrechnung, wenn alles nicht so läuft, wie erwartet).

Der engagierte Entwickler sieht sich nicht selten mit dieser unverhohlenen Art versuchter Erpressung konfrontiert. Ein Spiel, auf dass er sich auf keinen Fall einlassen sollte, es sei denn, er möchte, dass bis zum Ende aller Tage (in diesem Fall des Projekts) ein Damoklesschwert über seinem Haupt hängt. Er ist besser beraten, sich stets vor Augen zu halten, dass er Software und Services verkauft – nicht seine Seele.

Ständige Suche nach Defiziten

Den Ich-habe-hier-das-Sagen-Auftraggeber interessieren zunächst einmal nicht die Vorzüge oder überlegenen Merkmale einer Software. Damit würde er ja seine beherrschende Position aufgeben. Stattdessen macht er sich zuerst auf die Suche nach vermeintlichen Unzulänglichkeiten und Defiziten, versucht Lücken zu finden, die er in erster Linie über fehlende Knöpfe oder aus seiner Sicht fehlende Funktionen identifiziert.

Was will uns das sagen? Das Fehlen einer Funktion ist häufig nichts anderes als die subjektive Sicht einer einzelnen Person auf eine – von anderen mehrheitlich als voll funktionsfähig anerkannte – Software. Soll nun die Sichtweise dieser einen Person zum Maßstab der Bewertung einer Software erhoben werden? Könnte nicht vielmehr der Fall sein, dass diese eine Person lediglich nach oberflächlichen (Knopf) oder unterirdischen (Featuritis) Kriterien entscheidet? Kaum vorstellbar, dass eine nicht vorhandene Für-den-unglaublichen-Eventualfall-Funktion das Entscheidungskriterium für eine Software sein soll, die über viele Jahre mit profunder Fachkenntnis und Programmierkompetenz entwickelt wurde und permanent weiterentwickelt wird.

In Jared Spool’s Podcast äußert sich Hagan Rivers zu diesem “Get The Features In Mode” und stellt ihn in direkten Vergleich zu dem für Anwender deutlich wichtigeren Thema, der Eliminierung von “Pain Points”. Hier sieht sie den wahren Handlungsbedarf, nicht in der Integration vermeintlich fehlender Funktionen:

“You should have a good list of your user’s current pain points. What’s aggravating them in the software? Every time you do a release, you ought to knock a couple of those off that list. I worked with a client. We did some field studies. We watched the users using the software. I made that list of pain points…One of them, it was seven clicks to do this one thing that people did a lot…We fixed it so it was one click…When we finally showed the new version to the users, they were more excited about that one little fix than they were about the six other new features that they had also wanted.”
Quelle: Time Traveling with Enterprise Applications von Jared M. Spool

Die Reklamation fehlender Funktionen sollte einen Entwickler nie aus der Ruhe bringen (“Fehlt? Was fehlt?”), sondern ihn vielmehr ermutigen, auf die wirklich wichtigen Themen wie “Pain Points” einzuzahlen. Denn davon gibt es immer reichlich.

Permanente Meinungsänderung

Angenommen, der Entwickler gibt nach und beginnt mit der Umsetzung der nach seiner inneren Überzeugung überflüssigen Anforderungen (Wir erinnern uns: 90% des Arbeitsaufwands). Im schlimmsten Fall auch noch zu einem vereinbarten Pauschalhonorar, nur um sich in der Folge mit ständig geänderten Aufgabenstellungen konfrontiert zu sehen. Wo wird das für ihn enden? Mit einiger Sicherheit in der Psychiatrie.

Zumindest wird er in einer Endlosschleife von Programmieraufwand gefangen sein, für den dann dummerweise nicht endlos viel Geld gezahlt wird. Welches Ergebnis kann ein Auftraggeber unter diesen Voraussetzungen erwarten? Programmiert auf höchstem Niveau von Frustration, Verzweiflung und internem Druck durch das eigene Controlling. Man möchte das nicht zu Ende denken.

Die Softwarefirma kommt gar nicht darum herum, diese Meinungsschwankungen von Anfang an zu unterbinden. Notfalls sogar durch vertraglich festgelegte Rahmen- und Ausschlussbedingungen. Sonst beschäftigt sie am Ende mehr Anwälte und Gerichte als Entwickler. Vertragliche Festschreibung wird aber ein Problem auf gar keinen Fall lösen: Entwickler sind nicht Bestandteil einer Maschinerie, sondern Menschen, denen Respekt und Anerkennung mindestens so viel Wert sind wie ihr Honorar. Frustration und Demotivation können nicht mit Geld kompensiert werden.

Fazit

Verträge können nicht alles regeln. Darum müssen sich Auftraggeber und Entwickler schon im Vorfeld über die Vorgehensweise im Klaren sein und einigen. Keine sinnlosen Anforderungen, keine ständigen Meinungswechsel, keine Wer-zahlt-bestimmt-Attitüde. Die überzeugendsten Argumente, die der Entwickler vortragen kann, sind ohnehin sein anerkanntes Produkt, dessen ständige Weiterentwicklung sowie die Akzeptanz im Markt. Dann braucht er auch keine Übersetzungshilfen. Resultate sprechen für sich. Und das ist eine Sprache, die jeder versteht.