Ein Code Freeze im Weihnachtsgeschäft ist ein vereinbarter Zeitraum, in dem dein Team keine neuen Funktionen und keine riskanten Korrekturen veröffentlicht, weil Umsatz und Stabilität Vorrang haben. Im Onlineshop umfasst er meist die Wochen rund um Black Friday und Weihnachten. Ein Datum im Kalender reicht nicht: Du brauchst einen Modus, vorher abgeschlossene Arbeiten, eine Definition des Notfall-Fixes und einen Ort für Ideen, die im Januar zurückkommen.
Dieser Leitfaden richtet sich an kleine Teams, manchmal mit externer Agentur. Tests der Aktionsseite und die Vorbereitung des Supports behandeln eigene Leitfäden: Black-Friday-Aktionsseite vor dem Start prüfen und Kundenservice für Black Friday vorbereiten. Hier legst du die Regeln für Änderungen an Code und Konfiguration fest.
Weicher oder harter Stopp: den Modus wählen
Ein harter Stopp bedeutet: Niemand veröffentlicht Codeänderungen, außer einem Notfall-Fix, der nach festgelegtem Verfahren freigegeben wurde. Ein weicher Stopp erlaubt bestimmte, vorab benannte Arten von Änderungen, etwa Inhalte im CMS oder Preise. Die Wahl hängt davon ab, was eine Stunde Ausfall kostet und wie schnell du eine Änderung zurücknimmst. Ein geübter, schneller Rückweg spricht für den weichen Modus; ein Backup von Hand einzuspielen spricht für den harten.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Modus | Was erlaubt ist | Wann er passt |
|---|---|---|
| Harter Stopp | Nur ein freigegebener Notfall-Fix | Eine einzige Umgebung und kein geübter Rückweg |
| Weicher Stopp | Inhalte, Preise, Banner und andere vorab notierte Ausnahmen | Testumgebung und schnelle Rückkehr zur vorherigen Version |
| Schrittweises Bremsen | Kleinere Releases mit zusätzlicher Prüfung, immer seltener | Einige Wochen vor dem Stopp als Übergangsphase |
Die Ausnahmeliste im weichen Modus muss abgeschlossen sein. „Kleine Korrekturen“ sind ein Schlupfloch für ein neues Plugin oder eine Template-Änderung, keine Ausnahme. Werde konkret: Bannertext, Preisaktualisierung, neues Produktfoto. Alles andere ist ein Notfall-Fix oder wartet bis Januar.
Fullstory beschreibt drei Varianten: einen harten Stopp, bei dem Entwickler keinen Zugriff auf Deployments haben, einen weichen als Absprache, keinen Code zu ändern, mit erlaubten Ausnahmen, und den mildesten „Code Frost“, bei dem ein Team Änderungen reduziert statt stoppt. Zudem warnt der Artikel, dass der Stichtag zu Hektik und schwächerem Code verleitet. Welche Variante zu deinem Unternehmen passt, sagt er nicht: Fullstory zu Vor- und Nachteilen eines Code Freeze.
Termine und Umfang: was du genau einfrierst
Trage Beginn, Ende und einen Auswertungstermin in den Kalender ein. Starte den Stopp nicht am Tag des Aktionsbeginns, sonst zeigen sich die ersten Probleme beim stärksten Traffic, ohne Zeit für eine ruhige Korrektur. Unten siehst du den Zeitplan eines fiktiven Teeshops, als Beispiel und nicht als empfohlene Dauer.
- Sechs Wochen vorher
Kandidatenliste und Sprint mit den riskantesten Arbeiten
- Eine Woche vor Black Friday
Letztes Release, danach nur noch Beobachtung
- Hochsaison
Ausschließlich Ausnahmen von der Liste und Notfall-Fixes
- Erste Januarwoche
Auswertung der Workarounds und des Backlogs, dann der erste Sprint
- Theme- oder Template-Code und eigene Skripte.
- Updates von Plugins, Modulen und Shopsystem, mit eigener Entscheidung zu Sicherheitsupdates.
- Der Kaufweg: Warenkorb, Versand, Zahlung und Kontaktformulare.
- Skripte von Drittanbietern: Chat, Analyse, Consent-Banner, Werbepixel.
- Server-, Domain- und Weiterleitungskonfiguration.
- Die Person, die Ausnahmen freigibt, und ihre Vertretung an freien Tagen.
Der Stopp gilt auch für Dienstleister. Schick deiner Agentur Termine, Umfang und den Kontakt der freigebenden Person und frag, ob sie in dieser Zeit selbst pausiert.
Der Sprint vor dem Stopp: riskante Arbeit zuerst
Nutze die letzten Wochen vor dem Stopp für Arbeiten, die sich am schwersten prüfen und am leichtesten beschädigen lassen: eine neue Versandart, ein Wechsel des Zahlungsanbieters, ein umgebautes Formular. Jede davon braucht nach dem Release Zeit zur Beobachtung. Die Regel: Je höher das Risiko, desto früher im Sprint.
- Kandidaten sammeln.Notiere jede Änderung, die jemand „noch vor Weihnachten“ schaffen will, mit ihrer Wirkung auf Kunden und ihrem Rückweg.
- Aussortieren, was warten kann.Beeinflusst eine Arbeit weder den Saisonumsatz noch behebt sie ein bekanntes Problem, verschiebe sie sofort auf Januar.
- Nach Risiko sortieren.Zuerst Kaufweg und Formulare, dann Inhalte und Design. Beende den Sprint mit einigen Tagen ohne Releases, nur zur Beobachtung.
- Änderungen an den Support übergeben.Jede veröffentlichte Änderung bekommt vor Saisonbeginn eine kurze Notiz für alle, die Kunden antworten.
Sichere bei einem größeren Umbau zuerst die Messung ab; die Checkliste steht im Leitfaden dazu, was ein Website-Relaunch in der Messung zerstört. Die Notiz fürs Team schreibst du nach dem Leitfaden zur Übergabe von Änderungen an den Support. In Meetlead Projekte hat ein Sprint Namen, Ziel und Termine; beim Abschluss wandern offene Aufgaben in den Backlog oder den nächsten Sprint.
Notfall-Fix: Definition und wer ihn freigibt
Ein Notfall-Fix ist eine Änderung, ohne die Kunden etwas Wichtiges nicht erledigen können, und bei der Warten bis Januar mehr kostet als das Release-Risiko. Schreib die Kriterien vor dem Stopp auf, solange weder ein wichtiger Kunde noch der Vertrieb Druck macht.
- Blockierter KaufwegKunden können kein Produkt hinzufügen, nicht bezahlen, keinen Versand wählen oder kein Formular senden.
- Falsche KundeninformationDie Seite zeigt einen falschen Preis, Liefertermin oder Bedingungen, die in die Irre führen können.
- SicherheitDer Anbieter von Plattform oder Plugin veröffentlicht ein Sicherheitsupdate, oder du bemerkst einen Missbrauchsversuch.
- Kein NotfallEine neue Idee, eine andere Farbe, ein zusätzlicher Filter oder ein Funktionswunsch, auch von einem großen Kunden.
Bestimme eine freigebende Person und eine Vertretung, meist Inhaber oder Vertriebsleitung. Wer die Änderung entwickelt, bewertet Risiko und Rückweg, gibt sie aber nie selbst frei, und nach dem Release geht jemand anderes den korrigierten Weg wie ein Kunde durch. Zur Dringlichkeit eines Fehlers, der nur einen Teil der Besucher trifft, lies, wie sich Priorität und Schweregrad eines Fehlers unterscheiden.
Was nicht funktioniert: Kunden mit Lieferung an eine Paketstation kommen nicht zur Zahlung. Seit wann und bei wem: seit 10:40 Uhr, auf Smartphones, zwei Meldungen im Chat. Kosten des Wartens: verlorene Bestellungen mit dieser Versandart. Änderung: vorherige Version des Versandmoduls wiederherstellen. Rückweg: Rückkehr zur aktuellen Version. Freigabe: vollständiger Name der Person von der Liste.
Die Atlassian-Dokumentation beschreibt eine Notfalländerung als eine, die so schnell wie möglich bewertet und umgesetzt werden muss und dabei einige Prozessschritte auslässt; außerdem lassen sich Freeze-Fenster im Änderungskalender eintragen. Das beschreibt ein Werkzeug für IT-Abteilungen, kein fertiges Verfahren für einen kleinen Shop: Atlassian zum Änderungsmanagement.
Kundenideen: in den Januar-Backlog, mit Kontext
In der Saison kommen auch mehr Wünsche: ein zusätzlicher Filter, eine andere Versandart, klarere Versandtermine. Die schlechteste Antwort ist „Wir notieren das“, ohne dass etwas übrig bleibt. Kläre zuerst, ob es ein Fehler oder ein neuer Bedarf ist; dabei hilft der Leitfaden Fehler oder Feature-Wunsch. Ein Fehler, der Käufe blockiert, folgt den Notfallkriterien, eine Idee kommt in den Backlog.
Ein Backlog-Eintrag soll dir die Rückkehr zur Sache erlauben, ohne den Kunden erneut auszufragen, also halte den Bedarf in seinen Worten und die Ausgangssituation fest. In Projekte verknüpfst du die Aufgabe mit dem Ticket, einer Sitzungsaufzeichnung und anderen Aufgaben, markierst ähnliche Wünsche als Duplikat und setzt die Priorität bei der Auswertung im Januar. Projekte benötigt ein Konto, einen passenden Plan und die aktive App auf der Website.
Antworte ehrlich: „Danke, wir haben den Wunsch für die Auswertung nach der Saison notiert. Bis Anfang Januar ändern wir nichts an der Website, deshalb können wir noch keine Entscheidung und keinen Termin nennen.“ Versprich keine Umsetzung, nur um das Gespräch zu beenden.
Januar: Auswertung und erster Sprint nach dem Stopp
Beginne den Januar nicht damit, alles Liegengebliebene zu veröffentlichen. Prüfe zuerst die Notfall-Fixes der Saison: Manche waren Workarounds, die eine saubere Lösung brauchen. Geh dann den Backlog durch, führe Duplikate zusammen und setze Prioritäten nach der Zahl verknüpfter Tickets und dem Einfluss auf den Umsatz. Erst daraus wählst du den Umfang des ersten Sprints.
Betreut eine Agentur deine Website, eignet sich der Januar, um die Annahme von Anfragen zu ordnen; mehr im Leitfaden zu Kundenanfragen nach dem Website-Start. Notiere außerdem, ob die Ausnahmeliste reichte, wie viele Notfall-Fixes es gab und ob jemand die Regeln umgangen hat.
Fragen zum Änderungsstopp
Darf ich während des Stopps Inhalte und Preise ändern? Ja, im weichen Modus, wenn diese Änderungen auf der Ausnahmeliste stehen. Auch Inhalte können etwas kaputt machen, etwa ein Link auf eine gelöschte Seite, also lege fest, wer nach der Veröffentlichung prüft. Eine Änderung an Template, Plugin oder Skript ist nie eine Inhaltsänderung.
Warten Sicherheitsupdates ebenfalls bis Januar? Nicht automatisch. Behandle sie wie einen Notfall-Fix: Risiko bewerten, Rückweg vorbereiten, Freigabe einholen und nach der Installation den Kaufweg durchgehen. Bringt das Update auch neue Funktionen mit, frag den Anbieter nach einer Version nur mit der Sicherheitskorrektur.
