Der Steve-Test: Verdient die Arbeit, zu existieren?

Anfang der Woche habe ich ein Stück Arbeit ausgeliefert, bei dem die richtige Entscheidung gewesen wäre, es nicht auszuliefern. Eine Übersetzungspipeline schreibt die Inhalte dieser Website für 10 Sprachversionen in Cloudflare D1. Drei Übersetzungsjobs liefen gleichzeitig in ein Rate Limit; der Fallback-Mechanismus schrieb stillschweigend die englische Quelle als „Übersetzung“ für sechs dieser Sprachversionen in D1 und aktualisierte anschließend die Checkpoint-Hashes so, dass sie zum englischen Inhalt passten. Auf der Festplatte sah alles nach Erfolg aus. Die Pipeline meldete „complete“. Die Metrik sagte: 10 Sprachversionen ausgeliefert. Jede automatisierte Prüfung bestand.

Ein deutscher Leser auf /de/guides/claude-code hätte einen deutschen Absatz gesehen, dann einen englischen, dann wieder einen deutschen und schließlich eine englische Abschnittsüberschrift. Kein Marker erklärte die Wechsel. Die Seite wirkte absichtlich so und ließ die ganze Website unglaubwürdig erscheinen: wie ein Produkt, das wahrscheinlich auch bei allem anderen scheitern würde, wofür es gedacht ist. Der Jiro-Test (ist die Arbeit korrekt?) bestand auf jeder Ebene, die ich instrumentiert hatte. Und trotzdem war das Ergebnis nicht würdig. Es sah aus wie ein Produkt und verhielt sich wie eine Beleidigung.

Die richtige Antwort war: stoppen, jeden Fallback-Batch mit englischem Inhalt prüfen, die Checkpoint-Hashes gezielt löschen, die Übersetzungspipeline Job für Job laufen lassen, Sprachversion für Sprachversion verifizieren, committen, pushen. Etwa 6 Stunden reine Übersetzungslaufzeit und eine Schutzplanken-Änderung, damit es nicht wieder passiert. Das Artefakt auf der Festplatte war die ganze Zeit „funktionsfähig“. Das Artefakt in Produktion war Schaden, den ich verursacht hatte.

Die Form dieses Fehlers ist dieselbe, egal ob das Artefakt eine Übersetzungspipeline, ein Registrierungsfluss, ein Feature Toggle, ein CSV-Export oder eine Marketingseite ist. Jede automatisierte Prüfung besteht. Was vor einem echten Benutzer landet, ist Schaden.

Die leitende Produktfrage lautet nicht Ist es fertig? oder Funktioniert es? Die leitende Frage lautet: Verdient diese Arbeit, zu existieren? Jedes Artefakt muss diese Frage beantworten, bevor es ausgeliefert wird, neben einer getrennten Prüfung auf Korrektheit. Korrektheit ohne Existenzberechtigung erzeugt Bestand: Dinge, die funktionieren, ausgeliefert werden und kein Vertrauen verdienen. Existenzberechtigung ohne Korrektheit erzeugt Theater: Dinge, die sich richtig anfühlen und brechen. Beide Tests müssen bestanden werden.

Meine Kurzform dafür ist der Steve-Test. Er steht neben dem Jiro-Test für Sorgfalt und Nachweise. Es sind zwei verschiedene Fragen, gestellt vom selben Kopf, und ich liefere keine Arbeit aus, die an einer von beiden scheitert.

TL;DR

Der Steve-Test ist die zweite Prüfung, die jedes Artefakt bestehen muss. Jiro fragt, ob die Arbeit korrekt ist; Steve fragt, ob die Arbeit als Teil des Ganzen, das Sie bauen, existieren sollte. Der Test ist konkret, nicht abstrakt. Er misst an einem echten Benutzer in einem echten Moment, und sein verlässlichstes Ergebnis ist Verweigerung. Ich kürze Umfang. Ich lösche Funktionen. Was bleibt, muss meinen Namen tragen können. Beide Tests müssen bestehen. Wenn Jiro scheitert, stoppen Sie und reparieren. Wenn Steve scheitert, bauen Sie neu. Drei ehrliche Neuaufbauten sind die Grenze; danach liegt das Problem vorgelagert, im Zuschnitt.

Warum „Ist es fertig?“ die falsche Frage ist

Die meisten Produktteams optimieren auf Auslieferbarkeit. Messbar sind Commits, Deployments, Velocity-Charts, die bloße Präsenz von etwas in Produktion. Der Fehlermodus ist vorhersehbar: Teams produzieren einen stetigen Strom von Artefakten, die korrekt funktionieren und still Benutzervertrauen verbrauchen. Das Onboarding wird abgeschlossen, eine zweite Sitzung findet nie statt. Support-Tickets häufen sich bei Aufgaben, die das Produkt angeblich löst. Die Churn-Kurve sinkt gegen null, statt sich zu einem Kern zu stabilisieren.

