In zahlreichen Branchen ist es üblich, dass eine Leistung dann als erbracht gilt, wenn auch die Dokumentation zu dieser vollständig vorliegt. Der Kunde ist andernfalls nicht zur Zahlung verpflichtet. Nicht so im IT-Bereich. Aus leidiger Erfahrung wissen wir, dass es hier eher die Regel als die Ausnahme ist, dass viele Entwickler, Administratoren, Webdesigner aber auch anderweitig beschäftigte Mitarbeiter eines Unternehmens es selten für nötig halten ihre Tätigkeiten zu dokumentieren.
Die Agenturen tolerieren die Eigenart ihrer Mitarbeiter. Und das, obwohl nicht ausschließlich der Kunde, sondern oft auch der Arbeitgeber selbst, sowie alle Mitarbeiter des Unternehmens die Leittragenden eines solchen Misstands sind. Nur leider wird das spät erkannt.
Gründe mangelhafter Dokumentation
Die Gründe, warum die Dokumentation in den meisten Projekten stiefmütterlich behandelt wird sind vielfältig. Hier ein paar Beispiele:
- Entwickler lieben es zu entwickeln, aber Sie haben keine Zeit und Lust zu dokumentieren. Sie denken der Code spricht für sich (“Soll wer anders machen, mein Code ist selbsterklärend.”.
- Administratoren arbeiten gerne für sich. Sie mögen es nicht, wenn jemand anderes in ihrem Bereich “rumpfuscht” und sie lassen sich nicht gern “kontrollieren”. (“Das kleine Script für den Rollout lohnt sich nicht zu dokumentieren.”).
- Auch in vielen agilen Projekten, wo sich schnell mal viel ändert wird die Dokumentation als zu zeitaufwendig angesehen (“Der Aufwand lohnt nicht, soviel ändert sich zu schnell.”). Das mag durchaus so sein, aber ein gewisses Maß an Dokumentation ist auch hier erforderlich.
- Projektmanager wollen mit Ihren Projekten zeitnah fertig werden und sehen die Dokumentation als sekundär an (“Kann man später machen.”).
- Stakeholder wollen ihr Geld lieber in neue Features investieren und sehen im ersten Moment nicht den Sinn einer Dokumentation (“Mich interessiert nicht wie was zusammenarbeitet, es soll funktionieren.”).
Folgen mangelhafter Dokumentation
Werden Projekttätigkeiten vom Team unzureichend oder gar nicht dokumentiert ist eine spätere Erweiterung und Wartung des Projekts oft mit unnötigen und vor allem hohen finanziellen und zeitlichen Aufwänden verbunden.
- Ohne (ausreichende, aktuelle) Dokumentation ist die Einarbeitung neuer Teammitglieder zeitintensiv.
- Ohne (ausreichende, aktuelle) Dokumentation ist beim (plötzlichen) Ausscheiden eines Mitarbeiters aus dem Unternehmen, nicht selten das ganze Projekt in Gefahr. Wenn dieser z.B. für als “Mädchen für alles” in zahlreichen Tätigkeiten involviert war.
- Ohne (ausreichende, aktuelle) Dokumentation ist die Wartung als auch Funktionserweiterung zu einem späteren Zeitpunkt aufwändiger.
Uns ist klar, dass eine ausführliche Dokumentation nicht in jedem Projekt immer möglich ist, und dass eine nicht aktuelle Dokumentation oft nutzloser ist als gar keine. Dennoch wird kein Projektteam darum herum kommen die wichtigen Dinge entsprechend zu dokumentieren und gemeinnützig dem Team bereit zu stellen. Was die wichtigen Dinge eines Projekts sind, muss jedes Projektteam für sich selbst definieren und hier ein gewisses Mittelmaß finden.
Beispiele für dokumentationswürdige Projektinhalte
Hier ein paar Beispiele, was in einem Projekt in der Regel dokumentiert wird.
- Technische Konzepte und Abläufe
- Softwarearchitektur
- Anforderungen
- Design-Entscheidungen und Stylevorgaben
- Rahmenbedingungen der Systemumgebung (Testing, Staging, Produktiv etc.)
- Testfälle
- Rollout-Plan
- Anwenderdokumentation
- uvm.
3 Regeln für gute Dokumentation
Hier nun ein paar Grundregeln, die eine gute Dokumentation (egal für welchen Bereich) beachten sollte.
- Sie soll schnell und einfach zu erstellen und zu aktualisieren sein. Veraltete Informationen sind manchmal schlimmer als gar keine Informationen.
- Sie soll auf mögliche Fragen die richtige Antwort liefern. Wenn man Schwierigkeiten hat sich eine Frage zu überlegen, welche die Dokumentation abdeckt, dann ist sie nutzlos - weil niemand anderes diese Frage stellen wird.
- Sie soll auf keinen Fall menschliche Interaktionen ersetzen. Gemäß dem Manifest agiler Softwareentwicklung: Individuen und Interaktionen zählen mehr als Prozesse und Werkzeuge
Die Regeln lassen sich relativ leicht umsetzen, wenn man sich die Zielgruppe vor Augen hält, die mit der Dokumentation umgehen sollen. Das wären:
- Manager, die eine schnelle Übersicht über das haben möchten, woran gerade gearbeitet wird.
- Neue Teammitglieder, die eine schnelle Einführung ins Projekt benötigen.
- Frühere Teammitglieder, die nach einer zeitlichen Pause wieder einen schnellen Einstieg ins Projekt brauchen.
- Support Mitarbeiter, die im Fall von Problemen schnell Hilfestellung zum Projekt geben müssen.
Fazit
Die Dokumentation ist ideal, wenn man auf Anfrage dem Empfänger in einer E-Mail lediglich eine kurze Erklärung, sowie den Link zur Dokumentation schicken muss und man daraufhin keine Rückfragen mehr erhält ;) In jedem Fall sollte eine Dokumentation (welcher Art auch immer) an einem zentralen, für alle Teammitglieder zugänglichen Ort verfügbar sein, sie sollte einfach zu schreiben, zu aktualisieren und gut (strukturiert) zu lesen sein.
Tipp: Wer mit Redmine arbeitet kann seine Dokumentation in der Redmine Wiki hinterlegen. Sie ist für jedes Projekt aktivierbar und erlaubt eine übersichtliche Strukturierung von Inhalten. Mit Hilfe des AlphaNodes Redmine Plugins Wiki Guide wird eine übergreifende Wikiseite generiert, über die man dann unter anderem mittels Live-Search und anderer Suchkriterien schnell auf die im Wiki hinterlegten Inhalte zugreifen kann.
