Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

24.07.1987 - 

Neue Aufgaben in den Sektoren Software und Produktgeschäft:

Qualitätsingenieur - mehr als nur Kontrolleur

MÜNCHEN - Qualitätskontrolle und anwendergerechte Dokumentation gewinnen an Bedeutung. Deshalb sind künftig, so die Auffassung der mbp Software & Services GmbH, Dortmund, auch zwei neue Tätigkeitsfelder stark nachgefragt. Denn der Trend von der Individualsoftware aber Baukastensysteme (Produktkerne) führt für immer mehr Anwendungen hin zu vorkonfektionierten Produkten.

Das hat erhebliche Auswirkungen auf den Softwaremarkt. Vor allem kleinen und mittleren Anbietern der in Deutschland eher zergliederten Software-Landschaft fehlt hier oft die Finanzkraft. Das Produktgeschäft verlangt neben einem geschliffenen Marketing ein hohes Maß an Vorfinanzierung. Zwei bis drei Jahre sind das mindeste, mit dem man heute bei einem halbwegs anspruchsvollen Produkt von der Idee bis zur Vermarktung rechnen muß. Dazwischen liegen Marktanalyse, Produktdefinition, Produktion, Dokumentation, Test, Installation bei Pilotanwendern, Redefinition von Teilbereichen und jetzt parallel laufend:

- intensives Marketing (Produkteinführung),

- gründliche Qualitätstests,

- anwendergerechte Dokumentation,

- Vorbereiten von Schulungspaketen.

Dabei gewinnen zwei Tätigkeitsbereiche an Kontur: die Qualitätskontrolle und die anwendergerechte Dokumentation.

Das sind zwei unterschiedliche Tätigkeiten, die zu neuen Berufsbildern führen.

Bekannt ist, daß in 1000 Zeilen Programmcode - höchste Programmier- und Testqualität vorausgesetzt - ein Programmfehler steckt. In der Regel sind es mehr. Bei Softwareprodukten, die von vielen Nutzern mit unterschiedlichen Ausprägungen eingesetzt werden, sind die Anwender oft unfreiwillige Qualitätskontrolleure.

Sie stoßen auch bei Produkten, die schon längere Zeit auf dem Markt sind, immer wieder auf Mängel und Fehler.

Ein Softwareentwickler findet beim Test seiner Software oft nur die Fehler, die er sucht. Er ist froh, wenn unter einem gegebenen Datensatz die definierten Funktionen "laufen". Der Qualitätsingenieur geht ganz anders vor. Er sucht nach einem ausgeklügelten Testraster nach Fehlfunktionen, Mängeln und Fehlern. Für ihn gilt: Wer in 10 000 Zeilen Programmcode nicht 80 Fehler gefunden hat, hat schlecht getestet. Im Gegensatz zum Programmautor hofft er, daß er Fehler findet.

Nach drei- bis fünfjähriger Programmiererfahrung zieht es ihn zu neuen Ufern. Er bringt besondere Talente mit: Er ist nicht introvertiert, also kein "Arbeiter im Kämmerlein", aber auch kein "Überflieger". Er hat sich die mittleren Brettstärken zum Bohren ausgesucht, arbeitet aufgeschlossen und gern im Team. Praxis und Theorie sind für ihn nicht unterschiedliche Welten. Theorien des Projektmanagements und Vorgangsmodelle vermittelt er überzeugend und praxisnah, weil er seine didaktische Begabung anzuwenden weiß, wie seine Präsentationserfahrung.

Informationsinseln mit Festland verbinden

So tritt er seinen Kollegen in den Entwicklungsabteilungen nicht als Kontrolleur, sondern als Vertrauensmann entgegen. Ihm fällt es leicht, Akzeptanz zu gewinnen, er kann in unterschiedlichen hierarchischen Ebenen bis hinauf zur Geschäftsführung überzeugen.

Diese Aufzählung von Idealeigenschaften ließe sich beliebig weiter fortführen. Sie deutet an, wie schwer es für Softwarehäuser ist, eine eigenständige Qualitätssicherung aufzubauen, die ihrem Namen Ehre macht:

- Es fehlen geeignete Mitarbeiter.

- Es fehlt eine geeignete Struktur.

- Es fehlt der Karriereweg.

Die Aufgabe beschränkt sich nicht auf den Bereich der Softwareproduktentwicklung, auch das Produktgeschäft bietet ein Betätigungsfeld für den Qualitätsingenieur.