Fertig und würdig sind verschiedene Maße. Eine Funktion kann fertig sein und trotzdem ihre Existenz nicht verdienen. Eine Seite kann rendern und den Leser beleidigen. Eine Übersetzung kann technisch vorhanden und faktisch eine Lüge sein. Ob etwas fertig ist, entscheidet sich daran, ob es das spezifizierte Verhalten ausführt. Ob etwas würdig ist, entscheidet sich daran, ob ein echter Benutzer in einem echten Moment besser dran ist, weil Sie es ausgeliefert haben.

Mein Argument in Minimal würdiges Produkt lautet, dass die MVP-Kultur in der Praxis zwei Fragen zu einer verschmolzen hat: schnell lernen verkam zu schnell ausliefern, und Auslieferung wurde zur entscheidenden Metrik.⁷ Das Gegenmittel ist der Doppelstandard. Minimum kürzt den Umfang. Würdig hält die verbleibende Oberfläche an eine Messlatte, die der Benutzer spürt. Der Steve-Test ist das Werkzeug, mit dem Sie entscheiden, ob die verbleibende Oberfläche diese Messlatte erreicht hat.

Die leitende Frage

Verdient diese Arbeit, zu existieren?

Ich verwende diese Frage wörtlich. Wenn ich ein Stück Arbeit abgeschlossen habe und entscheiden muss, ob ich es ausliefere, stelle ich sie laut. Die Antwort ist ein Urteil, keine Stimmung. Lautet sie Ja, kommt die Arbeit für eine Auslieferung infrage; die nächste Frage ist dann, ob sie auch den Jiro-Test auf Korrektheit besteht. Lautet sie Nein, muss die Arbeit neu gebaut oder gelöscht werden. Lautet sie noch nicht, aber nach einer klar definierten Korrektur, arbeite weiter.

Die Frage funktioniert nur, wenn Nein eine zulässige Antwort ist. Ein Steve-Test, der alles abnickt, was vor ihm liegt, ist kein Test. Dass der Test wirklich läuft, erkennt man daran, dass manche Arbeit an ihm scheitert.

Der Benutzerpol: Existenzberechtigung ist nie abstrakt

Der Steve-Test scheitert in dem Moment, in dem er zu einer Geschmacksdebatte über die Arbeit isoliert von ihrem Kontext wird. Messen Sie Existenzberechtigung an einem bestimmten Benutzer in einem bestimmten Moment. Richtig formuliert lautet die Testfrage: Verdient diese Arbeit für diesen Benutzer in diesem Moment zu existieren?

Für blakecrosley.com ist der Benutzer ein Leser, der kalt aus der Suche kommt und eine unbeantwortete Frage zu Claude Code, Codex oder Infrastruktur hat. Der Moment sind die ersten 5 Sekunden nach dem Laden der Seite, bevor die Seite irgendein Vertrauen verdient hat. Eine Seite, die schnell lädt, ihre Perspektive lesbar darstellt und dem Leser etwas sagt, was seine Suche nicht bereits beantwortet hat, hat die Messlatte erreicht. Eine Seite, die ihn mit einem langsamen Bundle, einem nicht wegklickbaren Cookie-Banner und einer Wand aus generischem SEO-Text bestraft, ist durchgefallen, ganz gleich, wie gut sie auf der Jiro-Achse abschneidet.

Für ResumeGeni ist der Benutzer ein Jobsuchender in einem Moment, den ich als verletzlich behandle. Der Großteil der frühen Warteliste kam nach einer Entlassung oder mitten in einer Bewerbungsphase.⁶ Die würdige Version weigert sich, diese Menschen als Conversion-Metrik zu behandeln. Der Text weicht nicht aus. Der Parser lügt nicht darüber, was er gefunden hat. Die Hinweise sind konkret genug, dass sie danach handeln können. Der Ablauf lässt den Benutzer nicht mitten im Prozess zurück, nur weil ich nur den Happy Path ausgeliefert habe.

Der Benutzerpol verhindert, dass der Steve-Test zur Abstellkammer meiner eigenen Vorlieben wird. Wenn ich den Benutzer nicht benennen, seinen Moment nicht benennen und nicht erklären kann, wie die ausgelieferte Oberfläche ihn respektiert und stärkt, habe ich den Test nicht angewendet. Ich habe ihn nur behauptet.

Der Doppeltest: Jiro plus Steve

Die vollständige Doktrin braucht zwei Tests, nicht einen.¹ Ich liefere nichts aus, was an einem von beiden scheitert.

Der Jiro-Test fragt: Ist das korrekt gemacht? Er verlangt Nachweise. Randfälle behandelt. Unsichtbare Details abgeschlossen. Behauptungen mit konkreten Belegen. Kein Ausweichen: Ich glaube ist kein Nachweis. Tests bestehen. Keine Regressionen. Die Nachweisprüfung ist die Version des Jiro-Tests, die ich auf Codeberichte und Agent-Ausgaben anwende; die Jiro-Qualitätsphilosophie ist die ausführlichere Herleitung.

