Knowhow-Transfer - Erklären allein reicht nicht

• Wie kann man als neues Team Wissen über eine Applikation mit mehr als einer halben Million Zeilen Code effizient übernehmen?

• In meinem letzten Projekt standen wir genau vor dieser Herausforderung und müssen nun sicherstellen, dass das erarbeitete Wissen nicht wieder verloren geht

Wie kann man als neues Team Wissen über eine Applikation mit mehr als einer halben Million Zeilen Code effizient übernehmen? In meinem letzten Projekt standen wir genau vor dieser Herausforderung und müssen nun sicherstellen, dass das erarbeitete Wissen nicht wieder verloren geht.

In Softwareprojekten gibt es immer wieder Situationen, in denen Wissen übergeben werden muss:

• Neue Anforderungen: Viel Wissen ist noch nicht explizit vorhanden und muss mit Stakeholdern erarbeitet werden. Tägliche Arbeit für Business Analysten und Requirements Engineers.
• Mitarbeiterwechsel in bestehendem Projekt: Einzelne Mitarbeitende müssen ersetzt oder neu integriert werden. Vielleicht soll sogar ein komplett anderes Team übernehmen, wie in unserem Fall, wo der Lieferant gewechselt Das Team soll trotzdem möglichst ohne Unterbruch Wert liefern.
• Projektübergänge: Zum Beispiel müssen beim Go-Live eines Produkts, oder beim Übergang von Entwicklungs- in den Wartungsmodus Informationen weitergegeben werden.

Aus den Erfahrungen in meinem letzten Projekt, in dem wir eine komplexe Applikation komplett übernommen und revitalisiert haben, habe ich einiges über Knowhow-Transfer und Wissenserhaltung dazugelernt. Viele der folgenden Aussagen sind bestimmt auch allgemein gültig, der Fokus soll hier aber auf Projekten zur Softwareentwicklung liegen.
 

Mitarbeitendenwechsel als Beispiel

In einem idealen Projekt ist das perfekt passende Team mit allen nötigen Kenntnissen und Fähigkeiten von Anfang bis Schluss zu 100 Prozent verfügbar. Übergaben während dem Projekt sind nicht nötig. Da solche Projekte in der freien Wildbahn kaum vorkommen, ist derjenige im Vorteil, der mit dem Wechsel von Mitarbeitenden am besten umgehen kann. Wer neue Teammitglieder schnell einarbeitet, kann Verzögerungen sowie Transitionskosten minimieren, flexibel auf neue Anforderungen reagieren und im Idealfall Spezialisten über mehrere Projekte einsetzen.

Alles - so schnell wie möglich

Die Bezeichnung Knowhow-Transfer suggeriert, dass Wissen einfach von einer Person zur anderen übergeben werden kann. Ein Transfer des kompletten Wissens aus einem Kopf in den anderen ist aber eine Illusion. In der Praxis sieht es meist wie folgt aus:

• Viel Wissen ist nur implizit vorhanden und auf viele Köpfe verteilt.
• Die Kapazität, sich in kurzer Zeit neues Wissen anzueignen, ist beschränkt. Aber die Zeit ist knapp, alles Wissen kann kaum je übergeben werden. Der Fokus muss also auf die wichtigen Punkte gelegt werden.
• Etwas zu wissen heisst noch lange nicht, dass man es auch versteht, geschweige denn anwenden kann.

Werkzeuge und Methoden

Während dem Knowhow-Transfer sind sowohl der abgebende wie der übernehmende Mitarbeiter nicht produktiv tätig, ein Wissenstransfer allein verbessert kein Produkt und flickt keinen Fehler. Es ist deshalb klar, dass der Transfer effizient gestaltet werden muss.

Um neue Projektmitarbeitende im Projekt möglichst schnell einzuführen und das Wissen bestmöglich zu erhalten, haben wir verschiedene Methoden eingesetzt und Werkzeuge eingeführt:

