Was wir anders machen als andere ... ein Beispiel aus dem Alltag

04.08.2017

Eine Geschichte aus dem Alltag, die zeigt, wie wir uns von (manchen) anderen unterscheiden.

Ein Kunde hatte in seinem OXID PE ein kostenfreies Modul eines Zahlungsanbieters installiert, doch es wollte nicht richtig laufen. Im Adminbereich gab es einen ärgerlichen Fehler. Wenn er auf den Menüpunkt klickte, der die Moduleinstellungen öffnen sollte, wurde er aus dem Adminbereich ausgeloggt. Wir haben das Modul in einer OXID CE bei uns installiert, um zu prüfen, ob dort der Fehler auch auftritt. Tat er nicht.

Darum wandten wir uns an den Modulhersteller. Wir dachten (naheliegenderweise), dass dieser den Fehler schneller und zuverlässiger analysieren und beheben kann als wir. Schließlich kennt er sich mit dem Modul am besten aus, kennt die Tücken, und wenn es sich um einen Modulfehler handelt, der vielleicht auch nur in der PE auftritt, würde er auch gleich den Bugfix liefern können.

Der Modulhersteller war durchaus freundlich und schnell und sandte einen Supportauftrag, den der Kunde vorab unterschreiben musste. Darin stand das Übliche - dass die Analyse und Fehlerbehebung kostenpflichtig sein würde, wenn es sich nicht um einen Modulfehler handle. Da wir relativ sicher waren, dass es sich um einen Modulfehler handeln müsse, unterschrieb der Kunde den Vertrag, der erstmal auf eine Stunde begrenzt war, und wir richteten entsprechende Zugangsdaten auf dem Shop ein, damit die Supportmitarbeiter direkten Zugriff auf das Problem hatten.

Auch die Antwort kam relativ schnell. Schon am nächsten Tag erhielten wir die Information, dass das Modul in einer eigenen Shopinstallation PE getestet wurde, und der Fehler nicht reproduziert werden konnte. Es müsse sich also um einen Fehler im Shop unseres Kunden handeln. Die Stunde Kontingent sei nunmehr aufgebraucht und für die weitere Analyse sei eine Freigabe weiterer Stunden (Mehrzahl!) notwendig.

Wir waren total geplättet.

Der Modulhersteller hatte in der Tat die Stunde Kontingent verwendet, um das Modul in seiner Shop-Installation zu testen - was eigentlich zum normalen Entwicklungsprozess gehören sollte. Unsere Zugangsdaten hatte er komplett ignoriert, und nun waren für die Analyse weitere Stunden (Mehrzahl!) nötig. Auf unseren Hinweis, dass doch das Testen des Moduls in einer normalen Shopinstallation schon vorausgesetzt werden können müsse, antwortete der Modulhersteller leicht erbost, er lasse sich von uns nicht seine Prozesse und Vorgehensweisen diktieren. Ah ja.

Da das Modul unverschlüsselt war (zum Glück), rieten wir unserem Kunden dann erstmal davon ab, die weiteren Stunden Kontingent freizugeben und nahmen uns etwas Zeit, das Problem doch selbst eingehender zu analysieren. Das Ende vom Lied war, dass eine alte Modulinstallation der neuen reingegrätscht hat und zu den Fehlern führte, da die alten Dateien unter gleichen Namen in anderen Verzeichnissen lagen (statt in modules z. B. direkt in core). Innerhalb einer Stunde hatten wir im Shop das Problem nicht nur analysiert, sondern auch behoben! Unser Kunde war darüber natürlich sehr glücklich.

Ich will niemandem etwas Böses unterstellen. Aber der normale Modultest sollte doch zum Entwicklungsprozess gehören, der dem Kunden nicht extra in Rechnung gestellt wird. So ein Test dauert auch nie im Leben eine Stunde, es sei denn der gesamte Shop wird neu aufgesetzt - was aber auch gar nicht nötig war, da der Hersteller ja Zugangsdaten zum Kundenshop hatte. Der Hersteller konnte nach der Stunde noch nicht einmal sagen, was er vermutet, woran es liegen könnte!

Ich habe aber noch zwei ziemlich böse Gedanken, die den Support des besagten Modulherstellers angehen, und mich (wenn ich ein wenig negativ veranlagt wäre, was ich zum Glück nicht bin) beinahe denken lassen würde, das ist eine Masche, um zusätzlich Geld zu verdienen:

Erstens sollte ein Modul so programmiert werden, dass solche Probleme mit alten Installationen gar nicht erst auftreten können. Wenn man die Struktur eines Moduls im Laufe der Zeit an die Entwicklungen von OXID eShop anpasst, dann ist das super. Aber es ist dann kein riesiger Mehr-Aufwand, eine kleine Prüfung einzubauen und eine Warnung auszugeben, wenn eine alte Modulinstallation vorgefunden wurde. Idealerweise könnte man aber mit überschaubarem Aufwand auch bei Aktivierung des Moduls alte Modulreste einfach automatisch entfernen.

Zum Zweiten kann ich mir beim besten Willen nicht vorstellen, dass noch nie ein Anwender des Moduls Probleme dieser Art hatte, denn so exotisch war das jetzt nicht. Wer liest schon jedes Mal eine Installationsanleitung, Hand aufs Herz? Der Modulhersteller sollte diesen Fehler demnach kennen - und somit locker in einer Stunde (wenn er sie denn wirklich berechnen möchte) beheben können.

Dass Module vor dem Release getestet werden, gehört für mich nicht zum Service, sondern sollte selbstverständlich sein. Natürlich lassen sich nicht alle Fehler so vorab finden, denn jeder Shop ist anders, verwendet andere Module, ein anderes Theme und andere Modul- und Shop-Einstellungen. Doch wenn an uns ein (mutmaßlicher) Fehler herangetragen wird, dann prüfen und analysieren wir diesen natürlich bevorzugt im Shop des Kunden. Denn natürlich ist der Fehler bei uns nicht aufgetreten, sonst hätten wir das Modul ja nicht released! Und nur, wenn die Fehlerursache dann tatsächlich beim Kunden liegt, wird der Aufwand dafür in Rechnung gestellt.

Sharing is caring - teile den Beitrag

Ähnliche Beiträge

Beitrag kommentieren