Der Steve-Test fragt: Verdient diese Arbeit, zu existieren? Er verlangt Existenzberechtigung. Kohärenz mit dem Ganzen. Eine erkennbare Haltung. Eine benannte Verweigerung oder Löschung, die die Oberfläche sauber gehalten hat. Einen Mechanismus für Freude oder Klarheit, den der Leser erkennen kann, statt bloß behaupteter Wirkung. Die Fähigkeit, Ihren Namen zu tragen.

Die Schlichtung ist einfach. Wenn Jiro scheitert, stoppen und reparieren. Inkorrekte Arbeit wird nicht ausgeliefert; das Jiro-Veto ist absolut. Wenn Jiro besteht und Steve scheitert, bauen Sie neu. Korrekte, aber unwürdige Arbeit wird ebenfalls nicht ausgeliefert. Wenn beide scheitern, liegt das Problem vorgelagert, im Briefing, im Zuschnitt oder im Umfang. Nur Arbeit, die beide Tests besteht, kommt für die Auslieferung infrage.

Die meisten Auslieferungskulturen führen still nur einen der beiden Tests aus. Engineering-geführte Kulturen haben oft einen starken Jiro und einen schwachen Steve: Das Produkt wird ausgeliefert, wenn die Tests bestehen, und Existenzberechtigung wird zur Abteilung eines anderen. Design-geführte Kulturen haben manchmal einen starken Steve und einen schwachen Jiro: Das Produkt wird ausgeliefert, wenn es richtig aussieht, und Korrektheit wird zum operativen Problem. Beide Fehlermodi erzeugen erkennbare Artefakte. Schöner Unsinn. Korrekte, aber seelenlose Arbeit. Sie haben beides gesehen. Vielleicht haben Sie beides schon ausgeliefert.

Die beiden Tests stehen nebeneinander:

Das ganze Produkt: Ihnen gehört das Gesamterlebnis

Der Steve-Test beurteilt Artefakte nicht isoliert. Er beurteilt sie als Teil des gesamten Erlebnisses, dem der Benutzer begegnet.

Der Übersetzungsvorfall vom Anfang ist das sauberste aktuelle Beispiel, und der konkrete Fehlmechanismus lohnt sich, weil er die Form der Falle zeigt. Der Fallback-Mechanismus der Pipeline schrieb die englische Quelle in D1, als der Claude-Subprozess ein Rate Limit traf. Der D1-Writer akzeptierte diese Bytes, weil es Bytes waren. Der Checkpoint-Updater bildete einen Hash des gespeicherten Inhalts und schrieb diesen Hash auf die Festplatte. Weil die gespeicherte „Übersetzung“ identisch mit der englischen Quelle war, passten die Hashes exakt zusammen: identische Bytes, identische Hashes. Der nächste --update-Lauf verglich den Hash der englischen Quelle mit dem gespeicherten Hash, fand Gleichheit und markierte den Batch als unverändert. Jede Komponente bestand ihren eigenen Jiro-Test isoliert. Der Defekt lag in der Zusammensetzung. Ein Benutzer sah stundenlang gemischtsprachige Prosa in sechs Sprachversionen, bevor ein Mensch eine der Seiten öffnete.

„Wir verantworten das ganze Produkt“ ist die Regel. Produktverhalten, UX-Flows, Sprache, Datentreue, Support-Systeme, Verpackung, Dokumentationsgenauigkeit, Prompts, Regeln, Speicher, Skills, Hooks, Skripte, Orchestrierung, Ausgabestruktur. Alles davon, nicht nur das Artefakt, das Sie zuletzt ausgeliefert haben. Kein lokaler Gewinn ist akzeptabel, wenn er die Integrität des Ganzen schwächt. Der Steve-Test schlägt an, wenn eine Oberfläche lokal besteht und das gesamte Benutzererlebnis nicht.

Löschung: Eine Steve-Schicht, die nur hinzufügt, ist falsch

Das Nützlichste, was der Steve-Test hervorbringt, ist eine Löschung.

Eine Prüfung, die endet, ohne etwas zu entfernen, hat faktisch nicht stattgefunden. Wenn Sie Verdient diese Arbeit, zu existieren? auf eine Oberfläche mit echter Komplexität anwenden, findet sich fast immer mindestens ein Stück Umfang, Text, Funktion oder Bedienelement, das seine Anwesenheit nicht verteidigen kann. Eine Prüfung, die null solcher Stücke findet, ist meist eine Prüfung, die als Prüfung aufgeführt wird, nicht eine, die wirklich praktiziert wird.

Wonach der Steve-Test konkret sucht:

