Dieser Post ist der zweite Artikel der Serie “Aus der Praxis eines Collaboration Consultants – Tools, Kultur und ihre Wechselwirkungen” und dreht sich um das Wachstum eines Wiki – weitere Artikel dieser Serie findest Du in Kürze hier auf dem Blog. In dieser Serie schreibe ich als Atlassian Consultant aus eigener Beobachtung, meiner Praxis als Consultant bei diversen Unternehmen und meiner Freiberuflichkeit sowie dem Austausch mit anderen Atlassian-Anwendern und Administratoren über die Nutzung von Collaboration Tools und ihre kulturellen Wechselwirkungen. Mein Zielbild beim Einsatz von Collaboration Tools ist Selbstorganisation und Selbstmanagement von Teams zu unterstützen sowie Transparenz für mehr Synergien und Zusammenarbeit in Teams und Unternehmen herzustellen.
Wenn ein Team oder gar ein ganzes Unternehmen beginnt, ein Wiki gemeinsam zu nutzen ist das erstmal toll (dazu gleich mehr). Nach einiger Zeit allerdings beginnt die Akzeptanz bei den Nutzern häufig abzunehmen, da kaum noch relevante Inhalte gefunden werden (dazu später mehr). Dieser Post gibt Dir Aufschluss, was bei der Nutzung eines Wikis zu beachten ist, was für Möglichkeiten es gibt mit dem “Wildwuchs”-Problem umzugehen und was Auswirkungen auf eure Zusammenarbeitskultur sein können.
Doch nun zuerst zu den Grundlagen:
- Was ist ein Wiki?
- Wie kann das aussehen?
- Warum und wofür ein Wiki nutzen?
Was ist ein Wiki?
Laut Wikipedia (dem bekanntesten Beispiel für ein Wiki) ist ein Wiki “eine Website, deren Inhalte von den Besuchern nicht nur gelesen, sondern auch direkt im Webbrowser geändert werden können”. Mit anderen Worten: Wir können im Browser gemeinsam an Inhalten arbeiten, diese strukturieren, durchsuchen und damit z. B. eine Dokumentation unserer Arbeitsweise im Team und allen Infos, die wir dazu benötigen, an einer Stelle (“in unserem Wiki”) erstellen.
Wie kann das aussehen?
In untenstehendem Screenshot sehen wir einen Wiki-Bereich der Kollaborationslösung von Atlassian, Confluence. Confluence ist kostenpflichtig und in allen Software-nahen Branchen stark verbreitet, eignet sich aber auf Grund seiner einfachen Bedienung, umfangreichen Funktionalität und Erweiterbarkeit auch für viele andere Teams. Natürlich gibt es auch “kostenlose” Wikis – weder diese noch die Debatte Open Source-Software vs. kommerzielle Software sollen aber an dieser Stelle diskutiert werden.
Wikis sind häufig in “Bereiche” aufgeteilt, um thematisch ähnliche Seiten zusammen zu fassen (gerne als “Produktbereiche” oder “Fachbereiche” bezeichnet) oder um Seiten einer Organisationseinheit (gerne als “Teambereiche”) zusammen zu fassen.
Beispiele für Produkt- bzw. Themenbereiche sind:
- die Dokumentation eines intern genutzten und weiterentwickelten Customer Relationship Management-Systems inklusive Benutzerhandbuch, Roadmap, FAQ.
- die Dokumentation aller Prozesse eines Unternehmens im Sinne des Qualitätsmanagement und der kontinuierlichen Verbesserung.
- eine Knowledge Base für einen Support-Bereich bzw. eine Organisationseinheit mit Kundenanfragen.
- alle Dokumentation rund um Dein Projekt inklusive euren Zielen, Plänen, Ideen, Entscheidungsdokumentationen, Projektretrospektiven etc.
Beispiele für Teambereiche sind:
- das Entwicklungsteam des oben genannten Customer Relationship Management-Systems möchte die Ergebnisse ihrer organisatorischen Team-Meetings, Feedback zur Weiterentwicklung der Teammitglieder, die Ergebnisse von Team-Retrospektiven und die Organisation von Team-Events ebenfalls im Wiki dokumentieren. Da dies in der Regel nur für das Team relevant ist (und ggf. aus Datenschutzgründen auch nicht von Mitarbeitern außerhalb des Teams eingesehen werden sollte) erfolgt diese Dokumentation in einem separaten Team-Bereich.
- wenn in Deinem Projekt auch der (externe) Kunde und weitere Stakeholder mitlesen und -dokumentieren wollen kommst Du schnell in die Situation, dass Du Dir einen geschützten Raum zum Austausch für Dein Team wünschst. Ein separater Teambereich ist dann eine gute Lösung wenn ihr initial die Abgrenzung zu eurem Projektbereich besprochen habt.
Innerhalb dieser Bereiche gibt es eine Hierarchie von Seiten (ähnlich zum Explorer) und beliebig viele Seiten mit verschiedensten Inhalten, z. B. Bildern, Text und Makros (dynamisch generierte Inhalte, dazu später mehr). Anders als z. B. bei Google Drive erfolgt die Navigation meist innerhalb von Seiten über Verlinkungen und weniger über die Seitenhierarchie (der Dateistruktur in Google Drive entsprechend).
Zusätzlich gibt es zahlreiche weitere Funktionalitäten wie eine Suche, Vorlagen u.v.m.
Warum und wofür ein Wiki nutzen?
Für jeden, der bereits erfolgreich ein Wiki genutzt hat, liegen die Vorteile eines Wikis auf der Hand. Hier eine kurze (unvollständige) Aufzählung der Vorteile eines Wikis für alle, die noch kein Wiki genutzt haben:
- Auflösung der Datei- bzw. Informationssilos: Seiten und ihre Inhalte sind untereinander verknüpft bzw. bauen teilweise aufeinander auf (s. Dynamische Generierung von Inhalten) und sind für alle Mitarbeiter im jeweiligen Bereich sichtbar und bearbeitbar.
- Automatische Versionierung von Seiten: damit muss ich keine Dokumente mehr mit verschiedenen Versionen abspeichern und weiß hinterher nicht mehr, welche Version ich den Kollegen schon geschickt hatte.
- Gemeinsame Ansicht und Bearbeitung von Seiten: damit sind alle im Team bzw. Unternehmen immer auf dem aktuellen Stand und können neue Erkenntnisse sofort dokumentieren, statt eine ggf. veraltete Datei zu aktualisieren und die Änderungen möglicherweise zu verlieren, wenn der nächste Bearbeiter eine andere Datei als Basis nimmt.
- Dynamische Generierung von Inhalten: Das Inhaltsverzeichnis ist erst der Anfang – Inhalte können wiederverwendet, kategorisiert und auf verschiedenste Arten und Weisen gelistet werden.
- Volltext-Suche bei Text-Anhängen: Werden Dokumente an Seiten angehängt werden diese bei einer Suche mit durchsucht.
- Einbettung und Bearbeitung von Diagrammen in Seiten: Mit Erweiterungen können Diagramme in Seiten eingebettet und dort direkt von allen bearbeitet werden, statt auf die Kollegen mit der Visio-Lizenz zu warten.
- Erweiterbarkeit des Systems: Gerade Confluence hat einen großen Marketplace für Erweiterungen, mit denen zahlreiche weitere Funktionalitäten mit einem Klick (und Lizenzeinkauf) bereitgestellt werden können, z. B. eine Frage-Antwort-Community oder ein Excel-Klon in Confluence-Seiten.
Kurzum – wer einmal ein Wiki wirklich genutzt hat, möchte keine Word-Dokumente mehr schreiben…
Die Nutzung beginnt…
Nehmen wir an, Dein Unternehmen oder Team ist nun vom Wiki-Konzept so begeistert, dass sie die Nutzung beginnen wollen. Nach kurzer Evaluation beschließt ihr, erstmal ganz lean mit einer 10 User-Lizenz für Confluence Cloud zu starten – ihr könnt sofort mit bis zu 10 Kollegen loslegen und gemeinsam dokumentieren und zusammenarbeiten. Aus eurer Word-Dokumentenerfahrung heraus fangen einige Kollegen an, lieber Seiten zu kopieren und sie dann zu bearbeiten, als bestehende Seiten zu aktualisieren. Man weiß ja nicht genau, ob man dem Kollegen damit nicht auf die Füße tritt bzw. was die Kollegin damit vorhatte… Andere Kollegen legen viele neue Seiten an, schreiben ein paar Zeilen darauf und vergessen dann, dass sie die Seite bereits erstellt hatten und erstellen beim nächsten Mal eine ähnliche benannte Seite mit etwas anderem Inhalt. Nun habt ihr sehr schnell viele Seiten und…
Das Wildwuchs-Dilemma
… langsam findet ihr auch mit der Suche nicht mehr wirklich das, wonach ihr sucht. Manchmal findet ihr viele ähnlich benannte Seiten und wisst nicht welche die aktuelle (“die eine Wahrheit”) ist. Ein anderes Mal findet ihr nur irrelevante bzw. seit längerer Zeit nicht mehr aktualisierte Seiten. Und dass ihr jedes Mal die Suche bemühen müsst um mit etwas Glück überhaupt etwas zu finden macht euch nicht besonders glücklich. Keiner möchte noch wirklich neue Dokumentation erstellen, da diese sowieso nicht gefunden und damit auch nicht genutzt wird. Ihr seid im Wildwuchs-Dilemma…
Mögliche Lösungen
Das Wildwuchs-Dilemma folgt meist der anfänglichen Begeisterung für ein Wiki, wenn diese nicht von Anfang an mit einer gemeinsamen kritischen Reflexion der Nutzung kombiniert war.
Mögliche Lösungen sind nun:
- eine Sensibilisierung der Nutzer, z. B. dass sie nicht einfach neue Seiten erstellen sondern bestehende Seiten aktualisieren und nur, wenn sie keine passende Seite finden, eine neue Seite erstellen und diese dann in die bestehende Struktur integrieren. Auch die Scheu Inhalte anderer Kollegen zu bearbeiten sollte angesprochen werden – wir arbeiten zusammen und dokumentieren zusammen ohne dass jemand einen Teil der Dokumentation für sich beansprucht hat. Sollte doch mal etwas schief gehen kann man dank Versionierung die letzte Version wieder herstellen.
- manche Unternehmen oder Teams bestimmen eine zentrale Instanz, die für die Inhalte und Übersichtlichkeit im Wiki verantwortlich ist. Aus meiner Erfahrung ist das ein erster Schritt, der allerdings früher oder später nicht mehr mit dem Wachstum des Wikis statthalten kann, wenn nicht parallel eine Sensibilisierung der Nutzer stattfindet und diese auch nachhaltig regelmäßig erneuert wird, z. B. durch Doku- oder Gärtner-Treffen.
- bei Doku- oder Gärtner-Treffen kommen möglichst viele zusammen dokumentierende Menschen zu einer Besprechung der aktuellen Inhalte zusammen. Dabei kann z. B. über die Übersichtlichkeit, die Strukturierung und mögliche Optimierungen, wie z. B. die Nutzung bzw. Anpassung von Vorlagen oder Umstrukturierung von Seiten und Hierarchien gesprochen werden. Auch können Tipps und Tricks, z. B. hilfreiche Makros und Tastenkürzel etc ausgetauscht werden.
- ggf. kann für die zentrale Instanz oder die Doku-/Gärtner-Treffen (der Gärtner bekämpft den Wildwuchs) auch noch über Automatismen nachgedacht werden, die z. B. die Erstellung ähnlich benannter Seiten anmahnen oder Metriken erstellen, wie übersichtlich das Wiki gerade ist – für den Anfang ist das meist nicht erforderlich.
Allen Lösungen sollte nach dem gemeinsamen Beschluss, wie die Lösung aussehen soll, ein gemeinsames Aufräumen und Konsolidieren der bisherigen Inhalte vorangehen, um eine gute Basis zum Hegen und Pflegen zu haben. Ansonsten scheitert die Umsetzung der Lösung gerne am sogenannten “Broken Window Syndrom” – man denkt sich beim Dokumentieren, dass es sowieso schon unübersichtlich ist und man sich deswegen auch keine Gedanken machen muss, ob man es noch unübersichtlicher macht.
Aus meiner Praxis als Atlassian & Collaboration Consultant kann ich sagen, dass ich in der Regel eine Kombination aus allen drei Lösungen empfehle mit Option auf Lösung 4 (die Automatisierung als Unterstützung). Warum möchte ich mit den folgenden möglichen Auswirkungen einer gemeinsamen “Gärtner”-Kultur erläutern – ich freue mich auf euer Feedback, ob ihr diese bei euch festellen könnt bzw. konntet:
Sieben mögliche Auswirkungen einer gemeinsamen “Gärtner”-Kultur
- Durch die Sensibilisierung der Nutzer werden Seiten bewusster erstellt und bearbeitet und damit eine besser lesbare und pflegbare Dokumentation erstellt und somit größerer Mehrwert aus der Wiki-Nutzung gewonnen.
- Dadurch dass eine oder mehrere Personen für die Übersichtlichkeit etc. verantwortlich sind gerät das Thema nicht in Vergessenheit bzw. gibt es Ansprechpartner, falls der Wildwuchs erneut beginnt.
- Wenn diese Person bzw. Personen ein regelmäßiges Doku- bzw. Gärtner-Treffen ins Leben rufen und am Leben halten, steigt die Qualität und Übersichtlichkeit der Dokumentation nachhaltig und die Sensibilisierung wird verankert.
- Ebenso kann bei diesen Treffen ein Wissenstransfer sowohl über Inhalte und Strukturierung für neuere Kollegen als auch bezüglich der bestmöglichen Nutzung der Wiki-Funktionen erfolgen.
- Durch die Treffen kann die Dokumentation wirklich zu einer gemeinsamen Dokumentation werden, einer Dokumentation von uns allen für uns alle (wir haben ja gemeinsam darüber gesprochen und sind uns einig bzw. haben Konflikte ausgesprochen).
- Bei den Treffen kann ggf. über mögliche Defizite der Dokumentation, z. B. fehlenden Themen etc. gesprochen und die daraus resultierenden Aufgaben verteilt werden, sodass die Dokumentation gemeinsam verbessert wird.
- Ebenso kann über mögliche Defizite der Wiki-Funktionalitäten bzw. weitere Nutzungsmöglichkeiten gesprochen und der Umgang mit diesen z. B. durch die Evaluierung von Erweiterungen angegangen werden.
Bildnachweis
- Beitragsbild, Screenshots: Christoph Thomas, CC BY-SA 3.0
- Wildwuchs-Foto: Metilsteiner (Own work), CC BY-SA 3.0
