Regelungen zur Softwarequalität
Einleitung -Modellierung - Steuerbarkeit - Sichtbarkeit -Natürliche Symbole - Umgang mit Fehlern - Einfachheit - Intuitive Bedienung - Anpassbarkeit

Software ist nicht Software. Wie groß die Unterschiede noch sind, wird vielleicht durch einen Vergleich deutlich. Man kann heute Fernseher kaufen, deren Preis sich in der Regel irgendwo zwischen 300 und 3000 DM bewegt; sie unterscheiden sich in Bildgröße, Bild- und Tonqualität und in (vermutlich überflüssigen) Extras, so gut wie kaum aber in ihrer Funktionalität. Soweit Steckdose und Antennen-/Kabelanschluss vorhanden sind, kann man mit jedem dieser Geräte ein und dieselben Programme empfangen. Wieviele Programme man sehen kann, hängt am allerwenigsten ab von dem gekauften Gerät, sondern vom Einsatzort: ob empfangsbehindertes Schwarzwald-Nebental oder verkabeltes Großstadtquartier. Viel Geld kann der Käufer ausgeben für Ästhetik, Luxus und Design, Statussymbol oder was auch immer; die Leistungsfähigkeit des Fernsehers als Informations- und Unterhaltungsmedium ist davon wenig berührt.

Ähnlich verhält es sich mit dem Auto als Transportmittel. Ob Ente oder Porsche oder grauer Mittelklassewagen, allesamt geeignete Instrumente der mehr oder weniger problemlosen Fortbewegung, sogar mit weitgehend genormtem Benutzer-Interface: Navigation durch Sicht mittels analoger Steuerung durch Lenkradbetätigung, Gas unten rechts, Bremse links, Kupplung ganz links usw.

Doch wesentlich anders fallen die Unterschiede aus, wenn man sich einen Computer kauft. Daß Geräte-Design auch ein Marketingfaktor ist, hatte Apple-Chef Steve Jobs schon vor den iMacs mit dem Next-Cube entdeckt (1993). Die Unterschiede bei Computersystemen liegen im Elementar-, nicht im Luxusbereich der Funktionalität. Um im Vergleich mit dem Autokauf zu bleiben: der Kauf eines Computers ist etwa so, als ob man sich zu entscheiden hätte zwischen einem Traktor mit vielen Rückwärtsgängen, einem Amphibienfahrzeug, einem Formel-1-Rennwagen oder einem Fahrrad. Das Benutzer-Interface ist alles andere als einheitlich, von geheimwissenschaftsumwitterten Kommandosprachen bis zu einer Steuerung durch anklickbare Symbole, von Selber-Machen bis zwanghaft Geführt-Werden kommt alles vor, oft verwirrend vermischt wie in einem Labyrinth, in dem nur Eingeweihte sich zurechtfinden.

“Wenn man ein neues Auto kauft und das folgende Jahr damit verbringt, den Händler Dinge reparieren zu lassen, die von Anfang an nicht funktionierten”, urteilt John Shore recht hart, “sagt man nicht, dass das Auto gewartet wird; man sagt, man hat Schrott gekauft. Nach diesem Kriterium sind die meisten Softwareprodukte Schrott”.

Wie sollen sich nun Betriebsräte mit diesem Thema auseinandersetzen? Schon in der Sache tun sich hier schwierige Fragen auf, sie treffen auch noch auf eine ausgesprochene Umbruchzeit, in der die Halbwertszeit der marktgängigen Wahrheiten kurz ist.

Wir haben nun gesehen, wie komplex das Thema Softwaregestaltung ist und wie entscheidend die Qualität der Software die Qualität des gesamten Arbeitssystems beeinflusst: Arbeit kann kompliziert und beschwerlich oder klar strukturiert und im Ablauf trotz Einfachheit interessant sein, sie kann dem Menschen die aktive und bestimmende Rolle zuweisen oder ihn zur ausführenden Instanz degradieren, die selber nichts zu entscheiden und auch nichts zu verantworten hat. Software kann Menschen als unmündige, ständig Fehler machende und deshalb unbedingt auf Schritt und Tritt zu kontrollierende Wesen behandeln, oder sie kann ihnen “Fahrrad für den Geist” sein, ein Medium, mit dessen Hilfe sich Arbeit effizient und elegant in Szene setzen lässt. Das alles - ohne Zweifel - berührt die Belange der Beschäftigten gewaltig und entscheidet nicht nur über den Wert des Arbeitsplatzes, sondern auch über die Befindlichkeit der dort Arbeitenden. Also muss die Qualität von Software zum Thema gemacht werden, auch in der Betriebsvereinbarung, die ja schließlich das Mittel für den Betriebsrat ist, seinen Einfluss zur Geltung zu bringen.