• Eine Knowledge Base mit validiertem Wissen. Wichtig ist, dass diese nicht als Friedhof für veraltete Change-Request-Dokumentationen endet, sondern eine aktiv gepflegte Minimal-Dokumentation bleibt.
• Eine Onboarding- und Offboarding-Checkliste für die wichtigsten Setup- und Knowledge-Aufgaben. Damit können neue Projektmitglieder vieles selbständig erarbeiten. Mit jeder Rotation wird die Checkliste verifiziert und ergänzt. Sie bleibt damit immer aktuell.

Die Erfahrungen aus unserem Projekt decken sich mit einem Zitat von Benjamin Franklin:
Tell me and I forget. Teach me and I may remember. Involve me and I will learn.

In unseren ersten Arbeitssitzungen zur Übernahme der Applikation wurden uns Details im Code erklärt. Kontextinformation und praktische Anwendung fehlten uns, so dass von diesen Erklärungen nicht viel hängen blieb. Unser Wissen über die Applikation stieg rapid, als wir begannen, selbst damit und im Code zu arbeiten. Ausprobieren und gezieltes Nachfragen hat sich als wesentlich effektivere Lernstrategie erwiesen. Wobei Ausprobieren je nach Rolle etwas anderes bedeutet: Features implementieren und Fehler beheben für die Entwickler, (manuelle) Tests durchführen für die Tester, die Applikation deployen (in eine Testumgebung) für die DevOps-Aspekte, mit Stakeholdern sprechen für Requirements Engineers.
 

Auf die Perspektive kommt es an

Generell sollte im Knowhow-Transfer der Übernehmende die Führung innehaben: Er muss nachher mit dem erworbenen Wissen arbeiten können. Wenn nach einer Übergabe der Vorgänger aus seiner Sicht alle Themen behandelt hat, der Nachfolger aber nur Fragezeichen sieht, so ist das Ziel nicht erreicht.

Die Befürchtung ist berechtigt, dass ganze Themenblöcke vergessen gehen, wenn der oder die Lernende die Führung über den Transfer übernimmt. Um diesem Risiko vorzubeugen, haben wir im Projekt eine stichwortartige Zusammenfassung der Applikation erstellt. Keine umfassende Dokumentation, die schnell veraltet, aber eine grobe Übersicht auf einer A4-Seite über die wichtigsten Themenbereiche. Damit erhalten neue Teammitglieder schnell einen Überblick und die Themen im Knowhow-Transfer können priorisiert werden.

Implizites Wissen explizit machen

Checklisten und konkrete Ziele eignen sich gut als Aufhänger, um implizites Wissen aus den Köpfen zu holen. Viel schwieriger ist es, intuitives Verständnis, das aus langer praktischer Erfahrung resultiert, zu übergeben - dazu gehört beispielsweise das persönliche Netzwerk mit dem Wissen darum, wen ich bei welcher Art von Problem um Hilfe bitten kann. Praktische Aufgaben eignen sich, um zu erkennen, wo Erfahrungen hilfreich sind. So rasch wie möglich soll der oder die Lernende selbst mit der übernommenen Applikation arbeiten können, am Anfang noch mit Begleitung. So zeigen sich Verständnislücken sehr rasch.
Eine priorisierte Übersichtsliste hilft, vor lauter Bäumen den Wald nicht aus den Augen zu verlieren. Idealerweise muss diese Übersicht nicht erst für den Know-how-Transfer erstellt werden, sondern steht im Projekt bereits zur Verfügung.

Einfache Visualisierungen sind praktische Helfer, um gegenseitiges Verständnis zu fördern. Einfache Zeichnungen und skizzierte Modelle haben uns oft geholfen, Missverständnisse auszuräumen und komplexe Zusammenhänge zu erklären.
Um den Knowhow-Transfer zu steuern, haben wir einfache Etappenziele definiert, die der oder die Übernehmende nach und nach selbständiger erreichen kann. Als Beispiel unsere Schritte beim Onboarding eines neuen Testmanagers:

• Kann Applikation selber bedienen
• Übersicht und aktives Nutzen der Regressionstests
• Selbständiges Testen einer neuen Funktionalität
• Umfassende Applikationskenntnis und Übernahme der Verantwortung

Kontinuierlicher Knowhow-Transfer

