Interne Dokumentation 2026: Aufbau, Vorlagen + Tipps

Interne Dokumentation ist das schriftliche Wissen, das ein Team für sich selbst festhält: wie die Arbeit erledigt wird, warum Entscheidungen gefallen sind und was neue Leute wissen müssen. Das meiste davon fällt in vier Typen. Das sind Prozessdokus, Standardarbeitsanweisungen (SOPs), Onboarding-Guides und Entscheidungsprotokolle. Gute interne Dokus sind kurz, haben einen Owner, sind visuell und leicht zu finden.

Die meisten Teams haben kein Dokumentationsproblem. Sie haben ein Vertrauensproblem. Jemand hat vor zwei Jahren eine Wiki-Seite geschrieben, das Tool hat sich geändert, und jetzt glaubt niemand mehr etwas im Wiki. Also fragen alle im Chat, und dieselbe Frage wird diesen Monat zum fünften Mal beantwortet.

Dieser Guide zeigt dir, wie du das behebst: eine Struktur, die mitwächst, ein Ownership-Modell, Vorlagen zum Kopieren, Pflegegewohnheiten und ein Abschnitt zu visuellen Dokus. Wenn du zuerst tiefer in einen Typ einsteigen willst, fang mit diesem Leitfaden zur Prozessdokumentation an.

Was ist interne Dokumentation?

Interne Dokumentation ist jedes Dokument, das für Leute innerhalb deiner Firma geschrieben wird, nicht für Kunden. Sie deckt das „Wie" und das „Warum" deiner Arbeit ab. Denk an Setup-Anleitungen, Checklisten, Runbooks, Meeting-Entscheidungen, Richtlinien und den Onboarding-Plan für eine neue Kollegin oder einen neuen Kollegen.

Das Schlüsselwort ist intern. Diese internen Dokus können Kontext voraussetzen, den ein Kunde nicht hätte. Sie können interne Tools nennen, auf private Dashboards verlinken und auf Marketing-Politur verzichten. Diese Freiheit ist nützlich, aber sie ist auch der Grund, warum interne Dokus so schnell veralten: Niemand von außerhalb des Teams liest sie und beschwert sich.

So unterscheiden sich interne Dokus von externen:

Warum interne Dokumentation wichtig ist

Jede Frage, deren Antwort nur in einem Kopf steckt, kostet doppelt Zeit. Zuerst wartet die Person, die fragt. Dann unterbricht die Expertin oder der Experte die eigene Arbeit, um zu antworten.

Die Zahlen bestätigen das. In der Stack Overflow Developer Survey 2024 gaben 61 % der Befragten an, dass sie bei der Arbeit mehr als 30 Minuten am Tag mit der Suche nach Antworten verbringen. Dieselbe Umfrage ergab, dass 30 % der Entwickler zehnmal oder öfter pro Woche auf Wissenssilos stoßen. Das ist kein reines Entwicklerproblem. Vertrieb, Support, Finanzen und Operations kämpfen mit derselben Reibung.

Gute interne Dokumentation zahlt sich auf ein paar klare Arten aus:

• Schnelleres Onboarding. Neue Leute lesen, bevor sie fragen, und sind so in Wochen statt Monaten voll einsatzfähig.
• Weniger wiederholte Fragen. Du antwortest einmal schriftlich und schickst danach einen Link.
• Weniger Risiko, wenn Leute gehen. Das Wissen bleibt, wenn die eine Person, die „weiß, wie die Abrechnung funktioniert", weiterzieht.
• Bessere Entscheidungen. Wenn die Begründung früherer Entscheidungen aufgeschrieben ist, hört das Team auf, abgeschlossene Debatten neu zu eröffnen.
• Remote-Arbeit, die funktioniert. Schriftliche Dokus lassen Leute in anderen Zeitzonen weiterarbeiten, ohne auf einen Call zu warten.

GitLab ist hier das bekannte Beispiel. Sein Handbook-first-Ansatz bedeutet, dass Änderungen erst ins Handbuch geschrieben und dann angekündigt werden. So weit musst du nicht gehen, aber das Prinzip stimmt: Was nicht aufgeschrieben ist, ist nicht passiert.

