Alles nur in (m)einem Kopf?

… das hatten wir doch schon mal. Aber diesmal geht’s um was anderes: Wissensmanagement in IT-Projekten.

Kürzlich bin ich in ein neues Projekt gestartet, das schon eine Weile läuft und in dem schon einige Strukturen und Arbeitsabläufe gesetzt und mehr oder weniger erfolgreich gelebt werden. Ich wurde glücklicherweise explizit gebeten, diese Strukturen und Abläufe zu hinterfragen und Verbesserungen vor­zuschlagen.

Der erste Schritt war für mich aber erstmal: reinkommen, verstehen, verknüpfen. Gut, ist ja immer Zeitmangel in Projekten, also gab‘s keine Einweihung – äh Einweisung und auch der Zugang zur Dokumentation war sehr verstreut (Sharepoint, Teams, Quellcodeverwaltung, Köpfe der Anderen, …). Der Einstieg hat dann dementsprechend auch etwas länger gedauert, und da dachte ich mir: darüber könnte ich mal etwas schreiben. Was würde ich also anders machen? Nun, in jedem Fall sollte die Projektstruktur von einem erfahrenen Teammitglied technisch und organisatorisch erläutert werden. Schließlich ist eine gut dokumentierte und praktizierte Aufbau- und Ablauforganisation das Betriebssystem des Projektes und damit eine wichtige Voraussetzung, dass letztlich die Teamleistung besser ist als die Summe der Aktivitäten der einzelnen Teammitglieder.  Wenn das dann auch noch im Gespräch vermittelt würde, entstünde im besten Fall nicht nur Wissen beim Neuling, sondern durch kritisches Hinterfragen auch ein Erkenntnisgewinn beim Erklärenden.

Der zweite große Aspekt und meine Empfehlung zur Veränderung: der Projektablauf- und Ergebnisdokumentation einen höheren Stellenwert geben. Bei Wikipedia klappt das doch auch: Vergleichsweise wenige schreiben für sehr viele. Der Nutzen übersteigt also bei weitem den Erstellungsaufwand. Bei IT-Projekten klappt das leider häufig nicht so gut, und es liegt selten am Tool. Ja, ich weiß, knappes Budget, keine Zeit, working software over comprehensive documentation. Aber gute Doku stellt an sich auch schon einen Wert dar. Nämlich dann, wenn man erkennt, dass eine wichtige Kompetenz von IT‘lern das Lernen selbst ist – und dabei hilft gutes Material sehr und senkt damit die Zeit und Kosten für Einarbeitung.

Hier kann man viel von Open-Source Projekten lernen: wer da den Einstieg nicht einfach gestaltet, kriegt weniger Aufmerksamkeit (in der neuen Währung Github-Sterne) und hat es letztlich schwerer. Also: Zugang möglichst vereinfachen und so auch den Nutzen der Doku erhöhen. Beispiele: die Doku an einer zentralen Stelle zugänglich machen, möglichst auf Binärformate verzichten und einfachere Tools zum Einsatz bringen (Asciidoc oder Markdown statt Word!). Jede mögliche Hürde verringern, die das Schreiben erschwert, denn nur dann wird die Doku aktuell gehalten und die Nutzer nehmen sich Zeit zum Lesen – wer hat schon Lust Zeit zu investieren in Dokumente, die unvollständig und nicht aktuell sind? Eine professionelle Dokumentation ist auch ein Merkmal eines intelligenten Teams.

Darüber gibt es noch einiges mehr zu berichten. Für heute soll es das aber gewesen sein von mir.

Nur dies hier noch als Abschluss für die Nicht-so-Gern-Schreiber: „If it hurts, do it more often“! (Weisheit vermutlich von Martin Fowler)