Auch wenn aktuell kein Mitarbeiterwechsel ansteht, kann trotzdem einiges unternommen werden, um das Wissen gut im Team zu verteilen:

• Austausch-Sessions, um spezifische, zentrale Themen im ganzen Team bekannt zu machen.
• ChatOps: Ein historisiertes, durchsuchbares Gruppenchat-Tool erleichtert den informellen Austausch im Team, besonders bei verteilten Teams.
• Cross-funktionale Teams, wo verschiedene Aufgaben und Rollen von verschiedenen Personen wahrgenommen werden, und Entwicklungsmethodologien mit kurzen Feedbackschlaufen fördern den Austausch im Team.

Das hilft, Wissens-Silos vorzubeugen, weniger Wissen hängt an einzelnen Köpfen. Ein Mitarbeiterwechsel fällt damit weniger ins Gewicht.

Verständnis überprüfen

Es lohnt sich, nach der effektiven Übergabephase noch eine gewisse Zeit einzuplanen, wo die neue Person/Organisation schon in der Verantwortung ist, die Vorgängerin oder der Vorgänger aber noch für Hilfe zur Verfügung steht. Erst wenn produktiv mit dem neuen Wissen gearbeitet werden muss, zeigt sich, ob wirklich alles klar ist.

Ein Thema auf unterschiedlichen Niveaus zu erklären, hilft, das gelernte zu festigen und Verständnislücken zu identifizieren. Wenn ich das Projekt in wenigen Sätzen für unbeteiligte Kollegen zusammenfassen kann, so sind die Prioritäten vermutlich klar. Und wenn ich die Applikation meinem Kind erklären kann, so habe ich wahrscheinlich auch etwas verstanden. Ohne solche Kontrollen besteht die Gefahr, dass die Erklärungen zwar passiv verstanden wurden, aber nicht aktiv angewendet werden können.
 

Das Ziel definieren

Die Herausforderung ist, implizites, undokumentiertes Wissen zu identifizieren, und explizit zu transferieren. Damit die Nachfolger effizient arbeiten können, muss das Wissen in den neuen Köpfen wieder intuitiv verfügbar sein, wird also zu einem Teil wieder zu "unsichtbarem" implizitem Wissen. Hoffentlich aber nur soweit, dass beim nächsten Übergang eine nützliche Struktur für den Know-how-Transfer vorhanden ist.

Es reicht nicht, alles Wissen einmal anzusprechen. Das Ziel ist, dass der oder die Übernehmende damit effektiv arbeiten kann. Dafür ist es wichtig zu wissen, was denn mit dem übergebenen Wissen erreicht werden soll. Knowhow-Transfer ist also im grösseren Kontext einer Mission Preparation zu sehen: Es geht darum, eine Person oder Organisation auf ihre Aufgabe vorzubereiten. Dazu ist viel Wissen nötig, aber es gehört mehr dazu, wie beispielsweise eine funktionierende Arbeitsumgebung. Vielleicht sind dagegen aber gewisse Detailkenntnisse gar nicht nötig. Die Bezeichnung Mission Pre-paration für die ganze Übergangsphase hilft, den Fokus auf das Wesentliche zu setzen.

Den Erfolg überprüfen

Wo steht das eingangs erwähnte Projekt ein gutes Jahr nach dem initialen Knowhow-Transfer? Noch immer ist nicht jedes Detail bekannt, aber wir konnten mehrere Releases stabil in Produktion bringen. Zentrale Rollen wie der Software Architekt oder der Quality Manager konnten ausgewechselt werden, ohne das Projekt vor Probleme zu stellen. Die Applikation konnte stabilisiert werden und eine Umfrage unter den Benutzern zeigt eine deutliche Steigerung der Zufriedenheit.

Letztlich ist das das einzige Mass für einen erfolgreichen Knowhow-Transfer: Die neuen Mitarbeiter können produktiv arbeiten und die Stakeholder sind zufrieden mit dem Projektfortschritt.

Wie stellen Sie sicher, dass Wissen in den Projekten nicht nur in den Köpfen, sondern nachhaltig erhalten bleibt?