Entwickelt, bezahlt, vergessen: Warum manche Website-Funktionen niemand nutzt

Besonders sichtbar wird das bei großen Websites mit verteilten Redaktionen. Ein einzelner Markt meldet einen konkreten Bedarf an den Product oder System Owner, dort wird daraus eine Anforderung und schließlich ein Ticket für den Dienstleister.

Was dabei manchmal zu kurz kommt, ist die Frage: Wer hat dieses Problem eigentlich noch?

Vielleicht arbeiten andere Märkte ganz anders, vielleicht haben fünf Länder dasselbe Problem, beschreiben es aber unterschiedlich oder es existiert bereits eine Funktion, die mit einer kleinen Erweiterung auch diesen Anwendungsfall abdecken könnte. Bevor eine neue Funktion entwickelt wird, lohnt es sich deshalb, den Bedarf etwas größer zu betrachten:

• Welches Problem soll tatsächlich gelöst werden?

• Wer hat dieses Problem noch?

• Wie wird es heute gelöst?

• Können wir auf einer bestehenden Funktion aufbauen?

• Welchen konkreten Nutzen erwarten wir von der Änderung?

Aus fünf individuellen Anforderungen kann so vielleicht eine gemeinsame Lösung entstehen und aus mancher vermeintlich notwendigen Entwicklung auch die Erkenntnis, dass es sie gar nicht braucht.

Ein weiteres Problem entsteht durch Zeit.

Stellt Euch vor, Redakteure müssen einmal jährlich größere Datenmengen aktualisieren. Der manuelle Aufwand ist hoch, deshalb entsteht die Idee für einen Excel-Upload. Die Anforderung ist sinnvoll, aber nicht dringend und landet weiter unten im Backlog. Einige Sprints später wird sie umgesetzt. Zu diesem Zeitpunkt sind die Daten allerdings längst manuell aktualisiert worden. Wenn der Vorgang ein Jahr später erneut ansteht, weiß womöglich niemand mehr, dass inzwischen eine Importfunktion existiert.

Die Funktion ist da, das ursprüngliche Problem vielleicht auch, nur die Verbindung zwischen beiden ist verloren gegangen.

Noch deutlicher wurde das kürzlich in einem unserer Projekte. Vor mehr als einem Jahr hatte ein Verantwortlicher einen konkreten Schmerz bei den Nutzern erkannt und daraus eine Anforderung formuliert. Seitdem haben sich Verantwortlichkeiten und Prioritäten verändert. Nach über einem Jahr wurde das Ticket wieder aus dem Backlog geholt und sollte nun umgesetzt werden.

Der Dienstleister begann mit der Arbeit und stellte Rückfragen. Dabei zeigte sich plötzlich: Niemand konnte mehr genau sagen, warum die Anforderung ursprünglich entstanden war. Noch wichtiger: Niemand wusste, ob das Problem heute überhaupt noch existierte. Nach ersten investierten Aufwänden wurde die Umsetzung schließlich abgebrochen.

Das zeigt für uns eine wichtige Regel: Je älter ein Ticket ist, desto weniger sollte die Frage lauten „Wann setzen wir es um?“ und desto stärker „Würden wir dieses Ticket mit unserem heutigen Wissen noch einmal erstellen?“

Gerade Anforderungen, die mehrere Monate im Backlog lagen, sollten deshalb vor der Umsetzung noch einmal kurz validiert werden.

Auch eine weiterhin sinnvolle Funktion kann nach der Entwicklung scheitern.

Gerade bei verteilten Organisationen reicht es nicht, dem ursprünglichen Anforderer mitzuteilen, dass seine Funktion jetzt verfügbar ist. Andere Märkte, Redaktionen oder Fachbereiche erfahren möglicherweise nie davon. Selbst wenn sie von der neuen Funktion gehört haben, bedeutet das noch lange nicht, dass sie wissen, wann und wie sie diese einsetzen können, deshalb gehört zu einer abgeschlossenen Entwicklung auch eine saubere Dokumentation und zwar nicht nur auf technischer Ebene. Natürlich muss nachvollziehbar bleiben, was am System verändert wurde, wie eine Funktion technisch aufgebaut ist und welche Abhängigkeiten bestehen. Mindestens genauso wichtig ist aber eine Dokumentation für die tatsächlichen Nutzer.

Bei einem kleinen Redaktionsteam, das täglich miteinander spricht, lässt sich Wissen vielleicht noch direkt weitergeben. Bei internationalen Plattformen mit Dutzenden oder sogar Hunderten Redakteuren, unterschiedlichen Ländern, Mandanten und Verantwortlichkeiten funktioniert das nicht mehr. Hier braucht es eine zentrale und verständliche Redaktionsdokumentation: Was kann die neue Funktion? Für welchen Anwendungsfall ist sie gedacht? Wie wird sie eingesetzt? Was muss dabei beachtet werden?

Hinzu kommt die aktive Kommunikation. Eine Dokumentation allein hilft wenig, wenn niemand weiß, dass es sie gibt oder dass eine neue Funktion überhaupt bereitsteht. Release Notes, regelmäßige Redaktionsinformationen, Schulungen oder kurze Vorstellungen neuer Funktionen können deshalb genauso zum Release gehören wie der technische Rollout selbst.

Eigentlich sollten wir bei neuen Funktionen daher nicht nur drei, sondern vier Zustände unterscheiden:

gebaut → bekannt → verstanden → genutzt

In vielen Projekten messen wir vor allem den ersten. Das Ticket ist abgeschlossen, die Abnahme erfolgt und die Agentur hat geliefert. Ob die Funktion anschließend dokumentiert, kommuniziert, von den Nutzern verstanden und schließlich tatsächlich eingesetzt wird, wird dagegen wesentlich seltener überprüft.

Vielleicht sollten wir deshalb weniger über das Abarbeiten von Backlogs und stärker über den Lebenszyklus einer Anforderung nachdenken.

Am Anfang steht nicht die gewünschte Funktion, sondern ein Problem. Daraus entsteht eine mögliche Lösung. Diese wird priorisiert und, gerade wenn Zeit vergangen ist, vor der Umsetzung noch einmal hinterfragt. Nach der Entwicklung folgen Kommunikation und Einführung und irgendwann sollte überprüft werden, ob die Funktion tatsächlich genutzt wird.

Das gilt übrigens auch Jahre später. Funktionen, Komponenten und Sonderlösungen, die niemand mehr benötigt, dürfen auch wieder verschwinden.

Denn eine erfolgreiche Umsetzung erkennt Ihr nicht daran, dass ein Ticket auf „Done“ steht. Sondern daran, dass das ursprüngliche Problem anschließend tatsächlich kleiner geworden ist.