Das Design-Review am Donnerstag um 14 Uhr ist keine Methode. Es ist ein Workaround.
Ein Workaround für ein Problem, das aus der Dokumentenwelt stammt: Wenn Wissen in Dateien liegt, die einzelne Personen lokal bearbeiten, dann weiß niemand, was sich seit letzter Woche geändert hat. Also setzt man einen Termin, an dem alle Beteiligten denselben Stand vor sich haben, geht ihn gemeinsam durch, protokolliert Beanstandungen und vertagt den Rest. Das Review-Ereignis synchronisiert, was das Werkzeug nicht synchronisieren kann.
Meine These, und sie ist falsifizierbar: Sobald das Entwicklungswissen in einem Modell liegt, das Änderungen versioniert und Verantwortung je Sicht kennt, ist das Review als Termin überflüssig. Review wird eine Eigenschaft des Modells — ein Zustand, der jederzeit gilt, statt ein Ereignis, das quartals-, wochen, - Sprint-, oder Releaseweise stattfindet.
Falsifizierbar heißt: Wenn jemand einen Prüfinhalt eines klassischen Design-, FMEA- oder Architektur-Reviews benennt, der sich prinzipiell nicht als permanenter Modellzustand abbilden lässt — nicht „ist bei uns halt so", sondern strukturell nicht — dann ist die These widerlegt. Ich habe bisher keinen gefunden.
Der stärkste Einwand zuerst#
Der beste Einwand gegen diese These lautet nicht „Auditoren wollen Protokolle" — dazu gleich. Der beste Einwand ist psychologisch: Der Termin erzwingt Aufmerksamkeit. Ein Review-Meeting ist ein sozialer Commitment-Mechanismus. Alle wissen: Donnerstag muss ich vorbereitet sein, Donnerstag werde ich gefragt, Donnerstag kann ich mich nicht wegducken. Ein „permanenter Zustand" hat keinen Donnerstag. Was permanent möglich ist, wird erfahrungsgemäß permanent verschoben. Constant Review, so der Einwand, ist Continuous Ignoring mit besserem Namen.
Der Einwand ist ernst zu nehmen, und er ist der Grund, warum Constant Review mehr braucht als ein Änderungslog. Ein Git-Log ist auch permanent einsehbar — und wird genau deshalb von niemandem als Review verstanden. Die Antwort liegt in drei Mechanismen, die zusammen das leisten, was der Termin sozial erzwingt: Adressierung, Verbindlichkeit und Eskalation.
Der Mechanismus#
Erstens: Änderungen haben einen Adressaten. Jede Sicht auf das Modell — die Sicht des Mechanik-Verantwortlichen, des Safety-Verantwortlichen, des Prozess-Eigners — hat einen Eigentümer. Das System führt pro Eigentümer und Sicht mit, was er zuletzt gesehen hat. Beim Öffnen seiner Sicht sieht er nicht „das Modell", sondern das Delta: Seit deinem letzten Besuch: zwölf Elemente verändert, vier Beziehungen neu, eine beanstandet. Das ist kein Log, den man durchsuchen könnte. Es ist eine persönliche Inbox, die sich erst leert, wenn ihr Eigentümer reagiert hat. Der Donnerstagstermin adressierte alle gleichzeitig und deshalb niemanden wirklich; der Awareness-Mechanismus adressiert jeden einzeln.
Zweitens: Reaktion ist ein dokumentierter Akt, kein Meeting-Beitrag. Auf jeder Beziehung im Modell — etwa „diese Lösung realisiert jene Funktion" — kann jeder Sicht-Eigentümer mit einem Klick zwei Dinge tun: bestätigen aus meiner Sicht oder beanstanden. Eine Beanstandung erfordert einen kurzen Begründungstext; eine Bestätigung nur Autor und Zeitstempel. Beides ist unveränderlich. Eine spätere Äußerung kann eine frühere ablösen, aber nicht löschen. Aus den Reaktionen der relevanten Rollen ergibt sich je Beziehung ein sichtbarer Konsens-Zustand: offen, teilweise bestätigt, bestätigt — Beanstandung als eigenes Signal obendrauf. Das klassische Review produziert diesen Zustand implizit und flüchtig („dazu gab es im Meeting keine Einwände"); Constant Review führt ihn explizit und dauerhaft.
Wichtig ist dabei eine Designentscheidung, die trivial klingt und es nicht ist: Eine Beanstandung betrifft die Beziehung im Modell, nicht die Person, die sie angelegt hat. Sie erscheint als „Klärungsbedarf aus Sicht Safety", nicht als „beanstandet von Frau Müller". Wer diesen Unterschied im Werkzeug nicht sauber zieht, baut ein Pranger-System und wundert sich, dass niemand beanstandet.
Drittens: Was liegen bleibt, eskaliert — aggregiert, nicht einzeln. Hier greift der Einwand von oben am härtesten, und hier braucht es die klarste Antwort. Wenn ein Eigentümer nicht reagiert, häufen sich offene Punkte. Das System meldet dann nicht jeden Einzelpunkt nach oben — das wäre Mikromanagement per Software — sondern aggregierte Muster: In dieser Sicht liegen ungewöhnlich viele ungelöste Beanstandungen. Diese Beziehung ist seit Wochen unbestätigt, obwohl sich darunter etwas geändert hat. Die Führungsebene sieht keine Einzelbefunde, sondern Zustandsmuster ganzer Bereiche. Das ersetzt die soziale Verbindlichkeit des Termins durch eine strukturelle: Nichtstun ist nicht mehr unsichtbar.
„Aber der Auditor will ein Review-Protokoll"#
Will er. Und er bekommt eines — besser als vorher.
Ein klassisches Review-Protokoll ist eine Momentaufnahme: geprüfter Stand, Teilnehmer, Befunde, Entscheidungen, offene Punkte. Jede dieser Informationen liegt im Constant-Review-Modell bereits vor, nur granularer und mit lückenlosem Zeitstempel. Ein Generator rendert daraus auf Anforderung ein Protokoll im gewohnten Format — deterministisch, für jeden beliebigen Zeitpunkt, ohne dass es je von Hand gepflegt wurde. Der Unterschied zum handgeschriebenen Protokoll: Es kann nicht von der Realität abweichen, weil es aus der Realität erzeugt wird.
Das ist dasselbe Prinzip, das ich an anderer Stelle für Pläne beschrieben habe: Dokumente sind Sichten auf das Modell, keine parallel gepflegten Wahrheiten. Ein Review-Protokoll, das doppelt gepflegt wird, ist eine Fehlerquelle. Ein Review-Protokoll, das gerendert wird, ist ein Beweis.
Der zweite Einwand: Bestätigungs-Inflation#
Wenn Bestätigen ein Klick ist, wird geklickt ohne zu prüfen. Auch dieser Einwand trifft — er trifft allerdings das klassische Review genauso, nur unsichtbarer. Wer im Meeting schweigt, hat „keine Einwände", und niemand kann später nachvollziehen, ob er die Unterlage überhaupt geöffnet hatte.
Constant Review macht Gefälligkeits-Bestätigungen nicht unmöglich, aber nachweisbar: Wenn eine Beziehung später beanstandet wird oder im Feld versagt, ist auf den Zeitstempel genau sichtbar, wer sie wann in welchem Zustand bestätigt hat — und was sich zwischen Bestätigung und Versagen geändert hat. Die Bestätigung ist keine Höflichkeitsgeste mehr, sie ist eine dokumentierte fachliche Aussage. Das verändert das Klickverhalten schneller als jede Schulung.
Was das Review-Meeting nicht war#
Zum Schluss die Abgrenzung, die den Einwand von oben endgültig auflöst: Der Termin fällt weg — das Gespräch nicht. Wenn eine Beanstandung strittig ist, setzen sich die Beteiligten zusammen, wie bisher auch. Der Unterschied: Sie setzen sich zusammen, weil es einen konkreten strittigen Punkt gibt, mit dem Punkt vor Augen, und das Ergebnis landet als Annotation am Modell. Was wegfällt, ist die andere Hälfte des klassischen Reviews — die zwei Stunden, in denen vierzehn Personen zuhören, wie unstrittige Folien vorgelesen werden, damit das Protokoll „Review durchgeführt" sagen kann.
Das Review als Termin war nie das Ziel. Es war der Preis dafür, dass unsere Werkzeuge Wissen in Dateien versteckt haben. Wenn das Modell selbst weiß, was sich geändert hat, wer es sehen muss und wer es bestätigt hat, dann ist der Preis entfallen — und das Review ist das geworden, was es immer sein sollte: der jederzeit sichtbare Zustand geprüfter Übereinstimmung.
Thomas Arends entwickelt mit OTSM eine Plattform, in der Anforderungen, FMEA, Prozesse und Organisation Projektionen eines gemeinsamen Modells sind. Dieser Artikel beschreibt das Konzept „Constant Review", das dort als permanenter Ersatz für Review-Ereignisse umgesetzt wird.