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

Was ist go/no-go-entscheidung: entscheidungsbaum für die release-freigabe?

Eine Go/No-Go-Entscheidung ist keine Phase in einem Workflow, sondern eine Beurteilung. Wenn ein Release das Freigabe-Gate erreicht, ist die Arbeit getan; übrig bleibt, die Nachweise gegen vorab vereinbarte Kriterien zu prüfen und ausdrücklich und dokumentiert auszusprechen, welches der benannten Ergebnisse gilt. Die meisten Teams haben diese Fragen irgendwo (in einer Checkliste, einem Runbook, einer wiederkehrenden Besprechungseinladung), aber sie stehen selten als Baum geschrieben. Deshalb sieht niemand, welche Antwort wohin führt, welche Frage ein hartes Stoppkriterium ist und welche lediglich eine Auflage anhängt, und wer überhaupt befugt ist, sie zu beantworten.

Diese Seite ist bewusst ein Entscheidungsbaum und keine Prozesslandkarte. Eine Prozesslandkarte beantwortet „Was passiert als Nächstes, und wer tut es?“: Aufgaben in Reihenfolge, Übergaben zwischen Teams, ein Hauptpfad mit angehängten Ausnahmen. Ein Entscheidungsbaum beantwortet „Welche Option wählen wir, und wer entscheidet?“: ein Rückgrat aus Fragen, die sich jeweils aus Nachweisen beantworten lassen, mit Zweigen, die nach der Antwort statt nach der nächsten Aufgabe benannt sind und in klar unterschiedenen Ergebnissen enden. Wenn Sie den durchgängigen Ablauf rund um dieses Gate brauchen (Scope-Freeze, Build und Test, Staging und UAT, Deployment, Smoke-Tests und Monitoring), nehmen Sie das Flussdiagramm zum Software-Release-Prozess unter /de/templates/software-release-prozess. Diese Seite ist die Nahaufnahme der einen Entscheidung darin.

Der Baum unten führt zwölf Fragen über vier Prüfphasen, und die Bahnen benennen, wer antwortet, statt Abteilungen abzubilden: Release-Manager, Entwicklung und QS, Betrieb und Support sowie Geschäftsleitung. Er endet in sechs verschiedenen Ergebnissen (Go, Go mit benannten Auflagen, ein begrenztes Go für eine Pilotgruppe, No-Go wegen nicht erfüllter Abnahmekriterien, No-Go mit neuem Termin und Abbruch), denn ein Review, das nur Ja oder Nein sagen kann, presst jede Teilbereitschaft in eine von zwei falschen Antworten. Die beiden No-Go-Ausgänge sind bewusst getrennt: am ersten Gate an unerfüllten Kriterien zu scheitern ist ein anderer Befund, als die Qualität zu bestehen und das Änderungsfenster zu verlieren.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Vier Bahnen nach Entscheidungsbefugnis statt nach Abteilungen (Release-Manager, Entwicklung und QS, Betrieb und Support sowie Geschäftsleitung) über vier Phasen: Nachweisprüfung, Qualitäts-Gate, Betriebs-Gate sowie Entscheidung und Ergebnis.
• Der Zweig zu den Abnahmekriterien: „Alle Abnahmekriterien erfüllt?“ antwortet Erfüllt oder Lücken, und Lücken führt zu „Ausnahme für die Lücken möglich?“: Möglich erfasst die Ausnahme samt Verantwortlichem und kehrt ins Qualitäts-Gate zurück, Blockierend beendet das Review an einem eigenen Ausgang: „No-Go: Abnahmekriterien nicht erfüllt“.
• Der Schwellenwert-Zweig: „Fehler innerhalb der Schwellenwerte?“ antwortet Innerhalb oder Darüber, wobei Darüber zu „Behebung oder Ausnahme vereinbart?“ führt: ein Release oberhalb der Schwelle läuft damit nur auf Basis einer dokumentierten Vereinbarung weiter, nicht auf Zuversicht.
• Zwei Bereitschaftsfragen mit einer zweiten Prüfung dahinter: „Abhängigkeiten und Lieferanten bereit?“ fällt weiter zu „Release auch ohne sie möglich?“, und „Rollback erfolgreich getestet?“ fällt weiter zu „Ist die Änderung überhaupt umkehrbar?“, wo ein Nein der einzige Weg zum Abbruch statt zu einem neuen Termin ist.
• Support und Terminlage als eigene harte Gates: „Support geschult und besetzt?“ und „Änderungsfenster und Kalender frei?“ führen bei Nicht bereit beziehungsweise Konflikt unmittelbar ins No-Go und halten die Betriebsbereitschaft aus der Entwicklungsdiskussion heraus.
• Ein abschließendes Paar, das das Ergebnis benennt: „Freigabe der Geschäftsleitung erteilt?“ (Erteilt oder Verweigert) und danach „Welcher Umfang wird freigegeben?“ mit den Zweigen Vollständig, Mit Auflagen und Nur Pilot in drei getrennte Endpunkte, neben den Endpunkten für No-Go und Abbruch.

Wann Sie diese Vorlage verwenden sollten

• Sie halten ein Freigabe- oder Launch-Review ab, und die Kriterien leben in den Köpfen der Beteiligten: das Ergebnis hängt also davon ab, wer im Raum sitzt und wie die Woche gelaufen ist.
• Ihre Reviews produzieren nur „Go“ oder „Verschiebung“, und eine Teilbereitschaft (ein verspäteter Lieferant, eine dünn besetzte Support-Schicht) hat keinen Platz außer dem vollen Stopp oder einem undokumentierten Risiko.
• Sie wollen die Entscheidungsbefugnisse klären, bevor das nächste Release den Streit erzwingt: Wer darf ein Abnahmekriterium per Ausnahme aussetzen, wer einen Fehler oberhalb der Schwelle akzeptieren, und wessen Freigabe ist zwingend?
• Sie dokumentieren für ein Audit oder einen Sicherheitsfragebogen eines Kunden, wie Änderungen autorisiert, getestet und freigegeben werden, und müssen neben der Freigabe auch die Kriterien zeigen.
• Sie führen ein Post-Incident-Review zu einem Release durch, das nie hätte ausgeliefert werden dürfen, und wollen über die übersprungene Frage sprechen statt über eine Rekonstruktion aus dem Gedächtnis.

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.