Das Release Management skizziert die entscheidenden Phasen deines Projekts, von der Entstehung der Idee über den Aufbau einer neuen Funktion bis hin zum Testen und Freigeben.
Der Prozess muss sorgfältig gehandhabt werden. Schließlich lieferst du als Product Manager etwas an die Kunden, das du mühsam recherchiert hast und von dem du weißt, dass sie es brauchen. Du kannst jedoch nicht einfach ein Produkt veröffentlichen und hoffen, dass es erfolgreich ist. Die Planung des Releases ist eines der wichtigsten Elemente, um einen erfolgreichen Launch sicherzustellen und deinen Endkunden ein hochwertiges Produkt zu bieten.
Der folgende Guide wird den Release-Prozess von der Planung bis zur Ausführung anhand verschiedener Deployment-Strategien basierend auf deinen Zielen und Anwendungsfällen erläutern.
Was ist Release Management?
Release Management ist dein Managementprozess zur Steuerung des Software Development Lifecycles – von der Planung über das Testing bis hin zum Release.
Es hilft deinem Team, auf Kurs zu bleiben und auf ein gemeinsames Ziel hinzuarbeiten, indem sichergestellt wird, dass jedes Teammitglied auf einer Linie ist.
Einfach gesagt stellt der Release-Management-Prozess sicher, dass dein Produkt bereit für die Produktion und den Release an die Nutzer ist.
Wenn es richtig gemanagt und implementiert wird, führt es zu qualitativ hochwertigen Releases und erhöhter Produktivität, sodass du häufiger und mit weniger Risiko releasen kannst.
Im Herzen einer effektiven Agile Roadmap steht das Feature Release Management, das die Entwicklung in Sprints unterteilt und benutzerzentrierter ist.
Weiterlesen: Die wichtigsten Elemente, die du in deiner Agile Release Planung berücksichtigen solltest.
Phasen des Release Managements
Der Release-Management-Prozess ist dem Software Development Process sehr ähnlich, also dem Software Development Life Cycle (SDLC), der aus den folgenden Schritten besteht:
- Planen
- Bauen
- Testen
- Deployen
- Überprüfen
Am Anfang plant der Product Manager die neue Funktionalität, indem er ein Problempunkt der Kunden identifiziert und festlegt, wie eine Funktion das Problem lösen wird. Er beantwortet Fragen wie: Was wird dieses Release bewirken? Wie wird es genutzt werden? Und wer wird es nutzen?
Anschließend entwickelt der Product Manager eine Strategie und beginnt mit der Arbeit an der Produkt-Roadmap. Die Funktion wird dann durch die verschiedenen Developmentzyklen entwickelt und geführt.
Der Manager muss dann, je nach Anwendungsfall, Zielen und Budget, eine geeignete Release-Strategie festlegen.
Die Rolle eines Product Managers dreht sich also hauptsächlich um das Management von Product Releases. In diesem Guide werden wir erläutern, was wir unter Releases verstehen und welche Arten von Release- oder Deployment-Strategien Product Managern ermöglichen, ihre Produkte zu testen und zu optimieren, um die Kundenzufriedenheit zu maximieren.
Zuerst sammelt der Product Manager in der Planungsphase Feedback, um Ideen für eine neue Funktion zu entwickeln. Er bestimmt ein Kundenproblem und wie es durch diese neue Funktion gelöst werden kann.
In dieser Phase werden die Nutzer-Persona und die Wertigkeit festgelegt. Der Product Manager definiert KPIs, um den Erfolg des Produkts nach dem Release zu messen. Er entwickelt dann einen Plan, was für die Lieferung dieser neuen Funktion benötigt wird und legt das erwartete Release-Datum fest, basierend auf den folgenden Punkten:
- Zusammenstellung des Teams für den Aufbau der Funktion.
- Definition von Anforderungen und Endzielen.
- Erstellung einer Roadmap.
Von der Produktstrategie zur Produktlieferung: Planung eines Releases
Sobald eine Produktstrategie festgelegt wurde, ist der Aufbau eines Release-Management-Prozesses der nächste logische Schritt. Dieser Prozess erfordert eine sorgfältige Planung des Umfangs und der Phasen der Arbeit sowie das Festlegen klarer Erwartungen und Anforderungen.
Ein Release-Plan hilft jedem Teammitglied zu wissen, was es zu tun hat und wie der Zeitrahmen der Arbeit aussieht. Er legt die Prioritäten und den Ablauf des Projekts fest. Weitere Punkte, die in einem Release-Plan enthalten sein sollten, sind:
- Das Ziel des Produkts und die Roadmap
- Neue Features, die hinzugefügt werden sollen
- Arbeitsphasen
- Schätzungen zu den Deliverables
Die Product Roadmap ist ein wesentlicher Bestandteil, um den Erfolg deiner Produkte sicherzustellen. Sie wird die Strategie, Vision und Ziele skizzieren und als Leitfaden dienen, damit die verschiedenen beteiligten Teams diese Strategie umsetzen und alle auf Kurs bleiben.
Ein Product Manager ist daher dafür verantwortlich, eine priorisierte Liste von Features zu erstellen und zu definieren, die im Laufe der Zeit entsprechend den Zielen der Organisation entwickelt werden sollen. Diese Liste wird in der Regel in Zusammenarbeit mit dem Senior Management und anderen Stakeholdern erstellt.
Eine Agile Roadmap zu entwickeln, wird weitaus flexibler sein als eine traditionelle, da sie kürzere Zeitrahmen und Anpassungen ermöglicht, um sich ändernden Prioritäten gerecht zu werden.
In der Agile-Methodologie wird erwartet, dass der Product Manager regelmäßig neue Features bereitstellt, sei es vierteljährlich, monatlich oder sogar wöchentlich. Da eine Agile-Methode benutzerzentriert ist, wird der Erfolg anhand von User Feedback, Engagement, Conversion usw. gemessen.
Sobald der Release-Plan feststeht, wird die eigentliche Veröffentlichung geplant. Es gibt viele Release- oder Deployment-Strategien, die ein Product Manager je nach Zielen und geschäftlichen Anforderungen in Betracht ziehen sollte, wobei auch die Auswirkungen auf die Nutzer berücksichtigt werden müssen.
Welche Teams sind am Release-Prozess beteiligt?
Wie bereits erwähnt, erfordert ein erfolgreiches Release die Unterstützung mehrerer Abteilungen. Daher muss das Product Team die Zusammenarbeit mit anderen Teams koordinieren:
- Product Team: Je nach Organisation kann es klein oder groß sein und besteht aus verschiedenen Rollen mit unterschiedlichen Verantwortlichkeiten, einschließlich Product Owners und Product Managers. Die Grenzen zwischen diesen beiden Rollen verschwimmen oft, aber es gibt dennoch Unterschiede zwischen einem Product Manager und einem Product Owner.
- Development: Das Product Team arbeitet eng mit den Developern zusammen, um die Anforderungen des Releases zu erarbeiten und die Fristen für jede Phase des Releases festzulegen. Sobald die Anforderungen definiert sind, erstellen die Entwickler die Dokumentation und entwerfen die Funktionalität.
- Sales: Dieses Team benötigt Schulungen und muss mit Materialien und Dokumentationen versorgt werden, um bereit zu sein, das Produkt zu verkaufen.
- Marketing: Das Marketing-Team hilft dabei, effektive Kommunikation rund um das Release zu entwickeln, um potenzielle Kunden über das Produkt aufzuklären und zu überzeugen, es auszuprobieren.
Es gibt auch andere, technische Rollen im Release Management, neben den Product Managern:
- Release Manager: Sie spielen eine zentrale Rolle im Release Management, indem sie alle Aspekte des Software Delivery Lifecycles verwalten.
- DevOps Engineers: Sie überwachen die Veröffentlichung neuen Codes.
- Site Reliability Engineers: Sie schaffen eine Brücke zwischen IT und Operations, entwickeln skalierbare und zuverlässige Softwaresysteme und behalten mögliche Systemausfälle im Blick.
Auswahl einer Deployment-Strategie
Es gibt verschiedene Methoden, um neue Features in die Produktion zu bringen. Die Wahl der richtigen Strategie ist entscheidend und hängt von zahlreichen Faktoren ab, einschließlich der Auswirkungen auf die Nutzer und die Anwendungsfälle.
Es gibt sogenannte „Big Bang“-Deployments, bei denen die gesamte Anwendung auf einmal bereitgestellt wird, was längere Entwicklungs- und Abschlusszyklen erfordert. Solche Deployments sind jedoch im modernen Software Development aufgrund der hohen Risiken, wie Ausfälle und nahezu unmögliche Rollbacks, nicht mehr praktikabel.
Daher konzentrieren wir uns in diesem Guide auf vier Strategien innerhalb der phasenweisen Deployment-Strategien, die von Organisationen und modernen Teams häufig verwendet werden.
Blue-Green Deployment
Blue-Green Deployment ist eine Technik, bei der zwei Produktionsumgebungen, Blue und Green, verwendet werden, und der Traffic wird an eine dieser Umgebungen geleitet, sobald Änderungen bereit sind.
Bei dieser Art des Deployments sind also zwei Produktionsumgebungen vorhanden, aber nur eine ist aktiv, während die andere im Leerlauf bleibt. Diese inaktive Umgebung dient als Backup, falls Probleme in der aktiven Umgebung auftreten, sodass du schnell zur inaktiven Umgebung zurückwechseln kannst, während das Problem behoben wird.
Diese Praxis bietet viele Vorteile, einschließlich schneller Releases und einfacher Rollbacks. Allerdings erfordert Blue-Green Deployment viele Ressourcen, um zwei Produktionsumgebungen zu warten, insbesondere für Product Manager, die spezielle Software benötigen, um die Leistung ihrer Features zu überwachen.
Erfahre mehr in unserem Blog über die Vor- und Nachteile von Blue-Green Deployment, um herauszufinden, ob es eine praktikable Option für dein Team ist.
Canary Deployment
Canary Deployment ist eine Deployment-Strategie, die das Risiko neuer Releases reduziert, indem sie zunächst nur an einer Teilmenge von Nutzern getestet wird, bevor sie allen anderen zur Verfügung gestellt wird.
Das bedeutet, dass du einen Prozentsatz der Nutzer auswählen kannst, um das Release basierend auf bestimmten Attributen zu testen. Wenn keine Probleme entdeckt werden, kannst du das Release schrittweise an den Rest deiner Nutzer ausrollen.
Canary Deployment unterscheidet sich von Blue/Green Deployment dadurch, dass durch erstere gezieltere Releases ermöglicht werden, was besonders vorteilhaft ist, wenn das Release besonders risikobehaftet ist. Bei Blue/Green-Deployment handelt es sich mehr um eine „Alles oder nichts“-Strategie.
Erfahre mehr: Alles, was du über Canary Deployments wissen musst.
Ring Deployment
Ring Deployment ermöglicht es, neue Features schrittweise an verschiedene Benutzergruppen einzuführen, um die Auswirkungen zu minimieren. Diese Benutzergruppen werden als eine sich ausdehnende Reihe von Ringen dargestellt, daher der Name.
Diese Technik beginnt mit einer kleinen Gruppe von Nutzern, wie zum Beispiel internen Nutzern, und wechselt dann allmählich zu größeren Gruppen, bis du zunehmend Vertrauen in das Release gewinnst und es schließlich an alle deine Nutzer ausrollen kannst.
A/B -Testing
A/B-Testing ist eine gängige Release-Strategie, die von Product Managern verwendet wird, um Features in der Produktion mit geringem Risiko zu testen. Es handelt sich um eine Strategie, die besonders für Experimente genutzt wird, um zu beobachten und zu testen, welche Variante am besten bei den Nutzern ankommt.
A/B-Tests werden im Feature Testing eingesetzt, bei dem Product Manager ihre Ideen an der Zielgruppe testen, indem sie Daten zur Leistung der Features sammeln, um fundierte Entscheidungen zu treffen.
Bei diesem Test treten zwei Versionen eines Features oder Systems gegeneinander an. Basierend auf festgelegten KPIs wird die Version, die zu mehr Conversions oder Umsatz usw. geführt hat, als die erfolgreichere Variante angesehen, und alle Nutzer werden dann auf diese Version geleitet.
Diese Methode ist besonders nützlich für Product Manager, da sie es ihnen ermöglicht, ihre Ideen an ihren Zielkunden zu testen, jedoch mit geringerem Risiko. Sie können verschiedene Varianten weiter testen, bis sie die perfekte Lösung basierend auf dem Feedback der Live-Nutzer gefunden haben.
Schrittweises Release durch phasenweise Rollouts
Wie wir gesehen haben, können Deployments entweder komplett oder schrittweise in Form von progressiven Rollouts erfolgen, wie bei Canary Deployments und A/B-Tests. Erfahre in unserem Guide zu progressiven Rollouts, wie sie dir helfen können, schnelle Releases zu liefern und warum sie ein wesentlicher Bestandteil der Agile-Methode sind.
Das Release Management führt ein Produkt von der Entwicklung über das Testing bis hin zur Produktion.
Die Implementierung von Feature Flags im Release-Management-Prozess kann dabei helfen, noch schnellere und qualitativ hochwertigere Releases mit noch weniger Risiko zu ermöglichen. Durch den Einsatz von Feature Flags können alle neuen Änderungen bereitgestellt und von deinen Kunden genutzt werden, während unfertige Änderungen verborgen und durch ein Flag gekennzeichnet bleiben, bis sie abgeschlossen sind.
Mit Feature Flags entscheidest du, wann und für wen die Änderungen verfügbar sind, und erhältst so vollständige Kontrolle.
Alle oben genannten Deployment-Strategien können die Nutzung von Feature Flags integrieren, sei es bei prozentualen Releases in Form von Canary Deployments oder beim Freigeben oder Verbergen bestimmter Features in einem Ring Deployment.
Genauso wie Feature Flags bei schnelleren Deployments helfen, sind sie auch entscheidend, wenn du schnelle Rollbacks durchführen musst, falls Bugs entdeckt werden, die behoben werden müssen, bevor du sie allen anderen zur Verfügung stellst. Solche schnellen Rollbacks geben Product Managern mehr Kontrolle über den Deployment-Prozess und ermöglichen es ihnen, neue Features mit größerem Vertrauen zu testen, um wertvolles Feedback zur Verbesserung ihres Produkts zu sammeln. Finde heraus, wann du ein Feature Rollback durchführen musst.
Wahl der richtigen Release-Strategie
Wie wir gesehen haben, gibt es verschiedene Möglichkeiten, eine neue Version einer Anwendung oder neue Features zu veröffentlichen. Welche Strategie du wählst, hängt von deinen Zielen und deinem Budget ab.
Die gewählte Release-Strategie wird daher von vielen Faktoren beeinflusst:
- Die Bedürfnisse deiner Kunden
- Die Art des einzuführenden Features
- Die Ziele oder Zahlen, die du mit dem Release erreichen möchtest
- Verfügbare Ressourcen
Wenn du beispielsweise über ausreichende Ressourcen verfügst, um zwei Umgebungen zu verwalten, wie es bei Blue-Green Deployments der Fall ist, bietet dies dir erhebliche Vorteile bei gleichzeitig minimaler Downtime.
Wenn dein Budget und deine verfügbaren Ressourcen jedoch begrenzt sind und dein Release eher konfigurationsgetrieben ist, wäre eine Canary-Deployment-Strategie wahrscheinlich die beste Wahl.
Es wird auch stark von deinen Geschäftszielen abhängen. Wenn du zum Beispiel Änderungen mit möglichst wenig bis gar keiner Downtime ausrollen möchtest, ist Blue-Green Deployment eine sinnvolle Option. Wenn du hingegen deine Features an einer kleinen Nutzergruppe testen möchtest, könntest du zum Beispiel phasenweise Rollouts unter Verwendung von Feature Flags in Betracht ziehen.
Nach dem Release
Nach dem Release ist es wichtig, die Releases kontinuierlich zu überwachen, um mögliche Probleme sofort beheben zu können.
Drittanbieter-Dienste wie die Flagging-Funktionalität von AB Tasty bieten ein anspruchsvolles Kontrollpanel, welches es Teams außerhalb der Entwicklungsteams ermöglicht, die verwendeten Flags zu überwachen und auf Berichterstattung zuzugreifen, um festzustellen, ob das Release die zu Beginn des Experiments festgelegten KPIs erfüllt hat.
Solche fortschrittlichen Funktionen in einer Feature-Flagging-Plattform geben Product Managern mehr Zugriffskontrolle über Releases, ohne auf Entwickler angewiesen zu sein.
Feedback ist ein zentraler Bestandteil der Agile-Methode. Die Idee des Feedback Loops, also der Prozess des kontinuierlichen Sammelns von Feedback von Kunden und der entsprechenden Verbesserung des Produkts, stellt sicher, dass das Produkt, das du entwickelst, echten Mehrwert für deine Kunden liefert.
Warum Continuous Delivery für Product-Teams wichtig ist
Wie bereits erwähnt, sind häufige Releases das Herzstück der Agile-Methode. Daher ist es wichtig, ein Umfeld der kontinuierlichen Lieferung (Continuous Delivery) aufrechtzuerhalten.
Das bedeutet im Wesentlichen, dass Teams Produkte in kürzeren Chargen und Zeiträumen veröffentlichen, um Produkte schneller an die Verbraucher zu bringen. Dies ermöglicht es ihnen, wertvolles Feedback zu sammeln, um ihre Produkte kontinuierlich zu verbessern.
Ähnlich wird eine DevOps-Kultur oft mit Continuous Delivery in Verbindung gebracht, da beide Konzepte darauf abzielen, die Zusammenarbeit zwischen Entwicklern und Operations-Teams zu verbessern und beide automatisierte Prozesse im Software-Entwicklungsprozess nutzen, um schnellere und häufigere Releases zu erreichen.
Zusätzlich ist Continuous Deployment, das Continuous Integration und Continuous Delivery kombiniert, für Product-Teams ebenso essenziell, da es darauf abzielt, Software ohne menschliches Eingreifen bereitzustellen. Das bedeutet, dass es auf eine Reihe von automatisierten Prozessen angewiesen ist.
Erfahre mehr dazu, wie Continuous Deployment in agiles Product Management integriert werden kann.
Continuous Delivery ist für Product-Teams aus folgenden Gründen von entscheidender Bedeutung:
- Continuous Delivery ermöglicht es Product-Teams, ihre Produkte schneller auf den Markt zu bringen, was entscheidend ist, um auf die Anforderungen eines sich schnell verändernden Marktes zu reagieren.
- Durch häufigere Releases können Teams den Feedback Loop beschleunigen, anstatt auf eine vollständige Bereitstellung zu warten, bei der das Risiko höher ist. So können sie in kleineren Batches veröffentlichen und schneller auf Kundenfeedback reagieren.
- Das kontinuierliche Feedback von Zielkunden ermöglicht es, die Produkte zu verbessern und so Releases von höherer Qualität zu gewährleisten, die genau den Kundenanforderungen entsprechen.
Zusammenfassung
Als Product Manager hast du sorgfältige Schritte unternommen, um das richtige Produkt zu entwickeln. Daher musst du ebenso gewissenhaft vorgehen, wenn es veröffentlicht wird.
Um sicherzustellen, dass du einen erstklassigen Release lieferst, ist es unerlässlich, in der Produktion mit echten, aktiven Nutzern zu testen. Dies ist eine der wichtigsten Best Practices für jeden Product Manager.
Das Testen in der Produktion ermöglicht es dir, wertvolles Feedback von den Nutzern zu sammeln, die am meisten zählen. Dadurch kannst du das Produkt besser an die Bedürfnisse der Nutzer anpassen. Aber es geht nicht nur darum, das Produkt zu verbessern – du sammelst auch Ideen für zukünftige Releases und Features, die du vielleicht zuvor nicht in Betracht gezogen hast.
Erfahre mehr darüber, warum das Testen in der Produktion heutzutage ein wichtiger Bestandteil der Rolle eines Product Managers ist, indem du dir diesen Artikel ansiehst sowie eine humorvolle Herangehensweise an die Bedeutung des Testens in der Produktion, erklärt durch Memes.
