Wissenstransfer

Nicht als Frontalvortrag, den nach einer Woche keiner mehr weiß. Ich arbeite an Ihrem echten Code, an Ihren echten Problemen. Das kann ein Mentoring über Wochen sein, in dem ich einzelne Entwickler begleite. Es kann ein Workshop zu einem konkreten Thema sein, etwa sauberer Architektur, Testbarkeit oder dem Stack, mit dem Sie arbeiten. Und es kann eine Live-Coding-Session sein, in der wir gemeinsam ein reales Problem lösen. Ihr Team sieht dabei zu, wie ich denke, nicht nur, was ich tippe.

Standard-Schulungen behandeln Standard-Fälle. Ihr Team hat aber keine Standard-Probleme, sonst bräuchten Sie mich nicht. Weil ich an Ihrem konkreten System arbeite, bleibt das Gelernte hängen. Es hat sofort einen Ort, an dem es angewendet wird.

Mentoring und Workshops wirken über Menschen. Menschen wechseln aber die Stelle. Zum Wissenstransfer gehört deshalb auch das, was liegen bleibt, wenn jemand geht.

Ich dokumentiere direkt neben dem Code, nicht in einem Wiki, das nach einem Jahr niemand mehr pflegt. Am wichtigsten sind dabei die Begründungen. Warum wurde diese Bibliothek gewählt und eine andere nicht, warum ist die Schnittstelle so geschnitten. Das Was steht ohnehin im Code. Das Warum ist es, was Ihrem Team in drei Jahren fehlt, wenn eine Entscheidung wieder aufgemacht werden soll.

Dafür nutze ich Architecture Decision Records, also kurze, datierte Notizen zu jeder tragenden Entscheidung. Sie kosten im Moment des Schreibens zehn Minuten und ersparen später Tage.

Für Teams, die gute Entwickler haben, denen aber in einem bestimmten Bereich die Erfahrung fehlt. Für Firmen, die weg wollen von der Abhängigkeit von einzelnen externen Dienstleistern. Und für alle, die spüren, dass ihr Wissen an zu wenigen Köpfen hängt, und wissen, wie riskant das ist, wenn einer davon geht.