Eine Präsentation zur Release-Bereitschaft muss der freigabeberechtigten Person drei Fragen beantworten: Was genau soll produktiv gehen, welche Belege stützen die Änderung und was passiert, wenn sie fehlschlägt? Beginnen Sie mit der erbetenen Entscheidung, zeigen Sie offene Bedingungen neben den Ergebnissen und halten Sie abschließend fest, wer welchen Umfang freigegeben hat. Eine Reihe grüner Statussymbole reicht dafür nicht.
Bereiten Sie zunächst die geprüften Release-Unterlagen vor. Mit Presenti können Sie diesen Text in einen bearbeitbaren Präsentationsentwurf umwandeln; Belegverweise und Freigabebedingungen bleiben dabei Teil der Folien. Das folgende Beispiel begleitet einen fiktiven Terminbuchungsdienst durch eine Go/No-Go-Besprechung. Protokolle, Zeiten und Grenzwerte dienen der Veranschaulichung und stammen nicht aus einer echten Bereitstellung.
Nennen Sie Release und Entscheidung vor dem Fortschritt
Das Team möchte Version 2.4 veröffentlichen. Sie verändert, wie Kunden Termine buchen und stornieren. Preise, Kontenmigration und mobile App gehören nicht zu diesem Release. Geprüft wird Build 2.4-rc3 mit Konfiguration C17 und einer neuen Datenbankmigration. Zunächst sind zehn interne Testkonten vorgesehen; über Kundenzugriff soll später separat entschieden werden.
Zum Besprechungszeitpunkt sind die Buchungstests bestanden. Verzögerungen bei Benachrichtigungen werden noch untersucht. Eine Rücksetzprobe betraf den vorherigen Kandidaten, nicht rc3 mit seiner Migration. Die erste Folie sollte deshalb lauten:
Empfehlung: Den rc3-Pilot zurückstellen. Für das Buchungsverhalten liegen Testergebnisse vor, die Wiederherstellung mit diesem Kandidaten ist jedoch noch nicht nachgewiesen. Klären Sie die Wiederherstellungsbedingung und die Benachrichtigungsverzögerung, bevor Sie die Pilotfreigabe beantragen.
Das ist hilfreicher als „Release 2.4 ist zu 95 % bereit“. Ein Prozentwert vermischt Punkte mit unterschiedlichen Folgen. Mehrere abgeschlossene Dokumentationsaufgaben können einen fehlenden Wiederherstellungsnachweis nicht ausgleichen.
Nennen Sie auf der ersten Folie Build, Konfiguration, Prüfzeitpunkt und vorgesehenen Nutzerkreis. Ändert sich während der Besprechung ein Build oder eine Konfiguration, muss die Gruppe wissen, welche Belege weiterhin gelten. Übertragen Sie die Freigabe eines früheren Kandidaten nicht stillschweigend auf ein neues Artefakt.
Zeigen Sie, welche Aussage jedes Ergebnis tatsächlich stützt
Verwenden Sie eine kurze Belegübersicht und halten Sie die vollständigen Protokolle separat bereit. Jede Zeile sollte eine Aussage mit ihrem Geltungsbereich und der verbleibenden Lücke verbinden. „Tests bestanden“ ist zu pauschal, wenn nur interne Konten oder ein einzelner Zahlungsweg geprüft wurden.
| Bereich | Beleg in dieser fiktiven Prüfung | Bedeutung für die Entscheidung |
|---|---|---|
| Buchungsverhalten | QA-42 dokumentiert Tests zu Erstellung, Stornierung und gleichzeitiger Reservierung unter rc3/C17 in der Vorproduktionsumgebung. | Stützt die geprüften Abläufe, aber keine Aussage über jede mögliche Kundenlast. |
| Benachrichtigungen | MAIL-9 dokumentiert verzögerte Bestätigungen bei einem Test automatischer Wiederholungsversuche; maximale Verzögerung und Ursache sind offen. | Ausnahme sichtbar lassen. Benachrichtigungen nicht als bereit kennzeichnen oder die Verzögerung für harmlos erklären. |
| Wiederherstellung | RB-14 betraf den vorherigen Kandidaten. Für rc3 mit seiner Migration gibt es kein Probenprotokoll. | Die vereinbarte Wiederherstellungsbedingung ist nicht erfüllt; die Empfehlung lautet zurückstellen. |
| Supportbesetzung | OPS-6 nennt Erstverantwortlichen, Vertretung, Pilotzeitfenster und Eskalationsweg. | Die Abdeckung gilt für dieses Fenster, nicht unbegrenzt oder für eine ausgeweitete Einführung. |
QA-42 und die übrigen Kennungen sind Beispiele. Die entsprechenden Verweise in Ihrem Deck sollten zu den tatsächlichen Ergebnissen samt Umgebung, Kandidat und Zeitpunkt führen. Persönliche Angaben und betriebliche Geheimnisse bleiben in angemessen zugriffsbeschränkten Unterlagen und werden nicht in eine breit geteilte Präsentation kopiert.
Googles Beitrag zu zuverlässigen Produkteinführungen betont konkrete, praktikable Prüfungen, die zum Dienst passen. Die historische Einführungsliste behandelt unter anderem Fehlerverhalten, Überwachung, Wiederherstellung und stufenweise Einführung. Nutzen Sie diese Punkte als anpassbare Fragen, nicht als universellen Freigabestandard oder Beleg dafür, dass Ihr Dienst sie erfüllt.
Unterscheiden Sie Blocker und akzeptierte Ausnahme
Vereinbaren Sie vor der Besprechung, welche Bedingungen einen Stopp verlangen und welche bei einer ausdrücklich begrenzten Freigabe abgewogen werden dürfen. Sonst wird „gelb“ zu einer Verhandlung über Farben statt über den tatsächlichen Nutzerkreis.
Im Beispiel lautet die vereinbarte Regel: Der Wiederherstellungsweg des Kandidaten muss vor jeder Pilotbereitstellung nachgewiesen sein. Die fehlende rc3-Probe ist damit ein Blocker. Die Besprechungsleitung kann ihn nicht allein dadurch zu einer akzeptierten Ausnahme machen, dass statt Kunden nur zehn Mitarbeiter teilnehmen.
Die E-Mail-Verzögerung ist eine andere Frage. Könnte ein eng begrenzter Pilot trotz dieser Einschränkung stattfinden? Dafür müsste die Gruppe zunächst die beobachtete Verzögerung, die Korrektheit des Buchungszustands, die sichtbaren Auswirkungen und die Stoppbefugnis kennen. „Wir haben eine Umgehungslösung“ beantwortet diese Fragen nicht.
Halten Sie jede vorgeschlagene Ausnahme knapp fest: Einschränkung; betroffene Nutzer; Belege; vorübergehende Absicherung; verantwortliche Rolle; Ablauf- oder Prüfzeitpunkt. Eine Ausnahme ohne definierten Nutzerkreis und Endpunkt verändert das Release-Versprechen auf unbestimmte Zeit.
Trennen Sie drei Ergebnisse. Go genehmigt den genannten Umfang unter den vereinbarten Bedingungen. Eingeschränktes Go genehmigt einen kleineren, genau beschriebenen Nutzerkreis. No-Go lässt die Änderung unfreigegeben, bis die benannten Belege und die Entscheidung erneut geprüft werden. Keiner dieser Begriffe verleiht dem Vortragenden zusätzliche Befugnisse.
Zeichnen Sie einen Release-Weg mit Rückweg
Ein Zeitstrahl, der bei „Bereitstellen“ endet, verdeckt Arbeit, von der die Freigabe abhängt. Stellen Sie einen kurzen Ablauf mit Entscheidungs- oder Stoppbedingungen zwischen den Stufen dar:
- Vor dem Einsatz: rc3-Wiederherstellungsprobe abschließen, MAIL-9 eingrenzen und Protokolle der neuen Prüfung beilegen.
- Freigabe: Die benannte Freigabeinstanz entscheidet, ob dieser Kandidat in den Pilot mit zehn Konten darf.
- Begrenzte Beobachtung: Benannte Verantwortliche beobachten im Pilotfenster Buchungskorrektheit, Benachrichtigungen und vereinbarte Überwachungssignale.
- Nächste Entscheidung: Begrenzt fortfahren, stoppen und wiederherstellen oder eine Ausweitung beantragen. Die erste Freigabe genehmigt die letzte Option nicht automatisch.
Nehmen wir zur Veranschaulichung an, eine spätere Prüfung legt folgende Stoppbedingungen fest: jede bestätigte Doppelbuchung, eine Bestätigungsverzögerung von mehr als fünf Minuten oder der Ausfall der Überwachung, die diese Bedingungen erkennbar macht. Das sind beispielhafte dienstspezifische Grenzen, keine empfohlenen Standardwerte. Ein Beobachtungsfenster von dreißig Minuten könnte zu diesem begrenzten Pilot gehören, würde aber keine Zuverlässigkeit bei größerem Umfang nachweisen.
Schreiben Sie die Stoppbefugnis neben die Stoppbedingung. Im Beispiel darf die Bereitschaftsleitung den Pilot anhalten; die Freigabeinstanz entscheidet über eine Wiederaufnahme. Verweisen Sie für die Wiederherstellung auf das genehmigte Betriebshandbuch, statt aus der Präsentation eine ausführbare Bereitstellungsanleitung zu machen.
Fragen Sie bei der Migration, was „zurück“ bedeutet. Kann die vorherige Anwendung Datensätze lesen, die die neue geschrieben hat? Müssen im Pilot angelegte Termine abgeglichen werden? Zeigen Sie die bekannte Antwort oder den fehlenden Beleg. Ein Wechsel der Anwendungsversion beweist allein noch nicht, dass die Daten wieder verwendbar sind.
Führen Sie mit sechs Folien durch die Entscheidung
Eine kurze Präsentation kann der Entscheidung folgen, ohne die Wochenberichte aller Teams zu wiederholen:
- „rc3-Pilot zurückstellen, bis die Wiederherstellung nachgewiesen ist.“ Kandidat, Umfang, Empfehlung und Freigaberolle nennen.
- „Buchungstests stützen die geprüften Abläufe; zwei Bedingungen sind offen.“ Belegübersicht und Grenzen zeigen.
- „Das frühere Rücksetzergebnis deckt diese Migration nicht ab.“ Blockierende Lücke und benötigtes Ergebnis erläutern.
- „Die erste Freigabe würde nur zehn Konten umfassen.“ Stufenweg, Beobachtungsfenster und Stoppbefugnis zeigen.
- „Der Support ist für das vorgesehene Zeitfenster besetzt.“ Rollen, Vertretung und Übergabe nach dem Fenster benennen.
- „Entscheidung und Bedingungen der nächsten Prüfung festhalten.“ Die Besprechung mit einem konkreten Ergebnis beenden.
Die erste Folie ist die Empfehlung, die letzte hält die tatsächliche Entscheidung fest. Beides kann voneinander abweichen. Ändert die Gruppe den beantragten Umfang, dokumentieren Sie das, statt nachträglich die erste Folie umzuschreiben und dadurch die ursprünglich geprüfte Variante zu verlieren.
Fügen Sie für den Entwurf die sechs Überschriften samt geprüfter Belege darunter ein. Eine hilfreiche Anweisung lautet: „Lasse rc3/C17 unverändert. Behalte die Empfehlung zum Zurückstellen und die offene Wiederherstellungsbedingung bei. Trenne Belege, vorgeschlagene nächste Stufen und Freigabe. Erfinde keine Testergebnisse, Freigabenamen, Einführungstermine oder Leistungsverbesserungen.“ Prüfen Sie die Formulierungen vor der endgültigen Gestaltung; ein ordentliches Layout darf aus einer vorgeschlagenen Stufe keine genehmigte machen.
Beenden Sie die Besprechung mit einem ausgefüllten Entscheidungsprotokoll
Das Protokoll der fiktiven Besprechung ist kurz genug, um es vor dem Ende vorzulesen:
Entscheidung: No-Go für den vorgeschlagenen rc3/C17-Pilot mit zehn Konten, festgehalten in der Prüfung um 14:00 Uhr. Kein Einsatz für Kunden ist freigegeben.
Grund: Der Wiederherstellungsnachweis deckt die Migration des Kandidaten nicht ab. Die Benachrichtigungsverzögerung ist noch nicht eingegrenzt.
Nächste Belege: Die Entwicklungsleitung liefert den kandidatspezifischen Wiederherstellungsnachweis einschließlich des Umgangs mit neu angelegten Terminen. Der Benachrichtigungsverantwortliche liefert die Verzögerungsanalyse und den Vorschlag für eine Pilotbegrenzung.
Entscheidungsverantwortung: Die benannte Freigabeinstanz beruft eine neue Prüfung ein, sobald die Protokolle vorliegen. Der vorgeschlagene Termin um 16:00 Uhr dient der Statusmeldung, nicht als Erlaubnis, um 16:00 Uhr bereitzustellen.
Unveränderter Umfang: Kundeneinführung, mobile App, Preise und Kontenmigration bleiben außerhalb dieser Entscheidung.
Versenden Sie dieses Protokoll zusammen mit den Folien und Belegverweisen. Kommt die nächste Besprechung zu einem anderen Ergebnis, ergänzen Sie einen neuen Eintrag mit dem dann geprüften Kandidaten und den Bedingungen. Die Präsentation erfüllt ihren Zweck, wenn auch Abwesende erkennen können, was freigegeben wurde, was nicht und was als Nächstes geschehen muss.
