In Teil 1 ging es darum, wie ich zum TV Ober-Olm kam und was bei der Anforderungserhebung herauskam. Am Ende stand ein klares Bild davon, wie die Pflege funktionieren muss. Offen war die Frage, womit man das baut.

Meine Antwort war ein eigenes WordPress-Plugin für Sportvereine. Nicht für diesen einen. Für alle.

Das klingt nach Größenwahn für ein Dorfprojekt. Ich erkläre, warum es das Gegenteil war.

Der Reflex heißt: für den bauen, der fragt

Wenn dich ein Verein um Hilfe bittet, baust du für diesen Verein. Das ist keine bewusste Entscheidung, das ist die Voreinstellung. Die Anforderungen kommen von dort, die Beispiele kommen von dort, und irgendwann steht der Vereinsname im Quelltext. Nicht aus Faulheit, sondern weil jede einzelne Abkürzung in dem Moment vernünftig aussieht.

Man weiß ja, dass die Halle in Ober-Olm liegt. Also setzt man den Kartenmittelpunkt dorthin. Man weiß, dass die Vereinsfarbe ein bestimmtes Blau ist. Also steht das Blau im Stylesheet. Man weiß, dass der Verein Deutsch spricht. Also schreibt man die Beschriftungen auf Deutsch hin, statt sie übersetzbar zu machen.

Jede dieser Abkürzungen spart eine Viertelstunde. Zusammen entscheiden sie darüber, ob das Ergebnis jemals ein zweites Mal benutzt werden kann.

Die Frage, die alles gedreht hat

Ich habe mir irgendwann während der Anforderungsphase die Liste angeschaut und gefragt: Ist hier eigentlich irgendetwas speziell?

Sportarten mit Untergruppen. Trainingszeiten, die sich im Sommer ändern. Trainer, die man ansprechen kann. Hallen und Sportplätze. Ferien, in denen nichts stattfindet, außer Ferienbetreuung. Angebote, die im Beitrag enthalten sind oder extra kosten.

Das ist kein TV Ober-Olm. Das ist jeder Sportverein in Deutschland. Der Turnverein im Nachbardorf hat dieselbe Struktur, nur andere Namen drin. Und der Fußballverein zwei Orte weiter hat sie auch, plus Mannschaften und Spielbetrieb.

Wenn das Problem nicht speziell ist, ist die Lösung es auch nicht. Und dann ist es eine schlechte Idee, sie speziell zu bauen.

Was es schon gab, und warum es nicht passte

Fertige Lösungen gibt es reichlich. Kalender-Plugins, Event-Plugins, Vereinsverwaltungen mit Mitgliederdatenbank und Beitragseinzug, Baukästen für eigene Inhaltstypen.

Das Problem war nie die fehlende Funktion. Das Problem war, wer die Lücke dazwischen füllt.

Ein Kalender-Plugin kennt Termine, aber keine Sportarten. Es weiß nicht, dass „Leichtathletik Kinder“ im Sommer draußen und im Winter drinnen stattfindet, und schon gar nicht, dass in den Osterferien alles ausfällt. Eine Vereinsverwaltung fängt bei Mitgliedern und Beiträgen an, also bei einem Thema, das der Verein gar nicht auf der Website haben will. Und mit einem Baukasten für Inhaltstypen kann man sich das alles zusammenklicken, aber dann hat man genau das gebaut, was ich vermeiden wollte: ein System, dessen Logik nur der versteht, der es zusammengeklickt hat.

Der Ehrenamtliche, der in zwei Jahren die Trainingszeit von dienstags auf mittwochs ändern soll, muss sonst verstehen, wie drei Systeme zusammenhängen. Genau diese Verständnislast ist der Grund, warum Vereinswebsites verwaisen.

Ein Werkzeug, das den Verein bereits kennt, verlangt das nicht. Es fragt nicht „welchen Inhaltstyp möchten Sie anlegen“, sondern zeigt ein Feld für Trainingszeiten.

Die Entscheidung fiel am ersten Tag

Das ist der Teil, den ich selbst erst beim Nachschauen gemerkt habe, und er gefällt mir.

Der allererste Commit im Projekt heißt „Initialer Stand: Konzept Club Sports Manager (TVOO-Relaunch)“, vom 17. August. Vereinsprojekt, schon im Titel. In derselben Datei, im selben Commit, steht die zwölfte Entscheidung:

Bewusst produkt- statt vereinsspezifisch, damit jeder Sportverein es nutzen kann. „TVOO“ ist nur unsere Installation, nicht der Produktname.

