Optionales Angebot. Eine separate Assessment-Buchung ist keine Voraussetzung für Engineering-Unterstützung.
Noch eine Analyse zum Ablegen — Ein Angebot mit festem Umfang für Teams, bei denen der Weg in die Produktion nicht mehr trägt.
Vier Wochen mit festem Umfang, um eure Auslieferung in einen Zustand zu bringen, den euer Team allein hält. Am Ende stehen gemergte Änderungen in euren Repositories und ein Service, der darüber läuft — keine Empfehlungen.
Der Recovery Sprint ist bewusst kein Assessment. Ein Assessment endet mit einer Analyse, einer Priorisierung und einer Roadmap. Der Sprint endet mit Änderungen in euren Systemen. Wenn danach nur Dokumente dastehen, ist er gescheitert — und das ist die Messlatte, an der wir uns messen lassen.
Was „gesund“ heißt, wird gemessen statt behauptet: Deployment-Frequenz, Vorlaufzeit einer Änderung, Anteil fehlgeschlagener Deployments und Wiederherstellungszeit — erhoben aus euren eigenen Systemen, mit einem Verfahren, das ihr danach ohne uns wiederholen könnt.
Jede Plattformkomponente bekommt eine namentlich benannte verantwortliche Person und einen Eskalationsweg. Nicht als Organigramm, sondern als Liste, der die genannten Personen zugestimmt haben.
Ein vorgezeichneter Weg vom Repository bis in die Produktion — für genau einen Service, dafür vollständig: Projektgerüst, Pipeline, Deployment, Observability, Alarmierung. Danach übertragbar, aber erst einmal an einem echten Beispiel bewiesen.
Wählbarer Schwerpunkt: reproduzierbare Builds, ein definierter Rollback-Weg, der einmal ausgelöst wurde, und Deployments, die keine Sondergenehmigung mehr brauchen.
Wählbarer Schwerpunkt: die Pipeline wird schneller und vor allem verlässlich — Flaky Tests werden repariert oder abgeschaltet, Caching und Parallelisierung dort, wo sie wirken, und ein grüner Lauf bedeutet wieder etwas.
Wählbarer Schwerpunkt: die wiederkehrenden Handgriffe, die jede Woche Zeit kosten, werden automatisiert oder abgeschafft — und die Alarme, die niemand mehr liest, werden geschärft oder gelöscht.
Messen und festlegen: Zugänge, Baseline-Erhebung aus euren Systemen, Verantwortlichkeiten aufschreiben, Referenz-Service bestätigen, Sprint-Backlog einfrieren. Ab Ende dieser Woche wird der Umfang nicht mehr erweitert.
Der erste gewählte Schwerpunkt: Wir arbeiten an dem Weg, auf dem eine Änderung heute in die Produktion kommt — im Pull Request, mit eurem Team, nicht in einem Nebenprojekt.
Der Golden Path: Der Referenz-Service läuft Ende der Woche vollständig über den neuen Weg — mindestens bis in die letzte Umgebung vor der Produktion.
Der zweite gewählte Schwerpunkt, Runbooks, erneute Baseline-Messung und die Übergabe. Am letzten Tag deployt jemand aus eurem Team, ohne dass wir im Raum sind.
Eine gemessene Baseline eurer Auslieferung — aus euren Systemen erhoben, am Ende mit demselben Verfahren wiederholt, beide Werte im Übergabedokument.
Gemergte Änderungen an eurer Pipeline und Deployment-Konfiguration, in euren Repositories, über Pull Requests, die euer Team gereviewt hat.
Der Referenz-Service läuft über den neuen Weg — in Produktion oder in der letzten Umgebung davor, je nachdem, was ihr in vier Wochen freigeben könnt.
Eine wiederverwendbare Vorlage für den Golden Path: Projektgerüst, Pipeline und Deployment-Manifeste, mit denen ein zweiter Service denselben Weg nehmen kann.
Eine Verantwortlichkeitskarte: jede Plattformkomponente mit benannter Person und Eskalationsweg, bestätigt von genau diesen Personen.
Runbooks für die Vorfälle, die euch tatsächlich getroffen haben — im Sprint geschrieben und im Sprint mindestens einmal durchgespielt.
Die wiederkehrenden Handgriffe aus dem gewählten Schwerpunkt sind automatisiert oder abgeschafft, nicht nur dokumentiert.
Eine Übergabe mit eurem Team und ein schriftliches Restbacklog: was wir nicht gemacht haben, warum, und in welcher Reihenfolge es sinnvoll wäre.
Die Analyse ist als eigenes Angebot noch nicht veröffentlicht. Die linke Spalte beschreibt, was eine Analyse liefert — damit ihr erkennt, ob ihr sie oder den Sprint braucht.
| Analyse | Recovery Sprint |
|---|---|
| Analyse der Engpässe, aus Interviews und Systemeinblick. | Eine gemessene Baseline aus euren Systemen, am Ende erneut erhoben. |
| Eine priorisierte Liste schneller Verbesserungen. | Die Verbesserungen sind umgesetzt und gemergt, nicht gelistet. |
| Empfehlung, wie der Zielzustand aussehen sollte. | Ein Service läuft in diesem Zielzustand, an einem echten Beispiel. |
| Review der Architektur mit Befunden. | Eine Vorlage, die den geprüften Weg für weitere Services wiederholbar macht. |
| Risiko- und Abhängigkeitskarte. | Eine Verantwortlichkeitskarte, der die genannten Personen zugestimmt haben. |
| Review des Auslieferungsprozesses. | Runbooks, die im Sprint einmal durchgespielt wurden. |
| Roadmap für die kommenden Monate. | Ein Restbacklog dessen, was nach vier Wochen offen ist — mit Begründung. |
Fester Preis für festen Umfang, kein Tagessatz: ein Sprint, der nach Aufwand abgerechnet wird, hat keinen festen Umfang mehr. Eine Preisliste veröffentlichen wir nicht — den Preis nennen wir im Angebot, zusammen mit dem Zuschnitt, bevor ihr euch festlegt.
Danach gibt es drei ehrliche Möglichkeiten: ihr macht allein weiter — das ist der Normalfall und der Zweck der Übergabe; ihr übertragt den Golden Path auf weitere Services und wir begleiten die ersten davon; oder ihr holt euch technische Führung auf Zeit ins Team. Keine dieser Optionen ist Teil des Sprints, und keine ist Voraussetzung dafür, dass er funktioniert.
Ehrlich gesagt: Wir zeigen hier keine Vorher-Nachher-Zahlen aus früheren Sprints. Dieses Angebot ist neu zugeschnitten, und Zahlen aus früheren Projekten wurden nie so erhoben, dass sie hier etwas beweisen würden. Was wir gebaut und aufgeräumt haben, steht in den Referenzen — ohne Kennzahlen, weil wir sie nicht gemessen haben.
Noch nicht sicher, ob das der richtige Auftrag ist? Klärt es in einer Viertelstunde, mit dem Ingenieur, der die Arbeit später macht. Fit-Check buchen
Schriftgröße