Die 4 Typen interner Dokumentation

Die meisten Teams brauchen alle vier. Jeder beantwortet eine andere Frage, und wer sie vermischt, bekommt Dokus, mit denen niemand etwas anfangen kann.

1. Prozessdokumentation

Prozessdokus beschreiben, wie ein Stück Arbeit von Anfang bis Ende abläuft. Sie beantworten die Frage „Wie wird das hier erledigt?". Eine Prozessdoku für das Veröffentlichen von Inhalten könnte abdecken, wer schreibt, wer prüft, wo Entwürfe liegen und was „fertig" bedeutet.

Prozessdokus funktionieren am besten als Mix aus kurzem Überblick und einem Flussdiagramm oder einer nummerierten Liste. Bleib auf der Ebene von Phasen und Übergaben, nicht bei jedem Klick. Der Leitfaden zur Prozessdokumentation führt dich durch ein Framework in fünf Schritten, um sie zu schreiben.

2. Standardarbeitsanweisungen (SOPs)

Eine SOP ist die herangezoomte Version. Sie deckt eine einzige Aufgabe Schritt für Schritt ab, damit jede Person sie auf dieselbe Weise erledigen kann. „So stellst du eine Rückerstattung aus" ist eine SOP. „So bearbeitet das Support-Team Abrechnungstickets" ist ein Prozess.

SOPs brauchen Präzision. Jeder Schritt sollte eine Aktion sein, in der richtigen Reihenfolge, mit dem erwarteten Ergebnis. Hier verdienen sich Screenshots ihren Platz, denn „klick auf das Zahnrad-Symbol oben rechts" ist mit einem Pfeil auf einem Bild viel klarer. Eine fertige Struktur findest du in diesen Vorlagen für Standardarbeitsanweisungen.

3. Onboarding- und Schulungsdokus

Onboarding-Dokus beantworten die Frage „Was muss ich wissen, um hier nützlich zu sein?". Dazu gehören eine Checkliste für die erste Woche, Zugriffsanfragen, ein Glossar interner Begriffe und Links zu den wichtigsten Prozessdokus und SOPs.

Ein guter Trick von David Nunez, der erste feste Doku-Mitarbeiter bei Uber und später der erste Head of Docs Content bei Stripe, ist es, jede neue Person den Onboarding-Guide verbessern zu lassen. Nur sie sehen ihn mit frischem Blick. Sein komplettes Playbook steht in diesem First-Round-Review-Interview zu interner Dokumentation. Für Schulungen, die als Video besser funktionieren, sieh dir an, wie du ein Tutorial-Video erstellst, das Leute bis zum Ende schauen.

4. Entscheidungsprotokolle

Ein Entscheidungsprotokoll hält eine wichtige Entscheidung fest: was du entschieden hast, was du sonst noch erwogen hast und warum. Engineering-Teams nennen das Architecture Decision Records, kurz ADRs. Bekannt wurde das Format durch Michael Nygards Beitrag über das Dokumentieren von Architekturentscheidungen, und die ADR-Community-Website sammelt Vorlagen und Tools.

Entscheidungsprotokolle sind nicht nur etwas für Entwickler. Preisänderungen, Anbieterwahl und Einstellungspläne profitieren alle vom selben Format. Die Regel ist einfach: einmal schreiben, die Begründung nie nachträglich ändern und das Protokoll als „ersetzt" markieren, wenn eine neuere Entscheidung es ablöst. Genau diese Historie ist der ganze Sinn.

Weitere Dokus rund um die vier Typen

Deine Wissensdatenbank enthält auch Referenzmaterial. Dazu gehören Release Notes, Runbooks, Bug Reports und Richtlinien. Für sie gelten dieselben Regeln zu Ownership und Aktualität. Wenn dein Team Software ausliefert, sind eine einheitliche Release-Notes-Vorlage und eine gemeinsame Bug-Report-Vorlage zwei schnelle Gewinne.

So baust du eine Wissensdatenbank, in der sich dein Team zurechtfindet

