Bei einem Livegang treffen wir uns meistens zu einem festgelegten Zeitpunkt in einem digitalen Raum. Der oder die Product Owner:in geht mit dem Team die Checkliste durch. Wir ändern Konfigurationen, schalten eine Domain um und beobachten das System.
Dann warten wir.
Manche Kund:innen sind überrascht, dass wir nicht aufgeregt durcheinanderlaufen. Für sie ist der Livegang der große Moment, auf den das Projekt lange hingearbeitet hat. Für uns sollte das, was technisch passiert, zu diesem Zeitpunkt schon ziemlich gewöhnlich sein.
Wir freuen uns trotzdem jedes Mal und im besten Fall ist die Livegang-Party auch schon geplant und Kuchen und Sekt stehen bereit.
Wir versuchen, einen ersten Livegang so früh wie sinnvoll anzusetzen. Diese Haltung ist bei punkt.de nicht neu: Bereits 2015 haben wir über die Vorteile eines Continuous Relaunchs geschrieben. Auch unser damaliger Beitrag in der Computerwoche stellte die Frage, warum der Big-Bang-Relaunch Geschichte sein sollte.
Der Gedanke dahinter ist einfach: Ein neues System muss nicht mit seinem vollständigen, für die nächsten Jahre geplanten Funktionsumfang starten. Es kann mit einem sinnvollen Kern live gehen, echtes Feedback sammeln und sich anschließend weiterentwickeln.
Technisch klingt das logisch. Im Unternehmen ist es oft schwierig.
Wenn ein altes System über Jahre gewachsen ist, besitzt fast jede Abteilung Funktionen, die sie schützen möchte. Mit weniger live zu gehen, fühlt sich dann wie ein Rückschritt an – selbst wenn die vorhandenen Funktionen deutlich besser funktionieren als vorher. Aus vielen nachvollziehbaren Einzelinteressen entsteht schnell wieder ein großer Gesamtumfang.
Wir beraten an dieser Stelle, zeigen Abhängigkeiten und schlagen Ausbaustufen vor. Die Entscheidung bleibt beim Kunden. Nach unserer Erfahrung hatten allerdings gerade diejenigen Kund:innen besonders gute Livegänge, die den Mut zu einem kleineren ersten Schritt aufgebracht haben.
Ein früher Livegang darf kein leichtfertiger Livegang sein. Je kleiner wir den Schritt machen, desto zuverlässiger müssen die notwendigen Abläufe funktionieren.
Unser Ziel ist deshalb, möglichst viel von dem, was am Livegang-Tag passieren muss, in Code zu gießen. Datenmigrationen, Konfigurationen und Deployments sollen reproduzierbar sein. Automatisierte Tests und CI/CD-Prozesse helfen uns dabei, Änderungen kontinuierlich zu prüfen und auszuliefern. Warum das für uns mehr als ein Werkzeugthema ist, beschreiben wir ausführlicher in CI/CD als Kultur.
Ein besonders anschauliches Beispiel war der Relaunch eines Kundenportals mit mehr als 200.000 Angeboten. Diese Daten mussten zuverlässig in das neue System importiert werden. Ein halbes Jahr vor dem Livegang begannen wir deshalb, jede Nacht alle Angebote zu importieren.
Nacht für Nacht lief derselbe Prozess. Wir beobachteten ihn, fanden Engpässe und optimierten den Importer. Dadurch war die entscheidende Datenmigration am Livegang-Tag kein einmaliges Experiment mehr. Es lief einfach noch einmal der Importer – nur diesmal für das Produktivsystem.
Genau diese Art von Langeweile wollen wir beim Livegang erreichen.
Trotz Automatisierung bleibt ein Livegang eine gemeinsame organisatorische Aufgabe. Die Gesamtverantwortung liegt bei unserem oder unserer Product Owner:in. Dort laufen die einzelnen Aufgaben, Zuständigkeiten und Zeitpunkte zusammen.
Eine reale Checkliste für einen Website-Livegang enthielt beispielsweise:
Die Liste zeigt, warum ein Livegang keine rein technische Angelegenheit ist. Infrastruktur und Anwendung gehören ebenso dazu wie Inhalte, Datenschutz, Analytics, Auffindbarkeit und Nutzererlebnis.
Der oder die Product Owner:in hält den Ablauf zusammen. Zu einem vereinbarten Zeitpunkt treffen sich die Beteiligten in einem digitalen Raum, arbeiten die relevanten Schritte ab und teilen ihren Status. Viele Handgriffe bestehen dann tatsächlich darin, vorbereitete Konfigurationen zu aktivieren – und anschließend aufmerksam zu beobachten.
Ruhe am Livegang-Tag ist kein Zeichen dafür, dass wenig passiert. Sie ist das Ergebnis erfolgreicher Arbeit im Vorfeld!
Auch ein gründlich getestetes System trifft erst nach dem Livegang auf seinen vollständigen Alltag. Dann arbeiten echte Nutzer:innen mit echten Daten, Gewohnheiten und Erwartungen. Dass dabei neue Themen sichtbar werden, ist normal.
Kritische technische Fehler sollten uns nicht zuerst von Nutzer:innen gemeldet werden. Dafür investieren wir in Testing und Monitoring. Wenn ein wichtiger Dienst ausfällt oder sich ein technisches Problem abzeichnet, soll unser Team es selbst erkennen und reagieren.
Bei Nutzerfeedback ist die Lage weniger eindeutig. In manchen Projekten bauen wir einen Feedback-Button ein, über den Rückmeldungen direkt bei uns landen. In anderen unterstützen wir die Ansprechpartner:innen des Kunden dabei, Hinweise aus verschiedenen Kanälen zu sammeln und zu strukturieren.
In den ersten Tagen und Wochen müssen der Kunde und unser Product Owner:in diese Rückmeldungen gemeinsam einordnen:
Nicht jede Irritation sollte sofort eine Änderung auslösen. Aber „Die Nutzer:innen müssen sich nur daran gewöhnen“ darf auch keine Ausrede sein, berechtigtes Feedback zu ignorieren. Diese Unterscheidung braucht Erfahrung, Gespräch und manchmal etwas Zeit.
Nach der intensiveren Livegang-Phase geht das System in die dauerhafte Betreuung über. Diese besteht bei uns meist aus drei Bausteinen.
1. Wartung und Pflege
Wir halten Infrastruktur, Software und angebundene Systeme aktuell. Updates, Upgrades, Sicherheitsmaßnahmen und technisches Monitoring sorgen dafür, dass die Anwendung stabil und betreibbar bleibt.
2. Support und Hilfe
Wir unterstützen dort, wo das System im Alltag auf Menschen und Organisation trifft: beim Redaktionssupport, bei kleineren Bedienungsproblemen oder auch bei der technischen Begleitung einer Kampagne. Nicht jedes Anliegen ist ein Entwicklungsprojekt. Es braucht trotzdem jemanden, der das System kennt und helfen kann.
3. Weiterentwicklung
Größere Ausbaustufen planen und budgetieren wir häufig als eigene Vorhaben. Zusätzlich benötigt eine Anwendung ein gewisses Budgetgrundrauschen. Es ermöglicht dem Product Owner:in und den festen Ansprechpartner:innen, kleinere Verbesserungen umzusetzen, Feedback aufzunehmen und die Entwicklung des Systems im Blick zu behalten.
Keine Software, die man heutzutage baut, ist fertig.
Ohne dieses kontinuierliche Budget veraltet sie erstaunlich schnell. Oft bleiben schon kleine Verbesserungen im Ablauf liegen. Für sich genommen wirken sie vielleicht nicht kritisch. In der Summe werden sie zu täglicher Reibung. Die Zufriedenheit sinkt – bei den Nutzer:innen, beim Kunden und irgendwann auch im Projektteam.
Wer Weiterentwicklung lange genug aufschiebt, landet schließlich wieder bei einem großen Relaunch. Genau bei dem Zustand also, den ein Continuous Relaunch vermeiden soll.
Ein guter Livegang verbindet drei Dinge: eine bewusst begrenzte erste Version, technisch wiederholbare Abläufe und ein Team, das auch danach verantwortlich bleibt.
Manchmal gibt es vor dem Termin trotzdem stressige Phasen. Wir möchten das nicht romantisieren. Komplexe Systeme, viele Beteiligte und feste Termine lassen sich nicht immer vollständig entspannen. Aber Crunch-Time ist für uns kein Qualitätsmerkmal. Wenn am Livegang-Tag alle hektisch improvisieren müssen, ist vorher etwas schiefgelaufen.
Im vierten Teil dieser Serie geht es um Projekte mit besonderen Rahmenbedingungen und darum, wie wir bei unseren Spezialistenprojekten unsere Kompetenzen, Partner und Erfahrungen zusammenbringen.
