Interview mit David Tanzer

Der Kunde hat immer (Un)Recht

Hartmut Schlosser
David Tanzer

Wissen Ihre Kunden immer, was sie wollen? Und ist das, was sie wollen, auch das, was sie benötigen? Nun, wie oft kommt es vor, dass das beauftragte IT-Projekt mit unrealistischen Vorstellungen der Kunden verbunden ist! Dass die IT deshalb nicht blind die Vorgaben der Kunden umsetzen sollte, vertritt David Tanzer in seinem W-JAX Talk „Der Kunde hat immer (Un)Recht„. Im W-JAX Countdown erklärt David, wie man zu einem besseren Verständnis der Kunden-Bedürfnisse – und damit zu zufriedeneren Auftraggebern kommt.

JAXenter: Während Generationen von Marketing-Experten mit dem Spruch „Der Kunde ist König“ hausieren gingen, sagst du in deiner W-JAX-Session: „Der Kunde hat immer Unrecht.“ Lagen vorher also alle falsch?

David Tanzer: Der Kunde ist natürlich König: Unser Ziel sollte immer sein, unsere Kunden zufriedenzustellen. Wenn wir aber immer genau das machen, was der Kunde verlangt, können wir dieses Ziel oft nicht erreichen. Unsere Kunden sind z.B. meistens keine UX-Design-Experten, haben aber ganz genaue Vorstellungen, wie eine Anwendung auszusehen und zu funktionieren hat. Das führt im schlimmsten Fall zu unergonomischen Anwendungen, die den Benutzer bei der Arbeit mehr behindern als unterstützen.

JAXenter: Kannst du ein Beispiel aus deiner Praxis nennen: Wo liegt das, was der Kunde verlangt, und das, was er eigentlich wünscht, auseinander?

David Tanzer: Den Bereich UX-Design – und Design allgemein – habe ich ja bereits erwähnt. Ich habe auch schon erlebt, dass Kunden Technologieentscheidungen treffen wollten. Auch im Bereich Workflows und Geschäftsregeln müssen wir vorsichtig sein: Unsere Kunden wollen oft nur, dass wir ihren derzeitigen Workflow etwas besser unterstützen. Obwohl man mit einer innovativen Software die selben Ziele ganz anders – und effektiver – erreichen könnte.

Außerdem wollen unsere Kunden manchmal die Anwendung vergolden – sie wünschen sich also zu viele unnötige Features. Bei einem meiner Kunden wurde z.B. ein Release durch ein Feature, das nur von sehr wenigen Benutzern verwendet werden würde, um mehrere Monate verzögert.

JAXenter: Aus meiner Praxis kenne ich aber auch Entwickler, die plötzlich Entscheidungen über Dinge treffen, die sie eigentlich nicht entscheiden sollten. Da werden Features eingebaut, verändert, weggelassen  – oftmals aufgrund rein technischer Argumente  -, und es entsteht schließlich eine Software, die so niemals vom Auftraggeber gewollt ist. Wie kann man das vermeiden?

David Tanzer: Wenn es nur technische Argumente waren und die Software dadurch schlechter wurde, ist das natürlich nicht in Ordnung. Wenn wir es aber schaffen, die eigentlichen Ziele unseres Auftraggebers durch innovative Ideen auf eine andere,  bessere Weise zu erreichen, dann ist das doch eine gute Sache. Auch wenn das Endprodukt vielleicht ganz anders aussieht, als sich das der Auftraggeber ursprünglich vorgestellt hat.

Es muss aber auf jeden Fall jemanden geben, der das gesamte Produkt im Auge behält und Entscheidungen bezüglich Funktionalität, Bedienbarkeit, Return on Investment, usw. trifft. In Scrum ist das zum Beispiel der Product Owner. Wenn es so jemanden gibt, sollte es nicht passieren, dass Entwickler alleine aus technischen Gründen Features ändern. Auch wenn sie vermutlich ein Mitspracherecht haben sollten.