• Oberflächen, die vorhanden sind, weil ihre Aufnahme sich sicher anfühlte, nicht weil sie ihren Platz verdienen.
• Text, der ausweicht, weil das Entfernen der Absicherung eine echte Behauptung verlangen würde.
• Funktionen, die aus einer früheren Version mitgeschleppt werden und dem aktuellen Versprechen nicht mehr dienen.
• Bedienelemente, die für Randfälle hinzugefügt wurden, die im aktuellen Umfang tatsächlich nicht auftreten.
• Konfigurationsoptionen, die eine Entscheidung auf den Benutzer abladen, die der Ersteller hätte treffen müssen.
• Dokumentation, die Verhalten beschreibt, das das Produkt nicht mehr zeigt.
• Tests, die Code abdecken, der gelöscht werden sollte.

Löschung ist der Akt, der Geschmack von Ansammlung unterscheidet. Die würdige Oberfläche ist kleiner als die Version, die Sie ausgeliefert hätten, wenn niemand die Frage gestellt hätte. Ich habe nie bereut, etwas aus einem ausgelieferten Produkt entfernt zu haben. Ich habe regelmäßig bereut, was ich drinließ.

Verweigerung als primärer Akt

Verwandt mit Löschung und noch stärker: Der Steve-Test greift oft, bevor überhaupt etwas gebaut wird, nicht erst danach. Der primäre Akt des Geschmacks ist Verweigerung: die Entscheidung, die Sache gar nicht erst zu machen.

Der Steve-Jobs-Satz, der hier zählt, lautet „I’m as proud of what we don’t do as I am of what we do,“ berichtet in einer BusinessWeek-Titelgeschichte von 2006 über Apples Produktdisziplin.⁵ Menschen zitieren diesen Satz oft, weil er in einer spezifisch technischen Weise wahr ist. Jedes ausgelieferte Produkt ist von einem unsichtbaren Ring aus Produkten umgeben, deren Auslieferung Sie verweigert haben. Dieser Ring ist die eigentliche Haltung. Er ist der Nachweis, dass ein Mensch entschieden hat und nicht der Backlog.

Für blakecrosley.com ist der Stack ein Protokoll dessen, was ich beschnitten habe. Ich zog React in Betracht und lehnte es ab. Ich zog Tailwind in Betracht und lehnte es ab. Ein Bundler lag in den ersten zwei Wochen des Rebuilds auf dem Tisch, bevor ich ihn strich. Dass es nirgendwo im Repository node_modules/ gibt, ist keine Designentscheidung; es ist eine Verweigerung, die ich über Zeit gegen die Schwerkraft der Standardwerkzeuge halte. Diese Verweigerungen formen die Arbeit stärker als jede Aufnahme. Sie definieren, welchen Standard ich zu halten bereit war.

Für ResumeGeni fiel die Validierung sauber aus. 340 E-Mail-Anmeldungen, 12 direkte Anfragen, 3 unaufgeforderte Angebote, für frühen Zugriff zu zahlen.⁶ Der Backlog, den diese Nachfrage sichtbar machte, war groß: Vorlagen, Team-Zusammenarbeit, Analyse-Dashboards, LinkedIn-Integration, Indeed-Integration, Versionsverlauf, mehrere Exportformate, eine mobile App. All das habe ich für die erste ausgelieferte Version verweigert. Was ich nicht verweigern konnte: genaues Parsing, ehrliche Lückenanalyse, konkrete Umschreibungen passend zur Stellenbeschreibung, ein Export, der sauber in Word öffnet, ein Ablauf, der einem verletzlichen Benutzer Sicherheit gibt. Die verweigerten Dinge sind nicht für immer weg. Sie warten jenseits der würdigen ersten Oberfläche.

Eine Oberfläche, die nichts verweigert, hat keine Haltung. Wenn das Team nichts verweigert hat, ist der Umfang falsch.

Nennen Sie Unfug früh beim Namen, bei sich selbst zuerst

Verweigerung und Löschung funktionieren nur, wenn der Test falschen Erfolg wirklich benennen kann, sobald er erscheint. Der Steve-Test muss Unfug benennen, und zwar schnell, bei:

• Scheinfortschritt. Bewegung, die wie Fortschritt aussieht und kein greifbares Ergebnis hervorbringt.
• Verunreinigten Nachweisen. Ein Test, der aus dem falschen Grund besteht; Statistiken, die beweisen, was Sie bewiesen haben wollten, statt was wahr war.
• Eitelkeitszählungen. Commit-Zahlen, Zahlen ausgelieferter Artefakte, Velocity-Charts: alles vorhanden, alles am Punkt vorbei.
• Inkohärenten Systemen, die isoliert sauber ausgeliefert werden und einander in Kombination schwächen. Der Übersetzungsvorfall oben gehört dazu.
• „Alles läuft nach Plan“-Berichten, die eine Entscheidung überdecken, die niemand getroffen hat. Der Steve-Test ist ihr Gegner.
• Maschinenaktivität mit geringem Wert. Arbeit, die ein Computer erledigt, weil er es kann, nicht weil das Ergebnis seinen Platz verdient.

