Wir bleiben ganz profan, und doch ganz konkret. Kennen Sie das folgende hier?
kundenproposal_2.docx
Kundenproposal.docx
Kundenproposal_2_rev.docx
Kundenproposal_3.docx
Kundenproposal_3_tim.docx
Kundenproposal_3_tim_lara.docx
Kundenproposal_3_tim_lara_2.docx
Kundenproposal_4.docx
Kundenproposal_3_tim_lara_korr.docx
Kundenproposal_4_2.docxKennen Sie das? Welche Datei sollten Sie dem Kunden nun schicken? Welche Datei enthält den gültigen Stand, wenn überhaupt eine?
Nachdem wir es ja neulich vom Beherrschen des eigenen Werkzeugs hatten, sehen wir uns das für Versionen von Dokumenten mal an.
This post is also available in English.
Die Geschichte der Versionierung
Die Geschichte der Versionierung beginnt weit vor unserer Zeitrechnung. Yuval Noah Harari schreibt in seinem Buch Eine kurze Geschichte der Menschheit, dass die Erfindung der Schrift nur der erste wichtige Schritt zur Hochkultur gewesen sei. Doch – und er schildert das sehr anschaulich – wie konnten zwei Streitende in Babylon in der großen Besitz- und Steueraufzeichnungs-Bibliothek denn die richtigen Tontafeln finden oder durch den Bibliothekar finden lassen?
Dafür braucht es eine Ablagesystematik, und eine Methode, Änderungen zu kennzeichnen und sicherzustellen, dass immer bekannt ist, was die aktuellste und gültige Information ist.
Laut Harari ist somit Bürokratie die zweite wichtige Errungenschaft, die eine Hochkultur überhaupt erst möglich macht. Das ist mehr als dreitausend Jahre her.
Und jetzt kommen Sie, erstellen veränderte Kopien von Tontafeln und stellen sie einfach wieder irgendwo ins Regal.
Ablage als Lernfach
Eine gute Ablage mit Papier sicherzustellen, das lernen immer noch ganz viele Berufsgruppen in ihrer Ausbildung. Wie eine Regalsystematik funktioniert, wie in einem Ordner auch tatsächlich Ordnung zu halten ist, wie Loseblattwerke aktualisiert werden, und wie man Änderungen an Blättern oder Ordnern so fortschreibt, dass auch die nächste Verwalterin direkt damit weiter machen kann.
Das Problem ist nun, dass zum einen ganz viele Menschen, die mit Dateien arbeiten, niemals Ablagesystematik gelernt haben, und zum anderen diejenigen, die es gelernt haben versuchen, diese Techniken eins zu eins auf Dateien anzuwenden. Beide – gelernte Bürokaufleute und andere – haben ihre jeweils eigenen impliziten Annahmen, wie Ablage funktioniert. Meist haben sie nur implizite Annahmen noch nicht einmal explizite Annahmen.
Treffen beide Arten von Menschen aufeinander, kommt es zu Chaos in der digitalen Ablage.
Versionierung durch Software
Aus der Softwareentwicklung kennen wir die programmgestützte Versionierung. Die Ablage geschieht also nicht durch ständig manuelle und hoffentlich vereinheitlichte Vergabe von Dateinamen für fortlaufende Veränderungen, sondern durch eine Software.
Das ist jetzt nicht wirklich neu. SCCS, das Source Code Control System war eines der ersten breit eingesetzten Versionierungssysteme und bereits Anfang der 1970er Jahre im Einsatz. Das ist jetzt gut vierzig Jahre her, und so langsam könnten Sie das auch mal anerkennen.
Die Idee ist ganz einfach:
Statt dass Sie den Buchhalter spielen und eine Datei immer als neue Version ablegen und jeder, der das Dokument benutzen will, diese Gedankengänge nachvollziehen muss, überlassen Sie diese Aufgabe der Software.
Sie sagen nur noch, dass es jetzt eine neue Version des Dokuments gibt. Die korrekte Ablage sowie die Auslieferung jeweils des neuesten Standes an andere übernimmt die Software. In der Softwareentwicklung ist das Standard, und niemand, der auch nur halbwegs ernsthaft Software entwickelt, würde ohne Versionierungssystem arbeiten.
Meine Güte – was muss ich denn da wieder lernen?
Etwas oder fast gar nichts, das kommt darauf an.
Zunächst einmal: explizite Versionsverwaltungssysteme wie Git oder Subversion beißen nicht. Zumindest keine Informatiker, und bei allen anderen beißen sie nicht besonders fest. Es gibt ganz hervorragende Einführungen in Git oder Subversion für Nicht-Softwareentwickler. Dennoch verstehe ich, dass der Gedanke, ein Dokument quasi aus der Bibliothek auszuleihen, zu bearbeiten und nachher wieder ordentlich zurückzugeben, für viele ganz seltsam erscheint.
Aber ich möchte Ihnen einige andere Systeme vorstellen, die eine Versionierung von Dateien implizit vornehmen, also ohne, dass Sie überhaupt etwas machen müssen.
Denn implizite Versionierung funktioniert am besten, wenn Sie bestimmte Dinge eben gerade nicht machen.
Implizite Versionierung in Confluence, SharePoint, OneDrive, Dropbox, Google Drive
Sie verwenden in Ihrer Firma oder Ihrer Organisation Atlassian Confluence, Microsoft SharePoint oder OneDrive, Dropbox, oder Google G Suite inklusive Google Drive?
Dann herzlichen Glückwunsch, denn alle diese Systeme bieten implizite Versionierung.
Implizite Versionierung heißt: Sie speichern eine Datei wieder ab, und im Hintergrund überschreibt die Software nicht einfach die Datei, sondern legt eine neue Version an. Die alten Stände Ihres Dokuments können Sie über den Versionsverlauf ersehen.
Implizite Versionierung kann sogar heißen, dass Sie beispielsweise in Microsoft Word oder PowerPoint sich direkt die Änderungen von Version zu Version anzeigen lassen können, ohne dass Sie vorher die Änderungsverfolgung eingeschaltet haben.
Exemplarisch möchte ich die implizite Versionierung an zwei Systemen kurz aufzeigen.
Implizite Versionierung in Confluence
Confluence von Atlassian ist eine Intranet-Software und ist eigentlich nicht für Dokumentenmanagement gedacht. So gibt es auch keine Ordner und Bibliotheken für Dateien, sondern diese werden an Seiten angehängt.
Macht aber nichts, die Versionen werden trotzdem vorgehalten.
Um auf eine alte Version zuzugreifen, wählen Sie auf einer Confluence-Seite oben rechts die drei Punkte und dann Attachments/Anhänge. In der folgenden Ansicht können Sie für jede Datei alle Versionen anzeigen lassen, wer und wann die Datei gespeichert hat, und natürlich auch die alten Versionen nochmals herunterladen.
Für Office-Dokumente gibt es rechts jeweils einen Link mit Office öffnen, der statt herunterzuladen direkt die Datei vom Online-Speicherort lädt.
Wenn Sie eine Datei heruntergeladen haben, um sie zu bearbeiten, dann speichern sie diese ohne Veränderung des Namens ab und laden sie dann einfach wieder aufdieselbe Seite hoch.
Es gilt: Nicht umbenennen, nicht unter anderem Namen speichern. Dateiname immer gleich lassen.
Implizite Versionierung in SharePoint/OneDrive
Microsoft SharePoint und Microsoft OneDrive nutzen in den neueren Versionen dieselbe Technologie für das Cloud-Speichern von Dokumenten, deshalb fasse ich die beiden zusammen. Die implizite Versionierung klappt aber auch schon in älteren SharePoint-Versionen und naturgemäß am angenehmsten mit den Office-Programmen aus demselben Haus.
Das schöne ist hier, dass Sie in beispielsweise Word direkt Ihr aktuelles Dokument mit alten Versionen vergleichen lassen können, um die Änderungen zu sehen. Einfach in der Bedienleiste im Reiter Prüfen den Knopf Vergleichen drücken. Dort können Sie – wenn das Dokument von einem versionsfähigen Online-Ordner geöffnet wurde – direkt eine alte Version zum Vergleich auswählen.
Für jedes andere Dokument gilt wie vorhin: Herunterladen, bearbeiten, unter demselben Namen wieder hochladen – wenn Sie SharePoint im Browser nutzen. Wenn Sie den OneDrive-Client für Ihr Betriebssystem nutzen und die Dokument-Bibliothek auf Ihren Computer synchronisieren, dann verwenden Sie das wie einen ganz normalen Ordner.
Auch hier gilt wieder: Nicht umbenennen, nicht unter anderem Namen speichern. Dateiname immer gleich lassen.
Die Änderungshistorie finden Sie in der Web-Ansicht des Ordners wiederum hinter den drei Punkten hinter jedem Dateinamen.
In SharePoint/OneDrive funktioniert die Versionierung sogar, wenn Sie gerade nicht mit dem Internet verbunden sind, weil ja Ordner mit ihrem lokalen Computer synchronisiert werden: Bei der nächsten Synchronisierung spielt das System im Hintergrund all ihre offline vorgenommenen Änderungen als neue Version in den Online-Ordner.
Implizite Versionierung in Dropbox
Auf die Gefahr hin, mich zu wiederholen: So ähnlich funktioniert das auch in Dropbox, das sogar eine MS Office-Integration hat. Im synchronisierten Dropbox-Ordner rechts auf die Datei klicken und Version History auswählen.
Das öffnet dann die Eigenschaften dieser Datei im Browser. Voilà, auch hier sehen Sie wieder die letzten paar Versionen. In der kostenlosen Fassung von Dropbox nur ein paar, in der Bezahlvariante ein paar mehr.
Auch in Dropbox funktioniert die Versionierung, wenn Sie gerade nicht mit dem Internet verbunden sind, weil ja Ordner mit ihrem lokalen Computer synchronisiert werden: Bei der nächsten Synchronisierung spielt das System im Hintergrund all ihre offline vorgenommenen Änderungen als neue Version in den Online-Ordner.
Und was mache ich jetzt damit?
Eigentlich ist es gar nicht so schwer:
Keine Anhängsel an Dateinamen, weder das Datum noch Ihren Namen noch eine fortlaufende Ziffer. All das weiß das Versionierungssystem und zeigt es Ihnen an.
Selbst wenn Sie ein hier nicht angesprochenes System für Intranet oder Dateiablage nutzen, so ist es wahrscheinlich, dass Sie auch dort implizite Versionierung nutzen können. Fragen Sie Ihre IT oder Ihren computeraffinen Kollegen.
Sollte Ihr System keine implizite Versionierung bieten, dann lohnt es sich, ein eigenes Versionierungssystem wie Git zu benutzen, doch das wird dann ein anderer Blogpost.
Was Sie übrigens auch nicht machen sollten, ist tiefe Ordnerhierarchien bauen. Das bringt nichts, außer Ordner mit wenigen Inhalten und ewig langen und fragilen Gesamtpfaden. Vergeben Sie eher sprechende Dateinamen, doch das wird irgendwann ein anderer Blogpost.
Der Computer beißt nicht, sondern unterstützt Sie bei der Arbeit. Das tut er aber nur, wenn Sie ihn lassen.
Meme: Imgflip
Photo: Cloud Storage with Balloon, www.joachimschlosser.de, License Creative Commons Attribution Share-Alike
Ja, ich will…
…komplett auf Versionierungen im Dateinamen verzichten. Und doch gibt es auch in perfectly setup (Microsoft-)Cloud-Infrastrukturen mit Versionshistorien, die bis zum Sankt-Nimmerleinstag zurückgehen, immer wieder Fälle, in denen korrumpierte Dateiversionen abgespeichert werden oder eine Nachvollziehbarkeit der Fehlberechnungen oder Bugs mit der Cloud-Versionshistorie nicht möglich ist.
Als Best-Practise hat sich dort, wo man den Nicht-IT-Kollegen keine (Git-)Repository-Verwaltung aufbürden möchte, bewährt, nur bei strukturellen Changes eine neue Dateiversion zu erstellen, bei inhaltlichen Änderungen aber auf die Cloud/Server-eigene Versionskontrolle zu setzen. Das führt sonst genau zu den oben beschriebenen Rückfragen, „in welcher Version jetzt alle Daten zu finden sind“. Auch Vorlagen, bei denen nur unregelmäßig Veränderungen vorgenommen werden, benötigen keine Versionierung.
Wenn aber Berechnungs- und Formatierungslogiken oder Reihenfolgen, kurz: Veränderungen struktureller Natur vorgenommen werden, lohnt es sich, mit einem Eintrag im dateieigenen Changelog die neue Dateiversion (*.edXY) separat abzuspeichern, um auch auf die Schnelle vergleichen zu können, ob auch alles wie gehabt funktioniert und keine unbeabsichtigten Fehler auslöst.
Das ist zumindeset meine Erfahrung, but feel free to change(log) my mind. ;)
Ja, das klingt für mich nach einem Anwendungsfall für eine temporäre Sicherungskopie, bis verglichen ist, ob die strukturell veränderte Datei auch noch funktioniert. Danach kann diese Kopie wieder gelöscht werden. Jede Kopie einer Datei, die länger oder auf einem gemeinsamen Laufwerk rumliegt, stiftet Verwirrung.