Go/No-Go-Entscheidung: Entscheidungsbaum für die Release-Freigabe

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Entscheidungsbefugnissen

   Ersetzen Sie Release-Manager, Entwicklung und QS, Betrieb und Support sowie Geschäftsleitung durch die Rollen, die die Antwort in Ihrer Organisation tatsächlich halten. Die Bahnen benennen, wer antwortet, nicht wer beteiligt ist: Liefern drei Teams Nachweise zu einer Frage, entscheidet sie aber eine Person, gehört die Frage in deren Bahn. Führen Sie jede Bahn zusammen, für die Sie keine konkrete Person oder Rolle benennen können.

2. Schreiben Sie die Schwellenwerte auf, bevor Sie sie brauchen

   Der Baum ist nur so gut wie seine Prüfungen. Hinterlegen Sie an „Fehler innerhalb der Schwellenwerte?“ die Grenze je Schweregrad für den ausgelieferten Umfang, wer eine Überschreitung übersteuern darf und ob bekannte Altfehler aus früheren Releases mitzählen. Verfahren Sie mit „Alle Abnahmekriterien erfüllt?“ genauso, indem Sie jedes Kriterium beim Scope-Freeze als verbindlich oder wünschenswert markieren — dann wird das Gate nicht am Tag der Entscheidung neu verhandelt.

3. Definieren Sie, was ein getesteter Rollback bedeutet

   „Rollback erfolgreich getestet?“ sollte heißen: in einer produktionsnahen Umgebung geprobt, mit gemessener Dauer, mit einer namentlich benannten Person, die ihn ausführen kann, und einem schriftlichen Auslöser für die Entscheidung. Halten Sie die Datenfrage ausdrücklich fest, denn meist ist es eine Schema- oder Migrationsänderung, die „Ist die Änderung überhaupt umkehrbar?“ zu einem Nein macht — und dieser Zweig ist der einzige Weg zum Abbruch.

4. Machen Sie das bedingte Go und den Pilot zu echten Ergebnissen

   Ein Go mit Auflagen unterscheidet sich nur dann von einem einfachen Go, wenn jede Auflage einen benannten Verantwortlichen, eine Frist und eine ausgesprochene Konsequenz bei Nichterfüllung trägt. Ein Pilot-Go braucht eine definierte Kohorte, einen schriftlich festgehaltenen Anteil oder eine Kundenliste sowie das Kriterium für die Ausweitung. Tragen Sie beides in das Kommentarfeld von „Welcher Umfang wird freigegeben?“ ein, damit das Review nicht mit einem unbestimmten Nicken endet.

5. Trennen Sie No-Go und Abbruch

   No-Go heißt, dasselbe Release geht später live — es braucht also vor Ende der Besprechung einen neuen Termin und einen benannten Blocker. Abbruch heißt, das Release wird zurückgezogen und der Umfang geht zur Überarbeitung oder erneuten Bewertung zurück. Beide als getrennte Endpunkte zu führen verhindert, dass ein echter Abbruch als zweiwöchige Verschiebung erfasst wird, die sich still wiederholt.

6. Veröffentlichen Sie den Baum und prüfen Sie ihn nach jedem Gate

   Teilen Sie den Baum dort, wo das Review tatsächlich stattfindet — neben dem Nachweispaket — und halten Sie die Freigaben der in den Bahnen benannten Personen fest. Prüfen Sie nach jedem Release, ob eine Frage ohne Nachweis beantwortet wurde und ob ein benötigtes Ergebnis fehlte. Bewahren Sie die früheren Fassungen auf, damit erkennbar bleibt, wann sich die Kriterien geändert haben und warum.

Häufig gestellte Fragen

Worin unterscheidet sich ein Go/No-Go-Entscheidungsbaum von einer Release-Prozesslandkarte?

Eine Release-Prozesslandkarte beantwortet „Was passiert als Nächstes, und wer tut es?“. Sie zeigt Aufgaben in Reihenfolge über Bahnen hinweg — Scope-Freeze, Build, Test, Deployment, Monitoring — und behandelt die Go/No-Go-Entscheidung als einen einzigen Knoten. Ein Entscheidungsbaum beantwortet „Welche Option wählen wir, und wer entscheidet?“. Sein Rückgrat besteht aus Fragen statt aus Aufgaben, seine Zweige tragen Antworten wie Erfüllt, Darüber, Möglich oder Verweigert statt der nächsten Tätigkeit, und er endet in mehreren getrennten Ergebnissen, statt in einen einzigen glücklichen Pfad zurückzulaufen. Nutzen Sie beides: die Prozesslandkarte für den durchgängigen Ablauf unter /de/templates/software-release-prozess und diesen Baum für das Gate darin.