Die schwierigste und dauerhaft nützlichste Version der Regel lautet: Nennen Sie Unfug in Ihrer eigenen Ausgabe zuerst beim Namen. Der Übersetzungsvorfall am Anfang dieses Essays ist genau das. Die Pipeline meldete Erfolg. Die Logs waren sauber. Jede Metrik, die ich instrumentiert hatte, gab grünes Licht. Die Arbeit war Unfug, und ich musste ihn bei mir selbst benennen, bevor es die Benutzer taten. Die eigene Arbeit konsequent gegen Unfug zu prüfen, ist die Disziplin, die den Test ehrlich hält. Höflichkeit ist kein Schutzschild gegen Wahrheit; Beschäftigung ersetzt keinen Wert.

Oberflächen-Gradient: Die Prüfung kalibrieren

Der Steve-Test ist kein einzelner Durchlauf mit einer einzelnen Schwelle. Je schwerer eine Oberfläche zurückzunehmen ist, desto härter muss die Prüfung sein.²

Der Test ist dieselbe Frage. Die Strenge der erforderlichen Antwort skaliert mit dem Schadensradius. Eine Chat-Antwort können Sie im nächsten Zug korrigieren; davon stirbt niemand. Ein Produktionsdeployment, das am Steve-Test scheitert, verbrennt Benutzervertrauen, das Monate gebraucht hat, und die Korrektur kostet mehr, als die ursprüngliche Auslieferungsentscheidung gespart hat.

Die praktische Folge: Die Auslieferungsgeschwindigkeit sollte sinken, je schwerer Oberflächen rückgängig zu machen sind, nicht steigen. Teams, die mit einheitlicher Geschwindigkeit über Oberflächen sehr unterschiedlicher Umkehrbarkeit hinweg ausliefern, signalisieren, dass sie nicht glauben, der Test müsse variieren. Meist haben sie aufgehört, ihn auszuführen.

Geschmack ist kein Temperament

Eine weitere Unterscheidung verlangt der Steve-Test, weil sie am häufigsten verloren geht. Steve aufzurufen heißt, seinen Geschmack aufzurufen, nicht sein Temperament.

Die Doktrin verbietet ausdrücklich Folgendes:³

• Grausamkeit.
• Demütigung.
• Theatralische Verachtung.
• Visionärs-Cosplay.
• Aggression als Ersatz für Urteilskraft.
• Nachtragende Inszenierung.
• Drama, das mit Standards verwechselt wird.

Das Signal, dass die Steve-Schicht wirklich arbeitet, ist ruhige Verweigerung. „Nein, die Arbeit ist noch nicht würdig“, als Urteil ausgesprochen und gefolgt von der konkreten Korrektur. Keine Aufführung. Keine Demütigung der Person, die die unwürdige Version gebaut hat, oft man selbst. Keine sichtbare Verachtung für das Team. Kein Ausstrahlen, man habe höhere Standards. Die Arbeit erreicht die Messlatte oder nicht. Die Messlatte ist nicht die Ästhetik von Strenge.

Diese Unterscheidung zählt, weil die Karikatur von Steve Jobs sein Temperament in den Mittelpunkt stellt. Wer je von jemandem geführt wurde, der Steve aufführt, weiß, was ich meine. Grausamkeit macht die Arbeit nicht besser. Sie macht den Arbeitsplatz schlechter und, weil sie Theater an die Stelle von Urteilskraft setzt, auch die ausgelieferte Arbeit schlechter.

Der operative Test dafür, ob Sie in Steves Geschmacksschicht sind oder in Steves Temperamentsinszenierung, lautet: Führt der Test zu einem konkreten technischen Schritt? „Die Arbeit verdient nicht zu existieren“ ist kein Schluss, sondern der Beginn einer Frage. Die Antwort muss die gescheiterte Achse, die Korrektur und den nächsten Test benennen. Wenn die Prüfung bei „die Arbeit ist schlecht“ endet, ohne zu benennen, was sie würdig machen würde, war die Prüfung eine Aufführung.

Die Grenze für Neuaufbauten und die Anti-Lähmungs-Klausel

Ein hoher Standard ohne Stoppregel wird zu Vermeidung. Die Disziplin, die ich auf jede nicht triviale Arbeit anwende, hat eine Grenze von drei ehrlichen Neuaufbauten.

Ein ehrlicher Versuch bedeutet: Sie haben die gescheiterte Achse identifiziert, den konkreten Korrekturschritt benannt, den Ansatz materiell verändert und die Arbeit erneut gegen beide Tests geprüft. Drei Wiederholungen derselben Politur zählen nicht als drei Versuche. Diese Wiederholungen zählen als ein gescheiterter Versuch, dreimal wiederholt.

