Die Situation
Jeder neue Entwickler stellt dieselben drei Fragen. Warum ist das Caching so konfiguriert? Woher kommt die Custom-Post-Type-Struktur? Und warum gibt es zwei Plugins, die offenbar dasselbe tun?
Jemand im Team beantwortet diese Fragen. Erklärt die Geschichte. Erzählt, was vor zwei Jahren passiert ist, warum die Entscheidung damals so getroffen wurde, welche Zusammenhänge man kennen muss. Das dauert eine Stunde, manchmal einen ganzen Nachmittag. Danach weiß der neue Entwickler Bescheid. Sechs Monate später, wenn der nächste kommt, beginnt der Vorgang von vorn. Und wieder sechs Monate danach.
Was auffällt: Die meisten Teams empfinden diesen Zyklus als normal. Als den Preis, den man eben zahlt, wenn neue Leute dazukommen. Als etwas, das zur Arbeit gehört, wie Meetings oder E-Mails. Es fällt nicht auf, weil es nie ein einzelnes großes Problem verursacht. Es ist kein Ausfall, kein Fehler, kein Vorfall. Es ist ein gleichmäßiger Verlust an Geschwindigkeit, der so konstant ist, dass er unsichtbar wird.
Aber die Zahlen sind deutlich, wenn man sie zusammenrechnet. Ein Unternehmen, das wir im vergangenen Jahr beraten haben, hatte in 18 Monaten drei verschiedene Entwickler am System. Jeder brauchte vier bis sechs Wochen, bis er produktiv war. Nicht weil die Entwickler unerfahren waren, sondern weil das System keine lesbare Geschichte hatte. Kein Dokument erklärte, warum die Dinge so waren, wie sie waren. Jeder neue Entwickler musste das System durch Lesen von Code und durch Fragen rekonstruieren. Das sind insgesamt drei bis vier Monate an Einarbeitungszeit in anderthalb Jahren. Nicht weil die Aufgaben komplex waren, sondern weil der Kontext fehlte.
Der Mechanismus
Der Reflex, den die meisten Teams haben, wenn sie das Problem erkennen, ist mehr Dokumentation. Ein Wiki anlegen. Eine umfassende technische Dokumentation schreiben. Alles festhalten, was man über das System wissen muss. Das klingt logisch. In der Praxis scheitert es fast immer.
Das erste Problem: Umfassende Dokumentation, die niemand liest, hat keinen Wert. Und umfassende Dokumentation wird fast nie gelesen. Ein 40-seitiges Dokument über die Systemarchitektur, das alle Zusammenhänge erklärt, ist bewundernswert in seiner Vollständigkeit. Aber der Entwickler, der wissen will, warum das Caching so konfiguriert ist, wird es nicht durchlesen. Er wird seine Kollegin fragen. Weil das schneller geht.
Das zweite Problem: Dokumentation wird fast immer Wochen oder Monate nach der Entscheidung geschrieben. Zu dem Zeitpunkt ist der Kontext bereits verblasst. Der Autor erinnert sich an das Was, aber nicht mehr vollständig an das Warum. „Wir haben uns für Plugin X entschieden“ steht da dann. Aber nicht: „Wir haben uns für Plugin X entschieden, weil Plugin Y zu dem Zeitpunkt keine REST-API-Unterstützung hatte und wir die Schnittstelle zum CRM darüber bauen wollten.“ Das Warum ist der Teil, der für die nächste Person den Unterschied macht. Und es ist der Teil, der am schnellsten verschwindet.
Das dritte Problem: Statische Dokumentation für dynamische Systeme veraltet in dem Moment, in dem sie geschrieben wird. Ein WordPress-System verändert sich kontinuierlich. Plugins werden aktualisiert, Funktionen kommen hinzu, Konfigurationen ändern sich. Eine Dokumentation, die einmal geschrieben und dann nicht gepflegt wird, beschreibt irgendwann ein System, das so nicht mehr existiert. Und veraltete Dokumentation ist schlimmer als keine Dokumentation, weil sie falsches Vertrauen erzeugt.
Das vierte Problem ist das grundlegendste: Wissen, das nur in einzelnen Köpfen existiert, ist kein Organisationswissen. Solange die Person, die das System kennt, da ist und erreichbar ist und Zeit hat, funktioniert alles. Aber das sind drei Bedingungen, die gleichzeitig erfüllt sein müssen. In dem Moment, in dem eine davon wegfällt, Urlaub, Krankheit, Jobwechsel, ist das Wissen nicht mehr zugänglich. Und das Team steht da, wo es vor sechs Monaten schon einmal stand.
Die Konsequenzen
Die sichtbarste Konsequenz ist die Einarbeitungszeit. Teams, die keinen strukturierten Wissenstransfer haben, berichten von Onboarding-Zeiten zwischen drei und sechs Monaten für neue Entwickler. Teams, die es anders machen, liegen bei drei bis sechs Wochen. Der Unterschied ist ein Faktor zehn. In einem Markt, in dem gute Entwickler schwer zu finden sind, ist das nicht nur eine Frage der Effizienz, es ist eine Frage, ob neue Teammitglieder frustriert aufgeben, bevor sie ankommen.
Die zweite Konsequenz ist das Schlüsselperson-Risiko. In vielen Unternehmen gibt es eine Person, die „das System kennt“. Sarah. Oder Thomas. Oder wer auch immer es in Ihrem Unternehmen ist. Diese Person ist nicht offiziell für alles zuständig, aber de facto die einzige, die bestimmte Fragen beantworten kann. Was passiert, wenn Sarah geht? Nicht im Streit, nicht überraschend, einfach, weil sie nach vier Jahren eine neue Herausforderung sucht. Das Wissen, das sie mitnimmt, lässt sich nicht in einer zweiwöchigen Übergabe transferieren, weil es nie dokumentiert wurde. Es existiert nur als Erfahrung in ihrem Kopf.
Die dritte Konsequenz ist, dass Entscheidungen ohne Kontext getroffen werden. Ein neuer Entwickler sieht eine Konfiguration, die ihm merkwürdig vorkommt. Er ändert sie, weil sie offensichtlich nicht dem Standard entspricht. Was er nicht weiß: Die Konfiguration wurde absichtlich so gewählt, weil der Standard in Kombination mit einem bestimmten Plugin zu einem Fehler führte. Drei Tage später tritt der Fehler auf. Niemand versteht zunächst, warum. Stunden gehen in die Fehlersuche. Am Ende stellt sich heraus, dass die „Verbesserung“ das Problem war.
Die vierte Konsequenz zeigt sich erst, wenn ein Team wächst. Wachstum sollte zu mehr Geschwindigkeit führen. Mehr Entwickler, mehr Kapazität, mehr Output. In der Praxis passiert oft das Gegenteil: Ab einer bestimmten Teamgröße wird die Geschwindigkeit nicht mehr höher, sondern stagniert. Weil jeder neue Mensch denselben Wissenserwerb durchlaufen muss. Weil Abstimmung aufwendiger wird, wenn Zusammenhänge nicht dokumentiert sind. Weil niemand sicher ist, ob eine Änderung an einer Stelle etwas an einer anderen Stelle beeinflusst. Das Team wächst, aber die Velocity bleibt gleich.
Was es verändert
Teams, die diesen Zyklus durchbrechen, schreiben nicht mehr Dokumentation. Sie schreiben andere Dokumentation.
Der wirksamste Ansatz, den wir in der Praxis gesehen haben, ist das Entscheidungsprotokoll. Keine umfassende Systemdokumentation, sondern eine fortlaufende Liste von Entscheidungen, die am System getroffen wurden. Jeder Eintrag enthält drei Dinge: Was wurde entschieden? Warum? Und welche Alternativen wurden verworfen?
Ein Beispiel: „2025-03-15: Wir haben WP Rocket durch ein Server-seitiges Caching ersetzt. Grund: WP Rocket verursachte Konflikte mit dem dynamischen Pricing-Plugin. Alternative wäre gewesen, das Pricing-Plugin zu wechseln, was aber die Schnittstelle zum ERP betroffen hätte. Aufwand für die Migration wäre drei Tage gewesen.“
Dieser Eintrag ist in zwei Minuten geschrieben. Und er beantwortet die Frage, die jeder neue Entwickler stellen wird: „Warum nutzt ihr kein WP Rocket?“ Ohne dass jemand gefragt werden muss. Ohne dass der Kontext in sechs Monaten verloren ist.
Der zweite Baustein ist, das Warum festzuhalten, solange es klar ist. Nicht nächste Woche. Nicht beim nächsten Dokumentations-Sprint. Jetzt, in dem Moment, in dem die Entscheidung getroffen wird. Zwei Sätze. Mehr braucht es nicht. Aber diese zwei Sätze müssen in dem Moment geschrieben werden, in dem der Kontext vollständig im Kopf ist. Einen Monat später ist er es nicht mehr.
Der dritte Baustein ist Auffindbarkeit. Eine Entscheidung, die dokumentiert, aber nicht auffindbar ist, hat den halben Wert. Das bedeutet nicht, dass man ein komplexes Wissensmanagementsystem braucht. Es bedeutet, dass es einen Ort geben muss, an dem jedes Teammitglied weiß: Hier liegen die Entscheidungen. Ein Channel, ein Repository-Verzeichnis, ein einfaches Dokument, der Ort ist weniger wichtig als die Konsistenz, ihn zu nutzen.
Wie es weitergeht
Wenn Ihr Team regelmäßig Wissen neu aufbaut, wenn Einarbeitungszeiten lang sind oder wenn Sie eine Schlüsselperson haben, deren Wissen nicht dokumentiert ist, dann ist das kein Versäumnis. Es ist der Normalzustand in den meisten Unternehmen. Aber es ist ein Zustand, der sich verändern lässt, mit überschaubarem Aufwand und ohne großes Dokumentationsprojekt.
In unserer 90-minütigen Bestandsaufnahme schauen wir uns an, wo Wissen in Ihrem Team liegt, wo es fehlt und welche Art von Dokumentation in Ihrer konkreten Situation den größten Unterschied machen würde. Keine Theorie, sondern eine praktische Einschätzung.
Bestandsaufnahme vereinbaren →
Falls Sie erst einmal eine Frage klären möchten, erreichen Sie uns jederzeit über unser Kontaktformular.