Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Continuous Relaunch – 
Die einzige Konstante is...

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers. →

Continuous Relaunch – 
Die einzige Konstante ist die Veränderung

Meine Präsentation zur hallo.digital in Karlsruhe 2017

Sebastian Helzle

May 09, 2017

Transcript

25 slides
  1. Continuous Relaunch – 
 Die einzige Konstante ist die Ver

    ä nderung Sebastian Helzle hallo.digital Karlsruhe, 9.Mai 2017
  2. Übersicht • Motivation für den „Continuous Relaunch“ • Gefühlte Einbahnstraßen

    einer Webseite • Vorteile des „Continuous Relaunch“ • Achtung nicht vergessen • Zusammenfassung
  3. Motivation für den „Continuous Relaunch“ • Große Relaunches … •

    … sind aufwändig & teuer • … erfüllen nicht immer die gestellten Erwartungen • … gehen oft nicht auf Veränderung ein • … enthalten auch meist einen Rückschritt • … dienen auch einem Großreinemachen
  4. Gefühlte Einbahnstraßen einer Webseite • Technische Schulden zu groß •

    Zu viele Inhalte, die keiner p fl egen will • Bisheriges System unterstützt gewünschte Funktion X nicht • Zu langsam / zu alt • Keiner versteht mehr wie sie funktioniert • Erträge zu niedrig • Agenturwechsel
  5. „Technische Schulden zu groß“ • Mit einem Relaunch gehen auch

    gute Lösungen verloren • Ein Relaunch unter Zeitdruck bringt neue Schulden • Weniger Chancen um aus Fehlern zu lernen
  6. „Zu viele Inhalte, die keiner p fl egen will“ •

    Ein Relaunch verzögert das Problem nur • Es gehen auch gute Inhalte verloren • Wer entscheidet über gute und schlechte Inhalte? • Gefahren für SEO!
  7. „Bisheriges System unterstützt gewünschte Funktion X nicht“ • Oft gibt

    es andere Lösungswege • Open Source erlaubt Backports, externe Module, Microservices • Dieses Problem wird immer wieder auftreten • Unterstützt das neue System alle bisherigen Funktionen?
  8. „Zu langsam / zu alt“ • Umstellen auf bessere Hardware

    • Aktuelle Software verwenden • Problemanalyse durch Entwickler oder notfalls Berater • Bei viel Eigenentwicklung wird das Problem durch einen Relaunch nicht zwingend gelöst
  9. „Keiner versteht mehr wie sie funktioniert“ • Erstmal aus der

    Vergangenheit lernen • Konzepte prüfen • Bei einem Relaunch Gefahr groß, dass Funktionen fehlen • Ggf. lieber Stück für Stück Probleme lösen
  10. „Erträge zu niedrig“ • Auswirkungen eines Relaunches schwer zurückzuverfolgen •

    Relaunch kann die Situation verschlimmern • Grundsätzliche Analyse notwendig
  11. „Agenturwechsel“ • Fremdcode wird oft als „schlecht“ empfunden • Relaunch

    als emotionaler Abschluss mit der Vergangenheit • Ignoranz gegenüber der Vergangenheit auch gefährlich
  12. Vorteile des „Continuous Relaunch“ • Frühzeitig reagieren auf … •

    … die Wünsche der Benutzer • … die Konkurrenz • … interne Interessen • Festigt das Verhältnis zwischen Kunde und Agentur bzw. Team • Schlechtes wird gut & Gutes wird noch besser
  13. Vorteile des „Continuous Relaunch“ • Erlaubt auch mal ein „Ausprobieren“

    von Ideen (Prototypen & A/B-Tests) • Neue Funktionen in 14 Tagen mit agiler Entwicklung • Geringe Gefahr für die Sichtbarkeit (SEO) • Technische Lösungen werden immer wieder optimiert • Weniger Zeitdruck!
  14. Achtung nicht vergessen • Erwartungsmanagement ist wichtig, es fehlt der

    „Big Bang“ • Budgetmanagement & Ziele dürfen nicht aus dem Auge verloren werden • Meilensteine feiern! • Mehr Beratung notwendig • Auch die eigenen Benutzer einbinden (Redakteure, Webmaster, …)
  15. Ein Relaunch ist manchmal trotzdem angesagt • Bis dahin hilft

    der „Continuous Relaunch“ um … • … Komplexität zu mindern • … kritische Features mit hohem Wert transportabel zu machen • … alte Zöpfe abzuschneiden • … Prototypen auszuprobieren • … Wissen aufzubauen • … Ziele zu festigen • … vielleicht den Relaunch zu vertagen ;-)
  16. Zusammenfassung • Große Sprünge nicht ungefährlich — kleine Schritte führen

    auch zum Ziel • Ein „Geht nicht“ lieber nochmal hinterfragen • Ziele einer Webpräsenz immer wieder überprüfen • Lieber frühzeitige Erträge statt ungewissen „Big Bangs“

More Decks by Sebastian Helzle

Other Decks in Technology