Struktur ist das, was eine Team-Wissensdatenbank von einem Haufen Seiten unterscheidet. Wenn Leute nicht erraten können, wo eine Doku liegt, suchen sie nicht danach. Sie fragen im Chat.

So baust du eine Wissensdatenbank, die auch beim Wachsen hält:

1. Wähle einen Ort. Nimm ein einziges Tool als Single Source of Truth. Dokus, die über ein Wiki, drei geteilte Laufwerke und angepinnte Chat-Nachrichten verstreut sind, vertraut niemand.
2. Organisiere zuerst nach Team oder Bereich. Leg für jedes Team einen eigenen Bereich an, etwa Engineering, Support, Sales und People Ops. Leute wissen, welches Team für ein Problem zuständig ist, auch wenn sie den Titel der Doku nicht kennen.
3. Gib jedem Bereich eine Landingpage. Eine kurze Seite mit den zehn meistgenutzten Dokus des Bereichs bringt mehr als jeder Ordnerbaum.
4. Trenne die Doku-Typen in jedem Bereich. Nutz überall dieselben Unterbereiche: Prozesse, SOPs, Onboarding, Entscheidungen, Referenz.
5. Nutz klare, durchsuchbare Titel. „So stellst du eine Rückerstattung in Stripe aus" schlägt „Rückerstattungen v2 (final)". Beginn mit der Aufgabe und nenn den Namen des Tools.
6. Pflege ein Glossar. Eine Seite für Abkürzungen und Projekt-Codenamen erspart viel Verwirrung.

Wenn du ein bewährtes Denkmodell willst, sieh dir Diátaxis an. Es teilt Dokus in vier Arten ein, je nachdem, was die Leser brauchen: Tutorials zum Lernen, Anleitungen für Aufgaben, Referenz für Fakten und Erklärungen für Kontext. Das lässt sich gut auf interne Dokus übertragen. Onboarding ist Tutorial, SOPs sind Anleitungen, ein Glossar ist Referenz und Entscheidungsprotokolle sind Erklärung.

Ein Ownership-Modell, das Umstrukturierungen übersteht

Dokus ohne Owner sterben. Trotzdem haben viele interne Wikis gar kein Owner-Feld, also fühlt sich niemand verantwortlich, wenn eine Seite falsch wird.

Die Lösung: Mach Ownership sichtbar und langweilig. Jede Doku bekommt oben drei Felder:

• Owner: ein Teamname, nicht nur eine Person.
• Zuletzt geprüft: das Datum, an dem jemand bestätigt hat, dass die Doku noch stimmt.
• Prüfen bis: das nächste Datum, an dem sie kontrolliert werden muss.

Warum ein Team und keine Person? Leute wechseln die Rolle und gehen. Wenn der Owner „Support Ops" heißt und nicht „Dana", hat die Doku auch dann noch ein Zuhause, wenn Dana weiterzieht.

So schneiden die gängigen Ownership-Modelle im Vergleich ab:

Die meisten Teams fahren mit einem Mix am besten. Nutz Teams als Owner für die Dokus selbst. Ergänze dann einen rotierenden Steward, manchmal „Docs Czar" genannt, der sich eine Stunde pro Woche um markierte Seiten, kaputte Links und verwaiste Dokus kümmert. Der Steward leitet Probleme an den richtigen Owner weiter, statt alles selbst umzuschreiben.

Vorlagen für interne Dokumentation zum Kopieren

Vorlagen lösen das Problem der leeren Seite und lassen jede Doku vertraut aussehen. Halte sie kurz. Eine Vorlage mit fünfzehn Pflichtabschnitten wird ignoriert.

Vorlage für Wissensdatenbank-Artikel

Nutz sie für SOPs, Anleitungen und die meisten alltäglichen Dokus:

# [Titel mit der Aufgabe zuerst: So erledigst du X in Tool Y]

**Owner:** [Teamname] | **Kontakt:** [Person]
**Zuletzt geprüft:** [JJJJ-MM-TT] | **Prüfen bis:** [JJJJ-MM-TT]

