Handbooks first

Wieso Handbook-first?

Ein Handbuch zu schreiben scheint bei einem gutlaufendem Unternehmen inneffizient und unnötig zu sein. Es fühlt sich an, als würde man es nicht brauchen seine Strukturen, seine Prozesse und seine Kultur zu dokumentieren. Umgekehrt ist eine strukturierte Dokumentation der einfachste und effektivste Weg Chaos und Verwirrung vorzubeugen. Bei schnell wachsenden Unternehmen wächst auch das Chaos und die Verwirrung in der Belegschaft ohne Dokumentation. Erstellt eine Quelle der Wahrheit. Alles was für euch Relenvanz hat, etwa Entscheidungen, Prozesse, Tools, Werte und die Kultur, sollten im Handbuch aufgeschrieben werden.

Startet sofort

Einer der wichtigsten Faktoren bei der Transition zur Remote-Arbeit ist das Schreiben eines Handbuchs. Das gilt auch für Unternehmen, die an verschiedenen Standorten weltweit tätig sind. Die beste Zeit um mit dem Erstellen eines Handbuchs anzufangen ist Jetzt.

Das Handbuch ensteht iterativ!

Versucht nicht ein fertiges Handbuch zu erstellen. Das wird nicht funktionieren. Lasst alle Mitarbeiter an der Entsteheung ab der ersten Minute teilhaben. Das sorgt dafür, dass die Erstellung deutlich schneller vonstatten geht, mit dem Nebeneffekt, dass alle Mitarbeiter das Gefühl entwickeln, für die Richtigkeit des Handbuchs verantwortlich zu sein. Betrachtet das Handbuch als Auszubildenen, dem ihr tagtäglich neue Dinge beibringen solltet.

Die Dokumentation ist niemals zu Ende

Handbücher entstehen interativ und machen einige Evolutionstufen durch - und das ständig. Genauso wie ihr tagtäglich mit neuen Herausforderungen konfrontiert werdet, so wird sich auch das Handbuch laufend verändern. Es sollte als Daily Business Task Bestandteil des Arbeitstags sein, dass man auch Dinge im Handbuch aufschreibt.

Tools für die Erstellung eines Handbuchs

Ein allgemeiner Irrglaube ist, dass ein Wiki der richtige Ort ist für das Handbuch ist. Wir bei Ninjaneers glauben, dass ein Wiki genau der falsche Ort ist für ein Handbuch ist. Wir haben uns vor einigen Jahren dazu entschieden, dass wir kein Wiki wie etwa Confluence mehr einsetzen wollen. Die Inhalte waren größtenteils veraltet. Keiner fühlte sich für die Pflege verantwortlich. Die Struktur war schon nach wenigen Monaten ein undurchsichtiger Wildwuchs.

Statt eines Wikis nutzen wir nun die Tools, die wir sowieso tagtäglich nutzen. In unserem Fall die Sourcecodeverwaltung unseres Vertrauens GitLab. Wir haben also alle Vorteile, die wir auch bei der Entwicklung von Softwareprodukten nutzen, wie etwa Pull Requests oder ein Issue Tracker, sowieo die Kraft der Gewonheit.