Welche Fragen gehören in eine Go/No-Go-Entscheidung?

Sieben decken die meisten Launches ab. Sind alle verbindlichen Abnahmekriterien erfüllt? Liegen die offenen Fehler innerhalb der vereinbarten Schwellenwerte je Schweregrad? Sind Abhängigkeiten und Dritte bereit? Wurde der Rollback getestet und nicht nur beschrieben? Sind Support und Betrieb für das erwartete Volumen geschult und besetzt? Ist das Änderungsfenster sowohl im Geschäfts- als auch im technischen Kalender frei? Liegt die Freigabe der Geschäftsleitung vor? Jede davon sollte aus Nachweisen beantwortbar sein, die vor der Besprechung gesammelt wurden — deshalb beginnt der Baum mit einem Nachweispaket und nicht mit der ersten Frage.

Wer trifft die Go/No-Go-Entscheidung?

Eine namentlich benannte Person sollte sie leiten, üblicherweise der Release-Manager oder wer den Produktivbetrieb verantwortet. Die nützliche Disziplin besteht aber darin, jede einzelne Frage zuzuordnen statt der Gesamtentscheidung. Entwicklung und QS beantworten Abnahme und Fehler, Betrieb und Support beantworten Rollback und Besetzung, der Release-Manager beantwortet Abhängigkeiten und Änderungsfenster, die Geschäftsleitung beantwortet die Freigabe. So aufgeschrieben besteht die Aufgabe der Leitung darin, den Baum durchzugehen und das Ergebnis festzuhalten, nicht jede Frage persönlich zu entscheiden. Festzuhalten, wer was beantwortet hat, zählt auch als Nachweis: Rahmenwerke wie SOC 2 erwarten, dass Änderungen autorisiert, getestet, freigegeben und dokumentiert werden, und ein Entscheidungsbaum mit benannten Befugnissen zeigt genau das.

Wann sollte ein Go/No-Go in einem Go mit Auflagen enden statt in einem No-Go?

Wenn der offene Punkt das Release nicht gefährdet und jemand ihn nach dem Launch verantwortet. Ein Go mit Auflagen ist nur dann ein echtes Ergebnis, wenn jede Auflage einen benannten Verantwortlichen, eine Frist und eine ausgesprochene Konsequenz bei Nichterfüllung hat; sonst ist es ein einfaches Go mit zusätzlichem Papier. Reservieren Sie das No-Go für alles, was Nutzer ungeschützt oder ohne Unterstützung zurücklassen würde. In diesem Baum führen blockierende Abnahmelücken, ein nicht vereinbarter Fehler oberhalb der Schwelle, eine harte Abhängigkeit, ohne die nicht ausgeliefert werden kann, ein nicht bereiter Support und ein Konflikt im Änderungsfenster allesamt zum No-Go mit neuem Termin.

Worin unterscheiden sich No-Go und Abbruch?

No-Go heißt, das Release wird verschoben: derselbe Umfang geht zu einem neuen Termin live, sobald der Blocker beseitigt ist. Abbruch heißt, es wird zurückgezogen und der Umfang geht zur Überarbeitung oder erneuten Bewertung zurück, ohne Termin. Die Trennung ist wichtig, weil ein Release, das sich überhaupt nicht zurücknehmen lässt, oder eines, bei dem die Geschäftsleitung die Freigabe aus geschäftlichen Gründen verweigert, nicht auf eine Behebung wartet — es als Verschiebung zu erfassen führt dazu, dass dasselbe Review vierzehn Tage später mit denselben Nachweisen erneut stattfindet.

Wie begrenze ich einen Launch auf eine Pilot- oder Canary-Gruppe?

Behandeln Sie das als Ergebnis der Entscheidung und nicht als Kompromiss, der im Raum entsteht. In diesem Baum verzweigt die letzte Frage, „Welcher Umfang wird freigegeben?“, nach Vollständig, Mit Auflagen und Nur Pilot — ein begrenztes Release wird also bewusst gewählt, nachdem jede Bereitschaftsfrage beantwortet wurde, und nicht als Ausweg vor einem No-Go. Definieren Sie vor dem Review, was ein Pilot in Ihrem Produkt bedeutet: welche Kohorte oder welcher Anteil, wie lange er läuft, was überwacht wird und welches Kriterium die Ausweitung freigibt.