Nach drei ehrlichen Neuaufbauten, die keine würdige Arbeit hervorbringen, liegt das Problem fast nie im Handwerk. Es liegt vorgelagert: im Zuschnitt, im Umfang, im Briefing oder in der Zusammensetzung des Teams. Hören Sie auf, die Oberfläche neu zu bauen, und betrachten Sie die Prämisse. Manchmal war das Versprechen zu groß für den Umfang, den Sie realistisch auf Standard halten können. Manchmal war die Validierung weicher, als Sie dachten. Manchmal ist das Problem gar kein Produktproblem.

Die Grenze für Neuaufbauten löst zwei gegensätzliche Fehlermodi zugleich. Sie weigert sich, schwache Arbeit zu segnen, und sie verhindert, dass Verfeinerung zum Verstecken wird. Nicht auszuliefern ist nicht von sich aus tugendhaft. Endloses Neubauen auf der Suche nach Perfektion ist ein eigener Fehlermodus: Handwerk ohne Mut. Das Ziel ist nicht Perfektion. Das Ziel ist würdig und ausgeliefert. Nicht makellos und endlos ausstehend.

Wenn Sie beim vierten Neuaufbau derselben Oberfläche sind, bauen Sie kein Produkt mehr; Sie benutzen das Projekt als Versteck.

Beobachtbare Anzeichen: Wurde der Test wirklich ausgeführt?

Der Steve-Test lässt sich leicht behaupten und schwer wirklich ausführen. Die Disziplin besteht darin, konkret zu benennen, was der Test hervorgebracht hat.

Bevor ich nicht triviale Arbeit für abgeschlossen erkläre, stelle ich sicher, dass ich alle folgenden Fragen beantworten kann:⁴

1. Wer ist der Benutzer? Kein Persona-Archetyp. Eine echte Person in einer echten Situation.
2. Welche Haltung trägt diese Oberfläche? Wenn Sie keine benennen können, gibt es keine Haltung, nur einen Backlog.
3. Was haben Sie verweigert oder entfernt, damit das sauber bleibt? Die Löschung ist der Nachweis, dass der Test lief.
4. Wie dient das dem ganzen Produkt? Das Stück muss mit jedem anderen Stück zusammenpassen. Lokale Gewinne, die das Ganze schwächen, sind keine Gewinne.
5. Welcher Nachweis belegt, dass es solide ist? Die Jiro-Achse. Die Verifikation lief; die Behauptung ist gestützt.
6. Warum ist es würdig? Klar ausgesprochen. Wenn die Antwort vage ist, lief der Test nicht.
7. Würde ich meinen Namen daruntersetzen, ohne zu zucken? Das Geschmacksurteil. Wenn die Urteilskraft unsicher ist, die leitende Frage im Stack.

Wenn ich nicht alle sieben konkret beantworten kann, habe ich die Doktrin behauptet, statt sie anzuwenden. Ich schicke die Arbeit zurück.

Ausgearbeitetes Beispiel: die sieben Anzeichen an einer echten Oberfläche

Hier sind die Anzeichen angewendet auf eine konkrete Oberfläche, die nach dem Übersetzungsvorfall ausgeliefert wurde: ein Parallelitätsschutz, den ich in die Übersetzungspipeline geschrieben habe. Ungefähr 100 Zeilen Python, die den Start von guide_bootstrap.py oder blog_translate_batch.py verweigern, wenn bereits ein anderer Übersetzungsprozess läuft.

1. Wer ist der Benutzer? Ich zu Beginn eines Übersetzungslaufs in zwei Wochen, wenn ich den genauen Rate-Limit-Fehlermodus vergessen haben werde, der sechs Sprachversionen verbrannt hat. Außerdem jeder Agent, der eines der beiden Skripte in einer künftigen Sitzung aufruft.
2. Welche Haltung trägt die Oberfläche? Gleichzeitige Übersetzungsläufe sind nie das richtige Werkzeug. Der Schutz schreibt dieses Urteil in Code, damit der nächste Aufrufer es nicht erinnern muss.
3. Was habe ich verweigert oder entfernt, damit das sauber bleibt? Ich verweigerte, den Schutz nur zu einer Warnung zu machen. Ich verweigerte ein kurzes, bequemes Override-Flag wie --force. Der einzige Override ist eine Umgebungsvariable, I18N_ALLOW_CONCURRENT=1, lang genug, dass niemand sie versehentlich tippt.
4. Wie dient es dem ganzen Produkt? Die Übersetzungspipeline, der D1-Writer und der Fallback-Mechanismus sind jeweils einzeln korrekt. Der Schutz ist das Stück, das verhindert, dass sie sich zu einem Ganzen kombinieren, das still korrumpiert.
5. Welcher Nachweis belegt, dass es solide ist? Ich habe den Schutz mit zwei manuellen Prüfungen verifiziert. Erstens: sauberer Abschluss, wenn kein anderer Übersetzungsjob läuft. Zweitens: Exit-Code ungleich null, wenn ein echter guide_bootstrap.py-Subprozess aktiv ist. Beide Prüfungen liefen gegen die echten Skripte, nicht gegen Mocks.
6. Warum ist es würdig? Derselbe Wettlauf durch parallele Läufe, der sechs Sprachversionen korrumpiert hat, kann keine gemischtsprachigen D1-Zeilen erzeugen, solange der Schutz aktiv ist. Es ist keine Prävention aller Fälle; es ist Prävention für den spezifischen Fehlermodus, den die Doktrin gerade gelernt hat.
7. Würde ich meinen Namen daruntersetzen? Ja. Ein Job, saubere Override-Semantik, in einer Speichernotiz dokumentiert, damit eine künftige Sitzung den Grund erbt, warum der Schutz existiert.

