Wann funktioniert ein Wiki nicht?

Clay blogt zwei Meinungen über Erfahrungen mit Wikis, die beide - aus ganz unterschiedlichen Gründen - eher negativ sind. Beide haben durchaus ihre Argumente und sind nicht einfach von der Hand zu weisen.

[My Brilliant Failure: Wikis In Classrooms | Kairosnews
, Connected, Distributed Work via Many-to-Many: WhyWikiWorksNot: 2004 Dance Re-mix]

Da ich im Moment ein Projekt begleite, bei dem es um ein Wiki geht, interessiert es mich ganz besonderns, welche negativen Erfahrungen andere gemacht haben.

Ich stelle diesen meine Ideen gegenüber und gehe auf die Schritte ein, die wir tun müssen/sollten, um mehr Erfolg zu haben.

Und weil ich Optimist bin: Die Idee ist gut, jetzt müssen wir es nur noch umsetzten ;)

To really use a wiki, the participants need to be in control of the content- you have to give it over fully.[My Brilliant Failure: Wikis In Classrooms | Kairosnews]

Dieser Punkt ist durchaus einsehbar, vor allem wenn man davon ausgeht, das exakt diese Idee hinter einem Wiki steckt: jeder hat jederzeit vollen Zugang zu allen Inhalten.

80% of my time goes into coordination - communicating with people. […] We made an effort to introduce all involved to the concept of Wiki and use it wherever possible to reduce the time and effort spent in writing/forwarding e-mails and communicating the same idea to a million people in a million ways (ok I’m exaggerating here). However all efforts went in vain.
[…]
Editing other people’s work might only lead to more friction in a diverse work environment than increase the amount of trust. Access control/workflow is the only way to preserve integrity. [Connected, Distributed Work]

Stellt sich die Frage, warum alle Versuche, den Nutzern das Wiki näher zu bringen, gescheitert sind - und, ob man trotz der ursprünglichen Intention von Wikis, dem echten Leben nicht doch den Vorzug geben sollte und Workflow und Zugriffsrechte definieren sollte.

Ein solches Wiki wäre kein echtes Wiki mehr, denn dort gibt es keine unterschiedlichen Rechte oder Aufgaben, jedenfalls keine formalisierten. Informell mag man sich durchaus auf so etwas wie einen Workflow geeinigt haben - vielleicht sogar auf eine Art Schreibschutz für auf bestimmte Weise markierte Inhalte. Doch schon beim Lesezugriff scheitert dieses Modell, denn über die Suche kann man per Zufall über etwas stoßen, das man eigentlich nicht lesen sollte/dürfte/wollte.

Sind die Regeln jedoch formalisiert und werden sie von der Wiki-Engine entsprechend umgesetzt, gibt es keine Grauzonen mehr und man kann sich ‘frei’ weil ‘geschützt’ bewegen. Frei ist hier nicht im Sinne von Freiheit, sondern von Unbeschwertheit gemeint.

Kommen wir nun zu dem o. g. Projekt. Bisher lief nur die Planung und Umsetzung, tatsächlich scharfgeschaltet wurde die Anwendung noch nicht. Kurz zum Hintergrund: es gut um ein Handbuch, das die Arbeit einer Abteilung eines bekannten deutschen Softwarehauses regelt. Dieses Handbuch wird den Mitarbeitern dieser Abteilung weltweit zur Verfügung gestellt und dient als erste und einzige Referenz für deren Arbeit.

Welche Vorteile hat man, wenn man dieses Handbuch als Wiki zugänglich macht? Die Vorgabe war schlicht, das komplette Dokument ins Intranet zu bringen. Von einem Word-Export nach HTML über konventionelle Web-CMS bishin zu Sitemanagementtools zu Frontpage oder Dreamweaver wurde alles angedacht, auch Wikis. Dieser Idee wurde der Zuschlag erteilt weil: klein und schnell; gute eingebaute Suchfunktion; problemlos auf dem Server zu installieren (wenigstens in der Theorie, wir werden sehen ;)) - und vor allem: Inhalte sind ohne Klimmzüge direkt im Browser editierbar, durch die Kommentare besteht die Möglichkeit eines direkten, wenn gewünscht anonymen Feedbacks, alle Feedbacks sind gesammelt an einer Stelle.

Die Umsetzung erfolgt mittels Wikka, einem Wakka-Clon.