## Zusammenfassung
[Ein oder zwei Sätze: wobei dir diese Doku hilft und wann du sie nutzt.]

## Bevor du anfängst
- [Benötigte Zugänge oder Berechtigungen]
- [Tools oder Dateien, die du geöffnet haben musst]

## Schritte
1. [Eine Aktion pro Schritt. Füg einen Screenshot hinzu, wenn die Oberfläche beteiligt ist.]
2. [Nächste Aktion. Beschreib, was du siehst, wenn es funktioniert.]
3. [Letzte Aktion.]

## Wenn etwas schiefgeht
- [Häufiger Fehler] → [Lösung]

## Verwandte Dokus
- [Link zur übergeordneten Prozessdoku]
- [Link zu einer verwandten SOP]

Vorlage für Entscheidungsprotokolle

Nutz sie immer dann, wenn eine Entscheidung schwer rückgängig zu machen ist oder später wahrscheinlich hinterfragt wird:

# Entscheidung: [Kurzer Name der Entscheidung]

**Status:** Vorgeschlagen | Angenommen | Ersetzt durch [Link]
**Datum:** [JJJJ-MM-TT] | **Entschieden von:** [Namen oder Team]

## Kontext
[Welches Problem oder welcher Druck hat zu dieser Entscheidung geführt?]

## Erwogene Optionen
1. [Option A] mit ihren wichtigsten Vor- und Nachteilen
2. [Option B] mit ihren wichtigsten Vor- und Nachteilen

## Entscheidung
[Was wir gewählt haben, in ein oder zwei Sätzen.]

## Konsequenzen
[Was leichter wird, was schwerer wird und was wir beobachten.]

Für längere Prozessdokus und SOPs nutzt du am besten die Layouts aus den oben verlinkten Guides, statt neue zu erfinden.

Von den Machern dieser Seite

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Schöne Hintergründe, professionelle Anmerkungen, GIF-Aufnahme und sofortiges Teilen in der Cloud, alles in einer App. Einmal 39 $ zahlen, für immer besitzen.

Preis und Funktionen ansehen

Warum interne Dokus sterben und wie du jede Ursache behebst

Fast jedes tote Wiki ist an denselben wenigen Ursachen gestorben. Für jede gibt es eine praktische Lösung.

Ursache 1: Veraltete Inhalte

Das Tool ändert sich, der Prozess ändert sich, und die Doku bleibt, wie sie war. Nach einer schlechten Erfahrung vertrauen die Leser der ganzen Wissensdatenbank nicht mehr.

Die Lösung: Gib jeder Doku die Felder „Zuletzt geprüft" und „Prüfen bis", wie oben gezeigt. Viele Wiki-Tools können Owner erinnern, wenn ein Prüfdatum überschritten ist. Wenn eine Doku falsch ist und sie heute niemand korrigieren kann, setz oben einen Warnhinweis, statt sie stillschweigend kaputt zu lassen.

Ursache 2: Keine Visuals

Eine Textwand ist schwer zu überfliegen und leicht falsch zu verstehen. Schritte wie „öffne den zweiten Tab im Einstellungsbereich" lassen zu viel Raum zum Raten.

Die Lösung: Füg jedem Schritt in der Oberfläche einen annotierten Screenshot hinzu und für alles, was sich bewegt, ein kurzes GIF. Der nächste Abschnitt zeigt, wie das geht.

Ursache 3: Kein Owner

Wenn alle bearbeiten dürfen und niemand verantwortlich ist, repariert niemand etwas. Seiten stapeln sich, Duplikate tauchen auf und die Suchergebnisse füllen sich mit Rauschen.

Die Lösung: Nutz das Modell mit Teams als Owner plus einen rotierenden Steward. Erlaub den Leuten außerdem, Dinge zu löschen. Nunez vergleicht einen Doku-Bestand mit einem Garten: Zurückschneiden gehört zur Arbeit und ist kein Scheitern.

Ursache 4: Schwer zu finden

Wenn die Suche fünf Seiten mit ähnlichen Titeln liefert, geben Leser auf und fragen eine Kollegin. Das bringt dem ganzen Team bei, die Dokus zu überspringen.