Der Sinn des ausgearbeiteten Beispiels ist, dass jedes Anzeichen eine spezifische Antwort hat. Wenn ich keine liefern kann, lief der Test noch nicht.

Der Gegensatz zeigt, wie Scheitern aussieht. Als ich den Parallelitätsschutz entwarf, lautete mein erster Versuch für Anzeichen 3: „Ich habe verweigert, ihn zu überbauen.“ Der Satz klingt gut und sagt nichts. „Nicht überbauen“ benennt nichts Konkretes, das ich erwogen und abgelehnt habe. Es ist eine Pose, keine Verweigerung. Ich zwang mich, die echte Antwort aufzuschreiben: Ich verweigerte, den Schutz zu einer Warnung zu machen; ich verweigerte einen bequemen Override-Flag-Namen; ich verweigerte ein Verhalten, bei dem der Schutz im Fehlerfall offen bleibt, wenn er Prozesse nicht auflisten kann. Das sind Entscheidungen. Die erste Version war Doktrinentheater.

Zentrale Erkenntnisse

Für Gründer und Solo-Builder: - Benennen Sie den echten Benutzer im echten Moment, bevor Sie irgendeine Oberfläche als würdig bezeichnen. Abstrakte Existenzberechtigung ist unbrauchbar. - Jede ausgelieferte Oberfläche sollte mindestens eine sichtbare Verweigerung enthalten. Wenn Sie nichts entfernt haben, ist der Umfang falsch. - Wenden Sie den Oberflächen-Gradienten an. Ein Produktionsdeployment verlangt eine härtere Prüfung als ein Entwurf; Marketingaussagen verlangen die härteste Prüfung überhaupt.

Für Produktverantwortliche und PMs: - Messen Sie, ob der Steve-Test wirklich läuft, indem Sie Verweigerungen und Löschungen pro Release-Zyklus zählen. Null ist ein Warnsignal. - Trennen Sie „funktioniert“ von „verdient zu existieren“ in Ihren eigenen Review-Checklisten. Behandeln Sie sie als unabhängige Achsen. - Schützen Sie das Budget für Neuaufbauten. Drei ehrliche Versuche, dann eskalieren. Lassen Sie Perfektionismus nicht zum Versteck werden, und lassen Sie Termindruck den Test nicht töten.

Für technische Leitungen: - Benennen Sie für jede Oberfläche, die Ihr Team ausliefert, eine Jiro-Prüfung und eine Steve-Prüfung. Beide müssen bestehen. - Investieren Sie in die unsichtbaren Details. Der Unterschied zwischen korrekt und würdig lebt meist in den Übergängen. - Verweigern Sie das Temperament. Ruhige Verweigerung ist das Signal. Aufgeführte Strenge ist der Fehlermodus.

Für Designer: - Haltung ist keine Dekoration. Sie ist der Mechanismus, der das Produkt erkennbar macht. - Eine würdige Oberfläche verweigert Dinge sichtbar. Zu Ihrer Arbeit gehört, zu benennen, was Sie gestrichen haben. - Der operative Test in Mehrdeutigkeit: Würden Sie Ihren Namen unter diese Entscheidung setzen, ohne zu zucken?

Schluss: Würde ich meinen Namen daruntersetzen?

Die leitende Produktfrage lautet: Verdient diese Arbeit, zu existieren? Die leitende Frage bei unsicherer Urteilskraft ist die einfachste im Stack.

Würde ich meinen Namen daruntersetzen, ohne zu zucken?

Lautet die Antwort Ja, kommt die Arbeit für eine Auslieferung infrage. Lautet die Antwort „noch nicht, aber nach bis zu drei ehrlichen Neuaufbauten“, arbeiten Sie weiter. Lautet die Antwort Nein und bleibt nach drei ehrlichen Versuchen Nein, bauen Sie das Briefing neu, nicht die Oberfläche.

Ich führe diesen Test jedes Mal aus. Am Code. Am Text. An der Commit-Nachricht. An der Dokumentation. An der Produktoberfläche. An diesem Essay.