Dieses Wiki lässt drei Dinge zu: Erstens die Einrichtung von Zugriffsrechten auf Seitenebene. Man kann für jede Seite sagen, welche Art von Nutzer (Gast, eingeloggt = authentisiert) oder welcher Nutzer (Herr X, Frau Y) welche Rechte hat: Lesen, Schreiben, Kommentieren.
Zweitens: Kommentieren. Da der Schreibzugriff eingeschränkt werden soll, benötigt man eine andere Feedbackmöglichkeit. Statt dies per Mail geschehen zu lassen, sieht die Idee vor, dies in Form von Kommentaren zu tun. Kommentare darf jeder an jede Seite anhängen. Die Kommentare sollen genutzt werden um Fragen zu klären und um Hinweise für neue Versionen des Dokuments zu sammeln.
Schließlich bietet Wikka die Möglichkeit, einen Administrator zu bestimmen. Dieser hat global alle Rechte, kann Zugriffsrechte bestimmen und Dokumente (auch Kommentare) löschen.

Die Situation bisher bzw. mit den anderen vorgeschlagenen Lösungen sähe so aus: Ein statisches Dokument im Intranet. Feedback kommt ungesteuert per Mail zu mehreren Leuten. Änderungen an dem Dokument sind nur über zwei oder mehr Köpfe (technisches Personal, andere Abteilung) hinweg möglich.

Ein Web-CMS hätte zumindest das letzte Problem gelöst, nicht aber den Wunsch, das alles klein und übersichtlich zu halten, vor allem den Aufwand im Hintergrund. Niemand der Beteiligten will eine neue Oberfläche lernen oder sich gar mit Templates oder anderem technischen Kleinkram auseinandersetzen müssen.

Das Wiki hat keine spezielle Oberfläche. Die Seitenansicht ist die einer jeden anderen Webseite. Die Editieransicht sieht aus wie Word im Browser, auch das ist für Büro-Geübte kein Problem. Um Workflows oder Zugriffsrechte muss man sich ebenfalls keine Gedanken machen, da es außer einem Vieraugen-Prinzip (eventuell werden es auch mehr, aber die Anzahl bleibt überschaubar) keinen Workflow gibt, und die Zugriffsrechte automatisch vergeben werden. Ändert sich etwas an denen, ist man mit einer Änderung in der Konfiguration sowie einer kleinen Datenbankänderung dabei.

Von daher also keine Probleme, oder jedenfalls keine unlösbaren.

Hakeliger wird es hinsichtlich der eigentlichen Nutzung und der Nutzer.

Wikis kennen keine formale Struktur, wie man dies von üblichen Web-CMS her gewohnt ist. Die Struktur eines Wikis entsteht beim Schreiben im Wiki. Dies erfordert ein hohes Maß an Disziplin, soll das Ergebnis konsistent und nutzbar sein. Hier werde ich einspringen (müssen) und den Hauptnutzern zumindest die Grundzüge erläutern und mit ihnen gemeinsam Richtlinien schaffen. Im Besten Fall umfassen diese Richtlinien Themen wie: Seitenerstellung, Refactoring, Strukturierung und Navigation. Aber auch die Software hilft beim Strukturieren. OrphanedPages und WantedPages sind in dieser Hinsicht sehr nützliche Tools.

Ohne Nutzer ist das ganze Projekt aber zum Scheitern verurteilt, wie üblich ;) Wird es nicht genutzt, hat man Zeit und Geld verschwendet. Wir müssen den Nutzern also genau erklären, warum wir uns für das Wiki entschieden haben und wie sie aus dem Wiki den größtmöglichen Nutzen für sich ziehen können. Denn subjektiv kanns ihnen wurscht sein, ob das Handbuch als schlichtes Word-Dokument oder eben per Wiki zu ihnen kommt.

People are resistant to change. [Connected, Distributed Work]

Wo sind die Vorteile für die Nutzer? Was ist am Wiki besser als an der alten Lösung?

Direkt eigentlich nur die Suche. Die erzeugt nicht nur eine Trefferliste, sondern liefert die Treffer im Kontext des Dokuments, so daß man leichter erkennen kann, was ein guter Treffer ist und was nicht.

Die wahren Vorteile stecken in der Hintergrundarbeit und müssen von innen nach außen gekehrt werden.

