Netzwerkprodukte (24) - Planung

(Themenanfang)

Man könnte sagen: wenn es nicht möglich ist, ein (endgültiges) Design noch vor jeder Arbeit am konkreten Code zu erstellen, dann kann man ja wenigstens das Userinterface (GUI) im Vorhinein festklopfen (GUI jetzt nicht so verstanden, wie das mittlerweile fast schon gängig ist - als graphisches Design -, sondern in der ursprünglichen Bedeutung: als Summe aller Aktionen und Abläufe, mit denen es der User zuletzt zu tun bekommt).

Auch hier stößt man aber auf im ersten Moment überraschende Probleme. Zum einen sind die Auftraggeber einer Software normalerweise Experten in der jeweiligen Problemdomain (z.B. Sachbearbeiter von Petitionen an den Deutschen Bundestag), so daß man eigentlich erwarten könnte, sie wären in der Lage, eine adäquate Beschreibung der eigenen Tätigkeit abzuliefern. Das ist jedoch höchst selten der Fall. Zum zweitem - und das ist dann der springende Punkt - ist selbst ein vernünfig im Vorhinein abgestimmtes Interface in der praktischen Anwendung nie auf Anhieb brauchbar, einfach weil ein GUI auf dem Papier etwas völlig anders ist als eines, das man mit Maus und Tastatur wirklich bedienen kann. Ersteres ist eine Abstraktion, die zwangsläufig bestimmte Aspekte ausläßt - was erst in der konkreten Realisierung spürbar wird.

Zum ersten Punkt wäre anzumerken, daß gute Fachleute in einem beliebigen Bereich nur dann gut sind, wenn sie nicht mehr über das „Wie” ihrer Tätigkeit nachdenken (müssen). Sie haben ihren Job gelernt, und dieses Gelernte verinnerlicht - sie denken nicht über jeden Handgriff nach, sondern tun ihn einfach. Wenn man jetzt verlangt, daß sie sich selber bei der Arbeit beobachten und die Abläufe dokumentieren sollen, tun sie plötzlich nicht mehr ihren Job, sondern etwas ganz anderes - und zwar dann noch etwas, das sie nie gelernt oder geübt haben. Selbstanalyse ist eine Disziplin, die ganz eigene Anforderungen stellt.

Hinzu kommt, daß Fachleute, wenn sie an einer Software für den eigenen Bereich mitarbeiten sollen, schnell dazu tendieren, konkrete Funktionen, ja sogar einzelne Buttons oder Menupunkte vorzuschlagen, statt nur zu erklären, was sie mit Hilfe der neu zu entwickelnden Software eigentlich erreichen wollen (dasselbe Problem hat man, wenn User Verbesserungsvorschläge machen). In der Regel kommt dann die Frage nach einem weiteren Button für eine bestimmte Spezialfunktion, oder der Wunsch nach einem Modifier bei einer Mausoperation, um ein verändertes Verhalten zu bekommen. Dabei wäre es wünschenswert, zu erfahren, was denn mit dieser Spezialfunktion bezweckt werden soll - es wäre die Aufgabe der Software-Architekten, sich zu überlegen, wie man solch eine neue Anforderung dann im GUI implementiert.

Der zweite Punkt ist aber - wie gesagt - entscheidend: einen Entwurf auf dem Papier kann man nicht anklicken. Man kann das Verhalten des Programms und den „Workflow” für den User nur abstrakt beschreiben, aber nicht „am lebenden Objekt” testen, ob die Abstraktionen wirklich korrekt sind. In der Praxis stößt man immer (wieder ein „immer”, kein oft) beim ersten Testlauf eines auch noch so sorgfältig vorbereiteten Features auf Dinge im GUI, die sich falsch anfühlen, und die man definitiv ändern muß, wenn man die Erwartungen der User nicht enttäuschen will. Das können Kleinigkeiten sein, wie zwei Buttons, die man besser vertauscht, weil man den Button links oben intuitiv „lieber” drückt als den direkt daneben, so daß man die eher „ungefährliche” Auswahl eben besser ganz links unterbringt.[1] Das kann aber auch ein kompletter Um- bzw. Rückbau sein, wenn sich etwa herausstellt, daß man in typischen Arbeitssituationen derart viele Pannels (Fenster, die immer „oben” bleiben, auch „Floating Windows” genannt) geöffnet haben müßte, daß der komplette Arbeitsbereich im Hauptfenster von ihnen verdeckt wäre. Dann wird man vielleicht die Funktionen aus den Panels in einen festen Fensterbereich verlagern. - Usf.

Nochmal: Ein Plan ist die Abstraktion einer zukünftigen Realität. Wenn man den Begriff „Abstraktion” so definiert, wie ich das tue - als Vereinfachung eines komplexen Konkreten - hat man eine nur schwer wiederlegbare Begründung für die Beobachtung, daß letztlich jeder Plan scheitern muß, der auf etwas hinlänglich Komplexes abzielt.