Ich hatte das Vergnügen, letzte Woche einen ganzen Tag auf der Konferenz Mensch und Computer 2009 zu verbringen. Sie stand dieses Jahr unter dem Motto "Grenzenlos frei!?".
Aus dem dichtgedrängten Programm fielen mir drei Vorträge auf. Alle beschäftigten sich mit der Einbindung von Usability Spezialisten in IT-Projekte. Und alle berichteten von Problemen, die das Zusammenspiel verschiedener Disziplinen schwierig machen - aber auch von Lösungsansätzen. Nur ein Ansatz hat mir gefehlt.

Dr. Thomas Memmel sprach über "Integratives Usability Engineering – Benutzerorientierte Modellierung von Geschäftsprozessen und Softwareanforderungen".
Er gab einen groben Überblick über Werkzeuge und Methoden für Usability Engineering in frühen Projektphasen. Damit kann Usability-Expertise bereits in Requirement Engineering und Geschäftsprozessmodellierung eingebunden werden. Dies wäre wichtig, weil in diesen frühen Phasen bereits entscheidende Weichenstellungen für die Interface-Gestaltung getroffen werden.

Seiner Erfahrung nach ist die Wahl der Werkzeuge entscheidend, sie stellen gewissermaßen die gemeinsame Sprache im Entwicklungsteam dar. Und er empfiehlt Usability-Experten, sich in ihren Werkzeugen Entwicklern und Betriebswirtschaftlern anzupassen. So wäre es zum Beispiel hilfreich, Prozesse in UML zu notieren, um sich bei der Modellierung von Geschäftsprozessen schnell und effektiv zu verständigen.
(Abstract von Th. Memmel, Th. Büring & O. Lalive d‘Epinay)

Fazit 1:
Usability Experten müssen die Sprache der wichtigen Entscheider sprechen, um ihre Kompetenzen zur Wirkung zu bringen. Sie werden nur dann wirklich gehört, wenn klar ist, daß sie sich in Projekte und Teams mit etablierten Prozessen und Denkweisen integrieren können und wollen. Diese Beobachtung kann ich bestätigen.

Julia Maly und Henning Brau sprachen in ergänzenden Beiträgen über Usability Engineering mit Eclipse RCP.
Beide waren als Usability-Spezialisten an der Umstrukturierung der gesamten IT-Servicelandschaft eines Unternehmens beteiligt, die als SOA (Serviceorientierte Architektur) neu implementiert werden sollte. (Mehr zum Thema SOA)

Ihre Aufgabe war es, zunächst Arbeitsprozesse im Unternehmen zu analysieren und verbessern. Und im zweiten Schritt aus diesen Erkenntnissen Usability-Richtlinien und Standards zu erarbeiten.

Als Plattform und Entwicklungsumgebung wurde Eclipse RCP gewählt. Nun besitzt Eclipse RCP einige Eigenschaften, die in der Benutzungslogik stark von herkömmlichen Software-Interfaces abweichen. Eclipse RCP wurde aus technologischen Gesichtspunkten gewählt, und erzeugte (durch seine Flexibilität!) auf der Seite der Interfaces erhebliche Schwierigkeiten. Im Ergebnis bedeutete das, daß die Usability Experten ihre Zeit nicht mit der ursprünglich geplanten Aufgabe verbrachten, sondern mit Machbarkeitsstudien: Ist unser Interface-Konzept auf Eclipse RCP anwendbar? Den eigentlich angestrebten Erkenntnisgewinn (Usability Optimierung) konnten sie aus Ihrer Sicht nicht einbringen. (Abstract von Julia Maly, Henning Brau, B. Watzal)

Fazit 2:
Henning Brau sprach in seiner Schlußfolgerung unter anderem davon, daß Teambuilding-Aspekte hier entscheidend für Gelingen oder Scheitern sein können. Ich denke, es fehlte eine Schnittstelle, die die Diskrepanz zwischen gewählter Technologie und Benutzungslogik hätte aufdecken können und den Nachweis von Machbarkeit nicht den Usability-Experten überläßt.

Der ganze Nachmittag hinterließ bei mir die Frage: Wieso wird die Kommunikationsrolle bzw. Vermittlerrolle in derartigen Projekten nicht stärker ausgebaut?

Es ist nicht die Ausnahme, sondern die Regel, daß an IT-Projekten mehrere Fachdisziplinen beteiligt sind. Normal sind Informatik plus Betriebswirtschaft, Marketing, Design, Usability. Oft sind aber auch Fächer beteiligt, die spätere Anwender repräsentieren, man denke an Pädagogen und Erzieher (E-Learning), Mediziner (Medizintechnik) oder Ingenieure (Maschinenbau, Elektrotechnik usw.).
Ihr Beitrag fällt in der Praxis oft nicht so gewinnbringend aus, wie erhofft. Ich beobachte drei häufige Reaktionsweisen:

Interdisziplinäre Zusammenarbeit wird zwar gelobt, in der Praxis aber weitgehend vermieden. Entsprechende Versuche werden schnell verworfen, weil sie als Risiko an sich erscheinen.

Man versucht, Teams ausschließlich mit Personen zu besetzen, die IT-Kenntnisse besitzen. So werden grundsätzlich Kandidaten bevorzugt, die "irgendwas mit Programmierung" gemacht haben. Und das eigentlich gesuchte, zusätzliche Fachwissen rückt in den Hintergrund. Mittelmäßige Allrounder haben folglich bessere Chancen als wirklich exzellente Spezialisten, die einen Fremdkörper im Team darstellen könnten.

Kommen Projekte an kritische Punkte, so wird häufig zu der Lösung mit dem "kleinsten technischen Risiko" tendiert. Und zu solchen Lösungen, bei denen die Machbarkeit im Moment des Vorschlags bereits abzusehen ist. Dabei sollte es normal sein, daß Vorschläge Fachfremder noch nicht in den Dimensionen von Programmierung gedacht sind. Und deshalb auf Anhieb nicht sehr realistisch klingen. Eine interessante Anregung sollte eine zweite Runde wert sein - nur, wer nimmt sich eines scheinbar "irrwitzigen" Vorschlags an, wenn nicht ein Projektleiter, der das Potenzial dieses Vorschlagsverstehen kann.

Bei allen Versuchen, mit der Problematik umzugehen, vermisse ich eine Position, die anerkennt, daß es explizit einer Kommunikationsleistung bedarf, um interdisziplinäre IT-Projekte zum Erfolg zu führen. Das Problem liegt in der Integration, nicht in der Tatsache, daß es verschiedene Disziplinen, Kompetenzen und Denkweisen gibt.

Ich frage mich, ob nicht bereits bei der Ausbildung angesetzt werden müsste: Wie wäre es, die Kommunikatoren für interdisziplinäre IT-Projekte tatsächlich auszubilden? Dies würde bedeuten, daß man Fähigkeiten, auf die es ankommt, nicht weiterhin unter der Rubrik "wünschenswerte Soft-Skills" ablegt. Informatiknahe Studiengänge würden womöglich für einen ganz neuen Typus von Studenten attraktiv (Kommunizieren!).

IT ist kein Tisch, an dem alleine Tischler arbeiten. IT ist eine Baustelle, an der die verschiedensten Gewerke beteiligt sind. Laßt uns die Spezialisten. Und gebt uns Leute, deren einzige Aufgabe es ist, Beiträge aus verschiedenen Blickwinkeln zu einem Ziel zu führen.