Kontinuierliche Verbesserung scheitert selten am Willen. Sie scheitert an der Entfernung zwischen demjenigen, der das Problem sieht, und demjenigen, der es beheben darf. Ein überflüssiges Skript zu entfernen ist Arbeit von zwanzig Minuten. Wenn dafür ein Ticket geschrieben, ein Angebot eingeholt, eine Freigabe erteilt und ein Release-Fenster abgewartet werden muss, sind aus zwanzig Minuten mehrere Wochen und ein vierstelliger Betrag geworden. Und dann passiert es nicht. Nicht weil jemand dagegen wäre, sondern weil der Aufwand die Sache erdrückt.
Die vier Erfolgskriterien von Guideline 5.11
Kontinuierliche Verbesserung: Verankere Praktiken der kontinuierlichen Verbesserung, die klar berichten, was sich ändert, warum es sich ändert und ob dadurch die ökologischen Nachhaltigkeitsergebnisse besser werden. Stelle sicher, dass ökologische und weitere ESG-Auswirkungen gemeinsam mit betrieblichen und geschäftlichen Leistungskennzahlen bewertet werden.
Durchgeführte Retrospektiven: Überprüfe Arbeitsergebnisse und aktualisiere sie regelmäßig, damit die Projektteams genug Zeit haben, Nutzerforschung zu betreiben, technische Schulden zu erkennen und abzubauen, hochwertige Ergebnisse zu liefern und das Gelernte weiterzugeben.
Iteratives Vorgehen: Weise eine nachvollziehbare Historie kontinuierlicher Verbesserung nach, mit der das digitale Produkt oder der Dienst analysiert wird. Adressiere zugleich mögliche Folgen des fortlaufenden Experimentierens, etwa technische Schulden, Produktleistung und Emissionen. Beschränke Analytics auf die unbedingt notwendigen Funktionen, die Entscheidungen unterstützen, Nutzerfeedback fördern und den Vergleich mit den Zielen der Organisation und den Bedürfnissen der Nutzer ermöglichen.
Entscheidungen über Funktionen: Überprüfe regelmäßig sämtliche Funktionen über den gesamten Produktlebenszyklus hinweg. Begründe und priorisiere Entscheidungen darüber, Funktionen zu behalten, zu ändern, hinzuzufügen oder zu entfernen, anhand von Umweltwirkung, Nutzen für die Anwender, tatsächlicher Nutzung und Wartungskosten. Dazu gehört auch die Außerbetriebnahme ungenutzter oder wenig aufgerufener Funktionen und Inhalte.
Meine Einordnung
Das vierte Kriterium ist das schärfste des ganzen Kapitels, und es sagt endlich aus, was andere Guidelines nur andeuten: Funktionen und Inhalte, die kaum genutzt werden, gehören abgeschaltet. Nicht überarbeitet, nicht besser platziert, sondern außer Betrieb genommen. In einem Standard, der ansonsten sehr diplomatisch formuliert ist, steht damit ausdrücklich, dass Rückbau eine legitime Maßnahme ist.
Ebenso bemerkenswert ist der letzte Satz des dritten Kriteriums. Analytics soll auf das beschränkt werden, was Entscheidungen tatsächlich stützt. Das ist Datensparsamkeit an einer Stelle, an der man sie nicht erwartet: mitten in einer Regel über Produktentwicklung. Wer alles misst, um „später vielleicht“ etwas auswerten zu können, sammelt Bestände, die er schützen, aufbewahren und löschen muss, und trifft trotzdem keine besseren Entscheidungen.
Das erste Kriterium enthält eine kleine, folgenreiche Forderung: Es soll berichtet werden, ob eine Änderung die Nachhaltigkeit verbessert hat. Nicht nur, dass geändert wurde. Damit wird jede Anpassung zu einer überprüfbaren Behauptung, und Optimierung hört auf, ein Gefühl zu sein.
Wo ich weiter gehe
Die Guideline beschreibt Verfahren und setzt dabei stillschweigend voraus, dass jemand handeln kann. Genau das ist in der Praxis der Unterschied, der über Erfolg oder Stillstand entscheidet.
Ich habe hier eine privilegierte Ausgangslage: Ich kann alles selbst ändern. Fällt mir beim Testen etwas auf, ist es zehn Minuten später behoben. Die zweitbeste Konstellation sind eigene Entwickler im Haus, dann liegt die Reibung nur in der Priorisierung. Deutlich schwieriger wird es, wenn alles extern liegt, denn dann hat jede Kleinigkeit einen Preis und einen Vorgang.
Für diesen häufigsten Fall ist meine Empfehlung nicht technischer, sondern vertraglicher Natur.
Der zweite Hebel ist die Architektur. Wie teuer eine kleine Änderung ist, entscheidet sich lange vorher: bei der Wahl des Systems, beim Zugriff auf das Repository, bei der Frage, ob Inhalte ohne Entwicklerbeteiligung gepflegt werden können. Eine statisch erzeugte Seite mit klarer Trennung von Inhalt und Template macht viele Verbesserungen zu Textänderungen. Ein System mit proprietären Erweiterungen macht aus derselben Änderung ein Projekt. Wer sich kontinuierliche Verbesserung wünscht, muss sie sich technisch leisten können.
Und für alle drei Konstellationen gilt dasselbe Grundproblem: Verbesserung, die keinen festen Platz im Kalender hat, verliert gegen alles, was einen Termin hat. Bei mir ist das eine laufende Liste kleiner Auffälligkeiten, die ich abarbeite, wenn ich ohnehin im Projekt bin. Das ist unspektakulär, aber es ist der Grund, warum nie ein großer Rückstand entsteht.
Dein erster Schritt heute
Du brauchst kein Verfahren. Du brauchst eine Liste und einen wiederkehrenden Termin.
Wenn Deine Website extern betreut wird, nimm diese Liste ins nächste Gespräch mit und verhandle ein monatliches Pflegekontingent. Das ist der wirksamste Schritt, den Du in dieser Rolle machen kannst.
Verbesserung ist keine Frage des Wollens, sondern der Reibung. Wer sie günstig macht, bekommt sie von allein.
Quelle: W3C-Fassung von Guideline 5.11