Was wir aus unserem letzten Webshop-Go-live gelernt haben

Jeder Software Entwickler kennt es wahrscheinlich: Da arbeitet man Monate an einem Projekt, ist mit dem Code mehr als vertraut, dann kommt der eine Tag wo es live gehen soll und plötzlich kommen auch die Zweifel. Funktioniert alles? Haben wir trotz gründlicher Tests doch etwas übersehen? Das könnte man ja auch noch verbessern... sollen wir wirklich jetzt releasen oder doch noch die Stelle anpassen? Genau so einen Release hatten wir im Mai mit dem Go-Live des Onlineshops für Little John Bikes. Was wir daraus gelernt haben und was uns geholfen hat, erfahrt ihr in diesem Blogpost

Vom Start bis zum Ende eines Projektes mit dem man sich lange und intensiv beschäftigt hat, gibt es viele aufregende Momente - der aufregendste von ihnen ist und bleibt jedoch der Go-Live. Gerade bei derart kritischen Umstellen wie dem Release eines neuen Webshops ist es umso wichtiger, dass alles funktioniert und ineinandergreift. Schließlich sind die Verluste für den Kunden, wenn nach dem Go -live etwas schief läuft und beispielsweise keine Bestellungen getätigt werden können, enorm.

Deswegen war es uns besonders wichtig, optimal auf den Release vorbereitet zu sein.

3 Tage vor Release

Ein Webshop kann nicht alleine funktionieren, er ist immer abhängig von Schnittstellen und anderen Diensten.
Besonders wichtig ist dabei natürlich das Kernstück des Webshops: die Produkte. Doch wenn Produkte aus einer Middleware an einen Shop übertragen werden sollen, kann es zu Schwierigkeiten kommen:
Mal wird ein Feld nicht übergeben oder nicht richtig verarbeitet, dann fällt einem auf, dass manche Daten nicht ganz so passen, und die Datenstruktur muss noch einmal angepasst werden. Solche Sachen sind eigentlich keine großen Probleme, doch können sie sich durch Kommunikation über Tickets oder Chats sehr in die Länge ziehen. Das ist in komplexen Systemlandschaften ganz normal – entscheidend war, dass wir im gemeinsamen Endspurt schnell alles klären konnten

Die letzten drei Tage vor dem Go-live verbrachten wir vor Ort beim Kunden. Und das war auch die richtige Entscheidung. Egal, welche Frage auftauchte oder welche Entscheidung wir brauchten – vor Ort war immer jemand da, der uns schnell weiterhelfen oder eine Entscheidung treffen konnte. Dieser Fokus vor Ort hat dem letzten Sprint sehr gutgetan. So konnten wir alle Punkte, die wir uns für vor dem Go-live vorgenommen hatten, innerhalb dieser drei Tage umsetzen.

Unser Learning:
Ein gemeinsamer Schluss-Sprint vor dem Go-live kann das Projekt noch runder machen und helfen, kurze Kommunikationswege zu schaffen.

7 Stunden vor Release

Die letzten drei Tage vor dem Release waren also sehr erfolgreich und produktiv. Der Kunde war sich sicher: „So können wir erst mal online gehen.“ Aber uns fiel es schwer, den Punkt zu finden, an dem wir wirklich voll zufrieden waren.
Wir fanden immer wieder kleine Stellen, die man optimieren konnte, oder dachten bei Features, die für nach dem Release geplant waren: „Das Feature ist nicht so aufwendig, das können wir vor dem Release noch umsetzen.“ So hätten wir sicher unendlich weiter optimieren und verbessern können.

Wir waren beeindruckt von der klaren Einschätzung unseres Kunden – sie hat uns dabei geholfen, einen realistischen Cut zu setzen.
Nach dem Release war auch noch Zeit, die restlichen unkritischen Themen umzusetzen.

Unser Learning:
Ein Go-live bedeutet nicht, dass das Produkt fertig ist. Aber es ist gut genug, um online zu gehen. Denn durch den Go-live hat der Kunde – vor allem bei einer Migration – den Vorteil, schon die neue technische Basis zu haben. Und nach dem Go-live kann in Ruhe an den nächsten Features gearbeitet werden.

1 Stunde vor Release

Dann war es so weit. Wir saßen um 21 Uhr vor unseren Laptops und waren bereit. Die letzten kleinen Bugs waren gefixt, das Deployment lief durch, und auf dem Staging-Server sah alles gut aus. Jetzt konnten wir online gehen.

Doch trotzdem hat man immer so ein kleines mulmiges Gefühl: Was, wenn man doch etwas übersehen hat? Etwas, das auf Staging nie aufgefallen ist und erst auf der Production-Seite zu Fehlern führt? Was, wenn es im schlimmsten Fall dazu kommt, dass kein Kunde etwas bestellen kann oder die Zahlung nicht funktioniert?

Gespannt saßen wir also alle im Teams-Call und machten die letzten Vorbereitungen und Einstellungen.

Als der Webshop dann endlich online war und die ersten Bestellungen eintrudelten, fiel bei uns allen ein großer Stein vom Herzen.

Rückblickend weiß man immer, dass man sich zu viele Gedanken gemacht hat. Aber wahrscheinlich sorgt diese Sorge auch dafür, dass man umso vorsichtiger, aufmerksamer, sorgfältiger ist.

1 Monat nachdem Release

Ein Monat später können wir zufrieden sein mit dem was wir geschafft haben. Es gab kaum Probleme und wir konnten in den Wochen nach dem Release, noch mehr Verbesserungen und Features online bringen. Jetzt läuft der Shop noch runder und wir arbeiten schon fleißig an den nächsten Funktionen.

Abschließend können wir sehr stolz auf uns sein, dass wir den Release so gut über die Bühne gebracht haben.