5
Dokumentation richtig aufbauen - aber wie?
Hallo,
ich suche Infos und Tipps, wie eine Dokumentation zu einer Serverinstallation zzgl. weiterer Appinstallationen korrekt erstellt wird. Was muss rein, was kann rein. Macht man das mit Word oder mit Wiki (mein Favorit) oder braucht es doch ein DMS ? Für Tipps und Verweise auf Produkte (am liebsten OpenSource) wäre ich sehr dankbar.
Gruß
Jens
ich suche Infos und Tipps, wie eine Dokumentation zu einer Serverinstallation zzgl. weiterer Appinstallationen korrekt erstellt wird. Was muss rein, was kann rein. Macht man das mit Word oder mit Wiki (mein Favorit) oder braucht es doch ein DMS ? Für Tipps und Verweise auf Produkte (am liebsten OpenSource) wäre ich sehr dankbar.
Gruß
Jens
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 102751
Url: https://administrator.de/forum/dokumentation-richtig-aufbauen-aber-wie-102751.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
ob du das mit Word oder einem Wiki oder einem DMS aufbaust ist eigentlich ziemlich egal
Wichtig ist erstmal das du dir ein Konzept machst was du dokumentieren möchtest und für wen du die Doku machst!
Wenn es darum geht in drei Jahren noch zu wissen reicht ein Detaillierter Überblick der Installierten Software und der Vorgenommenen Einstellungen für jedes Programm, oder willst du ermöglichen das in deiner Abwesenheit (Krankheit oder Urlaub) ein Kollege oder Ersatzmann in der Lage sein soll, ein typischer Weise gerade dann eintretendes, Desaster zu beheben?
Wenn der zweite Fall eher der Sinn deiner Übung ist, solltest du eine Schritt für Schritt Anleitung mit Screenshots und Visiozeichnungen (o.ä.) und genauer Beschreibung jeder Einstellung vornehmen und diese vor allem immer (!) aktuell halten.
Es gibt nicht Bescheideneres als veraltete Dokus und falsche Passwörter (wobei nicht alle Passwörter in die Doku gehören, sondern eine Verweis in welchem Safe die Paswörter liegen und wer Zugang dazu hat.)
Egal ob du dich für Word oder Wiki entscheidest, sorge dafür das es mindestens eine Version auf CD oder einem entfernten Rechner gelagert ist UND eine gedruckte Version, denn typischer Weise geht die Festplatte auf der die Doku liegt als erste über den Jordan.
brammer
ob du das mit Word oder einem Wiki oder einem DMS aufbaust ist eigentlich ziemlich egal
Wichtig ist erstmal das du dir ein Konzept machst was du dokumentieren möchtest und für wen du die Doku machst!
Wenn es darum geht in drei Jahren noch zu wissen reicht ein Detaillierter Überblick der Installierten Software und der Vorgenommenen Einstellungen für jedes Programm, oder willst du ermöglichen das in deiner Abwesenheit (Krankheit oder Urlaub) ein Kollege oder Ersatzmann in der Lage sein soll, ein typischer Weise gerade dann eintretendes, Desaster zu beheben?
Wenn der zweite Fall eher der Sinn deiner Übung ist, solltest du eine Schritt für Schritt Anleitung mit Screenshots und Visiozeichnungen (o.ä.) und genauer Beschreibung jeder Einstellung vornehmen und diese vor allem immer (!) aktuell halten.
Es gibt nicht Bescheideneres als veraltete Dokus und falsche Passwörter (wobei nicht alle Passwörter in die Doku gehören, sondern eine Verweis in welchem Safe die Paswörter liegen und wer Zugang dazu hat.)
Egal ob du dich für Word oder Wiki entscheidest, sorge dafür das es mindestens eine Version auf CD oder einem entfernten Rechner gelagert ist UND eine gedruckte Version, denn typischer Weise geht die Festplatte auf der die Doku liegt als erste über den Jordan.
brammer
Hallo Jens,
ich nutze zur Dokumentation in der Regel ein WIKI (http://www.dokuwiki.org/dokuwiki) doch ich kann Dir nur raten auch eine "offline-Version" anzulegen. Man lernt Papier echt zu schätzen
.
Der Vorteil bei DokuWiki liegt in der schnellen Installation, den verfügbaren Plug-Ins und auch in der textbasierten Dateiablage, so dass keine Datenbank benötigt wird. Es kann also schnell kopiert und gesichert werden.
Was den Aufbau von Dokumentation angeht, so bin ich seit Jahr und Tag ein Freund von Screenshots, denn dann hat man direkt einen visuellen Überblick. Das macht die Sache meiner Meinung nach einfacher. Auch schön sind zum Beispiel Videos, der Aufwand ist aber ungleich höher.
Auch Visio bietet sich für die Dokumentation der Prozesse an. Ein Flussdiagramm und eine entsprechende Checkliste sind immer super.
Gruß
STX
ich nutze zur Dokumentation in der Regel ein WIKI (http://www.dokuwiki.org/dokuwiki) doch ich kann Dir nur raten auch eine "offline-Version" anzulegen. Man lernt Papier echt zu schätzen
.Der Vorteil bei DokuWiki liegt in der schnellen Installation, den verfügbaren Plug-Ins und auch in der textbasierten Dateiablage, so dass keine Datenbank benötigt wird. Es kann also schnell kopiert und gesichert werden.
Was den Aufbau von Dokumentation angeht, so bin ich seit Jahr und Tag ein Freund von Screenshots, denn dann hat man direkt einen visuellen Überblick. Das macht die Sache meiner Meinung nach einfacher. Auch schön sind zum Beispiel Videos, der Aufwand ist aber ungleich höher.
Auch Visio bietet sich für die Dokumentation der Prozesse an. Ein Flussdiagramm und eine entsprechende Checkliste sind immer super.
Gruß
STX
Moin,
ich benutze auch ein Wiki zur Dokumentation. Mei Favorit ist dabei PmWiki. Hat den großen Vorteil, dass wie bei Dokuwiki keine Datenbank benötigt wird. Das Wiki kann in Verbindung mit XAMPP auf einem Stick mitgenommen werden, was die Aktualität eines Wikis doch sehr begünstigt. Das Update kann man dann immer schnell vom Stick auf den Webserver schieben.
Gruß, Marco
ich benutze auch ein Wiki zur Dokumentation. Mei Favorit ist dabei PmWiki. Hat den großen Vorteil, dass wie bei Dokuwiki keine Datenbank benötigt wird. Das Wiki kann in Verbindung mit XAMPP auf einem Stick mitgenommen werden, was die Aktualität eines Wikis doch sehr begünstigt. Das Update kann man dann immer schnell vom Stick auf den Webserver schieben.
Gruß, Marco
Hallo,
Also in den meisten Fällen ist deine Doku für den "Worst-Case".
Wenn also jemand anderes deine Tätigkeit übernimmt.
Wenn es speziell für ein Programm und/oder deren Einstellung geht solltest du recht viele Screen-shoots machen.
Falls du es nur für dich machen möchtest, reichen in den meisten Fällen nur Stichpunkte auf einen Zettel.
und dieser Zettel sollte dann in Reichweite liegen oder im Serverschrank.
Alle Dokus hängen bei uns im Racket.
desweiteren Infos über :
Patchfelder - Kabelfarben - Telefon - Switche und so weiter
Und eine für den tollen Exchange...
Grüße
Also in den meisten Fällen ist deine Doku für den "Worst-Case".
Wenn also jemand anderes deine Tätigkeit übernimmt.
Wenn es speziell für ein Programm und/oder deren Einstellung geht solltest du recht viele Screen-shoots machen.
Falls du es nur für dich machen möchtest, reichen in den meisten Fällen nur Stichpunkte auf einen Zettel.
und dieser Zettel sollte dann in Reichweite liegen oder im Serverschrank.
Alle Dokus hängen bei uns im Racket.
desweiteren Infos über :
Patchfelder - Kabelfarben - Telefon - Switche und so weiter
Und eine für den tollen Exchange...
Grüße
Ich dokumentiere eigentlich nur noch die richtig knifflichen Dinge bei denen man ne weile basteln musste bis es lief, das macht den fachmann aus dass er knifflige dinge gelöst hat. Je mehr er davon gelöst hat desto besser wird er. Und wenn er es dokumentiert hat kann er es auch noch ein jahr später nachvollziehen was er damals gemacht hat damit was funktioniert.
jeden furz zu dokumentieren macht wenig sinn da das ausser einem selber eh kaum einer lesen wird, andere kollegen kapieren das auch meist nicht, ausser man gibt sich viel mühe - doch dazu reicht meist die zeit nicht.
Screenshots sind recht effektiv da es schnell geht. Ins Doc file rein und ablegen - und nächstes Projekt.
jeden furz zu dokumentieren macht wenig sinn da das ausser einem selber eh kaum einer lesen wird, andere kollegen kapieren das auch meist nicht, ausser man gibt sich viel mühe - doch dazu reicht meist die zeit nicht.
Screenshots sind recht effektiv da es schnell geht. Ins Doc file rein und ablegen - und nächstes Projekt.