“Weil Ihr direkt auf der Seite (anonym) Feedback geben könnt, haben wir es leichter mit neuen Versionen des Handbuchs weil wir alle Kommentare an einem Platz haben und schneller mit den einzelnen Dokumenten fertig sind. Wir müssen nicht mehr stundenlang im E-Mail-Programm bzw. in uralten E-Mail-Archiven (Outlook) wühlen, statt dessen sind alle Kommentare zu einer Seite direkt auf der Seite sicht- und verarbeitbar. Wenn wir mit Überarbeitungen und Korrekturen schneller sind , könnt Ihr schneller wieder an die Arbeit, verliert weniger Zeit und könnt effektiver arbeiten.”

“Weil Ihr (anonym) Feedback geben könnt, werden Fragen öffentlich beantwortet - im Laufe der Zeit erhält man eine Kommentarsammlung mit Tipps, Hinweisen und Use Cases (auch die Kommentare sind im Volltext suchbar, nebenbei bemerkt.)” [Anm.: Das könnte aussehen wie die User Comments im MySql-Handbuch (etwas nach unten scrollen, sie folgen unterhalb des eigentlichen Dokuments) oder die User Contributed Notes bei PHP.]

“Weil Ihr (und wir) das alles ohne Medienbrüche tun könnt, funktioniert die Kommunikation reibungsloser und weniger Informationsverlust. Keine dauernden doppelten Rückfragen mehr, Unklarheiten können sofort ausgeräumt und Fehler sofort korrigiert werden.”

Fassen wir also zusammen, wie wir unser Ziel erreichen wollen und was wir dafür tun müssen:

Übernahme gewohnter Strukturen aka Workflows und Zugriffsmechanismen sollen die Umgewöhnung für alle Beteilgten so schmerzfrei als möglich machen. Dazu bedienen wir uns der besten Ideen beider Welten, der Wiki-Welt und der Formalismen-Welt des Unternehmensalltags.

Ehrliche Information der Benutzer über die Möglichkeiten des Systems und warum wir glauben, das es besser ist als das alte. Schrittweises Vermitteln unserer Vision und der Vorteile, die mit ihrer Vollendung einhergehen. [Das ist natürlich bei fast jeder Neueinführung, Umstellung, … nötig. Dennoch kann gar nicht genug darauf hingewiesen werden. Viel zu oft wird dieser Punkt vernachlässigt, mit dem Ergebnis, das Neuerungen nicht angenommen werden.]

Eventuell habe ich hier noch das eine oder andere vergessen/übersehen/falsch gedacht. Kommentare willkommen ;)

