Produkte pflegen statt neu bauen

Für den Bau einer Website gibt es ein Budget. Für ihren Betrieb gibt es selten eines. Diese Asymmetrie erklärt fast alles, was auf gewachsenen Websites schiefgeht. Nach dem Launch fließt kein Geld mehr, also wird nichts mehr aufgeräumt, nichts refaktoriert, nichts entfernt. Die Seite altert, wird langsamer, sammelt Altlasten, bis irgendwann jemand feststellt, dass ein Relaunch nötig ist. Und der Relaunch ist der mit Abstand teuerste Vorgang im ganzen Lebenszyklus: neue Entwicklung, Migration sämtlicher Inhalte, neue Tests, oft neue Infrastruktur. Wer die Zeit bis dahin von vier auf acht Jahre verlängert, halbiert diesen Aufwand pro Jahr. Das schafft keine einzelne technische Optimierung.

Info

Die fünf Erfolgskriterien von Guideline 5.10

Management und Wartung: Erstelle und pflege eine Dokumentation, die beschreibt, wie die Organisation Produktmanagement und Wartung handhabt.

Planungsstrategie: Entwickle, implementiere und pflege Wartungs- und Sicherheitspläne für alle digitalen Produkte und Dienste, die langfristige Nachhaltigkeit, Energieeffizienz und verantwortungsvollen Ressourceneinsatz über den gesamten Produktlebenszyklus in den Vordergrund stellen.

Ausstattung der Produkte: Sorge dafür, dass Produkte, Prototypen, Tests und unterstützende Prozesse dauerhaft ausreichend ausgestattet sind. Halte genügend Personal und Budget vor, um die laufende Wartung zu tragen, einschließlich des Abbaus technischer Schulden, der Überarbeitung von Code und der Weiterentwicklung von Funktionen, ohne Projekte aufzugeben.

Ressourcenmessung: Nimm die Messung von Emissionen und Ressourcenverbrauch in Deine Wartungsprozesse auf und verfolge Verbesserungen im Zeitverlauf. Bevorzuge Kennzahlen, die den wesentlichen gelieferten Nutzen und die Nachhaltigkeitsergebnisse abbilden. Vermeide Kennzahlen, die zu unnötiger Arbeit, unnötigem Ressourcenverbrauch oder unnötigen Emissionen anreizen.

Fehlerindikatoren: Bestimme und dokumentiere zentrale Fehlerindikatoren (Key Failure Indicators, KFIs), auch solche zu Barrierefreiheit, Bedienbarkeit und weiteren ökologischen, sozialen und Governance-bezogenen Auswirkungen. Überwache diese Indikatoren, um aufkommende Risiken früh zu erkennen und Gegenmaßnahmen einzuleiten.

Meine Einordnung

Drei Wörter im dritten Kriterium verdienen besondere Aufmerksamkeit: „ohne Projekte aufzugeben“. Das ist eine höfliche Formulierung für ein sehr verbreitetes Phänomen. In fast jeder Organisation, die länger als zehn Jahre existiert, gibt es digitale Ruinen: die Kampagnenseite von 2019 auf einer eigenen Subdomain, das Microsite-Projekt einer Abteilung, die es nicht mehr gibt, das Portal, das zwei Menschen nutzen. Alle laufen weiter, alle werden gecrawlt, alle brauchen Zertifikate, Updates und Speicher. Niemand fühlt sich zuständig, weil das Projekt formal beendet ist. Nur der Betrieb ist es nicht.

Technische Schulden werden im selben Kriterium ausdrücklich genannt, und das ist wichtig. Sie sind kein Schönheitsproblem. Veralteter Code lässt sich nicht mehr sicher aktualisieren, alte Abhängigkeiten erzwingen irgendwann einen Neubau, und jede Umgehungslösung, die aus Zeitmangel entsteht, macht die nächste teurer. Wartung ist kein Aufschub von Entwicklung, sondern ihre Voraussetzung.

Das vierte Kriterium ist das, worüber ich am längsten nachgedacht habe. Es warnt vor Kennzahlen, die unnötige Arbeit oder unnötigen Verbrauch belohnen. Das ist eine seltene Selbstkritik in einem Standard. Denn genau das tun viele übliche Kennzahlen: Zahl der ausgelieferten Funktionen, Seitenaufrufe, Verweildauer, Anzahl der Releases. Wer ein Team daran misst, bekommt mehr Funktionen, mehr Aufrufe und mehr Releases. Ob irgendetwas davon nützt, misst niemand.

Wo ich weiter gehe

Am spannendsten finde ich das fünfte Kriterium, weil es eine Blickrichtung umdreht. Fast alle Organisationen führen Leistungskennzahlen. Kaum eine führt Fehlerindikatoren.

Ein KFI beantwortet nicht die Frage „läuft es gut“, sondern „woran würde ich merken, dass es schlecht läuft, bevor es jemand meldet“. Für Websites lassen sich solche Indikatoren erstaunlich leicht definieren: steigendes Seitengewicht, wachsende Zahl der Drittanbieter-Verbindungen, zunehmende 404-Fehler, Suchanfragen ohne Treffer, ausstehende Sicherheitsupdates, Fehler im Barrierefreiheitstest. Jeder dieser Werte kann still ansteigen, ohne dass irgendjemand ein Problem meldet, und jeder ist ein Frühwarnzeichen für den nächsten Relaunch.

Bei der Ausstattung habe ich eine einfache Faustregel, die sich in Projekten bewährt hat.

Achtung
Ein Wartungsbudget von null bedeutet nicht, dass keine Kosten entstehen. Es bedeutet, dass sie sich aufstauen und später als Relaunch in einer Summe fällig werden, meist zum ungünstigsten Zeitpunkt. Plane jährlich einen festen Anteil der ursprünglichen Erstellungskosten für Pflege ein. Wer das nicht tut, zahlt nicht weniger, sondern nur später und mehr.

Und dann ist da eine Konsequenz, die in der Guideline fehlt: Nicht jedes Projekt verdient dauerhafte Pflege. Manche Ruinen sollte man nicht renovieren, sondern abreißen. Zu einer ehrlichen Wartungsstrategie gehört deshalb die Bereitschaft, Dinge abzuschalten. Was niemand pflegt und niemand nutzt, gehört nicht gewartet, sondern beendet.

Dein erster Schritt heute

Du brauchst keine Produktstrategie. Du brauchst eine Liste Deiner Domains.

Tipp
Schreib jede Domain und Subdomain auf, die auf Deinen Namen oder den Deiner Organisation läuft. Trag zu jeder zwei Angaben ein: Wer ist zuständig, und wann wurde zuletzt etwas geändert? Alles ohne Zuständigkeit oder ohne Änderung in den letzten zwei Jahren ist ein Kandidat zum Abschalten. Definiere anschließend zwei Fehlerindikatoren, die Du künftig quartalsweise prüfst.

Diese Liste kostet eine Stunde und findet in den meisten Organisationen mindestens einen laufenden Dienst, von dem niemand mehr wusste.

Eine Website ist kein Projekt mit einem Ende, sondern ein Betrieb mit laufenden Kosten. Wer sie nur als Projekt finanziert, finanziert automatisch ihren Nachfolger.

Quelle: W3C-Fassung von Guideline 5.10