Die Einbeziehung der Anwender in die Entwicklung von Software ist notwendig. Die Konzepte der Anwenderpartizipation allerdings reichen nicht mehr aus. Erforderlich ist eine kooperative Systementwicklung, an der Anwender und Entwickler gleichermaßen beteiligt sind.

Seit einigen Jahren gehört es zum guten Ton, die Beteiligung der Nutzer bei der Entwicklung neuer Software zu fordern. Zahlreiche Publikationen und Vorträge haben die Notwendigkeit der Nutzerpartizipation zum Inhalt. Anhand von Modellen wird vorgestellt, wie diese zu praktizieren sei (Brödner, Floyd). In einer Reihe von Projekten, etwa im BMFT-Programm "Arbeit und Technik" wurden solche Partizipationsansätze entwickelt und erprobt.

In den meisten dieser Projekte ist es gelungen, Möglichkeiten der Nutzerbeteiligung zu erarbeiten und auch die Produktivität eines solchen Ansatzes zu beweisen. Fraglich bleibt allerdings, wie stabil sich solche Beteiligungsexperimente außerhalb des schützenden Rahmens subventionierter Projekte erweisen und welche Auswirkung sie auf die normale Praxis haben.

In den von uns untersuchten Projekten war die Beziehung zwischen Anwendungs- und Entwicklungsbereich vielgliedrig und komplex. Der Kooperationsprozeß setzte oft schon vor Projektbeginn ein und war mit dem offiziellen Projektende nicht unbedingt abgeschlossen - er gestaltete sich von Projekt zu Projekt sehr unterschiedlich.

Bislang wurde in der Diskussion der Anwender-Entwickler-Beziehungen der "eigentlichen" Software-Entwicklungsphase mehr Aufmerksamkeit gewidmet als den vor- und nachgelagerten Zeitabschnitten. Dabei kam gerade diesen Zeiträumen in vielen Entwicklungsvorhaben eine besondere Bedeutung zu. Schon mit Entstehung der Projektidee und der Formulierung des Auftrags wurden für das Entwicklungsvorhaben, vor allem aber für den Anwendungsbezug, richtungsweisende Vorgaben geschaffen.

Wir haben die komplexen Entstehungsprozesse von Softwareprojekten nachgezeichnet. Dabei fiel es oft schwer, nachträglich zu identifizieren, von wem welche Impulse ausgingen. In einem engmaschigen Netz waren die Initiativen und Aktivitäten einer Vielzahl von Stellen miteinander verwoben: Betroffen waren unter anderem der künftige Anwender, Führungskräfte in den Organisations- und DV-Abteilungen sowie im höheren Management des Anwenderunternehmen und natürlich die Spezialisten, darunter auch die Entwickler und das Management der Softwarefirmen.

Bei der Formulierung des Anforderungskatalogs beziehungsweise des Projektauftrags spielten die sogenannten "Endanwender", also die eigentlichen Nutzer der Software, eine untergeordnete Rolle. Dasselbe gilt für die Mitarbeiter in den Softwarefirmen oder DV-Abteilungen, die das entsprechende System entwickeln sollten. Nur selten kamen beide Gruppen in diesem frühen Stadium unmittelbar miteinander in Berührung. Sie waren die äußersten Glieder in dieser Kette von Instanzen, die in den Prozeß der Definition des Projektauftrags involviert waren.

Daß also die eigentlichen Träger der Software-Entwicklung in den Vorphasen der Projekte nur mangelhaft eingebunden waren, hatte seine Auswirkungen - zum Beispiel bei der Aufnahme des Ist-Zustands, wo es zu direkten Kontakten zwischen Entwicklern und Anwendern kam. Die Weichen waren nicht immer in die richtige Richtung gestellt.

