"Es gibt Wichtigeres im Leben, als beständig dessen Geschwindigkeit zu erhöhen."
(Mahatma Gandhi)

Protokolle

Dies ist eine gute Stelle, um ein leidiges Thema anzusprechen: Ich verstehe nicht, warum Projektteilnehmer so ungern Protokolle erstellen! Vielleicht liegt es daran, dass man sich festlegen muss. Vielleicht ist es auch, weil man dann zu einer Entscheidung stehen muss und später festgestellt werden kann, wer den Fehler gemacht hat. Es ist wahrscheinlich genau die große Verbindlichkeit, die ein Protokoll bedeutet, wovor sich die Menschen fürchten. Aber gerade diese Verbindlichkeit sorgt stets für klare Verhältnisse im Projekt und damit für ein hohes Maß an Objektivität und Fairness. Ich habe das Thema "Verbindlichkeit" bereits in der Pre-Analyse angesprochen und werde beim Design erneut darauf zurück kommen, denn es zieht sich wirklich durch das gesamte Projekt!

Alle Sitzungen mit dem Kunden sollten auf jeden Fall protokolliert werden, denn in solchen Sitzungen fallen beispielsweise Entscheidungen, die zu einem "In" oder "Out" führen oder die Priorität einer Anforderung ändern oder Änderungsanforderungen beschließen oder oder oder. Am Ende des Protokolls können Sie eine LOP (Liste offener Punkte) führen, in der alle offenen Punkte aus den Protokollen fortgeschrieben werden. Dann müssen Sie nicht immer alle Protokolle nach offenen Punkten durchsuchen und die offenen Punkte werden dann erfahrungsgemäß auch schneller abgearbeitet. Die nebenstehende Protokollvorlage können Sie gerne aus meinem Downloadbereich herunter laden und als Basis für Ihre Anpassungen verwenden.

Sie sollten die diskutierten Anlagen der Sitzung im Protokoll benennen, sei es ein Photo von der Flipchart-Agenda, ein technisches Dokument, eine vorgeführte Präsentation, etc. Wenn diese Dokumente nicht in das Protokolldokument eingearbeitet werden, sollte genau beschrieben werden, wo diese Anlagen zu finden sind oder von wem sie bis wann wie an welchen Verteiler übermittelt werden.

Sie sehen in dem Protokoll Unterschriftsfelder, denn ich drucke tatsächlich jedes Protokoll zwei mal aus; mein Ansprechpartner des Kunden und ich unterschreiben beide Protokolle, so dass jeder ein Exemplar mit beiden Unterschriften hat und dieses in seinem Projektordner abheften kann. Dabei folge ich einfach dem Motto: "Was am Freitag nicht unterschrieben ist, ist am Montag vergessen." Spätestens bei der Unterschrift merkt der Kunde, dass ich es ernst meine und er überlegt sich beispielsweise seine Ins und Outs sehr gut. Ich habe allerdings bei noch keinem ernsthaften Projekt ein Problem damit gehabt, die Unterschrift zu bekommen, denn auch der Kunde lernt diese Verbindlichkeit sehr schnell zu schätzen. Probieren Sie es mal aus! Erklären Sie Ihrem Kunden einfach mal die Vorteile und offerieren Sie ihm mal eine Probezeit.

Die Protokolle sind natürlich in der Sprache des Kunden zu führen. Ich erstelle Programmdokumentationen, Team-Spezifikationen und Quellcode-Kommentare grundsätzlich in Englisch, weil zum einen alle Programmiersprachen in Englisch arbeiten und damit auch englische Variablen-, Funktions- und Klassennamen selbstverständlich sind, zum anderen die Unterlagen der eingesetzten technischen Systeme inkl. der Online-Foren meist Englisch sind und weil nicht zuletzt zumindest bei größeren Projekten doch häufiger Leute beteiligt sind, die immer mindestens Englisch verstehen können und oft auch nur Englisch sprechen. Alle Dokumente, die der Kommunikation mit dem Kunden dienen, müssen aber natürlich in der Sprache des Kunden erstellt werden.