Es gibt einen Moment in fast jedem Software-Projekt, der sich wie das Ziel anfühlt und keines ist. Das Demo läuft. Der Kunde nickt. Jemand sagt den Satz: „Im Grunde ist es fertig, wir müssen es nur noch live stellen.”
Dieser Satz ist fast immer falsch. Nicht, weil das Demo schlecht wäre — sondern weil „nur noch live stellen” eine ganze Disziplin in vier Wörtern versteckt.
Was muss ein Demo nicht beweisen?
Ein Prototyp hat eine angenehme Eigenschaft: Er darf scheitern, ohne dass es zählt. Er läuft auf einer Maschine, unter Beobachtung, mit handverlesenen Eingaben, einmal. Wenn etwas hängt, startet man neu. Wenn ein Randfall auftritt, ignoriert man ihn.
Produktion darf nichts davon. Sie läuft unbeobachtet, mit Eingaben, die niemand vorhergesehen hat, parallel, dauerhaft. Sie scheitert irgendwann — die Frage ist nur, ob jemand davon erfährt, bevor der Kunde anruft.
Der Abstand zwischen diesen beiden Zuständen ist die unsichtbare Hälfte der Arbeit. Sie ist unsichtbar, weil sie in einem Demo nichts hinzufügt, das man vorführen könnte. Sie zeigt sich erst, wenn sie fehlt.
Was enthält die unsichtbare Hälfte konkret?
Die unsichtbare Hälfte besteht aus vier Bausteinen, die ein System von „funktioniert” auf „hält” bringen: Observability, Migrations-Disziplin, Deploy-Smoke-Tests und Incident-Runbooks. Keiner davon ist im Demo sichtbar — und genau deshalb wird keiner eingeplant.
Observability. Logs, Metriken, Trace-IDs. Nicht als Selbstzweck, sondern damit im Incident eine Frage beantwortbar ist: Was ist passiert, in welcher Reihenfolge, bei welchem Request? Ein System ohne Observability debuggt man im Ernstfall durch Raten. Raten ist langsam, und im Incident ist Langsamkeit teuer.
Migrations-Disziplin. Datenbank-Änderungen müssen linear sein, nachvollziehbar, und — wo möglich — umkehrbar. Eine Migration, die eine große Produktivtabelle sperrt, ist kein technisches Detail. Sie ist ein Ausfall. Der Unterschied zwischen einer sicheren und einer gefährlichen Migration entscheidet sich in der Demo-Phase nie, weil die Demo-Datenbank leer ist.
Deploy-Pipelines mit echten Smoke-Tests. Ein grünes Build-Image beweist, dass der Code kompiliert. Es beweist nicht, dass die Anwendung startet, dass sie ihre Datenbank erreicht, dass die zentrale Nutzerstrecke noch antwortet. Ein Smoke-Test, der genau das prüft — ein echter Endpunkt, eine echte Antwort — ist die letzte Verteidigungslinie vor dem Kunden.
Runbooks für den Ernstfall. Wenn etwas brennt, ist nicht der Moment, in dem man herausfindet, wie man zurückrollt. Ein Rollback-Runbook, ein Incident-Ablauf, eine klare Antwort auf „wer entscheidet” — das muss vorher stehen. Im Incident hat niemand Zeit, es zu erfinden.
Warum geht das in der Planung unter?
Die unsichtbare Hälfte wird systematisch unterschätzt, und der Grund ist strukturell. Aufwand wird meist an dem geschätzt, was man vorführen kann. Ein Feature ist sichtbar, also wird es eingeplant. Observability ist unsichtbar, also wird sie „mitgemacht”. Bis sie fehlt.
Mein Gegenmittel ist simpel: Die Produktionsreife gehört in dieselbe Schätzung wie das Feature, nicht in eine spätere. Wenn ein Vorhaben mit „in zwei Wochen fertig” beziffert wird, frage ich, ob in diesen zwei Wochen die Migration sicher ist, das Logging steht und der Deploy einen Smoke-Test hat. Lautet die Antwort nein, dann sind es nicht zwei Wochen. Es sind zwei Wochen bis zum Demo — und das ist eine andere Aussage.
Der ehrliche Satz am Ende
„Es funktioniert” und „es hält” sind zwei verschiedene Zustände. Zwischen ihnen liegt Arbeit, die niemand sieht und die trotzdem über Erfolg oder Störungsanruf entscheidet.
Wer ein Demo abnimmt und es für das Ziel hält, kauft die halbe Strecke und glaubt, er sei angekommen. Die zweite Hälfte kommt trotzdem — entweder als geplante Arbeit vorher oder als ungeplanter Notfall danach. Geplant ist billiger.
Häufige Fragen
- Was unterscheidet einen Prototyp von einem produktionsreifen System?
- Ein Prototyp läuft beobachtet, mit handverlesenen Eingaben, einmal — Fehler kosten nichts. Produktion läuft unbeobachtet, parallel, dauerhaft, mit unvorhergesehenen Eingaben. Der Unterschied liegt in Observability, Migrations-Sicherheit, Smoke-Tests und Runbooks.
- Warum reicht ein grünes Build-Image als Deploy-Test nicht aus?
- Ein grünes Build-Image beweist nur, dass der Code kompiliert. Es beweist nicht, dass die Anwendung startet, ihre Datenbank erreicht und die zentrale Nutzerstrecke antwortet. Dafür braucht es einen echten Smoke-Test gegen einen echten Endpunkt.
- Warum wird Produktionsreife in der Planung systematisch unterschätzt?
- Aufwand wird an dem geschätzt, was sich vorführen lässt. Ein Feature ist sichtbar und wird eingeplant. Observability ist unsichtbar und wird „mitgemacht" — bis sie im Incident fehlt. Produktionsreife gehört in dieselbe Schätzung wie das Feature.