Die Lösung: Nutz Titel, die mit der Aufgabe beginnen, eine Landingpage pro Bereich und eine Single Source of Truth. Beantworte Chat-Fragen mit einem Link zur Doku.

Ursache 5: Für den Autor geschrieben

Expertinnen und Experten überspringen Schritte, die sie gar nicht mehr bemerken. Das Ergebnis ist eine Doku, die nur für die Person Sinn ergibt, die sie geschrieben hat.

Die Lösung: Lass jemand Neues die Doku befolgen, während du zuschaust, ohne zu helfen. Jede Stelle, an der die Person stockt, ist ein fehlender Schritt. Der Google Developer Documentation Style Guide ist eine solide Referenz für einfaches, klares Schreiben, auch außerhalb des Engineerings.

Visuelle Dokumentation: annotierte Screenshots und kurze GIFs

Visuals sind der am wenigsten genutzte Teil interner Dokumentation. Mit einem Blick auf einen Screenshot kann ein Leser prüfen: „Bin ich an der richtigen Stelle?" Dieselbe Prüfung braucht im Text einen ganzen Absatz und lässt trotzdem Zweifel.

Wähle das passende Format für die Aufgabe

Annotationsregeln, die Screenshots nützlich halten

1. Eng zuschneiden. Zeig den Teil des Bildschirms, auf den es ankommt, plus genug Kontext zur Orientierung. Ein Vollbild-Screenshot eines 4K-Monitors ist in einem Wiki unlesbar.
2. Auf eine Sache zeigen. Nutz nach Möglichkeit einen Pfeil oder einen Rahmen pro Screenshot. Wenn du mehrere brauchst, nummerier sie passend zu den Schritten.
3. Schritte nummerieren. Nummerierte Marker im Bild, die zur nummerierten Liste im Text passen, lassen Leser folgen, ohne den Faden zu verlieren.
4. Private Daten verwischen. Kundennamen, E-Mail-Adressen, API-Schlüssel und interne Umsatzzahlen sollten nie offen zu sehen sein, auch nicht in internen Dokus. Dokus werden weiter geteilt, als du erwartest.
5. Größen einheitlich halten. Nimm in einer Doku immer dasselbe Fenster in derselben Größe auf, damit die Screenshots nicht springen.
6. Alt-Text schreiben. Beschreib, was das Bild zeigt und warum es wichtig ist. Das W3C-Tutorial zu Bildern erklärt, wie das gut gelingt.

Für einen tieferen Einblick in diese Gewohnheiten sieh dir den Guide zu Screenshots in technischer Dokumentation und das Tutorial zu Schritt-für-Schritt-Anleitungen mit Screenshots an.

Halte GIFs kurz und leicht

Ein GIF sollte eine Aktion zeigen, sauber loopen und klein genug bleiben, um in einer Wiki-Seite schnell zu laden. Ziel sind unter 15 Sekunden und höchstens ein paar Megabyte. Wenn ein GIF zu schwer ist, kannst du es mit einem kostenlosen GIF-Kompressor verkleinern, mit dem du Qualität, Größe und Framerate direkt im Browser reduzierst. Für eine einmalige Markierung ohne Installation eignet sich ein kostenloses Online-Tool zur Bildannotation, das Pfeile, Formen, Text, Hervorhebungen und Verwischen beherrscht.

Beim Aufnehmen geht die Zeit verloren

Das Schreiben der Schritte ist selten der langsame Teil. Aufnehmen, Zuschneiden, Annotieren, Verwischen und Hochladen jedes Bildes ist es. Wenn dein Team viele SOPs schreibt, lohnt sich ein eigenes Aufnahmetool schnell.

ScreenSnap Pro ist eine Option, die diesen Ablauf auf Mac und Windows abdeckt. Es nimmt einen Bereich, ein Fenster oder den ganzen Bildschirm auf und hat 15 Annotationswerkzeuge, darunter Pfeile, Text, Verwischen, Verpixeln und einen Zähler für nummerierte Schritte. Außerdem nimmt es den Bildschirm direkt als GIF auf, ohne Umweg über eine Videokonvertierung. Der optionale Cloud-Upload liefert dir einen teilbaren Link, den du in jedes Wiki einfügen kannst. Es ist ein einmaliger Kauf für 39 $ statt eines Abos, und eine Lizenz gilt für 2 Computer. Hier kannst du die Preise ansehen.

