Stephen King Geschrieben 27. April 2014 Teilen Geschrieben 27. April 2014 Hallo Leute, ich bin grad noch an meiner Projektdokumentation und bin mir nicht ganz sicher was ich wirklich alles da reinbringen muss, muss ich z.B. alle Linuxbefehle auflisten die ich im Rahmen einer Mailserver Installation benötigt habe? Die sind schließlich auch in der von mir verwendeten Anleitung drin (die in den Quellen angegeben wird). Von was sollte ich Screenshots machen und in den Anhang einfügen? Gibts da irgendwelche Anhaltspunkte? Sollten Probleme die während der Arbeit aufgetreten sind in einem extra Punkt aufgeführt werden oder kann ich die z.B. auch mit in die Phase packen in der Sie mir aufgefallen sind und wo ich Sie behoben habe? Würde mich über ein paar Antworten sehr freuen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Thanks-and-Goodbye Geschrieben 27. April 2014 Teilen Geschrieben 27. April 2014 Moin, dass du eine Software nach Anleitung installieren und konfigurieren kannst - davon geht der PA zwingend aus. In die Doku gehören alle Entscheidungen um das Wieso und Warum (weshalb diese Software als Lösung, was wären Alternativen gewesen) hinein. Screenshots sollten in den Anhang - und dann auch nur für Punkte innerhalb des Projektes, an denen du tiefgreifende eigenständige Entscheidungen triffst. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gast Geschrieben 29. April 2014 Teilen Geschrieben 29. April 2014 (bearbeitet) Auftretende Probleme sind nicht immer nachstellbar und in gewisser Hinsicht kann es dazu führen das man vom gewohnten Ablauf abweicht, den man in der Planung angegeben hat oder im schlimmsten Fall das Projekt nicht umgesetzt werden kann. Daher entweder in der Durchführungsphase bereits die Probleme ansprechen und die Verweise auf eine nähere Erläuterung im Projektabschluss ausführen oder nur im Projektabschluss. Hier kurz und kanpp die Abweichungen die es gab erklären, und natürlich die Ursache/n und Lösungsansätze(Hersteller Support,Bug Tracker, Knowledge Base) nennen die man unternommen hat. Im Idealfform gabs einen Workaround, diesen logisch erklären und in Form einer Quellenangabe benennen. Edit: Ich hahe mir zahlreiche Tipps von Kollegen(FISI ausgelernt) geholt bezüglich der Dokumentation, klar wir sind Techniker aber vor der IHK halt auch Kaufmänner. Daher ist es wichtiger die Abläufe, Prozesse, Schnittstellen und das kaufmänische zu erläutern, Entscheidungen zu begründen usw. Lehnt sich mehr an eine Kundendoku an, als an eine technische Dokumentation wobei der tecnische Part nicht fehlen soll. Jedoch nur an der Oberfläche kratzen und die Logik erklären und nicht zu sehr ins technische Detail gehen. Daher mein Rat, lass die Befehle weg, den Kunden interessieren die nicht, er wird nur fragen können Sie das umsetzen. Bearbeitet 29. April 2014 von laufzeitfehler Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.