Auf der Zugfahrt nach Berlin schaute ich mir den ersten Vortrag der „Write the Docs“-Konferenz an, kurz „WTD“. Maximilian Rosin führte durch Bertolt Brechts Verfremdungseffekt, durch Pokémon und Speedruns, alles im Dienst der Doku. Schon dieser Einstieg war thematisch so breit, nerdig und lebendig, wie es den besten Konferenzen eigen ist: Alles andere kann man schließlich nachlesen.
Write the Docs ist die weltgrößte selbstorganisierte TechDoc-Community mit Schwerpunkt Softwaredokumentation, jedoch einer tatsächlich viel größeren Themenbandbreite. Sie wurde vom US-Amerikaner Eric Holscher 2013 mitgegründet; inzwischen fasst der Slack-Server gut 25.000 User, Themen werden mit großer Dynamik diskutiert. Interessierte erhalten damit recht schnell für die eigene Arbeit relevante Informationen und können – fast noch wichtiger – niedrigschwellig mit Kollegen virtuellen Kontakt aufnehmen. Im „real life“ ist das bei Veranstaltungen an gut 20 Standorten weltweit möglich mit jeweils zwischen 100 und 2.000 registrierten Teilnehmern.
Mit knapp 220 Teilnehmern vor Ort war die Veranstaltung im Berliner Stadtteil Kreuzberg ausverkauft, ergänzt durch gut 200 Log-ins in einem konsequent hybriden Format. Schon am Eingang freute ich mich über die professionelle Hemdsärmeligkeit, die Sticker auf den Laptops und eine Atmosphäre, die von Beginn an eher an ein Meetup als einen Fachkongress erinnerte. Ein Teil dieser Atmosphäre kam durch einfache und klar kommunizierte Verhaltensempfehlungen, zum Beispiel die Pac-Man-Regel: „Stellt euch in Grüppchen immer so auf, dass offensichtlich Platz für jemand anderen bleibt.“ Eine Erleichterung sicher für diejenigen, die Kontakt suchen, aber noch Schwierigkeiten haben, ihn direkt aufzubauen.
Der spielerische Einstieg soll nicht über die pragmatische Motivation dieser Gemeinschaft hinwegtäuschen: „The job of a tech writer is to run toward the screaming,“ brachte es Val Grimm später auf den Punkt: Statt zu versuchen, das unvermeidliche Chaos der Realität durch Prozesse und Strukturen wegzuverwalten (mal Notwendigkeit, mal Angstreflex), stürzen sich die „Documentarians“ mitten hinein. Was soll man auch anderes tun? Software wandelt sich deutlich schneller als, sagen wir, Druckmaschinen oder Mähdrescher. Und sie trägt dabei ähnliche, oft sogar weiterreichende Verantwortungen.
Geteiltes Anderssein
Apropos Verantwortung: Die Rolle des „Documentarian“ ist viel weiter gefasst als die, die üblicherweise Technischen Redakteuren zugewiesen ist. Nach WTD-Lesart (selbst der Begriff „Definition“ ginge hier zu weit) ist ein Documentarian jeder, dem Dokumentation und Kommunikation am Herzen liegen, unabhängig von Titel oder Position. Das schließt Entwickler genauso ein wie zum Beispiel UX-Designer oder Manager. Die Philosophie dahinter: Man muss nicht in Vollzeit schreiben, um Teil der Lösung zu sein; man muss sich nur dafür interessieren, Kommunikation in (hier vor allem: Software-)Produkten zu verbessern.
Allein durch diese Perspektive weichen Silos. In der traditionellen Lesart „besitzen“ die Redakteure die Doku; in der Welt der Documentarians ist die Verantwortung verteilt. Nur ein kleiner Teil der WTD-Community besteht aus Vollzeitredakteuren; die anderen sind fachfremd und genau dadurch nahe dran. Wenn diese unterschiedlichen Gruppen dann als Documentarians zusammenkommen, mögen sich alle ein wenig als Außenseiter fühlen: Entwickler, die gerne dokumentieren, und Redakteure, die gern programmieren. Dieses „geteilte Anderssein“ schafft eine Verbundenheit, die sich nicht über Tools definiert, sondern über das gemeinsame Ziel: verstanden zu werden.
Natürlich bleiben auch in der Dynamik der Softwarewelt Prozesse und Standards unumgänglich für die Qualität. Die Herangehensweise unterscheidet sich jedoch fundamental von dem, was vermutlich für die meisten Leser dieses Hefts Standard ist. Die Welt der Softwaredoku hat gelernt (besser: musste lernen), Wartung zu automatisieren. Sie arbeitet mit Lintern und Tests in CI/CD-Pipelines sowie leichten, schnell rekombinierbaren und eigenständig anpassbaren Tools statt CCMS-Workflows von Drittanbietern.
Ohne den aus der Hardware bekannten hohen Regulierungsdruck und mit breiter gefasstem Selbstverständnis lässt es sich agiler arbeiten – und auch, weil die Stakeholder, die die Software entwickeln, selbst in der Agilität zu Hause sind. In Folge bekommen auf WTD-Konferenzen Themen die Bühne, die ansonsten auf der Hinterbank bleiben: die „Developer Experience“ und radikale Nutzerzentrierung, Docs-as-code, und vor allem essenzielle „soft“ skills wie der offene Umgang mit Fragen der Führung von Mitarbeitern, dem persönlichen Scheitern oder dem Stellenwert der Doku im Gesamtprozess.
Impulse von überall
Im Folgenden ein kurzer Blick auf einige Impulse, die ich aus Berlin mitnahm. Einige der Vorträge sind online (gratis) verfügbar; den Link finden Sie am Ende dieses Artikels.
Das Problem fragmentierter Dokumentationslandschaften (zum Beispiel nach Firmenübernahmen) kennen viele Redakteure nur zu gut. Ian Cowley schilderte in If you build it, they will come den Weg zu einer vereinheitlichten Plattform mit starkem Fokus auf Auffindbarkeit. Anders als bei monolithischen (C)CMS-Projekten zeigte er einen Weg auf, heterogene Inhalte aus verschiedenen Quellen für den Nutzer in einer zentralen, durchsuchbaren Oberfläche zusammenzuführen, ohne zugrunde liegende Prozesse umwerfen zu müssen. Besonders interessant bei Ians Vortrag war die Nähe zur Hardware: Sein „Docs-as-Product“-Ansatz greift (lange) nicht nur bei der reinen Softwaredoku.
In Developer Experience in Technical Writing brachte Michiel Mulders den Begriff der „Developer Experience“ (DX) ins Spiel: Für Entwickler muss Dokumentation mehr sein als nur Text: Interaktive Spielwiesen („Playgrounds“), direkt nutzbare Code-Schnipsel und Kommandozeilen-Tools holen den Nutzer in der Arbeitsumgebung ab, anstatt nur zu informieren. Dokumentation wird vom Nachschlagewerk zum interaktiven Werkzeug, das die Zufriedenheit des Nutzers messbar steigert.
Veraltete Dokumentation ist ein Dauerbrenner, den Dimple Poojary mit einer konsequenten Automatisierung im agilen Umfeld anging. Statt auf manuelle Revisionszyklen zu warten, zeigte sie in Automating Documentation Maintenance Workflow Process for Agile Teams, wie Doku-Aufgaben an die Sprint-Boards der Entwickler gekoppelt werden können und Teil des Entwicklungs-Zyklus werden. Neben der Reduktion manueller Arbeit fördert dies den Stellenwert der Dokumentation als notwendigen Bestandteil der Entwicklung.
Tiffany Hrabusa sprach in A beautiful reciprocal arrangement über das Henne-Ei-Problem vieler Berufseinsteiger: Wie bekommt man den ersten Job ohne Erfahrung – und die Erfahrung ohne Job? Der Weg kann über die Open-Source-Welt führen: Dort zählen weniger Titel oder Zertifizierungen, sondern das Commit: Durch aktive Mitarbeit an OSS-Projekten kann jeder in direkten Kontakt mit Entwicklern kommen und ein Portfolio aufbauen. Ein deutlicher Kontrast – und eine willkommene Ergänzung – zu traditionellen Wegen, die über Notenspiegel, Volontariate und Zertifizierungen führen.
Datensouveränität ist gerade in der aktuellen politischen Landschaft ein essenzielles Thema für viele Unternehmen. Val Grimm stellte in ihrem Vortrag Sovereign Docs vor, wie ihr Team die Dokumentation in Container „verpackt,“ um sie dann unabhängig von Cloud-Anbietern und sogar air-gapped (ohne Verbindung zum Internet) auszuliefern. Ein großer Kontrast zu klassischen Publikationsstrecken, der zeigt, wie Doku ähnlich wie Software als eigenständiges Artefakt behandelt und ausgeliefert werden kann.
Mein persönlicher Favorit, technisch wie menschlich, war Fabrizio Ferri-Benedettis Vortrag Failing Well. In der Dokumentation geht es oft um Minimierung von Risiken, um Fehlervermeidung und das Trimmen auf Perfektion. Fabrizio sprach über das unvermeidliche Scheitern, über berufliche Plateaus, über Texte, die niemand liest, Projekte, die sterben, und die emotionale Arbeit, die daraus folgt. Er bot einen „Feldführer“ für das persönliche Wachstum, der weit über das Erlernen neuer Tools hinausgeht, um psychologische Sicherheit zu schaffen. Ein Beispiel: Oft nehmen wir es zu persönlich, wenn eine aufwendig dokumentierte Funktion kurz vor Release gestrichen wird oder im Backlog „verhungert.“ Fabrizio plädierte dafür, zwischen systemischem und individuellem Scheitern zu unterscheiden. Sicher ist es hilfreich, wenn Redakteure ihren Selbstwert und den wahrgenommenen Stellenwert der Technischen Redaktion von unvermeidbaren organisatorischen Wirren entkoppeln.
Das Komplement einladen
Seit 2016 schreibe ich für tekom und tcworld, und auf Veranstaltungen spreche ich im immer gleichen Themenfeld: Kommunikation, Psychologie, Selbstführung und Haltung. Mit diesen Themen bin ich der bunte Hund auf den tekom-Konferenzen; bei WTD sind solche Themen selbstverständlicher Teil des Programms. Das unvermeidliche Chaos der Realität präventiv ordnen? Oder dorthin rennen, wo es brennt, und mit einer klaren Haltung so viel ins Optimum bringen, dass das Ergebnis präzise und hilfreich ist? Für beides bot die Konferenz ungemein bereichernde Perspektiven, eine pragmatisch-experimentelle Grundhaltung und große Offenheit für Neues.
„It takes courage to advocate for change,“ sagte Ian Cowley in If you build it, they will come. Sicher braucht es nicht viel Mut, um von einer Bubble in die andere zu schauen, aber das Komplementäre bewusst einzuladen und dabei die gegenseitigen Leerstellen als Chance für Weiterentwicklung zu begreifen, erfordert Offenheit.
Jennifer Rondeau sprach in What’s past is prologue über die Geschichte verschiedener TechComm-Communities, darunter auch Write the Docs und tekom. Sie betonte das Komplementäre beider Organisationen: Professionalisierung bei der tekom, Agilität bei WTD. Der typische Diskurs der tekom liefert ein Fundament für Rechtssicherheit, Normenkonformität und Informationsarchitektur; von Write the Docs kommt die Geschwindigkeit und schnelle Wandlungsfähigkeit der Softwarewelt und eine tatsächlich radikale Empathie für die „Experience“ der Nutzer.
In dieser Verbindung kann neben guter Technischer Dokumentation vor allem eine Kommunikationskultur entstehen, die regelkonform ist und dabei Nutzer und Technische Redakteure begeistert. Man müsste es einfach mal machen. Mehr über Write the Docs finden Sie bei writethedocs.org. Mitmachen ist kostenlos. Auf der Website sind die lokalen Meetups gelistet: Die Organisatoren freuen sich bestimmt, bei den nächsten Events auch Mitglieder von tekom Deutschland oder tekom Europe zu begrüßen.
Mehr über Write the Docs finden Sie bei writethedocs.org. Mitmachen ist kostenlos. Auf der Website sind die lokalen Meetups gelistet: Die Organisatoren freuen sich bestimmt, bei den nächsten Events auch Mitglieder von tekom Deutschland oder tekom Europe zu begrüßen. |