So kamen in manchen Fällen die Entwickler von Softwarehäusern zum erstenmal bei der Schulung der Anwender mit diesen in direkten Kontakt. Sie wurden prompt mit Anforderungen und Vorschlägen konfrontiert, die sich zwar als durchaus sinnvoll erwiesen, die aber nicht im "offiziellen" Projektauftrag vorgesehen waren und nun nachträglich nur unter Mühen eingearbeitet werden konnten.

Präzisierungen und Korrekturen des ursprünglichen Projektauftrags wurden in der überwiegenden Mehrheit der Projekte (zirka 80 Prozent) durchgeführt. Diese Redefinition war aber häufig ein mühsamer Prozeß, den man durch eine frühere Einbeziehung der eigentlichen "Experten" an der Basis effektiver hätte gestalten können.

Kaum Berührungen zwischen Anwendern und Entwicklern

Die Intensität der Kontakte zwischen Entwicklungs- und Anwendungsbereich während des "eigentlichen" Entwicklungsprozesses im Projekt, und die Formen, wie diese Kontakte geregelt waren beziehungsweise abliefen, war in den untersuchten Projekten sehr unterschiedlich. Es gab Projekte, in denen es nach einem Minimum an Abstimmung zu Projektbeginn kaum mehr zu Berührungen zwischen Anwendern und Entwicklern kam. In anderen Fällen beobachteten wir eine kontinuierliche und enge Zusammenarbeit zwischen den beiden Bereichen; dies schlug sich auch deutlich in der Gestaltung der Software nieder.

Im Zusammenhang mit der Diskussion um die Anwenderpartizipation interessiert besonders die Frage, wie tragfähig und wirksam sich formale Regelungen erwiesen durch die die Anwender in den Entwicklungsprozeß einbezogen werden sollten. Projekte, in denen die "Beteiligung" des Auftraggeber- oder Anwenderbereiches formal detailliert fixiert war, standen solchen gegenüber, in denen entsprechende Regelungen völlig fehlten.

Die am häufigsten auftretende Spielart formaler Anwenderbeteiligung war ein Verfahren, bei dem offiziell benannte Anwendervertreter deren Belange im Projekt wahrnehmen und als Informationsmittler zwischen Entwicklern und Anwendern fungieren. In 70 Prozent der untersuchten Projekte gab es eine formalisierte Anwendervertretung, zumeist durch einen (künftigen) Anwender, der für diese Aufgabe benannt wurde. In jedem fünften dieser Fälle wurde die Aufgabe durch Vorgesetzte beziehungsweise durch DV-Verbindungsleute wahrgenommen.

Keine Anwendervertretung gab es bei kleinen Softwarehäusern in 56 Prozent der Projekte. Große Softwarehäuser verzichteten dagegen nur zu 20 Prozent auf eine User-Vertretung. Die Anwenderrepräsentanten spielten eine sehr unterschiedliche Rolle. Vielfach waren sie nicht mehr als ein Feigenblatt, das die in Wirklichkeit unzulängliche Einbindung der Anwender verdecken sollte.

Vor allem dort, wo DV-Verbindungsleute als Anwendervertreter benannt waren, agierten diese häufig mehr als Außenstelle des Entwicklungsbereichs, denn als Vertreter der Anwender. Dort, wo Führungskräfte diese Funktion wahrnehmen sollten, blieb dies oft wenig mehr als eine Fiktion. Diese Anwenderrepräsentanten nahmen gelegentlich an Sitzungen oder Besprechungen teil, hatten aber kaum Einfluß auf die Projektgestaltung. Neben mangelnden technischen Kenntnissen verhinderte bei ihnen vor allem Zeitmangel eine aktive Wahrnehmung ihrer Vertreterfunktion.

Solche Restriktionen gab es auch in solchen Projektgruppen, in denen Entwickler und Anwender vertreten waren. In etwa der Hälfte der untersuchten Projekte wurden solche Arbeitsgruppen gebildet mit sehr unterschiedlicher Zusammensetzung, Aufgabenstellung und Befugnis. In einigen Projekten war die Bildung solcher Gremien nicht mehr als ein Versuch, die de facto bestehende Nichteinbeziehung der Anwender in den Prozeß der Softwaregestaltung zu verschleiern.

