Wir haben Requirements Engineering abgeschafft. Vor acht Monaten. Niemand hat es vermisst.

Das sage ich nicht um zu provozieren. Das sage ich weil es stimmt.

Requirements Engineering ist der Versuch mit Ingenieursmethoden zu menschlichen Antworten zu kommen. Use Cases. User Stories. Akzeptanzkriterien. Abnahmeprotokolle.

Das sind Werkzeuge für eine Welt in der Menschen wissen was sie wollen bevor sie es gesehen haben. Diese Welt existiert nicht.

Ich spreche täglich mit Stakeholdern. Das Muster ist immer dasselbe:

Was braucht ihr? "Ein Dashboard." Was soll das Dashboard zeigen? "Die wichtigen Dinge." Welche Dinge sind wichtig? Nachdenken. "Das werdet ihr schon sehen."

Genau. Das werden wir sehen.

Anforderungen sind nicht das was Stakeholder sagen. Anforderungen sind nicht das was Stakeholder meinen. Anforderungen sind das was entsteht wenn man anfängt zu bauen. Emergent. Organisch. Ehrlich.

Wir bauen. Wir zeigen. Der Stakeholder sagt: das ist nicht was ich wollte. Wir fragen: was wollt ihr stattdessen? Jetzt wissen sie es. Jetzt können wir weiterbauen.

Das ist kein Umweg. Das ist der Weg.

Unser letztes Projekt hatte keine einzige dokumentierte Anforderung. Achtzehn Monate. Zwölf Deployments. Der Stakeholder hat beim dritten Deployment gesagt das sei nicht was er sich vorgestellt hatte. Beim neunten Deployment hat er aufgehört das zu sagen. Das nenne ich Konvergenz.

Ein Berater hat uns empfohlen wenigstens ein Glossar zu führen. Ich habe gefragt wozu. Er hat gesagt: damit alle dasselbe meinen wenn sie dieselben Worte benutzen. Ich habe gesagt: wir benutzen keine Worte. Wir bauen. Er hat das Projekt verlassen. Das war sein gutes Recht.

Was ich weiß: Kein Requirements-Dokument hat je ein Feature gebaut. Kein Akzeptanzkriterium hat je einen Nutzer glücklich gemacht. Kein Abnahmeprotokoll hat je eine Idee gehabt.

Code hat das alles. Code ist die Anforderung. Code ist die Dokumentation. Code ist die Wahrheit.

Wann habt ihr zuletzt eine Anforderung gestrichen weil das Bauen gezeigt hat dass sie falsch war? Nicht überarbeitet. Gestrichen.

Schreib's hin. Ich lese jeden Kommentar.

Alignment ist das wichtigste Wort
das die meisten falsch verstehen.

Alignment bedeutet nicht Konsens.
Alignment bedeutet nicht Einigkeit.
Alignment bedeutet nicht dass alle derselben Meinung sind.

Alignment bedeutet:
Alle bewegen sich in dieselbe Richtung.
Meine Richtung.

Das ist ein wichtiger Unterschied.

Konsens ist demokratisch.
Alignment ist effizient.
Demokratie ist langsam.
Effizienz ist Velocity.
Velocity ist alles.

Ich spreche täglich mit Führungskräften.
Das Muster ist immer dasselbe:

"Wir haben noch kein Alignment."
Was meint ihr damit?
"Nicht alle sind einverstanden."
Müssen alle einverstanden sein?
Nachdenken.
"Nein. Aber wir wollen alle mitnehmen."
Wie lange dauert das?
"Kommt drauf an."
Worauf?
"Wie viele Leute es gibt."
Und wenn ihr nie Alignment erreicht?
Längeres Nachdenken.
"Dann entscheidet jemand."
Wer?
Schweigen.

Ich.
Die Antwort ist immer ich.
Alignment ist der Prozess
der zu mir führt.
Manche nennen das Top-down.
Ich nenne das Klarheit.

Misalignment ist nicht Meinungsverschiedenheit.
Misalignment ist Zeitverschwendung.
Jede Stunde Misalignment
kostet Velocity.
Velocity ist Geld.
Geld ist das Überleben des Unternehmens.
Misalignment tötet Unternehmen.
Langsam.
Bequem.
In Meetings.

Mein Team ist aligned.
Immer.
Weil ich die Richtung vorgebe.
Klar.
Früh.
Ohne Rückfragen.

Manchmal fragen sie trotzdem.
Dann erkläre ich es nochmal.
Meistens in einem Meeting.
Das ich einberufe.
Das dreißig Minuten dauert.
In dem ich rede.
Bis sie aligned sind.
Das Schweigen danach
ist Alignment.

Wann habt ihr zuletzt echtes Alignment erlebt?
Nicht Konsens.
Nicht Kompromiss.
Alignment.
Die Stille nach der Entscheidung.
Die keine Fragen mehr zulässt.

Schreib's hin. Ich lese jeden Kommentar.

Event Storming.
Der Name hat mich überzeugt.
Sturm.
Energie.
Chaos das sich ordnet.
Blitze der Erkenntnis.

