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 ;)