In anderen Projekten allerdings erwiesen sich die Arbeitsgruppen als zwar aufwendiges, aber doch recht produktives Instrument zur Koordination der Belange und Anforderungen von technischer und fachlicher Seite. Besonders in den frühen Phasen der Erarbeitung der Anforderungsspezifikation und des Fachkonzepts waren solche Gruppen aktiv, im weiteren Projektverlauf dann meist weniger.

Die Effektivität solcher Arbeitsgruppen beruhte nicht zuletzt darauf, daß die Erarbeitung von Lösungen eng mit einem Prozeß wechselseitiger Wissensvermittlung und zugleich der Konsensbildung verknüpft war. Dabei ging es um die Herstellung eines Einverständnisses nicht nur zwischen Entwicklern und Anwendern, sondern auch unter den Anwendern. Es gab nie "den Anwender", sondern immer verschiedene Gruppen von Anwendern, die recht unterschiedliche, unter Umständen konkurrierende Interessen und Vorstellungen in die Gestaltung der Software einbrachten. Anwenderpartizipation hieß hier immer zugleich Auseinandersetzung mit den divergierenden Interessen.

In einigen Projekten beherrschte dieser Aspekt die Diskussion um die Spezifikation der Anforderungen wie auch deren Realisierung. In einer Arbeitsgruppe, in der im Rahmen der Entwicklung eines umfassenden administrativen Systems die Anforderungsspezifikation für ein Teilsystem erarbeitet werden sollte, war der Vertreter des Entwicklungsteams nicht zuletzt in Anspruch genommen, weil er zwischen den Leitern zweier Abteilungen zu vermitteln hatte.

Er beschreibt die Situation so: "Jede Sitzung war zugleich eine psychologische Aufgabe für mich. Es kam vor allem darauf an, daß die beiden zusammenkamen, daß ich die Gewißheit haben konnte, beide stehen zu dem Beschluß. Wenn da einer eingeschnappt war, dann war der Tag kaputt und wir mußten das nächste Mal nochmal dran. So haben wir schließlich 30 Sitzungen gebraucht."

Neben den institutionalisierten Formen der Anwenderbeteiligung hatten sich in zahlreichen Projekten informelle Kontakte zwischen Anwendern und Entwicklern herausgebildet. Diese Kontakte erwiesen sich in der Regel als sehr tragfähige und produktive Grundlage für eine weitgehende zeitliche wie inhaltliche Abstimmung der Entwicklungsaktivitäten auf den Bedarf der Anwender. Wir fanden solche Formen der Partizipation sowohl in Projekten in Anwenderunternehmen als auch in solchen, die extern von einem Softwarehaus oder einzelnen Entwicklern ausgeführt wurden.

Im Zuge solch informeller Kooperationsbeziehungen bildeten sich Vorgehensweisen heraus, die alle Züge von Prototyping-Verfahren aufwiesen. Man verständigte sich über das Anforderungsprofil, das von den Entwicklern mehr oder weniger versuchsweise in eine Softwarelösung umgesetzt wurde, die dann von Anwendern erprobt wurde. Die dabei gemachten Erfahrungen bildeten den Bezugspunkt für die nächste Version.

Wesentliche Qualität dieses Vorgehens und seiner besonderen Effektivität war nicht zuletzt seine Informalität und die persönliche Vertrautheit von Entwicklern und Anwendern. Durch sie waren die Voraussetzungen gegeben, die anstehende Entwicklungsaufgabe flexibel und entlastet anzugehen und damit einen Kompromiß zwischen den technischen und fachlichen Anforderungen rasch und mit wenig Aufwand zu erreichen.