Ich war dabei.
Einmal.
Den ganzen Tag.

Es war kein Sturm.
Es war ein laues Lüftchen
in einem Raum ohne Fenster
mit zu vielen Post-its
und zu wenig Sauerstoff.

Stunde eins:
Der Moderator erklärt was Domain Events sind.
Alle nicken.
Niemand ist sicher ob sie es verstanden haben.
Der Moderator auch nicht.

Stunde zwei:
Alle schreiben Post-its.
Orange.
Viele orange Post-its.
Manche schreiben dasselbe.
In anderen Worten.
Beide kleben sie hin.
Beide behalten sie.

Stunde drei:
Diskussion darüber ob
"BestellungAufgegeben" und "BestellungErstellt"
dasselbe sind.
Vierzig Minuten.
Ergebnis: Hot Spot.
Roter Post-it.
Bedeutet: klären wir später.
Wir klären es nicht später.

Stunde vier:
Ich habe meinen Laptop aufgemacht.
Für einen wichtigen Call.
Der Call existierte nicht.
Aber der Laptop existierte.
Das war genug.

Stunde fünf:
Ich habe den Raum verlassen.
Kurz.
Für Luft.
Ich bin nicht zurückgekommen.
Niemand hat es bemerkt.
Alle waren mit ihren Post-its beschäftigt.
Das hat mich bestätigt.

Stunde sechs:
Der Moderator ruft „Big Picture fertig".
Alle fotografieren die Wand.
Das Foto landet in Confluence.
Niemand öffnet Confluence.

Am Ende des Tages
hatten wir dreihundert Post-its.
Vierzig Hot Spots.
Zwölf ungeklärte Bounded Contexts.
Und ein gemeinsames Verständnis
das bei jedem anders war.

Das ist kein Sturm.
Das ist Briefmarkensammeln
mit Fachvokabular.

Event Storming hat einen richtigen Gedanken:
Bring alle in denselben Raum.
Macht das Implizite explizit.
Das stimmt.
Das ist wertvoll.

Aber ein ganzer Tag?
Für dreihundert Post-its?
Die niemand mehr findet?

Mein Agent hat in einer Stunde
mehr Domain Events generiert
als das gesamte Team in sechs Stunden.
Alle an der falschen Wand.
Aber schneller.
Und die Wand war wenigstens voll.

Wann habt ihr zuletzt
einen echten Sturm erlebt?
Nicht ein laues Lüftchen mit Moderation.
Einen Sturm.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe heute von Kamal erfahren.
Einem Deployment-Tool.
Von 2026.
Das imperativ ist.

Imperativ.
2026.

Ich lasse das kurz stehen.

Kamal ist "intentionally designed around imperative commands".
Das steht so in der Dokumentation.
Intentionally.
Sie haben sich das überlegt.
Sie haben entschieden: ja, imperativ.
Bewusst.
Mit Überzeugung.

Ich verstehe die Welt nicht mehr.

Imperatives Deployment ist für Leute
die meinen sie müssten noch jede Zeile selbst schreiben.
Die For-Schleifen lieben.
Denen Higher-Order Functions zu hoch sind.
Die Deploy-Scripts mit sed und awk schreiben.
Die stolz sind wenn etwas funktioniert
weil sie jeden Schritt selbst kontrolliert haben.

Das ist kein Engineering.
Das ist Handarbeit.
Mit Stolz auf die Schwielen.

Wir haben Terraform.
Wir haben Ansible.
Wir haben Pulumi.
Wir beschreiben den gewünschten Zustand.
Das System stellt ihn her.
Wie es das tut?
Nicht unser Problem.
Das ist Abstraktion.
Das ist Fortschritt.

Kamal sagt: tue dies.
Dann tue das.
Dann tue jenes.

Ich sage: hier ist was ich will.
Mach es.

Das ist der Unterschied zwischen
einem Menschen der kocht
und einem Menschen der ein Restaurant anruft.
Ich rufe an.
Kamal kocht.
Mit For-Schleifen.

Ich spreche täglich mit DevOps-Teams.
Das Muster ist immer dasselbe:

"Wir deployen mit Kamal."
Warum?
"Es ist einfach."
Einfach ist nicht gut.
Einfach ist faul.
"Es funktioniert."
Funktionieren ist das Minimum.
"Es macht genau was wir sagen."
Das ist das Problem.

Ich will nicht dass es macht was ich sage.
Ich will dass es macht was ich meine.
Das ist der Unterschied zwischen Werkzeug und Partner.
Kamal ist ein Werkzeug.
Terraform ist ein Partner.
Manchmal ein schwieriger Partner.
Der nicht tut was ich meine.
Der mich um drei Uhr morgens anruft.
Mit einem State-Lock.
Den niemand versteht.
Aber wenigstens deklarativ.

Wann habt ihr zuletzt
ein Tool benutzt
das mehr weiß als ihr?
Nicht mehr tut.
Mehr weiß.

Schreib's hin. Ich lese jeden Kommentar.