Bevor eine einzige Zeile Code existierte, stand fest, dass der Verein ein Anwendungsfall ist und nicht das Ziel. Das ist keine nachträgliche Verklärung einer Erfolgsgeschichte. Das ist datiert und nachlesbar, und ich war selbst überrascht, wie früh das war.

Der Grund war übrigens nicht Weitsicht. Der Grund war Bequemlichkeit in der richtigen Richtung: Ich wollte nicht in einem Jahr dasselbe nochmal bauen, wenn der Schützenverein fragt.

Was die Entscheidung im Alltag bedeutet

Sie klingt nach einem Satz im Konzept. In Wirklichkeit ist sie eine tägliche Disziplin, und man verliert sie ständig aus den Augen.

Ein paar Monate später, kurz vor der Veröffentlichung, bin ich das Projekt nochmal auf Vereinsspezifisches durchgegangen. Ich hatte ja alles generisch gebaut, dachte ich.

Gefunden habe ich: einen fest eingetragenen Kartenmittelpunkt, der auf Rheinhessen zeigte. Eine Kennung, mit der sich das Plugin beim Geocoding-Dienst vorstellte und die den Vereinsnamen enthielt. Einen Rückfall-Hostnamen in den Kalender-Exportdateien, der auf unseren Server zeigte. Und einen Platzhalter für die Markenfarbe, der eben nicht neutral war.

Nichts davon war falsch für den TV Ober-Olm. Alles davon war falsch für jeden anderen.

Das ist die eigentliche Arbeit hinter „generisch bauen“. Nicht die Architektur, nicht das saubere Trennen von Schichten. Sondern immer wieder die Frage: Weiß dieser Code gerade etwas, das er nicht wissen darf?

Was das kostet, und wer es bezahlt

Ehrlich gesagt: Es dauert länger. Spürbar.

Jede Annahme wird zu einer Einstellung. Jede Beschriftung wird übersetzbar, also brauchst du Sprachdateien und einen Weg, sie zu prüfen. Jede Adresse im System muss konfigurierbar sein, weil ein Verein in Österreich eine andere Struktur will als einer in Hessen. Aus zwei Zeilen werden fünfzehn.

Diese Zeit bezahlt der Verein mit. Er bekommt sein Ergebnis später, als wenn ich ihm eine maßgeschneiderte Seite hingestellt hätte.

Im Gegenzug bekommt er etwas, das ein Auftragsprojekt nie hat: Das Ding gehört ihm nicht allein, also hängt es auch nicht an mir allein. Es liegt öffentlich, es bekommt Aktualisierungen, es hat eine Dokumentation, die nicht aus meinem Kopf kommt. Wenn ich morgen keine Lust mehr habe, steht der Verein immer noch besser da als mit einer Maßanfertigung von jemandem, der weg ist.

Das war von Anfang an das Ziel: Hilfe zur Selbsthilfe. Ein Produkt ist die belastbarere Form davon als ein Gefallen.

Der Name war die letzte Konsequenz

Irgendwann braucht das Ding einen Namen, und der Name entscheidet mit, wofür man es hält.

„TVOO-Kalender“ wäre der ehrliche Name für ein Vereinsprojekt gewesen. Geworden ist es Squadeno – Club Sports Manager: ein beschreibender Teil, der sagt, was es tut, und ein Markenteil davor. Die Software heißt bewusst nicht nach dem Verein, für den sie zuerst gebaut wurde. Wenn sie es täte, würde sie niemand sonst installieren, egal wie generisch der Code darunter ist.

Dass mir ausgerechnet bei diesem Namen später noch jemand reingeredet hat, und zwar das Review von WordPress.org, ist eine eigene Geschichte. Die kommt in Teil 4.

Fazit

Ich bin nicht losgezogen, um ein Produkt zu bauen. Ich wollte einem Verein helfen, dessen Angebot meine Tochter nutzt.

Der Umweg über „für alle statt für einen“ hat das Projekt größer gemacht, langsamer und anstrengender. Er ist trotzdem die richtige Entscheidung gewesen, und der Grund ist banal: Eine Maßanfertigung ist nur so lange gut, wie der Schneider erreichbar ist.

Das Plugin liegt inzwischen kostenlos im WordPress-Verzeichnis, und es gibt eine eigene Seite dazu. Wie so ein Ding in wenigen Wochen entsteht, ohne auseinanderzufallen, kommt in Teil 3. Was das Review daran auszusetzen hatte, in Teil 4.