Mobiles Menü
Wenn Wissen im Code verstaubt: Wie wir das Busrisiko senken
Jonathan Reißig
Jonathan Reißig

// //
Lesedauer: 5 Minuten

Wenn Wissen im Code verstaubt

Wie wir das Busrisiko senken


Stell dir vor, du steigst in ein Projekt ein. Vor dir liegt ein riesiger Haufen Puzzleteile – Geschäftsprozesse, Module, Methoden, Schnittstellen. Alles wild durcheinander, ohne Vorlage. Dein Job: nicht nur das Puzzle zusammensetzen, sondern nebenbei auch noch neue Teile basteln. Klingt anstrengend? Willkommen im Alltag vieler Entwicklerteams.

Ich habe das live miterlebt: Wenn erfahrene Entwickler das Projekt verlassen, bleibt oft nicht nur weniger Entwicklungspower, sondern auch weniger Verständnis fürs Ganze. Wissen wandert nicht automatisch weiter – vieles steckt in Köpfen, alten Tickets oder unvollständigen Dokus. Und ehe man sich versieht, wird eine Person zum Single Point of Knowledge – ein Risiko, das so gut es geht, minimiert werden sollte.

Schwarz-weiß-Aufnahme von zwei Personen, die nebeneinandersitzen. Beide tragen dunkle Shirts mit den BCxP-Buddies. Die Person links hat kurze Haare, Brille und einen leichten Schnurrbart. Die Person rechts hat kurze Haare, einen gepflegten Bart und sichtbare Tattoos am rechten Arm. Hinter ihnen sind große Buchstaben des Wortes ‚ZONE‘ an der Wand zu sehen.

Das Problem mit dem einen Experten

In einem unserer Projekte war es lange so: Viele Geschäftsprozesse kamen über die Jahre dazu, die Oberfläche wurde neu gebaut, die Architektur wuchs – aber nicht unbedingt im gleichen Takt. Mit der Zeit entstand ein Flickenteppich, in dem nur noch eine Handvoll Menschen den Überblick hatte. Derzeit ist eine Person mit dem vollständigen System vertraut.

Das bedeutet: Fällt dieser Kollege mal aus – oder möchte schlicht Urlaub machen – wackelt das ganze Projekt. Wir sprechen hier vom klassischen Busrisiko: Wenn die eine Person mit dem gesamten Wissen vom Bus überfahren wird, bleibt das Team ratlos zurück. Damit wird klar: Wenn Wissen an einer Person hängt, reicht der Blick in den Code längst nicht mehr aus, um ein komplexes System zu verstehen.

Code allein ist kein Wegweiser

Lange Zeit galt hier das Credo: „Der Code dokumentiert sich selbst.“ Das Problem: Er tut es nicht. Vor allem dann nicht, wenn über die Jahre versucht wurde, Geschäftsprozesse zu harmonisieren, ohne eine saubere Trennung durchzuziehen. Die Architektur wurde komplexer, die Qualität litt – und jede Einarbeitung dauerte viel zu lange.

Neue Entwickler:innen standen damit vor einem Berg Puzzleteile ohne erkennbares Bild. Sie sollten gleichzeitig verstehen, wie die alten Teile zusammengehören, und neue Teile „dazu bauen“, also Features entwickeln. Das ist frustrierend und ineffizient.

Unser Weg: Das Puzzle wieder zusammensetzen

Um aus dem Chaos ein Bild zu machen, haben wir eine Reihe von Maßnahmen gestartet. Sie alle haben ein Ziel: das Wissen im Team zu verteilen – und die einzelnen Puzzleteile wieder sichtbar zu machen.

Grafik aus sechs miteinander verbundenen roten Puzzle-Teilen auf weißem Hintergrund. Auf den Puzzleteilen stehen folgende Begriffe: „Dokumentation als Startpunkt“, „Regeltermine zu Geschäftsprozessen“, „Austausch zwischen Entwicklern“, „Fragen festhalten statt verlieren“, „Hackathons als Spielfeld“ und „Technische Schulden abbauen“.

DOKUMENTATION ALS STARTPUNKT
Wir haben die Geschäftslogik der wichtigsten Prozesse nachdokumentiert – auf einem hohen Level, aber so, dass man versteht, was gemeint ist. Dazu kommt eine technische Dokumentation, die Stück für Stück wächst. Sie ist kein Roman, sondern eher die Puzzle-Vorlage: Sie zeigt, wie das Bild aussehen könnte.