Dabei geht es nicht um die bloße Einhaltung von Richtlinien, etwa der DIN-Norm Bildschirmarbeit oder der Bildschirmarbeitsplatzverordnung. Es genügt sicher auch nicht, gebannt wie das Kaninchen auf die Schlange zu starren und abzuwarten, was Deutschlands Arbeitsschutzinstitutionen und weitere sich berufen fühlende Organisationen nun mit ihrer handelsüblichen Jahrzehnteverspätung zu Wege bringen. Es geht vielmehr um einen Gestaltungsprozess, dessen Thema die komplette Auslegung des jeweiligen Arbeitssystems ist.

Das sich Berufen auf Normen und Richtlinien kann hilfreich sein; man darf sich aber keinen Illusionen über deren Tragweite hingeben. Die Debatte um eine bessere Operationalisierung von Software-Qualitätsnormen bemüht sich deutlich um Zertifizierbarkeit der Kriterien. Dabei konzentrieren sich viele Forderungen auf die Vorstellung, dass die Kriterien am Software-Produkt prüfbar sein müssen, unabhängig von den Aufgaben und Benutzern. Damit droht aber der wichtige Aspekt in den Hintergrund zu rücken, dass es sich bei dem, dessen Qualität gestaltet werden soll, ja um ein aus Menschen und Technik bestehendes Arbeitssystem handelt. Weiter verfolgt die Debatte um eine bessere Operationalisierung der Software-Qualitätskriterien die Forderung nach einer “Dichotomisierung” der Kriterien, d.h. eine Reduzierung des Beurteilungsrahmens auf Ja-/Nein-Entscheidungen. Die Prüfung soll bei jedem Kriterium zu einer eindeutigen Entscheidung führen, ob das Kriterium erfüllt ist oder nicht. Die Materie ist recht komplex, und die Welt tut uns nicht den Gefallen, sich auf die Zustände schwarz und weiß reduzieren zu lassen.

Auch für die Betriebsräte hilfreich sind solche Kriterien zumindest dann, wenn der Schwerpunkt ihrer Kritik schon beim technischen Teil des Arbeitssystems ernsthafte Defizite umfasst.

Eine Betriebsvereinbarung, die sich an das Thema herantasten will, könnte erst einmal den Grundsatz formulieren, dass neben der Funktionalität oder Leistungsfähigkeit von Software ihre Handhabbarkeit durch die Benutzer überhaupt zum Thema gemacht wird.

Fordert man benutzerfreundliche Software, so rennt man wieder alle offenen Türen ein. Schaut man genauer hin, so muss man feststellen, dass es doch recht verschiedene Dinge sind, die sich unterschiedliche Leute darunter vorstellen. Was ist gefragt? Etwa der kleinste gemeinsame Nenner zwischen Softwarefirma, Händler, Projektleiter, Vorgesetztem, “power user” und ganz einfachem Benutzer? Also muss man sich die Mühe machen, zu sagen, was man unter benutzerfreundlicher Software versteht, wenn man schon die Verkürzung des Themas durch das Etikett Benutzerfreundlichkeit akzeptiert.

Es gibt nur wenige Erfahrungen mit der komplizierten Regelungsmaterie in Betriebsvereinbarungen und folglich auch noch keine gestandenen Traditionen, auf die man sich berufen könnte. Auch die Arbeitgeber sind es nicht gewohnt, von ihren Betriebsräten auf die Qualität der Software angesprochen zu werden. Entsprechend vorsichtig sind Regelungen in Betriebsvereinbarungen. Hier ein Beispiel:

Einleitung -Modellierung - Steuerbarkeit - Sichtbarkeit -Natürliche Symbole - Umgang mit Fehlern - Einfachheit - Intuitive Bedienung - Anpassbarkeit