8 comments

  1. Darf man auch einfach nur applaudieren? - Klasse dargelegt worauf es bei nem Wiki in so ner Umgebung ankommt. Recht gut durchdacht alles.

    Ein Problem könnten die Funktionen wie Seitenversionen, Referer, Benutzerverwaltung usw. werden - damit weiss der normale Nutzer nichts anzufangen. Hier kann aber sicher durch ein gutes Seitenlayout einiges wett gemacht werden, eventuell bekommen das auch nur eingeloggte Nutzer zu sehen, weiss ich gar nich wie das bei Wikka abläuft.

    Ich arbeite bisher mit Wakka, und hier ist die Textformatierung manchmal ein wenig mühsam. Tabellen zum Beispiel gehen einfach nicht, da ist die Syntax viel zu kompliziert. Aber vemutlich ist hier Wikka auch einfach besser.

  2. Sehr schön dargestellt.

    Ein paar Anmerkungen:

    1. Mach einen Scalability Test. Ich hatte mal eine Wakka-Installation, die mit dem Wachstum auf einmal sehr langsam wurde. Fülle eine Test-Instanz unbedingt mal mit so vielen Dokumenten, wie Du erwartest.

    2. Versionsmanagement über Kommentare riecht nicht ungedingt nach Wiki. Hat die Firma irgendeine Collaborations-Infrastruktur? In einem Notes-Umfeld liessen sich die Anforderungen, die Du formulierst, viel elegante umsetzen.

    3. Wie sieht es mit Medienbrüchen aus? Muss das Dokument nur online verfügbar sein? Aus einem Wiki heraus wirst Du Dich sehr schwer tun, irgendetwas anderes zu erzeugen. Offline-Kopie, PDF, etc. Alles relativ schwierig.

    4. Last but not least: Du hast sehr richtig erkannt, dass es auf das Change Management, vulgo: die Verkaufe, ankommt. Ohne das macht jede Veränderung eine Bauchlandung.

  3. Ich kann mich den Vorschreibern auch nur anschliessen: du hast in deinen Ausführungen eine Menge Aspekte dargelegt.

    Ich persönlich bin ein grosser “Wiki-Fan” und betreibe ein wiki (comawiki), eher auf privater Basis. (http://k-ho.de/wiki). Für mich mittlerweile ein unverzichtbares, jederzeit und überall verfügbares Werkzeug. Coma hat auch den Vorteil, dass sich auf Seitenebene Zugriffsrechte vergeben lassen…

    Der Charme eines wiki ist ja eigentlich die Entwicklung über die Nutzung der wikisprache, es mag auch gern als Wildwuchs gesehen werden. Und für ein wiki, wie du es beschreibst, sind sicherlich auch Definitionen und Zugriffsrechte erforderlich.. Die Inhalte erfordern eine gewisse Qualitätskontrolle, das sieht man ja auch bei wikipedia..

    Ich perönlich denke schon, dass das wiki, idealerweise vielleicht auch irgendwann verzahnt mit der weblog-Technologie, eine Option für die zukünftige Entwicklung ist…

    Liebe Grüsse, kho

  4. Hab ich also den Geschmack meiner Leserschaft getroffen - ich hoffe in Inhalt und Form ;)

    @Jan: Diese speziellen Funktionen werden nur für die Administratoren sichtbar sein, die Referrergeschichte wird (wahrscheinlich) komplett deaktivert. Die Idee ist, das die Benutzer nur die Inhalte und die Kommentierungsfunktion sehen, zusätzlich zu Dingen wie der Suche und dem allgegenwärtigen HomePage-Link.

    Textformatierungen können über “Word im Browser” http://wackowiki.com/WikiEdit erledigt werden. Tabellen sind zugegebenermaßen komplizierter, aber das alles ist nur für die Administratoren wichtig.

    @Volker: Die Testumgebung ist bereits voll aufgefüllt mit allen Inhalten - und läuft momentan auf meinem Notebook. Auf einem ausgeachsenen Server sollten wir hier keine Probleme bekommen - hoffentlich. Allerdings werde ich das nach Deinem Hinweis etwas genauer beachten und prüfen. Danke.
    Es gibt durchaus eine Kollaborationsplattform, nämlich Exchange. Unsere Idee war, da sich alles in der Webanwendung selbst abspielt, wir uns den Sprung weg von der Anwendung in eine andere Umgebung und dann wieder zurück in die Webanwendung sparen können.
    Da das Dokument nur online genutzt werden soll gibt es inhaltlich keine Gefahr eines Medienbruchs. Lediglich einige Beispiele oder externe Tools sind als PDF oder Excel-Sheets verlinkt und stehen nicht direkt im Wiki als Text zur Verfügung. Mit dieser Einschränkung können wir allerdings leben, da hier wie gesagt nur Addons zum Handbuch bzw. Tools betroffen sind, die wir ganz einfach nicht im Wiki darstellen können.
    Tja, und zum Thema Changemanagement… Das ist so wie Backup: keiner will Backup, aber alle wollen Restore ;)

    @kho: Auch CoMaWiki ist ein Wakka-Clon ;) Wikipedia ist hier ein ganz spannender Vergleich, weil die aktuelle Diskussion zeigt, das man auch hier inhaltliche und vielleicht sogar formalisierte Kontrolle bräuchte.

    So, nun gehts auf nach Aschebersch zum Paddy-Konzert ;) Bis die Tage.

  5. Ich bin gerade in der Phase der Einführung eines Wikis in eine Gruppe von ca. 25-30 Leuten. Es geht dabei um die gemeinsame Entwicklung einer neuen Website und die Kommunikation untereinander in den verschiedenen Teams.

    Wie bekommt Ihr die Team-Mitglieder in’s Wiki? Soll heißen: die Jungs sind es gewohnt, entweder für jeden Scheiß eine Mail an alle zu schicken, oder in einem Forum jeden Mist und jede Lästerei niederzuschreiben oder sie hängen an die Wiki-Seiten ihre Word-Dokumente dran…

    Anscheinend ist der Grundgedanke eines Wikis für einen Normalsterblichen nicht so einfach zu verstehen :-(

  6. Schulungen ;) So doof es klingt. Aber das Konzept eines Wikis ist nunmal quer zu allen ‘üblichen’ Modellen, das man es langsam und schonend erklären muss. Ob eine Schulung allerdings Erfolg hat, hängt von der Schulung selbst ab und wie überzeugend die Coaches sind.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert