Jedes Enterprise-Engagement beginnt gleich: Jemand fragt nach einer Discovery-Phase. Zwei Wochen um „die Landschaft zu verstehen". Ein Monat um „Stakeholder auszurichten". Bis jemand Code schreibt, ist die Hälfte des Budgets weg und das ursprüngliche Problem hat sich in etwas verwandelt, das niemand wiedererkennt.
Strike existiert, um das zu verhindern. Es ist ein 72-Stunden-Drucktest, bei dem wir bestimmen, ob ein Proof Sprint machbar ist, ihn bepreisen und die genauen Bedingungen definieren, unter denen wir ihn abbrechen, wenn er nicht funktioniert. Kein Discovery-Theater. Keine Alignment-Workshops. Nur Entscheidungen.
Warum Meetings zu schwarzen Löchern werden
Das traditionelle Enterprise-Meeting hat einen fatalen Fehler: Es belohnt Reden über Entscheiden. Die Person, die die meisten Bedenken äußert, wirkt gewissenhaft. Die Person, die mehr Recherche fordert, wirkt gründlich. Niemand wird dafür getadelt, Dinge zu verlangsamen, aber alle werden getadelt, wenn etwas ausgeliefert wird und scheitert.
Protokoll eins: Zeitdisziplin
Jedes Thema in Strike bekommt ein 12-Minuten-Segment. Das ist kein Vorschlag—es wird durchgesetzt. Wenn die Zeit abläuft, dokumentieren wir das Ergebnis und machen weiter.
Zwölf Minuten klingt brutal, und das ist es. Aber hier ist, was wir gelernt haben: Die meisten Themen brauchen nicht mehr Zeit. Sie brauchen weniger Ambiguität.
Protokoll zwei: Beweise statt Meinungen
Debatten in Strike finden im Repo statt, nicht im Raum.
Wenn Sie denken, die vorgeschlagene Architektur wird nicht skalieren, zeigen Sie einen Lasttest. Wenn Sie denken, das Datenmodell ist falsch, reichen Sie eine Schema-Alternative mit Migrationsnotizen ein.
Wir haben eine bestimmte Klasse von Einwänden verboten: die Sorge ohne Beweis. „Ich mache mir Sorgen um die Sicherheit" ist kein Einwand. „Hier ist ein Bedrohungsmodell, das drei nicht geminderte Angriffsvektoren zeigt" ist ein Einwand.
Protokoll drei: Sichtbare Abbruchkriterien
Das wichtigste Ergebnis von Strike ist nicht das grüne Licht. Es sind die roten Linien.
Bevor sich jemand zu einem Proof Sprint verpflichtet, definieren wir genau, was uns zum Abbruch bringen würde. Keine vagen „wenn die Dinge schiefgehen" Formulierungen—spezifische, messbare Bedingungen.
Wer im Raum sitzt
Strike erfordert genau vier Rollen, nicht mehr: Business-Owner, Technical Lead, Sicherheitsvertreter und Einkauf/Finance. Wenn eine dieser Personen nicht die vollen 72 Stunden teilnehmen kann, führen wir Strike nicht durch.
Was herauskommt
Go: Ein bepreister Proof Sprint mit fixem Scope, definierter Timeline, unterschriebenen Abbruchkriterien und einem Backlog, das Ihr Engineering-Team bereits geprüft und akzeptiert hat.
No-go: Eine dokumentierte Entscheidung, nicht fortzufahren, mit spezifischen Gründen. Das ist ein Erfolg, kein Misserfolg.
Warum das funktioniert
Strike funktioniert, weil es Entscheidungsfindung als Produktionsprozess behandelt, nicht als sozialen. Das Unbehagen ist ein Feature. Wenn Ihr Planungsprozess angenehm ist, produziert er wahrscheinlich keine Entscheidungen.