Ein internes Wiki oder Dokumentationstool auswählen

Es gibt nicht das eine richtige Tool für interne Dokus. Das richtige ist das Tool, das dein Team ohnehin jeden Tag öffnet, mit guter Suche und den Funktionen, die deine Pflegegewohnheiten brauchen. Ein neues Wiki repariert keine Kultur, die nichts aufschreibt.

Mit diesen Fragen bewertest du jedes interne Wiki oder Wissensdatenbank-Tool:

• Suche: Finden Leute eine Doku über die Wörter, die sie eintippen würden, und nicht nur über den exakten Titel?
• Ownership und Prüfdaten: Kannst du einen Owner festlegen und Erinnerungen für Prüfungen einstellen?
• Berechtigungen: Kannst du vertrauliche Dokus, etwa zu HR oder Finanzen, ohne separates Tool einschränken?
• Bilder und Video: Kannst du einen Screenshot oder ein GIF direkt einfügen, und wird es inline angezeigt?
• Vorlagen: Kannst du deine Vorlagen speichern, damit neue Dokus mit den richtigen Abschnitten starten?
• Versionshistorie: Siehst du, wer was geändert hat, und kannst du eine schlechte Änderung zurücksetzen?
• Ausstiegsweg: Kannst du alles exportieren, falls du später wechselst?

Engineering-Teams halten technische Dokus oft als Markdown im Repo, direkt neben dem Code. Fachteams fahren meist besser mit einem Wiki mit visuellem Editor. Beides zu mischen ist in Ordnung, solange jeder Bereich einen klaren Ort hat und die Landingpages aufeinander verlinken. Wenn du Optionen vergleichst, zeigt diese Übersicht der Tools für Prozessdokumentation die Abwägungen nach Anwendungsfall.

Pflegerituale, die Dokus am Leben halten

Dokus zu schreiben ist ein Projekt. Sie nützlich zu halten ist eine Gewohnheit. Diese Rituale sind absichtlich klein, damit sie auch stressige Wochen überstehen.

Wöchentlich

• Steward-Durchgang (30 bis 60 Minuten). Der rotierende Steward prüft markierte Seiten, kaputte Links und Dokus mit überschrittenem Prüfdatum und stupst dann die Owner an.
• Mit einem Link antworten. Jedes Mal, wenn jemand eine Frage im Chat beantwortet, verlinkt er die Doku. Wenn es keine gibt, schreibt er zuerst eine kurze.

Bei jeder Änderung

• Dokus in der Definition of Done. Ein Feature, eine Prozessänderung oder ein Toolwechsel ist erst fertig, wenn die betroffenen Dokus aktualisiert sind. Füg deiner Ticket- oder Pull-Request-Vorlage eine Checkbox hinzu.
• Dokus beim Arbeiten mitschreiben. Schreib die echten Schritte auf, während du eine Aufgabe zum ersten Mal erledigst. Das dauert Minuten und wird zum ersten Entwurf der SOP.
• Screenshots erneuern, wenn sich die Oberfläche ändert. Notier dir, welche Dokus welche Bildschirme zeigen, damit ein Redesign eine schnelle Neuaufnahme auslöst.

Monatlich

• Die meistgelesenen Dokus prüfen. Ein kleiner Teil der Dokus bekommt den Großteil des Traffics. Nunez schätzt, dass etwa 10 % der Dokus rund 90 % der Aufrufe erzielen. Sorg dafür, dass diese 10 % makellos sind.
• Suchprotokolle prüfen. Suchen ohne Ergebnis zeigen dir, welche Dokus fehlen.

Vierteljährlich