Dies machte allerdings Kontinuität in der personellen Besetzung zu einer essentiellen Vorbedingung. Produktiv waren diese kontinuierlichen informellen Beziehungen zwischen Entwicklern und Anwendern auch deshalb, weil sie ganz offensichtlich dazu beitrugen, bestehende Vorbehalte und Vorurteile abzubauen. Entwickler und Anwender von Softwareprodukten hatten voneinander oft eine nicht allzu gute Meinung.

Die Software-Entwickler sahen im Anwender jemanden, der nicht fähig ist, seine Wünsche zu formulieren. Er wechsele seine Vorstellungen "so schnell wie das Hemd", stehe der Technik relativ naiv gegenüber, erschwere mit immer neuen Zusatzwünschen die Arbeit des Entwicklers und müsse letztendlich zu seinem Glück gezwungen, das heißt zur richtigen Softwaregestaltung und Anwendung geführt werden. Vor allem, so meinten die Entwickler, fehle ihm das Verständnis für die Besonderheiten und Anforderungen der Software-Entwicklung.

Die Anwender wiederum sahen im Software-Entwickler jemanden, der wenig Ahnung von der Komplexität und den Anforderungen der Arbeitswirklichkeit hat und der auch wenig Interesse dafür zeigt. Auf seine Technik fixiert sitze er im Elfenbeinturm der DV-Abteilung oder der Softwarefirmen und gehe seiner Arbeit mit wenig Verständnis für die Besonderheiten der jeweiligen Arbeitssituation nach. Dies könne man seinen Produkten dann auch ansehen.

Diese Urteile fielen um so krasser aus, je sporadischer und je formalisierter der Kontakt zwischen den beiden Gruppen war. Dabei waren die Urteile in der Regel nicht ganz aus der Luft gegriffen. Man konnte auf Erfahrungen zurückgreifen, die die negative Sicht bestätigten. Von seiten der Entwickler etwa auf fehlgeschlagene Versuche, die Anwender "zu beteiligen", und von seiten der Anwender auf die formale, bürokratische oder weltfremde Behandlung eigener Wünsche.

So blieb bei vielen Softwareentwicklern eine ausgeprägte Skepsis gegenüber dem Beitrag, den Anwender im Entwicklungsprozeß leisten können. Man konzedierte zwar die Notwendigkeit seiner Anwesenheit, versprach sich aber nicht immer viel davon, wie folgende Aussagen zeigen: Für uns ist ein Riesenproblem: Wie bekommen wir das Anforderungsprofil zusammen. Die Demokratisierung bringt da nichts. Wir haben im letzten Projekt sehr aufwendig die Prioritäten gesammelt, das führte aber zu keinem verwertbaren Ergebnis. Aber ich bin mir darüber im klaren, daß wir die Anwender mitreden lassen müssen."

Viele Software-Entwickler waren der Ansicht, daß "Beteiligung" nichts bringe, daß man die Kontakte mit den Nutzern möglichst gering halten und den Anwender als Informationsquelle, nicht aber als Gesprächspartner behandeln müsse. Zu dieser Einstellung beigetragen hat bisweilen die Erfahrung, daß User-Beteiligung durchaus nicht immer die Akzeptanz der Vorhaben erleichtert - im Gegenteil, manchmal werden auch schlafende Hunde geweckt. "Es ist ein Irrtum, daß Demokratisierung Akzeptanz verbessert. In vielen Sitzungen erzeugt sie erst Gegnerschaften."

Wenig Interesse an Kontakten zu Anwendern

Ein beträchtlicher Teil der Entwickler, mit denen wir uns unterhielten, zeigte wenig Interesse an verstärkten Kontakten zu Anwendern oder deren Vertretern. Im Gegenteil, sie wurden als störend, belastend und zeitraubend empfunden. Man war dankbar, wenn einem diese lästige Pflicht - etwa vom Projektleiter - abgenommen wurden.

