Eine Änderung ausliefern, ohne den Abend zu verlieren
Die Frage vor jedem Release ist nicht, ob es funktioniert. Sondern was Sie in den zwanzig Minuten tun, nachdem es das nicht tut.
Die meisten Releases gehen gut. Die anderen scheitern meist aus Gründen, die niemand vorhersehen konnte — genau deshalb dreht sich die Vorbereitung um Erholung, nicht um Vorhersage.
Schreiben Sie zuerst den Rückweg auf
Beantworten Sie vor dem Release eine Frage schriftlich: Wie machen wir das rückgängig, und wie lange dauert es? Ist die Antwort länger als zehn Minuten oder lautet sie „darüber müssten wir nachdenken“, sind Sie nicht bereit — nicht weil die Änderung schlecht wäre, sondern weil Sie dann nachdenken, während etwas kaputt ist und Leute fragen.
Manche Änderungen lassen sich wirklich nicht zurücknehmen: eine Datenmigration, eine bereits versandte E-Mail. Die brauchen eine andere Sorgfalt — eine kleinere erste Charge, ein Test am eigenen Konto — gerade weil es keinen Fluchtweg gibt.
Ausliefern, solange die Leute wach sind, die es reparieren können
Freitagnachmittag ist der schlechteste Slot und bleibt beliebt, weil es sich anfühlt, als räume man vor dem Wochenende den Tisch. Tatsächlich verschiebt es die Entdeckung jedes Problems auf Samstag, wenn die Person, die die Änderung kennt, nicht erreichbar ist und die erreichbare sie nicht kennt.
Dienstag- und Mittwochvormittag sind die guten Slots. Sie bekommen einen vollen Arbeitstag echter Nutzung, während alle Beteiligten am Schreibtisch sitzen. Ein Release, das vier Tage wartet, ist fast nie schlechter als eines, das niemand betreuen kann.
Beobachten Sie das Geänderte, nicht das Dashboard
Nach einem Release wirft man einen Blick auf eine allgemeine Statusansicht, sieht Grün und macht weiter. Allgemeine Ansichten bemerken einen konkreten Defekt spät — ein Formular, das in einem Browser scheitert, ein Schritt, der stillschweigend übersprungen wird.
Verbringen Sie die ersten fünfzehn Minuten damit, das Geänderte so zu benutzen, wie es eine Kundin täte. Es klingt zu simpel und findet mehr als Monitoring, denn Monitoring meldet nur Fehler, die jemand zu instrumentieren dachte.
Sagen Sie es dem Support vor der Welt
Wer Nachrichten beantwortet, sollte von einer Änderung erfahren, bevor eine Kundin sie beschreibt. Sonst ist der erste Kontakt mit Ihrer Arbeit eine verwirrte Person, und man muss raten, ob es ein Fehler oder Absicht ist.
Zwei Sätze genügen: Was hat sich geändert, und was könnte auffallen. Am selben Vormittag schicken. Es ist die billigste denkbare Maßnahme und die am häufigsten übersprungene, weil die ausliefernde Person an den Code denkt und nicht an die, die um vier danach gefragt wird.
Häufig gestellte Fragen
Was gehört zur Vorbereitung eines Releases?
Der Rückweg. Schreiben Sie auf, wie die Änderung rückgängig gemacht wird und wie lange das dauert; über zehn Minuten oder „darüber müssten wir nachdenken“ heißt: nicht bereit.
Wann ausliefern?
Dienstag- oder Mittwochvormittag — ein voller Arbeitstag echter Nutzung, während alle Beteiligten am Schreibtisch sind. Freitagnachmittag verschiebt die Entdeckung jedes Problems auf Samstag.
Wie kündigt man eine Änderung an?
Dem Support vor den Kundinnen: zwei Sätze, was sich geändert hat und was auffallen könnte. Sonst ist der erste Kontakt mit Ihrer Arbeit eine verwirrte Person und eine Vermutung.
