Eat your own Continuous Relaunch

oder warum wir unsere eigene Website solange nicht gebacken bekommen haben

Laptop im mit Aufkleber

Ihr kennt das: »Lehrers Kinder, Pfarrers Vieh, gedeihen selten oder nie.« Und dann war da noch die Website der Digitalagentur … Ich denke, Ihr wisst, worauf ich hinaus will.
An dieser Stelle daher ein ganz offenes Bekenntnis. Ja, auch wir haben uns mit unserem eigenen Website-Relaunch im letzten Jahr (und dem davor) schwer getan. Dabei haben wir doch die Experten im Haus, machen solche Projekte regelmäßig und wissen sogar ziemlich genau was wir wollen. Dennoch präsentieren wir uns bis heute mit einer nicht responsiven Website im Netz. Hashtag an uns selbst: #fail.

Wie wir diesem Missstand nun zu Leibe rücken und das Projekt endlich zum Abschluss bringen werden, davon wollen wir in einer kleinen Blogserie berichten. Schonungslos offen und schonungslos ehrlich.

Kapitel 1 – Warum geht's eigentlich nicht los?

Nachdem unser Relaunch im letzten Jahr nicht live gehen konnte, haben wir uns zuerst mal die Frage gestellt, was uns eigentlich gehindert hat.

1.) Unser Erfolg stand uns im Weg. What?!?!?

Rauchender Ofen

Wir folgen einer ungeschriebenen Regel – die lautet: »Kundenprojekte gehen vor eigenen Projekten«. Diese kaufmännisch sinnvolle Regel stand uns beim Projekt Relaunch immer wieder im Weg. Denn dadurch, dass wir mit Kundenprojekten weitgehend ausgelastet waren, gab es immer nur kleine Zeitfenster, in denen einzelne Personen nebenbei oder nur kurzzeitig an unserem Relaunch gearbeitet haben. Wir hätten es wissen können: auf dieser Basis gedeihen weder Teamgefühl noch Projekteffizienz. Kurz: Viel Rauch. Wenig Feuer.

Wie machen wir es in Zukunft also besser? Wir haben mittlerweile ein festes Web-Relaunch-Team gebildet. Und das trifft sich regelmäßig und hat ein festes Zeitkontingent, das nicht mit der Arbeit an Kundenprojekten konkurriert. Und siehe da …

2.) Zu früh, zu viel gewollt

Temperaturanzeige

Der Wunsch, auf der eigenen Website möglichst viel von dem zu zeigen, was man kann, klingt in der Theorie gut, führt in der Praxis aber schnell zu einem Feature-Overload – wird zum Fass ohne Boden, an dessen Ende viel Halbgares steht.

Auch das wollen wir diesmal besser machen: lieber das Projekt mit einigen wenigen Features starten, diese dafür aber alle bis ins Ziel bringen als umgekehrt. Features nachliefern ist ja jederzeit möglich – Continuous Relaunch eben. So empfehlen wir das ja auch unseren Kunden.

Soll heißen: Klar priorisieren und entscheiden, was für den Livegang wirklich wichtig ist. Und Fragen stellen. Braucht eine schlanke Agentur-Website eine leistungsfähige Suche? Braucht es wirklich 30 Referenzen oder genügen nicht auch einige wenige? Muss jedes Bild von Anfang an perfekt und selbstgemacht sein oder darf es auch mal Stock sein?

3.) Das Rad wird nicht runder

Teigkugeln

Eng verknüpft mit Punkt 2.) ist auch dieser Punkt. Wenn man (zu) viel will, will man natürlich auch keine Einschränkungen hinnehmen und verzichtet deshalb schnell mal auf ein sinnvolles, aber irgendwie limitierend empfundes Framework. Damit stehen einem zwar alle Möglichkeiten offen – dummerweise muss man dann aber auch das Meiste von Grund auf neu anlegen. Das kostet immer viel Zeit und fast immer auch Nerven, die man an anderer Stelle besser gebraucht hätte. Als wäre das Rad beim erneuten erfinden jemals runder geworden.

Diesmal erfinden wir nicht neu, diesmal nutzen wir das t3kit-Paket von Pixelant (Tack så mycket Robert, för att göra denna Open Source!). Ein Framework dessen Enwticklung wir schon länger beobachten und begleiten. So entwicklen wir unseren neuen Webauftritt natürlich basierend auf t3kit und wir können Euch schon so viel verraten ++ SPOILER ++ das war eine hervorragende Entscheidung! Mehr dazu in einem nachfolgenden Artikel mit dem Schwerpunkt »t3kit«.

4.) Alles anders – weil es geht

Chili Cayenne Extrem

Hat man – so wie wir – den Luxus, jede Menge hochkarätige Entwickler im Haus zu haben, will man auch gerne etwas Außergewöhnliches zeigen. Deshalb entstehen schnell spannende Ideen und komplexe Features, die sich nicht mit Standardmitteln umsetzen lassen. Diese Features sind zwar cool und außergewöhnlich – aber sie sind auch heldenhafte Blocker, wenn es um Livegänge geht.

Konsequenterweise müssen wir uns die ehrlich Frage stellen, ob diese Features unseren Besuchern so wichtig sind, dass sich Ihre Umsetzung auch lohnt. Und falls wir uns dann dafür entscheiden, gehören komplexe Features bei einem Continuous Relaunch besser in einen späteren Release und nicht schon in den ersten Wurf.


Auf einen Blick

An dieser Stelle möchte ich den Beitrag für heute abschließen und noch einmal kurz unsere Lösungsansätze zusammenfassen:

  • Klare Priorisierung
  • Komplexität reduzieren
  • Ein passendes Framework als Basis auswählen (z. B. t3kit)
  • Standards nicht ohne klares Ziel anders umsetzen

Und so geht's weiter

Wie oben bereits geschrieben, ist dieser Artikel der Beginn einer Serie von Artikeln rund um unseren Website-Relaunch. Deshalb gibt es sicher noch etliche Themen, die hier nicht oder nur unzureichend angeschnitten wurden. Gerne schreibe ich auch über Aspekte, die Euch ganz besonders interessieren. Schreibt mir dazu einfach in Euren Kommentaren, was Euch besonders interessiert!

Geschafft

Erfreulicherweise stehen wir heute bereits kurz vor dem tatsächlichen Relaunch. Aber darüber berichten wir im nächsten Artikel mit dem Arbeitstitel »Teil 2: Hurra, der Relaunch ist geschafft. Aber wie geht's jetzt weiter?«