„Wir sind fertig!“ Drei Wörter, die bei unserem Website Relaunch ganz unterschiedliche Reaktionen ausgelöst haben: Erleichterung beim Dev-Team, Stolz beim UX/UI Designer und bei mir leichte Panik. Am 24. September 2026 habe ich bei der Agile Tour Vienna im Europahaus Wien über dieses Projekt gesprochen. Warum ich auf dem Event gesprochen habe? Ich bin keine Expertin für agile Methoden, sondern Head of Marketing bei LEAN-CODERS. In diesem Projekt war ich die Person, die am Ende mit dem Ergebnis arbeiten musste. Das ist die Geschichte dazu, samt der Frage, die mich seither beschäftigt: Wann ist etwas eigentlich fertig?
Kurz zur Einordnung: Die Agile Tour Vienna war mit rund 300 Teilnehmer:innen ausverkauft. Neben der Main Stage gab es eine Side Stage im Seminarraum, und dort war mein Slot. Zwischen 50 und 60 Leute haben den Weg zu mir gefunden. Für meinen allerersten Vortrag überhaupt war das mehr, als ich mir erhofft hatte. Ich war super happy. Adrenalin-Level: irgendwo zwischen Football-Kickoff und Live-Sendung.
Die Ausgangslage: neue Marke, neue Website, ein blinder Fleck
LEAN-CODERS hat sich letztes Jahr ein Rebranding gegönnt: neue Farben, neue Schriften, neues Logo und eine neue Markenwelt, die endlich zu unserer DNA passt. Wir sind nicht angepasst und nicht leise. Wir sind wild, frech, laut und provozieren auch gern mal. Das alte Design war dafür viel zu brav und ein wenig zu langweilig. Mit der neuen Marke musste also auch eine neue Website her. Ein Website Relaunch als internes Projekt, mit eigenen Leuten und kurzen Wegen. Easy peasy, dachten wir. Spoiler: Es wurde weder easy noch peasy.
Zum Einstieg in den Talk habe ich das Publikum per QR-Code gefragt, für wen wir die neue Website eigentlich bauen. Die Antworten waren bunt: Am häufigsten kam „Kunden“, dicht gefolgt von Firmen, KMUs, Kleinunternehmen und Jobsuchenden. Dazu Bewerber:innen, potenzielle neue Mitarbeiter:innen, Entwickler:innen und Software Engineers, CTOs, CFOs und Department Leads. Genannt wurden auch Start-ups, Selbstständige, Handwerksbetriebe und IT-ferne Unternehmen. Einige dachten an Investor:innen, die Presse oder die Konkurrenz. Und eine Antwort war besonders präzise: „Frauen zwischen 30 und 40“. Wir rätseln bis heute, was die Person mit unserer Website vorhat.
Unsere eigene Liste (die ich selbst erstellt habe) sah damals ganz ähnlich aus: CTOs, CIOs, CEOs, Tech Leads, Solution Architects, Head of IT, POs, PMs, Senior Devs und Bewerber:innen. Alles richtig. Aber eine Zielgruppe hat gefehlt, im Saal genauso wie in unserem Projekt: die Redakteurin, die das System befüllt. Also ich.
Akt 1: Das Team baut, ich schaue zu
In den Weeklys mit UX/UI-Design und Development habe ich Figma-Designs gesehen. Ganze Unterseiten, sauber modular aufgebaut. Wir haben pro Seite über Funktionen und Module gesprochen. Das CMS habe ich in dieser Zeit kein einziges Mal geöffnet.
Rückblickend war das der Kern des Problems. Ich habe schöne Bilder gesehen, und meine Erwartungen sind mit jedem Weekly gewachsen. Gleichzeitig wusste ich nicht, was ich überhaupt fragen soll. Wenn man ein System nie angefasst hat, weiß man nicht, was man nicht weiß.
Akt 2: Das böse Erwachen bei der Übergabe
Tag 1 der Übergabe: „Wir sind fertig. Meld dich, wenn du Hilfe brauchst.“
Die Startseite war vorhanden, die restlichen Seiten nicht. Ich hatte das Figma-Design im Kopf und saß vor der Oberfläche von Strapi, unserem Headless CMS. Schon am Cover der Startseite bin ich gescheitert: Eine Einstellung war falsch, und die Komponente ist verschwunden. Ich habe erst einmal gar nichts gesehen. Weiß ist ja auch eine Farbe.
Es gab eine Dokumentation, eine umfangreiche Confluence-Seite mit 5.946 Wörtern. Das ist fast der Umfang einer technischen Bachelorarbeit. Gut gemeint, aber im Zeitdruck nicht die Hilfe, die ich gebraucht hätte.
Warum ich nicht einfach gefragt habe? Habe ich, aber jedes Modul funktionierte anders. Es gab 48 Module, allein zehn verschiedene Grid-Module. Irgendwann hatte ich das Gefühl, alle zehn Minuten nachzufragen, und dachte mir: „So doof kann ich doch nicht sein.“ Dazu kamen asynchrone Arbeitszeiten und eine Deadline, die sich nicht verschieben ließ.
Auf dem Papier hatte ich 14 Arbeitstage für den Content. In der Realität gingen zwei Tage für das Verstehen des Systems drauf, zwei Tage für die Migration auf die Live-Umgebung und zwei Tage fürs Umschreiben, weil parallel eine neue Sales-Strategie mit zwölf neuen Services kam. Am Ende waren es rund 155 Stunden in drei Wochen für Contenterstellung, Seitenaufbau und Einpflegen, neben meinen anderen Aufgaben. Zum Vergleich: Ein Arbeitsmonat hat etwa 173 Stunden. Entstanden sind 23 Seiten.
Die Zeitauswertung aus unserer Projekt-Retro zeigt das Ungleichgewicht deutlich. Von 6,6 Monaten Gesamtdauer entfielen 38 % auf Design, 53,2 % auf die Umsetzung und 8,8 % auf den Content. Das Verhältnis von Development zu Content lag bei 4,9 zu 1, also eher wie bei einer App als bei einer Website. Der Content war quasi der Beilagensalat neben dem Schnitzel: eingeplant, aber nie die Hauptsache. Die Feedback-Schleifen mit Stakeholdern wurden durch den Zeitdruck reduziert oder fielen ganz weg. Eine denkbar schlechte Voraussetzung, um Stakeholder-Erwartungen abzugleichen.
Akt 3: Das etwas andere Happy End
Die Geschichte endet trotzdem gut, nur anders als gedacht. Aus Frust wurde Ownership. Ich kenne das System heute in- und auswendig, weil ich mich durchkämpfen musste.
Technisch ist die Website ganz vorne dabei: unter 0,5 Sekunden Ladezeit, 100/100 im Lighthouse SEO Score und 100/100 im Lighthouse Accessibility Score. Sie lädt tatsächlich so schnell, dass wir Page-Transitions einbauen mussten, damit das menschliche Auge mitkommt. Luxusprobleme. Wir arbeiten an einer Selbsthilfegruppe.
Die wichtigste Erkenntnis kam aber aus der Retro: An dem Projekt waren sechs Personen beteiligt, von UX/UI-Design über Marketing, SEO/GEO und Development bis zu unserem COO als Stakeholder. Das waren auch sechs unterschiedliche Bedeutungen von „fertig“. Niemand hat etwas falsch gemacht. Wir haben nur nie gemeinsam festgelegt, was „fertig“ heißt.
Definition of Done in Scrum: kurz erklärt
In Scrum beschreibt die Definition of Done, welchen Zustand ein Inkrement erreichen muss, damit es als abgeschlossen gilt. Sie ist eine gemeinsame, verbindliche Vereinbarung im Team, zum Beispiel: Code reviewed, getestet, dokumentiert, deployed. Solange ein Punkt offen ist, ist die Arbeit nicht „done“.
Die Stärke der Definition of Done ist Transparenz. Alle wissen, was „fertig“ bedeutet. Ihre typische Schwäche zeigt unser Projekt: Sie wird meist aus Sicht des Teams geschrieben, das baut, und nicht aus Sicht der Menschen, die danach damit arbeiten.
Wann ist ein Projekt wirklich fertig?
Für das Dev-Team war das Projekt fertig, als der Code lief. Für das Design, als die Komponenten dem Figma-Entwurf entsprachen. Für mich wäre der Projektabschluss erst erreicht gewesen, als ich selbstständig eine Seite bauen konnte, ohne Angst, etwas kaputtzumachen. Oder kann eine Webseite überhaupt jemals "fertig" sein?
Alle Sichtweisen stimmen. Genau deshalb reicht technische Fertigstellung als Kriterium nicht aus, sobald ein Projekt an jemanden übergeben wird. Ein Projekt ist erst dann wirklich fertig, wenn die Menschen, die es übernehmen, damit arbeiten können.
Lessons Learned: fünf Dinge, die ich heute anders machen würde
- Fertig ≠ fertig. Sechs Beteiligte, sechs Bedeutungen. Wer nicht explizit klärt, was „fertig“ heißt, klärt es spätestens bei der Übergabe, und zwar schmerzhaft.
- Kund:innen wissen nicht, was sie nicht wissen. Ich konnte keine Fragen zum CMS stellen, weil ich es nie gesehen hatte. Vorausschauende Kommunikation entschärft das: Zeigt das System früh, auch wenn noch nicht alles fertig ist.
- Kund:innen sprechen eure Sprache nicht. Slug, metaRobots, Edge to Edge: für euch Alltag, für andere Fremdwörter. Ich dachte bei „Slug“ lange an eine Nacktschnecke. Ist es übrigens auch. Übersetzt es, bevor jemand danach fragen muss.
- Kontrolliertes Failing ist euer Freund. Lasst Kund:innen in einer sicheren Umgebung Fehler machen. Wer eine Komponente einmal auf Staging „kaputt“ gemacht und wieder repariert hat, verliert die Angst vor dem Live-System.
- Formuliert eure Zielgruppe so detailliert wie möglich. Dazu gehören nicht nur die Besucher:innen der Website, sondern auch die Redakteur:innen, die das System täglich betreuen.
Definition of Done Beispiel: drei Kriterien, die bei uns gefehlt haben
Mein Vorschlag aus dem Talk ist keine neue Definition of Done, sondern eine Erweiterung um Endanwender-Kriterien. Als Definition of Done Beispiel für jedes Projekt, das am Ende übergeben wird:
- Onboarding hat stattgefunden. Nicht nur angeboten, sondern als fixer Teil des Projekts eingeplant.
- Die Dokumentation wurde übergeben, und zwar bevor die Kundin oder der Kunde startet, nicht parallel zur Deadline.
- Ownership ist etabliert. Die Person, die übernimmt, hat selbst eine Seite oder einen Datensatz gebaut und durch kontrolliertes Failing gelernt.
Erst wenn diese drei Punkte erfüllt sind, ist das Projekt „done“.
Website Relaunch Checkliste: Was vor der Übergabe erledigt sein muss
Aus unseren Lessons Learned ist eine kurze Liste entstanden, die ich jedem Team vor dem Go-live empfehle:
- Redakteur:innen sind als eigene Zielgruppe definiert
- Content wurde von Anfang an mitgeplant (Content first), inklusive Keyword-Strategie für SEO und GEO
- Zeit für Content ist realistisch eingeplant, nicht als Restposten nach der Entwicklung
- Das CMS wurde der Redaktion schon während der Entwicklung gezeigt
- Fachbegriffe im System sind erklärt
- Es gibt eine Testumgebung zum gefahrlosen Ausprobieren
- Feedback-Schleifen mit Stakeholdern sind fix eingeplant, auch unter Zeitdruck
- Alle Beteiligten haben gemeinsam festgelegt, was „fertig“ bedeutet
Fazit: Fertig ist, wenn es für alle fertig ist
Unser Website Relaunch war technisch ein Erfolg und menschlich eine Lektion. Die Website ist schnell, barrierearm und gut auffindbar, und sie wird laufend weiter optimiert, denn eine Website ist nie ganz abgeschlossen. Mitgenommen habe ich vor allem eines: „Fertig“ ist keine Eigenschaft eines Produkts, sondern eine Vereinbarung zwischen Menschen. Wer diese Vereinbarung früh trifft und die Menschen mitdenkt, die am Ende damit arbeiten, erspart sich viel Frust.
Und falls ihr euch gerade fragt, ob euer Projekt wirklich fertig ist: Fragt die Person, die es übernehmen muss. Und bringt Kaffee mit.
Steht bei euch ein Website-Projekt an? Wir denken die Übergabe von Anfang an mit.
