Busfaktor und Kontinuität
Dieser Artikel erklärt, was mit Busfaktor gemeint ist, warum kleine Entwicklungsprojekte dadurch verletzlich werden und wie Ephraim damit umgeht. Die Antwort ist nicht nur technische Dokumentation, sondern ein schulisches Modell: Wissen wird weitergegeben, Verantwortung wächst nach und jüngere Schülerinnen und Schüler werden früh als Qualitätssicherung, Ansprechpartner und Multiplikatoren eingebunden.
1. Was der Busfaktor bedeutet
Der Busfaktor ist ein Begriff aus der Softwareentwicklung. Er fragt: Wie viele zentrale Personen müssten ausfallen oder nicht mehr verfügbar sein, bevor ein Projekt ernsthaft handlungsunfähig wird? Die drastische Formulierung kommt aus der Vorstellung, dass Wissen an einzelnen Menschen hängen kann. Wenn eine Person weggeht und das Wissen über Architektur, Betrieb, Sicherheitsgrenzen oder Deployments nicht übertragen wurde, wird ein Projekt plötzlich langsam, unsicher oder nicht mehr wartbar.
Ein hoher Busfaktor bedeutet: Viele Menschen verstehen die wichtigen Zusammenhänge, Entscheidungen sind dokumentiert, Abläufe sind prüfbar, und neue Personen können einsteigen. Ein niedriger Busfaktor bedeutet: Das Projekt funktioniert, solange die richtigen Personen anwesend sind. Das ist bequem, solange alles gut läuft, aber riskant, sobald jemand Abitur macht, die Schule verlässt, krank wird, keine Zeit mehr hat oder schlicht andere Aufgaben übernimmt.
2. Warum kleine Teams besonders gefährdet sind
Kleine Teams sind schnell, weil Wege kurz sind. Eine Idee wird besprochen, direkt umgesetzt, geprüft und verbessert. Genau diese Stärke erzeugt aber ein Risiko: Vieles wird nicht ausdrücklich erklärt, weil die Beteiligten es ohnehin wissen. Man kennt die Datenbank, die Startreihenfolge der Dienste, die heiklen Sicherheitsstellen, die Logik der Projekte, die Grenzen der Verschlüsselung und die Gründe, warum eine Entscheidung so und nicht anders getroffen wurde.
In einem Schulprojekt kommt eine besondere zeitliche Grenze hinzu. Schülerinnen und Schüler bleiben nicht dauerhaft im Team. Sie wachsen fachlich hinein, übernehmen Verantwortung, werden schnell sehr gut und verlassen die Schule dann wieder. Das ist kein Fehler des Projekts, sondern Teil seiner Natur. Wer ein schulisches Entwicklungsprojekt ernst nimmt, muss deshalb nicht nur Software bauen, sondern auch Übergänge bauen.
Der Busfaktor ist bei Ephraim deshalb keine abstrakte Managementfrage. Teammitglieder aus Klasse 10 tragen aktuell zentrale Entwicklungsverantwortung. Das ist für das Tempo und die Tiefe des Projekts ein großer Vorteil. Gleichzeitig ist klar: Nach dem Abitur dürfen Architekturwissen, Betriebserfahrung und technische Urteilskraft nicht einfach verschwinden.
3. Warum Dokumentation allein nicht reicht
Dokumentation ist notwendig. Sie erklärt Entscheidungen, macht Abläufe nachvollziehbar und hilft neuen Personen, schneller in ein System einzusteigen. Ephraim nutzt dafür Handbücher, technische Dokumente, Git-Verlauf, Tests, Audits, Screenshots und nachvollziehbare Arbeitsstände. Auch KI-Werkzeuge können diese Spuren auswerten und Zusammenhänge erklären.
Trotzdem ersetzt Dokumentation keine Verantwortung. Wer ein System wirklich tragen soll, muss Fragen stellen, Fehler suchen, Grenzen ausprobieren, Änderungen begleiten und erleben, wie eine Entscheidung im Betrieb wirkt. Ein Dokument kann erklären, warum Projektchats geschützt sind. Verantwortungswissen entsteht aber erst, wenn jemand die Folgen dieser Entscheidung im Projektmodus, im Datenschutz, in der Oberfläche und in der Kommunikation mit Lehrkräften zugleich versteht.
Deshalb behandelt Ephraim Dokumentation als Gedächtnis, nicht als Ersatzteam. Sie bewahrt Wissen, macht Übergabe möglich und senkt Einstiegshürden. Die eigentliche Kontinuität entsteht aber erst, wenn jüngere Teammitglieder dieses Wissen praktisch verwenden und nach und nach selbst Entscheidungen mittragen.
4. Die technische Antwort: lesbare Spuren
Die erste Antwort auf den Busfaktor ist technische Lesbarkeit. Ein Projekt muss Spuren hinterlassen, die andere Menschen und KI-Werkzeuge später wieder erschließen können. Dazu gehören klare Architektur, sprechende Begriffe, Tests, nachvollziehbare Commits, stabile Handbuchartikel, konkrete Screenshots, Auditberichte und ein Glossar, das die wichtigsten Konzepte nicht voraussetzt.
| Spur | Wirkung gegen den Busfaktor |
|---|---|
| Tests | Zeigen, welche Abläufe weiterhin funktionieren müssen, und machen Fehler nach Änderungen schneller sichtbar. |
| Git-Verlauf | Erklärt, wann und warum Funktionen entstanden sind, statt nur den aktuellen Endzustand zu zeigen. |
| Handbücher | Übersetzen technische Entscheidungen in eine Sprache, die Lehrkräfte, Eltern, Förderer und neue Teammitglieder verstehen. |
| Audits | Erzeugen unabhängige Prüfperspektiven und machen Risiken explizit, bevor sie im Alltag überraschen. |
| KI-Werkzeuge | Können vorhandene Spuren durchsuchen, erklären und gegeneinander prüfen, ersetzen aber keine menschliche Bewertung. |
Diese technische Antwort ist wichtig, aber sie bleibt unvollständig. Sie macht Wissen zugänglich. Sie garantiert nicht, dass jemand dieses Wissen tatsächlich übernimmt. Dafür braucht Ephraim eine zweite, schulische Antwort.
5. Die schulische Antwort: Verantwortung wächst nach
Ephraim senkt den Busfaktor nicht nur durch Dokumentation, sondern durch ein rollierendes Kontinuitätsmodell. Die jüngeren Teammitglieder werden nicht erst dann wichtig, wenn ältere Schüler die Schule verlassen. Sie werden vorher in reale Verantwortung hineingeführt: durch Qualitätssicherung, Testen, Rückmeldungen, Gespräche mit Nutzenden, Erklären von Funktionen und zunehmend auch durch technisches Verständnis.
Dieses Modell passt zur Schule. Jüngere Schülerinnen und Schüler können zunächst prüfen, ob eine Oberfläche verständlich ist, ob ein Projektablauf wirklich funktioniert oder ob ein Handbuch eine Frage beantwortet. Danach können sie erklären, Fehler eingrenzen, andere einweisen und technische Zusammenhänge tiefer verstehen. Aus Qualitätssicherung wird Ansprechpartnerrolle. Aus Ansprechpartnerrolle wird Multiplikation. Aus Multiplikation kann später Entwicklungs- oder Betriebsverantwortung entstehen.
6. Der konkrete Übergang im Ephraim-Team
Der aktuelle Plan ist bewusst generationenbezogen. Die Teammitglieder aus Klasse 10 stehen für die gegenwärtige Entwicklungsstärke des Projekts. Die Teammitglieder aus Klasse 9 sollen nach und nach mehr Verantwortung übernehmen und in die Rollen hineinwachsen, die Klasse 10 heute prägt. Damit wird Kontinuität nach dem Abitur der älteren Teammitglieder nicht dem Zufall überlassen.
| Ebene | Aufgabe im Kontinuitätsmodell |
|---|---|
| Klasse 10 | Tragen zentrale Entwicklungsverantwortung, prägen Architekturentscheidungen und geben ihr Wissen schrittweise weiter. |
| Klasse 9 | Wachsen von Qualitätssicherung, Testen und Rückmeldung in Betrieb, Verständnis, Kommunikation und spätere Kernverantwortung hinein. |
| Jüngere Schülerinnen und Schüler | Rücken als Qualitätssicherung, Ansprechpartner und Multiplikatoren nach, damit auch der nächste Übergang vorbereitet wird. |
| Projektleitung | Hält pädagogische, organisatorische und technische Leitungsverantwortung zusammen und sorgt dafür, dass Übergabe nicht nur behauptet, sondern praktiziert wird. |
Entscheidend ist der letzte Punkt der Kette: Wenn Klasse 9 mehr Verantwortung übernimmt, entsteht an ihrer bisherigen Stelle eine Lücke. Diese Lücke soll wieder durch jüngere Schülerinnen und Schüler gefüllt werden. Genau dadurch wird aus einer Nachfolge ein Kreislauf.
7. Warum das sehr wichtig ist
Ephraim ist kein fertiges Produkt einer Firma, das eine Schule einkauft und bei Problemen an einen externen Support weiterreicht. Ephraim ist ein eigenes System der Schule. Dadurch gewinnt die Schule Kontrolle über Datenschutz, lokale KI, pädagogische Regeln und Weiterentwicklung. Diese Kontrolle ist nur dann belastbar, wenn sie nicht an einzelnen Personen hängt.
Der Busfaktor entscheidet deshalb, ob Ephraim nur ein beeindruckender Moment bleibt oder zu einer belastbaren schulischen Struktur wird. Ein System, das lokale KI, Datenschutz, Kryptografie, Projektarbeit, Betrieb und Handbücher zusammenführt, darf nicht davon abhängen, dass einzelne Personen dauerhaft verfügbar bleiben. Sonst wäre die technische Souveränität der Schule wieder nur geliehen.
Kontinuität macht aus individueller Stärke eine gemeinsame Fähigkeit. Tests, Dokumentation und Audits halten Wissen fest; die Übergabe an jüngere Teammitglieder macht dieses Wissen lebendig. Dadurch entsteht nicht nur Software, sondern eine schulische Praxis: Schülerinnen und Schüler lernen, ein reales System zu prüfen, zu erklären, zu verantworten und weiterzutragen.
Wer Ephraim von außen beurteilt, sollte deshalb nicht nur fragen, ob die aktuelle Version funktioniert. Die entscheidende Frage lautet: Kann die Schule dieses System verstehen, kontrollieren und weiterentwickeln, wenn sich das Team verändert? Das Kontinuitätsmodell ist die Antwort auf diese Frage und gehört deshalb zur Projektarchitektur.
8. Was damit nicht behauptet wird
Das Kontinuitätsmodell bedeutet nicht, dass alle Personen austauschbar sind. Die Beteiligten bringen unterschiedliche Stärken, Tempi und Perspektiven ein. Diese Unterschiede sind wertvoll. Der Sinn des Modells ist nicht Gleichmacherei, sondern Übergabefähigkeit: Wissen soll nicht verschwinden, wenn eine Person geht.
Ebenso wenig bedeutet der Ansatz, dass KI, Dokumentation oder Tests menschliche Urteilskraft ersetzen. Sie machen Einstieg und Prüfung leichter. Verantwortung bleibt menschlich. Genau deshalb ist der schulische Teil des Auswegs so wichtig: Menschen müssen miteinander arbeiten, erklären, widersprechen, prüfen und lernen, Entscheidungen zu tragen.