• Ausmisten. Archiviere alles, was seit sechs Monaten niemand angesehen hat, und alles, was ersetzt wurde. Weniger, bessere Dokus schlagen ein großes, lautes Wiki.
• Onboarding-Durchgang. Bitte die zuletzt eingestellte Person, den Onboarding-Guide mit allem zu ergänzen, was sie verwirrt hat.

Checkliste mit Best Practices für interne Dokumentation

Nutz diese Checkliste, bevor du eine neue interne Doku veröffentlichst:

• Der Titel beginnt mit der Aufgabe und nennt das Tool
• Die Felder Owner, zuletzt geprüft und prüfen bis sind ausgefüllt
• Die Schritte sind nummeriert, eine Aktion pro Schritt
• Schritte in der Oberfläche haben einen zugeschnittenen, annotierten Screenshot, Bewegung bekommt ein kurzes GIF
• Private Daten sind verwischt und jedes Bild hat Alt-Text
• Die Doku verlinkt auf ihre übergeordnete Prozessdoku und verwandte SOPs
• Jemand, der sie nicht geschrieben hat, hat sie einmal befolgt

Häufig gestellte Fragen

Was ist interne Dokumentation?

Interne Dokumentation ist das schriftliche Wissen, das eine Firma für die eigenen Leute festhält und nicht für Kunden. Dazu gehören Prozessdokus, SOPs, Onboarding-Guides, Entscheidungsprotokolle, Runbooks und Richtlinien. Ihre Aufgabe ist es, dem Team zu helfen, die Arbeit jedes Mal gleich zu erledigen, und Wissen zu halten, wenn Leute weiterziehen.

Was sind die wichtigsten Typen interner Dokumentation?

Die vier wichtigsten Typen sind Prozessdokumentation, Standardarbeitsanweisungen, Onboarding- und Schulungsdokus und Entscheidungsprotokolle. Die meisten Teams pflegen zusätzlich Referenzmaterial wie Glossare, Release Notes und Runbooks. Jeder Typ beantwortet eine andere Frage, also halte sie in getrennten Bereichen deiner Wissensdatenbank.

Wie hältst du interne Dokumentation aktuell?

Gib jeder Doku ein Team als Owner, ein Datum „zuletzt geprüft" und ein Datum „prüfen bis". Nimm Doku-Updates in deine Definition of Done auf, mach mit einem rotierenden Steward einen kurzen wöchentlichen Durchgang und miste jedes Quartal alte Dokus aus. Erneuere Screenshots, sobald sich die gezeigte Oberfläche ändert.

Was gehört in eine Vorlage für Wissensdatenbank-Artikel?

Eine gute Vorlage für Wissensdatenbank-Artikel hat einen Titel, der mit der Aufgabe beginnt, Owner und Prüfdaten, eine Zusammenfassung in einem Satz, Voraussetzungen, nummerierte Schritte, einen Abschnitt zur Fehlerbehebung und Links zu verwandten Dokus. Halte sie kurz, damit Leute sie nutzen. Plan neben jedem Schritt, der eine Oberfläche betrifft, einen Platz für einen Screenshot ein.

Sollten interne Dokus Screenshots und GIFs enthalten?

Ja, für jeden Schritt, der einen Bildschirm betrifft. Ein annotierter Screenshot zeigt dem Leser genau, wo er klicken muss, und ein kurzes GIF erklärt Bewegungen, die sich im Text schwer beschreiben lassen. Schneide eng zu, nummeriere die Schritte, verwische private Daten und schreib für jedes Bild einen Alt-Text.

Klein anfangen und dranbleiben

Du brauchst keine komplette Doku-Überholung, um Ergebnisse zu sehen. Nimm die zehn Fragen, die dein Team am häufigsten beantwortet, schreib für jede eine kurze Doku, gib jeder einen Owner und verlinke sie jedes Mal, wenn die Frage auftaucht.

Dann bau die Gewohnheiten auf: Prüfdaten, ein rotierender Steward, Dokus in der Definition of Done und Visuals für jeden Schritt in der Oberfläche. Wenn das Aufnehmen und Annotieren von Screenshots der langsame Teil deiner Doku-Arbeit ist, erledigt ScreenSnap Pro das auf Mac und Windows für einmalig 39 $.