Dieser Essay hat drei Abschnitte gestrichen, von denen ich zu Beginn des Entwurfs dachte, ich bräuchte sie: einen langen biografischen Abschnitt über Jobs, eine Einführung in die „dent in the universe“-Zeile und eine Verteidigung, warum die Doktrin den Namen einer realen Person verwendet statt eine Abstraktion. Keiner davon diente dem Benutzer, für den ich schrieb: einem Builder, der entscheiden muss, ob er eine Oberfläche ausliefern soll, bei der er unsicher ist. Die Kürzungen machten das Stück kleiner und ehrlicher. Und der Übersetzungsfehler, der den Essay eröffnet, erzeugte neben der Reparatur ein dauerhaftes Artefakt: einen Parallelitätsschutz in der Übersetzungspipeline, der den Start nun verweigert, wenn bereits ein anderer Übersetzungsjob läuft. Abgelehnte Arbeit hat die Regeln verändert. Die Doktrin hat gelernt.

Steve besteht. Jiro besteht. Es wird ausgeliefert.

FAQ

Was ist der Steve-Test?

Der Steve-Test fragt, ob eine Arbeit für einen echten Benutzer in einem echten Moment zu existieren verdient. Er steht neben der Jiro-Qualitätsphilosophie: Jiro prüft Korrektheit, Nachweise und Randfälle; Steve prüft Existenzberechtigung, Kohärenz, Verweigerung und Geschmack.

Wie unterscheidet sich der Steve-Test vom Jiro-Test?

Jiro fragt, ob die Arbeit korrekt gemacht ist. Steve fragt, ob die korrekte Arbeit überhaupt ausgeliefert werden sollte. Eine Funktion kann Tests bestehen und trotzdem am Benutzer, am Produkt oder an der Haltung hinter der Oberfläche scheitern.

Wann sollte ein Team den Steve-Test ausführen?

Führen Sie ihn aus, bevor schwer umkehrbare Oberflächen ausgeliefert werden: öffentliche Deployments, Marketingaussagen, Onboarding-Flows, Preisseiten, Dokumentation und Produktfunktionen, die Benutzervertrauen prägen. Leichtere Arbeit kann eine weichere Prüfung verwenden, aber öffentliche Oberflächen brauchen eine strenge.

Was sollte der Test hervorbringen?

Der Test sollte eine konkrete Entscheidung hervorbringen: ausliefern, neu bauen, löschen oder verweigern. Ein wirklich bestandener Test benennt den Benutzer, den Moment, die Haltung, die Nachweise und mindestens eine Sache, die das Team entfernt hat, um das Ganze zu bewahren.

Kann der Steve-Test zu Perfektionismus werden?

Ja. Deshalb braucht die Doktrin eine Grenze für Neuaufbauten. Drei ehrliche Neuaufbauten reichen; danach liegt das Problem meist vorgelagert im Briefing, Umfang, Team oder in der Prämisse.

Die Review-Vorlage

Kopieren Sie dies in eine Arbeitsnotiz, eine PR-Beschreibung, eine Notion-Seite oder an den Anfang Ihrer Commit-Nachricht. Füllen Sie es aus, bevor Sie nicht triviale Arbeit für erledigt erklären. Wenn Sie eine Zeile nicht mit etwas Konkretem beantworten können, ist der Test noch nicht gelaufen.

Steve-Test: Review-Protokoll

Benutzer:            [echte Person in einer echten Situation, kein Persona-Archetyp]
Moment:              [der konkrete Moment, in dem der Benutzer auf die Arbeit trifft]
Haltung:             [was diese Oberfläche behauptet; was sie verweigert]
Verweigerung:        [was ich erwogen und gestrichen oder ganz abgelehnt habe]
Ganzes Produkt:      [wie dies mit jedem angrenzenden Produktteil zusammenpasst]
Nachweis:            [Jiro-Achse: Verifikation lief; konkreter Beleg für die Behauptung]
Würdigkeitsurteil:   [ja / nein / noch nicht innerhalb von N definierten Neuaufbauten]
Signatur:            [würde ich meinen Namen daruntersetzen, ohne zu zucken? wenn nein, stoppen]

Die Vorlage hat genau eine Aufgabe. Sie zwingt den Tester, in jeder Zeile eine spezifische Antwort zu liefern. Vage Antworten erreichen die Messlatte nicht. „Ich habe verweigert, es zu überbauen“ ist keine Verweigerung; „ich habe ein bequemes Override-Flag und einen Fail-open-Pfad verweigert“ ist eine. „Es dient dem Benutzer“ ist keine Antwort auf das ganze Produkt; „es schließt die konkrete kompositorische Lücke, die den letzten Vorfall verursacht hat“ ist eine. Wenn eine Zeile sich gegen Spezifität sträubt, ist die Arbeit nicht bereit; dieser Widerstand ist der Test, der Ihnen sagt, wohin der Neuaufbau gehen muss.

Diese Vorlage ist das operative Artefakt des Essays. Alles andere auf dieser Seite ist Erklärung dafür, warum die Zeilen existieren.

Referenzen