REGELTERMINE ZU GESCHÄFTSPROZESSEN
Einmal dokumentieren reicht nicht. Deshalb gibt es feste Termine, in denen wir die Abläufe vorstellen, Besonderheiten erklären und Schnittstellen beleuchten. Hier dürfen Fragen gestellt werden – gerade die scheinbar simplen, die sonst oft ungestellt bleiben. So wird der Puzzle-Rahmen stabil.

AUSTAUSCH ZWISCHEN ENTWICKLERN
In gesonderten Terminen sprechen wir über Konzepte, Architekturentscheidungen oder knifflige technische Fragen. Es geht darum, nicht nur das Ergebnis im Code zu sehen, sondern auch das „Warum“ zu verstehen.

FRAGEN FESTHALTEN STATT VERLIEREN
Oft stolpert man über alte Relikte im Code, deren Sinn nicht sofort klar ist. Anstatt die Frage im Kopf zu behalten (und wieder zu vergessen), gibt es im Story-Template jetzt einen eigenen Bereich dafür. Offene Punkte landen dort und werden im Teamtermin geklärt – fachlich oder technisch, je nachdem. So wandern Puzzleteile nicht unbemerkt wieder unter den Tisch.

HACKATHONS ALS SPIELFELD
Wenn das System im Betrieb Probleme macht, machen wir daraus einen Hackathon. Wir stellen die Situation nach, suchen die Ursache und erarbeiten Lösungen. Das macht nicht nur Spaß, sondern sorgt für aktives Lernen am echten Puzzle – ohne Risiko für das Produktivsystem.

TECHNISCHE SCHULDEN ABBAUEN
In jedem Sprint planen wir Tickets für technische Schulden ein. Wer diese alten Baustellen bearbeitet, muss sich zwangsläufig mit den zugrunde liegenden Prozessen auseinandersetzen. Dadurch wird das Puzzle Schritt für Schritt vervollständigt.

Ein System zu verstehen, ist wie ein Puzzle zu legen. Am Anfang liegt ein chaotischer Haufen Teile vor einem – Prozesse, Module, Schnittstellen, Code-Fragmente. Die fachlichen Prozesse bilden dabei den Rahmen: Wer versteht, wie sie gedacht sind und wie sie zusammenhängen, erkennt schon grobe Strukturen. Die technischen Details sind das Innenleben: Architektur, Implementierungen, Patterns. Je mehr Teile ihren Platz finden, desto klarer wird das Gesamtbild.

Natürlich gehen auch mal Teile verloren. Wissen verschwindet, Fragen geraten in Vergessenheit. Doch wenn schon ein großer Teil des Bildes liegt, ist das kein Drama – dann findet jedes wiederentdeckte Teil schnell zurück an die richtige Stelle.

Für neue Kolleg:innen macht genau das den Unterschied: Statt allein vor einem chaotischen Berg zu sitzen, puzzeln wir gemeinsam. Jeder bringt Teile ein, Fragen sind willkommen, und das Bild wächst Schritt für Schritt. So entsteht kein perfektes Puzzle, aber eines, das stabil genug ist. Stabil genug, damit niemand allein das ganze Bild zusammensetzen muss – und stabil genug, dass das Projekt auch dann läuft, wenn der eine Experte endlich mal Urlaub macht.


Porträtfoto eines jungen Mannes mit dunklen, zurückgekämmt gebundenen Haaren, schmalem Schnurrbart und kleinem Kinnbart. Er trägt einen dunklen Strickpullover und schaut ruhig lächelnd in die Kamera. Schwarz-weiß-Aufnahme vor hellem Hintergrund.

Fragen? Lust auf Austausch? Oder steckt ihr vielleicht selbst in einem Projekt, in dem das Puzzle aus Architektur, Prozessen und Code immer komplizierter wird?

Jonny kennt genau diese Situationen: Vom Entwickeln tief im Code bis hin zur Rolle als Product Owner begleitet er heute Teams dabei, Wissen sichtbar zu machen, Strukturen zu klären und die Brücke zwischen Business und Technik zu schlagen. Mit seinem Blick fürs Ganze hilft er dabei, Risiken zu senken, Verantwortung breiter zu verteilen und komplexe Systeme wieder verständlich zu machen.

Wenn ihr herausfinden wollt, wie ihr euer eigenes Wissens-Puzzle stabiler machen könnt – sei es durch bessere Dokumentation, klarere Prozesse oder gemeinsames Lernen im Team – dann ist Jonny eure perfekte Anlaufstelle.

Neugierig geworden? Jonny freut sich auf eure Nachricht!


Hinweis: Das Header- und Zusatzbild dieses Artikels wurden mithilfe Künstlicher Intelligenz erstellt.