Zu viel Arbeit, zu umständlich, zu chaotisch: Die meisten können technische Dokumentationen nicht leiden. Unsere ECM-Beraterin Anja Genser allerdings ist ein grosser Fan des Dokumentierens. Sie verrät Ihnen 7 Tipps, wie Sie Ihren Mitarbeitenden die ungeliebte Aufgabe erleichtern können.

Wer kennt es nicht: Sieben Projekte gleichzeitig managen, Meetings abhalten, Notizen schreiben und irgendwo abspeichern, Gedankenschleifen drehen, Notizen suchen und nicht wiederfinden, Ideen verwerfen und neu entwickeln, Prozesse ändern. Das meiste ist im Kopf gespeichert. Vorspulen: 15 Monate später, fünf Projekte mehr. Weitere zwei Monate später: die Projektleiterin verlässt das Unternehmen. Päng! Ihr ganzes Wissen nimmt sie mit.

Sie ahnen es: Das frische Gedächtnis Ihrer Mitarbeitenden mit den klaren Erinnerungen von damals ist mittlerweile überschrieben worden von dringenderen Informationen. Und Sie wissen auch: Hätten sie das doch besser dokumentiert! Nur wie bringen Sie Ihr Team dazu, das Dokumentieren wirklich umzusetzen?

Technische Dokumentation bringt viele Vorteile

Dokumentationen sind in ECM-Projekten weit verbreitet. Doch sie gehören zu den unbeliebtesten Tätigkeiten. Dass Dokumentation auch Spass machen können, dafür ist Anja das beste Beispiel. Die ECM-Expertin bewegt sich täglich in komplexen IT-Projekten, die sie für ihre Kund:innen betreut. In einem solchen Umfeld sind auch Monate später noch kleinere Details wichtig.

“Dokumentationen sind dann besonders nützlich, wenn sie alle wichtigen Fakten enthält, die für alle Beteiligten hilfreich sein können.” Anja Genser schreibt die Dokumentationen ihrer Projekte zwar auch für sich selbst, aber vor allem für Kund:innen und Lieferanten. Denn auch interne Dokumentationen müssen möglicherweise externen Audits standhalten.

Wann ist der beste Zeitpunkt für die Projekt-Dokumentation?

Idealerweise läuft die technische Dokumentation nebenher. Sollte dies versäumt worden sein, könnte dies nachgeholt werden, wenn das Projekt auf das Testing zugeht. Denn die Tester:innen können von der Dokumentation profitieren. Sie kann dabei helfen, test cases zu erstellen.

Spätestens zum Ende des Projekts sollte die Dokumentation nachgeholt werden. Hier könnten sich mehrere Beteiligte in einem kurzen Meeting zusammensetzen und gemeinsam das Projekt mithilfe der Dokumentation Revue passieren lassen. Insbesondere bei einer Übergabe, wenn die Verantwortlichkeit des Projekts wechselt, ist eine genaue Dokumentation wichtig.

Wie schreibt man eine gute, technische Dokumentation?

“Ich schreibe sie direkt nebenher, wenn ich an Projekten arbeite. Dann dauert es nicht lange. Und alles ist viel ausführlicher, als wenn ich am Schluss versuchen würde, mich an alles zu erinnern.” Anjas Lieblingsform ist das Wiki. Dort beschreibt sie quasi blanko-Seiten. Für sie ideal, weil sie mit der kompletten Freiheit eines Wikis sehr gut zurecht kommt. Auch lässt sich ein Wiki gut durchsuchen, was hilft, wenn man in den Dokumentationen anderer etwas sucht. Alternativ können Ticket-Systeme genutzt werden oder Word-Dokumente auf einer zentralen Datenablage.

Was beim Schreiben hilft, ist eine zentrale Frage. Zum Beispiel: Wenn ich dieses Projekt in zwei Jahren übernehmen würde, was würde ich wissen wollen? Das führt dazu, zwei Perspektiven mitzudenken. Die eigene und die der anderen Person. Die können sich durchaus unterscheiden, denn beide haben ein unterschiedliches Wissensniveau.

Die beiden Personen im Kopf, schreibt Anja Genser neben offensichtlichen Fakten wie Software-Änderungen auch kleine Erinnerungen an sich selbst. Etwa kurze Notizen, warum sie etwas wie aufgebaut hat. Sie hält zudem die Ergebnisse von Meetings fest. Und auch, warum etwas so programmiert ist, wie es ist. Was sich danach geändert hat, was mit dem oder der Kundin besprochen war.