JAXenter: Stellen wir uns mal ein internes Projekt vor, bei dem die Situation „Kunde – Dienstleister“ nicht so klar ist. Zum Beispiel: Die Entwickler einer Werbeagentur bauen ein Tool für das Einstellen von Anzeigen auf einer Webseite. Die Entwickler sehen sich selbst als zentrale Abteilung, die den Laden am Laufen hält. Die Anzeigenabteilung aber ebenfalls. Jeder will das letzte Wort haben, wie das Tool auszusehen hat. Agile ist allen zwar ein Begriff, wird aber nicht wirklich praktiziert. Wie würdest du hier als „Mediator“ reagieren?

David Tanzer: Es ist in so einem Fall wahrscheinlich sogar egal, wer Kunde und wer Dienstleister ist. Vielleicht sind es wirklich zwei unabhängige Abteilungen, die gemeinsam ein Ziel erreichen sollen. Sie müssen aber auf jeden Fall klären, welche Abteilung wofür zuständig ist und wer welchen Beitrag zum gemeinsamen Ziel leisten kann. In jeder Abteilung gibt es die unausgesprochene Annahme „Die anderen sind unsere Dienstleister“. Diese müssen wir ersetzen durch ein gemeinsames Verständnis darüber, wie die Zusammenarbeit funktionieren soll. Als Mediator würde ich also versuchen, die beiden Abteilungen an einen Tisch zu bekommen, um dieses gemeinsame Verständnis zu schaffen.

JAXenter: In deiner zweiten W-JAX-Session sprichst du über Offline-Webanwendungen. Worüber geht es genau?

David Tanzer: In dieser Session zeige ich, wie man Webseiten und Webanwendungen auch offline verfügbar machen kann. Dafür braucht man zumindest eine Datenbank im Browser und eine Möglichkeit, um Dateien beim Benutzer offline verfügbar zu machen. Beides gibt es mit HTML5. Ich werde anhand von Codebeispielen zeigen, wie man mit diesen Technologien eine Webseite offline bedienbar machen kann.

JAXenter: Wann macht es aus deiner Sicht Sinn, einen Rich Client zu nutzen, wann eine Webanwendung mit Offline-Fähigkeiten?

David Tanzer: Man muss seine Zielplattformen genau kennen. Die benötigten Technologien wurden zum Beispiel unter iOS lange Zeit nicht richtig unterstützt.

Weiters muss man sich überlegen, welche Hardwarefunktionen der Geräte man verwenden will. Es gibt noch nicht für jede Hardware eine funktionierende HTML5-Anbindung – aber das wird immer mehr.

Für performancekritische Anwendungen wird auch eine „Native App“ besser sein. Weiters kann man Native Apps in App-Stores platzieren, und sie sehen genau so aus, wie alle anderen Anwendungen auf dem Zielgerät.

Webanwendungen haben aber zwei große Vorteile: Man schreibt sie nur einmal für alle Plattformen. Und das Deployment und Update funktioniert einfach und schnell. Man stellt eine neue Version auf einen Webserver, und alle Benutzer haben sofort die neue Version. Niemand kann vergessen, ein Update einzuspielen.

JAXenter: Vielen Dank für dieses Interview!

David Tanzer ist seit 2006 als freiberuflicher Berater, Trainer und Softwareentwickler tätig. Im Rahmen dieser Tätigkeit beschäftigt er sich mit Softwarequalität in agilen Projekten, also unter anderem mit den Themen Architektur in agilen Projekten, Softwaredesign, agiles Anforderungsmanagement und Testen. David „spricht“ mehrere Programmiersprachen und ist als Entwickler sowohl im Frontend als auch im Backend – vor allem von Webanwendungen – zu Hause.

Talks auf der W-JAX 2014:

Der Kunde hat immer (Un)Recht
Offlinewebanwendungen

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: