Wie viele Fehler sind zu verzeihen?

Veröffentlicht am 22. Juli 2013 von Markus Härtig. Abgelegt in Kategorie: Customer Experience Analytics, Meinungen, Projekte, Usability | 0 Kommentare »
Wie viele Fehler sind zu verzeihen?

Natürlich möchte man stets, dass Software fehlerfrei funktioniert und auch Kampagnen reibungslos laufen. Doch leider ist der Wunsch selten Realität. Je komplexer ein Vorhaben ist, desto wahrscheinlicher ist es, dass sich Fehler einschleichen. Warum sonst werden neue Applikationen intensiv getestet, bevor sie live gehen? - Man möchte ein einwandfreies Produkt liefern. Dieser Qualitätsanspruch ist gut und wichtig, denn wer an seine Kunden ein fehlerhaftes Produkt ausliefert, gefährdet nicht nur das Wohlwollen des Kunden, sondern auch seine Reputation.

"Den FDIV-Bug leistete sich 1994 Intel mit seinem Pentium Prozessor, der mit bestimmten Werten falsche Ergebnisse bei einer Gleitkomma-Division erzeugte. Der Fehler wurde erst anderthalb Jahre nach der Markteinführung entdeckt und hatte für die wenigsten damaligen Anwendungen eine tatsächliche Auswirkung. Allerdings bedeutete der Fehler einen erheblichen (Image-)Schaden für Intel."

Während ein Mangel an einem physischen Produkt meist offensichtlich ist, so sind Fehler in einem digitalen Erzeugnis tückischer, schwerer zu finden und erheblich schwerer zu beseitigen. Schließlich gibt es Abhängigkeiten und das Beseitigen eines Fehlers darf nicht das Auftauchen eines anderen begünstigen. Aber wie viel Fehler ist noch verzeihbar? Was kann man überhaupt als Fehler werten? Wie kleinlich muss der Maßstab angesetzt werden?

Machen wir uns nichts vor. Perfekt gibt es einfach nicht. Man kann sich dem Idealzustand annähern, aber es wird immer etwas geben, was man noch optimieren kann. Fehlverhalten, welche die Ausführung der eigentlichen Aufgabe erschweren oder gar unmöglich machen, sind gravierend und müssen umgehend behoben werden, das ist auch klar.

Aber was kann man machen, wenn man den Fehler nicht reproduzieren kann? Man hört nur: "Bei mir funktioniert das nicht!" Was ist wenn die Anwendung nur bei einem aus 10.000 nicht funktioniert? Was ist, wenn man keine Informationen zu den Umständen hat, unter denen der Fehler aufgetreten ist? Eine Blackbox für den, der den Fehler beseitigen soll.

Möglicherweise gibt es ja gar keinen Fehler, aber der Anwender macht etwas falsch. Vielleicht sind auch die Voraussetzungen nicht gegeben oder eine äußere Macht verhindert das Gelingen. Konkret fällt mir hier die Kampagne eines Kunden ein. Es geht hier um eine schicke Webanwendung, mit einem Registrierungsformular am Ende. Drum herum ist eine komplexe Kampagne, mit vielen Abhängigkeiten, gestrickt. Alles beginnt mit einem Mailing, in dem man den Link auf das Portal findet. Und auch hier, auf der eigentlichen Webseite, sind einige wenige Voraussetzungen nötig (z.B. JavaScript). Jeder halbwegs aktuelle Browser unterstützt JavaScript, HTML5 und CSS3. Selbst wenn man davon ausgeht, dass die Zielgruppe aus technik-affinen Anwendern besteht, kann man dennoch nicht sicher sein, dass jeder Empfänger die nötigen Voraussetzungen mitbringt, um reibungslos die Kampagne zu durchlaufen. Irgendwer wird aus irgendeinem Grund immer Schwierigkeiten haben, die Kampagne so zu nutzen, wie man es angedacht hat.

Gibt es hier einen Richtwert, einen Punkt, ab den man sagen kann, dass die Kampagne gescheitert ist? Klar, wenn mehr als die Hälfte Fehler beobachtet oder aus Usability-Gründen nicht zurechtkommt, ist das Vorhaben klar gescheitert. Aber was ist, wenn der Anteil derer, die sich beschweren im Promillebereich liegt? Ist es unverschämt davon auszugehen, dass das Problem in diesem Fall beim Anwender liegt und nicht bei der Anwendung - wenn es nur 0,02% sind, bei denen es nicht funktioniert? Ist es wert, für diese kleine Gruppe auf Fehlersuche zu gehen, um am Ende herauszufinden, dass es eigentlich doch hätte gehen müssen?

Wir finden, dass jeder Bug-Report ernst genommen, aber auch relativiert werden muss. Mit Aussagen wie "Bei mir funktioniert das nicht!" kann man in der Regel wenig anfangen. Nur eine exakte Fehlerbeschreibung hilft, den Fehler einzugrenzen und zu beseitigen. Am Ende war es vielleicht ja doch nur eine kurzzeitige Server-Downtime, veraltete Cache-Einträge oder das Defizit des Anwenders und die Suche nach einem Fehler, den es gar nicht gibt, war überflüssig. Dennoch sollte man jedem, der ein Fehler beobachtet, zuhören und das Anliegen ernst nehmen…

Wie denkt Ihr darüber?

Weiter empfehlen:

Kommentar schreiben

biuquote
Loading