Besser zu wenig dokumentieren als gar nichts

Doch nicht jeder kommt mit der unstrukturierten Art eines Wikis gut zurecht. Viele Menschen bevorzugen gewisse Regeln oder Vorgaben. “Auch diese Form ist geeignet, etwa, wenn sich auch andere an meinen Dokumentationen orientieren müssen”, sagt Anja. “Ein gewisser Konsens darüber, wie Dokumentation aufgebaut ist, hilft vor allem grösseren Unternehmen. Denn jeder Mensch denkt anders. Also ist auch jede Dokumentation anders. Auch wenn ich am liebsten frei dokumentiere, kann es passieren, dass ich mit der freien Dokumentation einer anderen Person überhaupt nicht zurecht komme.”

Selbst wenn es also Vorgaben gibt, sollte jede Person immer noch gewisse Freiheiten haben. Denn niemandem ist geholfen, wenn manche die Dokumentation völlig verweigern, nur weil sie mit dem System nicht zurecht kommen.

“Wenn jemand schon nicht gern dokumentiert, dann hilft vielleicht das Mindset, zumindest das aufs Papier zu bringen, worüber man sich ärgern würde, wenn man es in einem Jahr wieder herausfinden müsste. Die Knackpunkte und Besonderheiten sozusagen. Es gibt auch Leute, die am besten in Bildern denken und beispielsweise ein Whiteboard abfotografieren. Oder andere, die nur Texte schreiben. Wieder andere machen gerne mal ein Video, wenn es das Dokumentationsmedium zulässt”, sagt die Beraterin.

Wichtig sei es, sich als Team darauf zu einigen, an welchem Ort die Dokumentation abgelegt wird. “Einen festen Ort zu defnieren erleichtert die Suche nach Dokumentationen, die man nicht selbst verfasst hat, sehr. Und Dokumentation überhaupt finden zu können ist noch wichtiger, als dass einem die Struktur innerhalb der Dokumentation zusagt.”

Was tun, wenn sich jemand standhaft weigert, zu dokumentieren?

Wenn tatsächlich nichts passiert, trotz geeigneter Vorlagen und Anleitung, könnte es helfen regelmässig explizit Zeit für die Dokumentation einzuplanen und die Dokumentation auch mit anderen Personen zu besprechen. Im Gespräch mit am Projekt Unbeteiligten fällt schnell auf, an welchen Stellen die Dokumentation noch optimiert werden könnte. Hier die nötige Zeit aufzuwenden, die es braucht, bis die Person sich mit der Dokumentation angefreundet hat, kann auf lange Sicht helfen.

Auch kann es helfen, sich auf den Mindestinhalt eines Dokuments zu einigen. So könnten etwa drei Punkte benannt werden, die besonders wichtig sind, und daher mindestens festgehalten werden sollen. Besser, es stehen nur wenige Infos in der Dokumentation als gar keine.

Die 7 Tipps zusammengefasst:

  1. Zeitpunkt: Sofort während des Projekts mitschreiben.
  2. Ort: Ein Wiki nutzen, falls möglich. Der Vorteil: absolute Freiheit und Durchsuchungsfunktion. Alternativ einen einzigen festen Ort für die Dokumentation festlegen.
  3. Eine Frage als roten Faden im Kopf haben, z.B.: „Wenn ich dieses Projekt in zwei Jahren übernehmen würde, was würde ich wissen wollen?“
  4. Alle Zielpersonen beim Schreiben vor Augen haben.
  5. Besser wenig als gar nichts dokumentieren.
  6. Vorlagen nicht zu eng gestalten, denn zu viele Regeln schrecken ab.
  7. Konkrete Inhalte einer Dokumentation:
    • Fakten: die wichtigsten Eckpunkte des Projekts.
    • Was ist mit Dienstleistern oder Partnern abgesprochen?
    • Technische Inhalte: Welche Funktionalität befindet sich wo? Notizen, warum etwas auf eine bestimmte Art gebaut wurde. Besonderheiten im Code.
    • Ergebnisse und Entscheidungen von wichtigen Meetings.
    • Was hat sich im Laufe des Projekts geändert? Bei Übernahme eines bestehenden Projekts: Warum wurde etwas so und nicht anders programmiert? Was sind Idee und Zweck dahinter?
    • Ende / Ergebnis / Stand der Dinge bei (vorläufigem) Abschluss des Projekts.