Was passiert eigentlich, wenn der Kunde anruft und sagt, "Ich hab da ein Problem, bei Funktion X erscheint Y, aber da sollte eigentlich ein Fenster aufgehen und Z stehen!". In den meisten Fällen hat die den Anruf annehmende, liebliche Supportmitarbeiterin die Anwendung so gut im Kopf, daß sie rundheraus antworten kann "Ja guter Mann, Z gibt es seit Version 8.15 nicht mehr, jetzt erscheint Y!". Wenn es sich nun um eine äußerst komplexe Angelegenheit handelt, die Geschäftsvorfälle kompliziert und voller versteckter Abhängigkeiten sind, kann sie einen Rückruf ankündigen. Sie öffnet ihre Schublade und sucht in der Dokumentation nach dem entsprechenden Vorfall. Sie findet die Beschreibung der aktuell ausgelieferten Version und kann gleich entscheiden, ob es sich um einen Fehler handelt.
Hat sie keine (aktuelle) Dokumentation, greift Plan C. Abmarsch zu dem für diesen Kunden zuständigen Consultant. Der hat das Ganze ausgeheckt, er müßte es wissen.
Nun kann es sein, daß dieser Mensch das Ganze auch nicht mehr so richtig durchdringt. Wie war das noch gleich wenn Fall A und B zutreffen und der Kunde X aufruft?... Hm. Wir gehen auf Nummer sicher und holen einen Entwickler! Der hat in der Regel natürlich auch keine Antwort parat, da er es a) entweder gar nicht selbst implementiert hat oder b) aus Entwicklersicht gar nicht ohne weiteres beantworten kann, da er ja tagsüber entwickelt und nicht die Anwendung bedient. Es kommt zum Äußersten: Mit dem Debugger bewaffnet stellt der Entwickler die Situation beim Kunden nach und wurstelt sich Schritt für Schritt durch die Anwendung, bis er verstanden hat, weshalb Y auftaucht. Kein Fehler! Der Kunde hat nur vergessen, vorher N und M richtig einzustellen.
Ich sage mal voraus, das eine Firma nicht viel Gewinne machen kann, wenn der letzte Fall zu häufig vorkommt. Ähnlichkeiten mit mir bekannten Firmen sind rein zufällig und höchstens beiläufig beabsichtigt.
Dokumentation
4
