Welchen Qualitätsanspruch erwartest du von deinem Team, und wie setzt du ihn durch?

Setz die Latte nach Risiko statt nach einer einheitlichen Regel. Definiere, was wahr sein muss, bevor Code rausgeht (Tests, die die realistischen Failure Modes fangen, Review durch jemanden, der wirklich widersprechen kann, Instrumentierung auf dem neuen Pfad, ein dokumentierter Weg zurück) und automatisier davon so viel wie möglich in der Pipeline. Setz über Defaults und Automatisierung durch statt über Nörgeln im Code Review.

Ich setze sie nach Blast Radius. Eine Änderung am Payment-Pfad und eine Änderung an einer Marketingseite verdienen nicht dieselbe Zeremonie, und ein Standard für beides heißt, dass du entweder alles verlangsamst oder dich dort verbrennst, wo es zählt. Für alles Relevante ist meine Checkliste: Tests, die den realistischen Fehler tatsächlich fangen, statt Coverage-Prozent-Theater, ein Reviewer, der die Domäne gut genug versteht, um zu widersprechen, Instrumentierung auf dem neuen Pfad, damit wir ihn in Produktion beobachten können, und ein dokumentierter Weg zurück. Dann schiebe ich davon so viel wie möglich in die Pipeline, denn Standards, die darauf beruhen, dass Menschen sich im Review erinnern, zerfallen in etwa einem Monat. Lint, Test-Gates, Migrations-Checks, eine Rollback-Notiz als Pflichtfeld im Template. Wenn eine Senior-Person das umgeht, behandle ich das als Gespräch über den Standard statt über sie, denn meist hat sie einen echten Grund und der Standard ist falsch. Passiert es zweimal ohne Grund, ist das ein Performance-Gespräch und kein Prozess-Gespräch.