Hinter den Kulissen eines Website-Entwicklungsprojektes (Teil 2)
Im ersten Beitrag haben wir berichtet, wie unsere Digital Presences Unit von der ersten Anfrage bis zum Umsetzungsstart für einen Website-Relaunch herangeht. Im zweiten Teil berichten wir darüber, was alles in der Phase der Umsetzung passiert.
Jetzt sind ist alles safe… oder?
Die Milestone-Planung ist komplett, die Kapazitäten sind entsprechend eingeteilt und dem Team sind die individuellen Aufgaben klar – von hier an kann also in der Umsetzung nichts mehr schiefgehen, oder? Auf dem Papier beziehungsweise an der Wand (wie in unserem Fall oft üblich) ist ein Website-Relaunch zwar ein großes Projekt, dafür aber mit klaren Regeln und eindeutigen nächsten Schritten. In der Praxis bemüht man sich als Agentur, sich für sämtliche Eventualitäten zu rüsten – denn Deadline ist Deadline ist Deadline. Wie bei jedem Projekt ist daher ein Projektleiter unentbehrlich – im besten Fall sowohl auf Agentur- als auch auf Kundenseite. Unser Head of Digital Presences Aleks, kümmert sich also darum, dass die Entwickler alles haben was sie brauchen um effizient an den Milestones oder Sprints arbeiten zu können.
Doch womit beginnt man eigentlich bei einem Website-Relaunch? Nachdem das grobe Konzept mittels Wireframes steht und auch vom Kunden abgenommen ist, geht es an die Detailkonzeption. Dabei wird die Informationsarchitektur der Website weiter verfeinert sowie die Corporate Identity in das zukünftige Design eingearbeitet. Ab diesem Zeitpunkt ist vor allem das Key Account Management gefragt, denn ohne Feedbackrunden mit dem Kunden gibt es kein entsprechendes Frontend-Design. Doch dieses ist schließlich für die Kunden der Kunden die Visitenkarte des Unternehmens, egal ob es sich hierbei um einen komplexen Online-Shop, einen Blog oder eine klassische Unternehmens-Website handelt. Nachdem also sämtliche Feedbackrunden geschafft sind (und somit auch einige Pläne wieder umgeworfen wurden) geht es endlich um den Kern für unsere Digital Presences Abteilung: das Coden.
Coding makes the world go round
Dabei werden am Montag bei einem wöchentlichen Kick-Off Termin die zu erledigenden Tasks besprochen, die dann am Freitag noch einmal einem Review unterzogen werden. Bei umfangreichen Projekten mit vielen Teilnehmern kommen noch täglich 5 bis 10 Minuten Standups dazu. Welche Arbeiten sind vielleicht liegen geblieben? Wird noch etwas vom Kunden oder vom Key Account Management gebraucht? Ist alles in der Qualität vorhanden, mit der die Entwickler arbeiten können? So entsteht Woche für Woche Codezeile um Codezeile – die Überwachung des Quellcodes wird bei uns über Git geregelt, eine freie Software, die sich um die verteilte Versionsverwaltung von Dateien kümmert.
Der Vorteil besteht in der Versionisierung – jeder Entwickler kann so effizient am Code arbeiten, ohne dem anderen im Weg zu sein. Fertiggestellter Code kann im Anschluss in den Branch des Projekts übernommen werden. Auch das Projektmanagement wird bei uns mittels Tool geregelt – übergeordnet über alle Units arbeiten wir mit Trello, das uns nicht nur dabei unterstützt den Milestone-Plan im Überblick zu behalten, sondern auch Leistungen aus anderen Units mit in das Projekt einfließen zu lassen. Wird beispielsweise Content gebraucht, so stellt Aleks in Trello einen Request, damit nicht nur jedes Teammitglied Bescheid weiß, sondern der Task auch fristgerecht von der beauftragten Person erledigt wird.
Qualitätssicherung: Freeze Phase vor dem Going-Live
Der weitere Prozess beim Website-Relaunch besteht bei jedem Modul sowohl im Unit-Testing als auch in der Qualitätssicherung. Bevor ein Modul fertiggestellt ist, muss es sorgfältig getestet werden, um etwaige Bugs zu fixen und dem internen Qualitätsanspruch gerecht zu werden. Erst nach dieser erneuten Überprüfung geht das Modul an den Kunden. Ab diesem Zeitpunkt schaltet sich wieder das Key Account Management ein, das dankenswerterweise Feedbackrunden mit dem Kunden koordiniert und das Feedback gebündelt an die Digital Presences Unit übergibt.
Diese arbeitet wiederum die entsprechenden Wünsche ein, das Modul geht wieder nach der Qualitätssicherung an den Kunden.
Bis zum Going-Live werden einige dieser Runden über die Bühne gegangen sein.
Schließlich kommen wir zur so genannten Freeze-Phase – jener Phase also, in der keine neuen Features mehr entwickelt werden und sich um intensives Testing und Bug-Fixing gekümmert wird.
Nun ist es so weit: Der Kunde ist mit dem Ergebnis zufrieden, unsere Entwickler haben wochenlange Arbeit in den Relaunch gesteckt – im besten Fall tatsächlich ohne Nachtschichten mit Pizza und Energy Drinks – und die Seite kann live gehen.
Doch halt: Wie geht das eigentlich? Entgegen der vielleicht weitverbreiteten Meinung, dass wir einen riesigen roten Startknopf drücken (obwohl wir den gerne hätten), braucht es für das Going-Live doch noch einiges an Arbeit.
Going live? Respect the freeze phase!
Am geplanten Tag des Going-Live wird der Letztstand der Betaversion von der Entwicklungsumgebung auf das Live-System übernommen. Alle Daten werden migriert und auch Ist-Daten, die noch vom alten System kommen, müssen übernommen werden. Außerdem müssen in dieser Phase die Domain-Pointings entsprechend angepasst werden.. So wird sichergestellt, dass die Kunden des Kunden automatisch von der alten auf die neue Domain weitergeleitet werden.
Ach ja, und da ist ja noch diese Sache mit der Operation am offenen Herzen. Egal wie gut vorbereitet der gesamte Relaunch-Prozess ist: am Tag des Going-Live kommen in letzter Sekunde ein paar Ideen und Anforderungen hinzu. Da wird „noch schnell“ Bildmaterial ausgetauscht oder eine Funktion angepasst … die Liste der Möglichkeiten ist schier unendlich.
Hier auch ein Appell an sämtliche Relaunch-Beteiligten: Respect the Freeze-Phase! Natürlich bekommen wir es auch am Tag des Going-Live hin „noch schnell“ irgendwelche vergessenen Wünsche entsprechend anzupassen. Aber die Wahrheit ist: wir machen es nicht gerne.
Das Fehlerpotenzial ist erstens relativ hoch und zweitens kann auch nach dem Going-Live noch gefeilt werden – und das ohne Stress und mit demselben Qualitätsanspruch, den wir während des gesamten Projektes an uns selbst stellen.
Je nach Umfang eines Website-Relaunches kann die Dauer der Umsetzung natürlich stark variieren. Hier eine pauschale Angabe zur Projektdauer zu machen wäre also nicht besonders seriös. Mittels eines strukturierten Debriefings nach Going-Live fließen die gewonnenen Learnings immer in den nächsten Relaunch hinein. So werden für zukünftige Projekte mögliche Stolpersteine schon vorab aus dem Weg geräumt.
Im nächsten Blogbeitrag zeigen wir was nach dem Going-Live alles passiert und ja – auch hier gibt es einige To Dos.