Gesondert zu betrachten sind - ähnlich wie die die dem Projekt vorausgehenden Kontakte - die Beziehungen zwischen Anwendern und Entwicklern nach dem Projektabschluß. Dieser bedeutet meistens eine mehr oder weniger starke Zäsur, sowohl in der Verteilung der Zuständigkeiten als auch in der personellen Besetzung. Dieser "nachgeschaltete" Abschnitt wird in der Diskussion um die Anwenderpartizipation meist nur am Rande oder gar nicht behandelt.

Dabei erfordert gerade dieser Abschnitt besondere Aufmerksamkeit, bietet er doch die - verspätete - Chance zur Korrektur von Fehlentwicklungen, die nicht zuletzt auf die mangelnde Kooperation zwischen Entwickler und Anwender während des eigentlichen Projekts zurückzuführen sind. Außerdem wird hier die Grundlage für Weiterentwicklungen gelegt, die eigentlich immer notwendig und sinnvoll sind.

Kontinuierlicher Austausch ist erforderlich

Software-Entwicklung ist ja nicht mit dem Einsatz des Produktes beendet, es handelt sich vielmehr um einen Prozeß, der weit in die Zeit der produktiven Nutzung hineinreicht. Dann nämlich kommt es darauf an, daß die praktischen Erfahrungen bei der Benutzung systematisch für die laufende Verbesserung der Software verwertet werden. Für diese nachgeschaltete Kooperation tragfähige Verfahren und einen geeigneten Rahmen zu finden, ist ebenso wichtig wie die Organisation der Anwender-Entwickler-Kooperation während des "eigentlichen" Entwicklungsprozesses.

Im Rahmen unserer Untersuchung (siehe Kasten), die sich auf die Abwicklung der eigentlichen Softwareprojekte konzentrierte, konnte dieser nachgeschaltete Abschnitt nur am Rande betrachtet werden. Trotzdem zeichneten sich einige Tendenzen sehr deutlich ab. In zahlreichen Projekten bildeten sich nach dem offiziellen Abschluß intensive Kontakte zwischen einzelnen Entwicklern und Anwendern heraus. Die laufende Pflege und Weiterentwicklung der Software machte diesen kontinuierlichen Austausch erforderlich und führte somit ganz von selbst zu einer engen Kooperation zwischen beiden Gruppen.

Für die eigentliche Software-Entwicklung blieben diese nachgeschalteten Kontakte allerdings weitgehend folgenlos. Die Entwickler mußten sich mit Projektende überwiegend neuen Aufgaben widmen, und wir trafen nirgendwo auf Regelungen, die sichergestellt hätten, daß das Feedback des Anwenders auch beim Entwickler ankäme.

Die organisatorische Trennung von Entwicklung und Maintenance, der wir häufig begegneten, hatte zur Folge, daß aus den Erfahrungen der Software-Implementierung kaum Nutzen für die weitere Entwicklungspraxis gezogen werden konnte. Der Zustand, in dem das Feedback ungenutzt blieb, wurde institutionell festgeschrieben. Abgesehen von informellen Nachfragen gab es praktisch keine Rückmeldung von den Wartungsbeauftragten an die Entwickler.

Solche Rückmeldungen aber müßten für die Entwickler von hohem Interesse sein, denn die Erfahrungen der Anwender, ihr Verlangen nach Unterstützung oder Änderungen, kann als Prüfstein für die Qualität der entwickelten Software gelten.

In unserer Untersuchung, so läßt sich bilanzieren, begegneten wir nur relativ selten wirklich tragfähigen offiziellen und institutionalisierten Ansätzen zur unmittelbaren Einbeziehung der Anwender in den Entwicklungsprozeß. Als sehr tragfähig und wirksam erwiesen sich dagegen in vielen Projekten die informellen Kontakte zwischen Entwicklern und Anwendern.

Die Grenzen der direkten Kooperation

