Software Engineering Blog

Wie gut ein Team kommuniziert und Lösungen findet, läßt sich sehr gut an seinem Whiteboard ablesen. Idealerweise gibt es mehr als ein Whiteboard, aber das nur am Rande. Werden an diesem Whiteboard gemeinsam Probleme diskutiert und Lösungen gefunden, dann ist das, was auf dem Whiteboard steht wertvoll. Doch wie gehen wir mit diesen Werten um?

Oft habe ich bis jetzt beobachtet, daß ein Whiteboard während einer langen Diskussion immer wieder beschrieben wird, um diese dann gleich wieder abzuwischen, da der Platz wieder benötigt wird. Kurz vorher wird noch gefragt: "Alles klar? Kann ich das wieder abwischen?" Dummerweise steckt die Information genau in diesem Moment noch in unserem Kurzzeitgedächtnis und die Wahrscheinlichkeit ist hoch, daß es über dieses nicht hinauskommt. Das heißt nichts anderes, als das es morgen vergessen sein wird.

Wir dokumentieren dieses Wissen nur in wenigen Fällen. Und wenn, dann auch meist falsch. In den meisten Fällen werden einfach Fotos gemacht und diese in irgendeinem Verzeichnis abgelegt. Leider versauern sie dann dort auch. Das ist nicht schade, denn meist sagen die Bilder anderen ohne irgendeinen Kommentar auch nichts.

Aus diesem Grund habe ich vor einiger Zeit eine PowerPoint-Vorlage erstellt, mit denen man sehr einfach Whiteboard-Diskussionen dokumentieren kann. Im Grunde bietet die Vorlage nicht mehr, als ein paar Layoutvorlagen für Bilder in Hoch- und Querformat mit einem Textfeld für Notizen. Hinzu kommt noch eine Titelfolie, auf der man Dinge wie Teilnehmer und Datum bei Bedarf eintragen kann und ein paar weitere Folien für ausführlichere Kommentare.

Die Anwendung

Was wird noch gebraucht? Eine Digitalkamera oder ein besseres Handy. Damit wird das Whiteboard während der Besprechung abfotografiert und die Bilder anschließend in die PowerPoint-Vorlage eingefügt und soweit wie notwendig kommentiert. Anschließend sollte die PowerPoint noch als PDF abgespeichert werden, denn für die Verteilung an Externe sind solche offenen Formate wesentlich besser geeignet.

So lassen sich Diskussionen und Entscheidungen effizient und effektiv dokumentieren und können auf professionell verteilt werden. Und das ohne viel Aufwand.

Beispiel

Auf den Bildern in diesem Artikel ist ein kleines Beispiel für den Einsatz der Powerpoint-Vorlage enthalten und ganz am Ende sind ein paar Download-Links für das Beispiel und die Vorlage selber enthalten.

Beispiel für die Titelseite einer Whiteboard-Dokumentation.

Folie für eine ausführlichere Dokumentation in Textform.

Beispiel für die Verwendung mit einem hochformatigen Bild.

Beispiel für die Verwendung mit einem querformatigen Bild.

Auf der letzten Folie können ein paar Schlußbemerkungen festgehalten werden.

Eine gute Alternative zu dieser Vorlage ist die Dokumentation in einem Blog. In meinem Artikel Tod den Statusmails, es lebe das Blog habe ich hierzu auch schon einmal etwas geschrieben.

Probleme treten oft an unerwarteten Stellen auf. Ursache hierfür ist nur zu oft unser eigenes Wissen oder Können. Dinge die wir nach unserem Wissen „richtig“ angehen, Standards, die wir unbewußt einhalten, weil wir sie verinnerlicht haben, setzen wir auch stillschweigend bei anderen voraus.

Ein kleines Beispiel: In einem Projekt hatte ich die Leitung für ein russisches Outsourcing-Projekt in dem win Wissensmanagementsystem für einen deutschen Automobilbauer umzusetzen war. Die Spezifikation wurde von unserem deutschen Partner erstellt, während wir für die reine Umsetzung uns verantwortlich zeichneten. Da unserem Partner die personellen Ressourcen für die Spezifikation fehlten wurde auf externe Beraterressourcen für dieses Projekt zugegriffen. Schnell wurde klar, daß dies das erste Spezifikationsprojekt des eingestellten Beraters war.

Da wir die Thematik schon aus einem Vorgängerprojekt kannten, war dies nicht allzu schwerwiegend. Vieles wußten wir aus dem Kontext und die Architektur wurde fest durch ein Framework des Kunden vorgegeben. Nur die Use Cases keine stabile Bezeichnung hatten, das machte uns das Leben schwer, da wir unsere Arbeitspakete auf Basis der Use Cases zusammenstellten. Ein Arbeitsauftrag war bei uns beispielsweise die Umsetzung der Anwendungsfälle „Projekt anlegen“, „Projekt bearbeiten“ und „Projekt freigeben“. Nur konnte sich die Benennung der Anwendungsfälle auch ändern und tat dies auch. Dies sollte eigentlich auch kein Problem sein, wenn es für jeden Anwendungsfall eine eindeutige Nummer gibt wie beispielsweise UC-223, nur wurden die Use Cases anfangs über die Kapitelnummern identifiziert. Sie ahnen es sicherlich schon. Sobald ein neues Kapitel in das (Word-)Dokument eingefügt wurde, änderten sich natürlich auch die Kapitelüberschriften und damit konnte über die Zeit Uses Case 3.2.2 unterschiedliche Anwendungsfälle beschreiben. Später wurde dies auch geändert, doch war dies auch ein langwieriger Prozess.

Was kann man daraus lernen:

• Setze nie voraus, daß Dein Gegenüber über das gleiche Wissen verfügt wie Du, sondern schaffe eine gemeinsame Wissensbasis.
• Halte Anwendungsfallbezeichner immer stabil und ändere sie nie. Sie bilden in anwendungsbezogenen Projekten eine Grundlage für die Kommunikation zwischen allen Beteiligten.

Bei Gelegenheit schreibe ich etwas darüber, wie eine Use Case-ID gebildet werden kann und wie mit man mit ihnen umgehen sollte.

Bei der Durchsicht meiner Mails bin ich auf den letzten JavaBlackBelt-Newsletter gestoßen. War bisher nur der Gelbe Gürtel ohne eigenen Beitrag zur Sammlung von Prüfungsfragen zu erreichen, kann jetzt der Grüne Gürtel erreicht werden. Für die nächst höheren Gürtel müssen Mitglieder aber weiterhin neue Beiträge zur Fragensammlung leisten.
(weiterlesen...)