In fast jedem gewachsenen System gibt es eine Person, bei der man nachfragt. Nicht, weil sie die beste ist, sondern weil sie die einzige ist, die weiß, warum der Abrechnungslauf zweimal läuft und was passiert, wenn man ihn nicht zweimal laufen lässt.
Die übliche Antwort darauf ist eine Personalmaßnahme: Wissen teilen, dokumentieren, Vertretung aufbauen. Das ist gut gemeint und wirkt selten, weil es die Ursache nicht berührt. Wissen sammelt sich nicht, weil jemand es hortet. Es sammelt sich, weil das System es erzwingt.
Dieser Artikel beschreibt, welche Eigenschaften eines Systems ein Wissensmonopol herstellen, warum die üblichen Gegenmaßnahmen verpuffen, und was stattdessen wirkt.
Der Bus-Faktor ist der Messwert, nicht das Problem
Der Bus-Faktor ist die Zahl der Menschen, die ausfallen müssten, damit ein Vorhaben stillsteht. Bei eins wird es unangenehm.
Nützlich an dieser Zahl ist, dass sie sich messen lässt. Unnütz ist sie, wenn man sie als Ziel nimmt: Ein Team kann den Bus-Faktor auf zwei heben, indem eine zweite Person einmal im Quartal etwas an einem Modul ändert. Die Zahl steigt, und im Ernstfall hilft es niemandem, weil diese Person das System nicht versteht, sondern nur Zugriff hatte.
Interessanter ist die Frage dahinter: Warum kann nur eine Person hier arbeiten? Auf die gibt es technische Antworten, und technische Antworten lassen sich beheben.
Fünf Eigenschaften, die ein Monopol erzwingen
Wenn ich einen Bereich finde, an dem seit zwei Jahren nur eine Person arbeitet, finde ich fast immer mindestens drei der folgenden fünf Eigenschaften.
Erstens: Es gibt keinen Weg, etwas gefahrlos auszuprobieren. Ohne Testumgebung, ohne Tests, ohne Rückweg ist jede Änderung ein Eingriff am lebenden Objekt. Wer das noch nie gemacht hat, fasst es nicht an, und das ist vernünftig. Das Monopol entsteht aus berechtigter Vorsicht.
Zweitens: Das Verhalten steht nur im Kopf. Nicht die Funktionsweise, die steht im Code, sondern die Absicht: warum diese Sonderbehandlung, warum diese Reihenfolge, warum dieser eine Kunde anders. Das ist der Teil, den Lesen nicht ersetzt.
Drittens: Der Start dauert zu lange. Wenn eine Entwicklungsumgebung drei Tage braucht, wird niemand für eine kleine Änderung drei Tage investieren. Die Änderung geht an die Person, bei der die Umgebung schon läuft.
Viertens: Die Fehler sind stumm. Wo ein Fehler sich nicht meldet, sondern eine falsche Zahl erzeugt, braucht es jemanden, der erkennt, dass die Zahl falsch ist. Das ist die Sorte Wissen, die am schwersten zu übertragen ist, und sie kommt nicht aus Dokumentation, sondern aus Beobachtbarkeit.
Fünftens: Der Bereich hat keine Grenze. Wenn eine Änderung an der Abrechnung Kenntnisse über den Versand, die Preisfindung und den Bestellprozess verlangt, kann sich niemand einarbeiten, ohne alles zu lernen. Das ist der teuerste der fünf Punkte und der einzige, der wirklich Architektur ist.
Alle fünf sind Eigenschaften des Systems, nicht der Person. Das ist die Umdeutung, auf die es ankommt: Ein Wissensmonopol ist kein Personalthema, sondern ein Symptom, und es verschwindet, wenn man das System ändert.
Was nicht hilft
Drei Maßnahmen werden regelmäßig beschlossen und erzeugen Aufwand ohne Wirkung.
Eine Dokumentationspflicht. „Bis Ende des Quartals ist das Modul dokumentiert." Das Ergebnis ist ein Dokument, das beschreibt, was der Code auch sagt, und das die Begründungen auslässt, weil die dem Autor selbstverständlich sind. Nach sechs Monaten stimmt es nicht mehr, und niemand merkt es, weil niemand es liest.
Paarprogrammierung als Verordnung. Zwei Menschen vor einem Bildschirm sind wirksam, wenn beide eine Aufgabe haben. Als Wissenstransfermaßnahme ohne konkrete Änderung wird daraus eine Vorführung, und die zweite Person vergisst sie in zwei Wochen, weil sie nichts damit getan hat.
Der Wissenstransfer-Termin. Zwei Stunden, in denen die Person erklärt, wie es funktioniert. Das ist genau die Menge Information, die niemand behält, und sie kommt in der falschen Reihenfolge: Erklärung vor Bedarf.
Allen dreien ist gemeinsam, dass sie Wissen übertragen wollen, ohne die Arbeit zu verlagern. Wissen bleibt aber nur dort, wo damit gearbeitet wird.
Was hilft: die Arbeit umleiten
Die wirksame Maßnahme ist unspektakulär und unbequem: Die nächste echte Änderung in diesem Bereich macht jemand anderes. Nicht als Übung, sondern als Aufgabe, mit Verantwortung für das Ergebnis.
Die Person mit dem Wissen ist dabei nicht Lehrer, sondern Prüfer. Sie beantwortet Fragen und liest den Änderungssatz, sie schreibt nicht mit. Das ist der Unterschied, an dem sich entscheidet, ob Wissen entsteht oder eine Vorführung stattfindet.
Damit das funktioniert, müssen drei Dinge vorher da sein, und das sind genau die ersten drei Punkte von oben.
- Ein Weg, etwas auszuprobieren. Eine Umgebung mit realistischen Daten, in der ein Fehler nichts kostet. Ohne die wird jede Übernahme zur Mutprobe.
- Ein Netz aus Tests um den Bereich, in dem gearbeitet wird. Nicht überall, dort. Es muss nicht viel sein, es muss das Verhalten festhalten, das niemand mehr erklären kann.
- Ein Start, der einen halben Tag dauert. Das ist oft die billigste der drei Maßnahmen und die, die am längsten liegen bleibt.
Der vierte Punkt, die stummen Fehler, wird von derselben Übung mit erledigt: Wer zum ersten Mal an einem Bereich arbeitet, merkt sofort, wo er nicht sehen kann, was passiert, und das ist die beste Anforderungsliste für Beobachtbarkeit, die es gibt.
Wie sich prüfen lässt, ob das Wissen tatsächlich übergegangen ist, steht in Der Übergabetag.
Die Grenze ziehen, damit sich jemand einarbeiten kann
Bleibt der fünfte Punkt, und der ist der einzige, der wirklich Architekturarbeit verlangt. Solange eine Änderung an der Abrechnung Wissen über vier andere Bereiche braucht, hilft keine der Maßnahmen oben.
Was hier wirkt, ist nicht eine Aufteilung in Dienste, sondern eine Grenze innerhalb des Systems: ein Modul mit einer klaren Schnittstelle, hinter der der Rest nicht hineinsieht. Das ist mehr Arbeit als eine Dokumentation und weniger als ein Umbau, und es ist die einzige Maßnahme, die dauerhaft wirkt.
Ein praktischer Anhaltspunkt dafür, ob die Grenze reicht: Kann eine neue Person eine Änderung in diesem Bereich vornehmen, ohne eine Datei außerhalb zu öffnen? Wenn ja, ist der Bereich einarbeitbar. Wenn nein, ist er es nicht, egal wie gut er dokumentiert ist.
Wer wissen will, wo solche Grenzen im eigenen System bereits ungefähr verlaufen, findet das in der Versionsgeschichte: Dateien, die regelmäßig gemeinsam geändert werden, gehören zusammen, auch wenn sie in verschiedenen Verzeichnissen liegen.
# Welche Dateien werden zusammen geaendert? Grobe Naeherung, reicht
# fuer die Frage, wo eine Grenze ueberhaupt moeglich waere.
git log --since="2 years ago" --name-only --pretty=format:--- \
| awk '/^---/{c++} /\.php$/{print c, $0}' \
| sort -k2 | uniq -c | sort -rn | head -40Was man einem Agenten über ein System aufschreiben muss, ist dasselbe, was einem neuen Kollegen fehlt: Coding-Agenten im Altsystem.
Messen, wer wo arbeitet
Damit die Sache nicht nach Gefühl läuft, lohnt eine Messung, die zehn Minuten dauert und je Bereich zeigt, wie viele Menschen dort in den letzten zwei Jahren tatsächlich etwas geändert haben.
for bereich in src/Abrechnung src/Versand src/Katalog src/Bestellung; do
echo -n "$bereich: "
git log --since="2 years ago" --pretty="%an" -- "$bereich" \
| sort -u | tr '\n' ' '
echo
doneDie Liste liest sich anders als erwartet. Regelmäßig steht in einem Bereich, den alle für gefährlich halten, eine Handvoll Namen, und in einem, über den niemand spricht, genau einer. Genau dort ist das Risiko, weil es nicht bekannt ist.
Zu jedem Bereich mit einem einzigen Namen gehört danach eine Entscheidung, und die dritte Möglichkeit ist die, die am seltensten genutzt wird: Es ist in Ordnung so.
Wann ein Monopol in Ordnung ist
Nicht jeder Bereich braucht zwei Köpfe. Drei Fälle, in denen ich die Sache stehen lasse.
Der Bereich wird nicht mehr geändert. Ein Modul, das seit drei Jahren unverändert läuft und niemanden stört, braucht keine zweite Person. Es braucht eine Notiz, dass niemand es mehr versteht, und einen Plan für den Tag, an dem es doch geändert werden muss.
Der Bereich verschwindet. Was in einem Jahr abgelöst wird, bekommt keine Einarbeitung mehr. Das ist dieselbe Rechnung wie bei einem eingefrorenen Altsystem: Aufwand in ein Auslaufmodell.
Der Aufwand steht in keinem Verhältnis. Ein Bereich, in den sich jemand zwei Monate einarbeiten müsste und der einmal im Jahr angefasst wird, ist beim nächsten Mal billiger extern eingekauft als intern vorgehalten.
In allen drei Fällen ist die Entscheidung dieselbe wie überall in diesem Thema: nicht verhindern, sondern benennen. Ein bekanntes Monopol mit einer Notiz und einem Plan ist ein Risiko, das man eingeht. Ein unbekanntes ist eines, das man erleidet.
Und wenn die Person tatsächlich geht, bevor etwas davon passiert ist, entscheidet die erste Woche über die Kosten: was dann zu tun ist, steht in einem eigenen Artikel. Wie eine geordnete Übernahme abläuft, steht auf einer eigenen Seite.
Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.