Nicht zu übersehen waren allerdings zugleich auch Schwächen und Grenzen dieser direkten Kooperation zwischen Entwicklern und Anwendern. So wuchs die Gefahr, daß die große Linie bei den Entwicklungsarbeiten nicht im Auge behalten wurde, daß sich Inkompatibilitäten unerkannt einschlichen und Schwierigkeiten bei der Festlegung der zeitlichen und inhaltlichen Prioritäten auftraten. Die Reichweite solch informeller Beziehungen war in der Regel auf die Entwicklung von Anwendungen für einzelne oder nur wenige Anwender begrenzt.

Die Untersuchung der Anwender-Entwickler-Beziehungen zeigt generell: Überall dort, wo sich effektive Formen des Zusammenwirkens beider Seiten etabliert hatten, konnte nicht mehr von der "Beteiligung" des Anwenders an der Entwicklung gesprochen werden; eher mußte von der Kooperation zweier Gruppen von Experten die Rede sein, die ihr spezifisches Fachwissen in den Prozeß der Software-Entwicklung einbrachten und ihre Belange vertraten.

Nutzer wird zum Ausbügeln der Fehler herangezogen

Den Systemexperten, also den Software-Entwicklern mit ihrem technischen Know-how, standen die Anwenderexperten in den Fachabteilungen oder anderen Anwendungsbereichen gegenüber. Sie kannten die Aufgabenstellungen und die Bedingungen, unter denen gearbeitet werden mußte.

Beide Formen von Experten- und Fachwissen gingen in die Software-Entwicklung ein; ihre gleichgewichtige Berücksichtigung war die wichtigste Voraussetzung für die Entwicklung aufgaben- und nutzungsgerechter Systeme.

Organisation von Software-Entwicklung heißt also, die Voraussetzungen für ein Zusammenwirken von Systemexperten und Nutzerexperten zu schaffen, wodurch gewährleistet ist, daß beide ihr spezifisches Fachwissen einbringen können. Erforderlich ist dabei auch die Einbeziehung der Führungskräfte, sowohl in den Entwicklungs- als auch in den Anwenderbereichen, denn nur so kann die notwendige Verbindlichkeit erreicht werden.

Der Begriff "Beteiligung" scheint hier eher irreführend, signalisiert er doch etwas grundsätzlich Falsches. Beteiligung im herkömmlichen Sinn ist nämlich tendenziell die Teilnahme an der Reparatur: Der Nutzer wird einbezogen, damit Fehler und Lücken in der Arbeit der Systementwickler ausgebügelt werden können. Mag dieses Verfahren noch für die Entwicklung herkömmlicher EDV-Lösungen angemessen sein, so ist es für die Entwicklung von Informations- und Kommunikationssystemen nicht mehr ausreichend.

Bei der Entwicklung solcher Systeme haben wir es gleichermaßen mit einem technischen und einem Anwendungsproblem zu tun. Die Systemlösung strukturiert die Anwendung, und aus der Anwendung ergeben sich die Vorgaben für die Systemlösung. Hier geht es also nicht um Beteiligung, sondern um Kooperation - vergleichbar etwa dem Zusammenwirken von Fertigung und Einkauf, Entwicklung und Vertrieb.

Es wäre besser, auf den - irreführenden - Begriff "Nutzerbeteiligung" oder "Partizipation" zu verzichten und statt dessen von "kooperativer Systementwicklung" zu sprechen. (wird fortgesetzt)

*Professor Friedrich Weltz ist Geschäftsführer der Sozialwissenschaftlichen Projektgruppe, München, und Honorarprofessor an der Universität Göttingen; Rolf Ortmann ist Mitarbeiter der Sozialwissenschaftlichen Projektgruppe, München

Literatur:

P. Brödner/G. Simonis (Hrsg.): Arbeitsgestaltung und partizipative Systementwicklung. Opladen, 1991.

C. Floyd/F.M. Reisin/G. Schmidt: Steps to Software Development with Users. In: C. Ghezzi/J.A. McDermid (Eds./Proceedings of the 2nd European Software Engineering Conference, Berlin 1989).

F. Weltz/H. Bollinger: Nutzerbeteiligung oder kooperative Systementwicklung? Office Management, 3/1990.