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.
4 thoughts on “Dokumentation”
Leave a Reply
You must be logged in to post a comment.
das szenario draengt sich einem ja fast nie auf wenn man mal derjenige ist der anruft, oder ? um solchen situationen vorzubeugen gibts ja prozesse in denen wohldefiniert drin steht wer wann was udn wieviel auzuschreiben hat.
das geht soweit dass es tools gibt die staendig statistiken darueber fuehren wieviel kommentarzeilen + zeichen auf wieviele codezeilen in irgendwelchen programmen folgen und das sogar mit externen dokumenten korrellieren. das sagt nun sogar zunaechst nich einmal etwas ueber die qualitaet der dokumentation aus.
bei meiner hausmarke resultierten die prozesse sogar in einem buch das sich “practical software metrics for project management and process improvement nennt”. damit die dokumentation nicht nur reichhaltig sondern auch qualitativ hochwertig ist, wird hier die “Flesch-Kincaid”- redability metrik (http://en.wikipedia.org/wiki/Flesch-Kincaid_Readability_Test) eingefuehrt die vor release eines Produktes gewaehrleisten soll, dass die netten fraeuleins vom telefon die doku auch lesen und verstehen koennen.
nunja. ueber sinn und unsinn dieser metriken laesst sich treffich streiten.
und als ich noch bei der hausmarke selbst mit software- enwicklung konfrontiert war, hat weder der verantwortliche abteilungsleiter noch einer seiner projektleiter / manager irgendwas von den prozessen und oder der dokumentation der Prozesse / dem buch gewusst.
insofern “gute nacht deutschland”
Eine Metrik hilft leider nicht viel (wie du schon sagst), wenn es ein Loch in der Kette gibt. Dokumentation ist zwar wichtig, aber IMO mehr im Hinblick darauf festzuhalten, was dem Kunden denn eigentlich geliefert wurde und in welcher Version.
Daß der Support daraus sinnvolle Hilfe ziehen kann, steht auf einem anderen Blatt (vor allem, wenn der Text von einem Entwickler geschrieben wurde).
Es gibt aber einen wirkungsvollen Kurzschluß, jedenfalls für kleinere Firmen (die den Kundensupport noch nicht nach Nirwanistan ausgelagert haben): Der Support und die Tester sind dieselbe Abteilung. Wenn einer mal eine Anwendung intensiv getestet hat, kennt er sich damit aus, vor allem auch mit den Änderungen in den erst kürzlich gelieferten Versionen. Das setzt natürlich ein paar Investitionen im Personalbereich voraus, die sich meiner Meinung nach aber schnell bezahlt machen.
Das Support und QA dieselbe Abteilung sind hat sicherlich Vorteile (wer die Anwendung getestet hat weiß danach worum es geht (zumindest in den getesteten Teilen)). Das setzt aber auch vorraus, das eine getestete Version (von Bugfixes mal abgesehen) eine Weile im Einsatz bleibt. Wenn sich alle paar Wochen Funktionalitäten grundlegend ändern ist sich auch der gute Tester bald nicht mehr sicher wie es jetzt grad aktuell funktionieren sollte.
Das ganze macht (je nach Releasehäufigkeit) sowohl Test als auch QA aus meiner Sicht zu “full time jobs”. Wenn man gerade mit dem Test einer Anwendung beschäftigt ist, ist es ungemein Schwierig Fragen zu alten Versionen zu beantworten bzw. Bughunting zu betreiben.
Es mag Wirtschaftlich von Vorteil sein beide Abteilungen als eine zu betreiben, aus meiner Sicht wäre es aber sinnvoller Personen zu haben, die sich ganz auf das Testen (und das optimieren der Testprozesse) konzentrieren können und Personen die sich gut mit der Anwendung auskennen und dem Kunden Fragen beantworten können. Es muss sicherlich eine gute Schnittstelle zwischen beiden Abteilungen geben, und es gibt auch Redundanz beim Know-How aber ich komme immer mehr von diesem Gemisch von Support und QA ab.
Das Testen wird leider oft auch nicht richtig ernst genommen. Hier etwas mehr zu investieren zahlt sich langfristig aus, da es die Wartungskosten senkt:
Personell aufstocken: Vollzeitsoftwaretester einstellen. Das können aber auch Leute aus der Entwicklung sein, speziell Berufseinsteiger oder auch neue Mitarbeiter.
Automatisierte Tests: Skripte, Unit Tests