Das Aufgabenfeld dieser neuen Position muß abteilungs- und bereichsübergreifend angelegt sein, damit ein umfassender Aktivitätsüberblick gewährleistet ist.

Nur so kann der Qualitätsingenieur verhindern helfen, daß überall daß Rad neu erfunden wird. Er muß "Informationsinseln" mit dem "Festland" verbinden und lokal entstandene Ideen und Hilfsmittel aufgreifen. Nach genauer Prüfung wird er sie in eine Modul-Datenbank integrieren. Dadurch beeinflußt er neben der vordergründigen Qualitätskontrolle mit früh ansetzender Beratung die Produktivität aller positiv.

Er übernimmt damit eine wichtige Funktion auf dem Weg zu einer leistungsfähigen, qualitätsorientierten Softwareentwicklung.

Also: Dokumentation - ein alter Hut? Ist der Technical Writer die Lösung? Wenn ja, wie wird man das?

Garant für kurze Anlaufzeiten

Globales Marketing und erfolgreicher Produktvertrieb decken schnell Schwächen herkömmlicher Dokumentation auf. Es gibt viele Gründe die trotz guter Vorsätze zu einer wenig aussagekräftigen Dokumentation fuhren:

- Der Entwickler entwickelt auch die Dokumentation.

- Die Zeit war zu knapp.

- Die Software ist der Dokumentation um zwei Schritte voraus.

- Man beschreibt die Leistung der Software und vergißt den Benutzer den die Anwendung interessiert.

- Man kennt den Kreis der Zielpersonen nicht oder nur ungenau.

- Der Anwender liest sich "tot", findet aber nicht, was er sucht.

- Auf unterschiedlichen Kenntnisstand nimmt die Dokumentation keine Rücksicht.

Früher wußte man, daß DV-Spezialisten oder wenigstens mehr oder weniger geschultes DV-Personal die Software einsetzen. Heute ist die Situation komplizierter.

Immer neue Anwendungen werden erschlossen, immer neue Anwenderkreise angesprochen. Waren es früher die Hilfskräfte und bestimmte Sachbearbeiter, so sind es heute auch der gehobene Sachbearbeiter und das Management. Damit ist ein neuer Anwendertyp erschlossen, für den das jeweilige System eine eher weniger genutzte Unterstützungsfunktion darstellt. Sie ist häufig mit dem Zwang gekoppelt, bereichsübergreifend mehrere Softwarepakete einzusetzen. Die Einarbeitungszeit muß vergleichbar gering sein, der Faktor Übung auch.

Hier ist damit auch eine neue Form der Dokumentation gefragt. Sie muß aus der Anwendung heraus einfach und kurz Hilfestellung leisten. Sie muß aus der Sicht des Anwenders und nicht des Autors erstellt sein.

Das stellt an den Autor besondere Anforderungen. Für Endanwendersysteme sind hier nicht in erster Linie Informatikkenntnisse gefragt. Wichtiger sind andere Talente:

- klare leichtverständliche Sprache,

- schnelle Einarbeitungsfähigkeit in wechselnde Aufgabenstellungen,

- Erfahrung im Texten,

- Arbeiten in wechselnden Team-Umgebungen,

- gute englische Sprachkenntnisse.

Vom Marketing übernimmt der Autor für ein gutes Handbuch die Marktdefinition, das heißt die Eingrenzung der Zielpersonen in ihr Arbeitsumfeld. Richtet sich das Softwareprodukt an den DV-ungeübten Benutzer, dann sollte man mit der Dokumentation eher einen informatikfremden Mitarbeiter betrauen. Im Idealfall testet er die "Rohdokumentation" gegen das Anwendersystem und erstellt so aus Sicht der späteren Nutzer die Dokumentation.

Die Aufgabe bietet erfahrungsgemäß einer Reihe von Jobumsteigern eine neue Karrierechance. Dazu zählen zum Beispiel auch Pädagogen, die keinen Einstieg in den Lehrerberuf gefunden haben.

Eine aufgabengerechte Dokumentation wird den Interessen von Anwender und Softwareanbieter gleichermaßen gerecht: Sie erhöht die Akzeptanz und ist ein wesentlicher Garant für kurze Anlaufzeiten bei der Neueinführung von Software.

Immerhin sind 90 Prozent der Fehlermeldungen in der Startphase bei eingeführten Softwareprodukten auf Bedienungs- und Dokumentationsmängel zurückzuführen.