Entscheidungen, die niemand mehr anzweifeln muss

„Das haben wir nie so besprochen” ist in Beratungsprojekten fast immer vermeidbar. Dieser Beitrag zeigt, wie du Entscheidungen so dokumentierst und belegst, dass sie Bestand haben.

Situation

In einem Beratungsprojekt wird eine technische Richtung im Meeting besprochen und mündlich vereinbart. Wochen später, wenn die Umsetzung schon läuft, bestreitet ein Beteiligter, dass diese Richtung so abgestimmt war, oder erinnert sich an eine andere Variante. Die Diskussion beginnt von vorn, obwohl die eigentliche Arbeit schon investiert ist. Parallel dazu wird eine andere Entscheidung allein mit einer Einschätzung begründet: „Das fühlt sich langsamer an.” Niemand kann die Aussage prüfen, jede Gegenmeinung ist genauso schwer zu widerlegen wie zu belegen, und die Diskussion dreht sich im Kreis statt zu einem Ergebnis zu kommen. Beides hat dieselbe Ursache: Die Entscheidung existiert nur im Gedächtnis der Beteiligten, nicht als Referenzpunkt, auf den sich alle beziehen können.

Taktik

Das Werkzeug dafür heißt Architecture Decision Record, kurz ADR: ein kurzes, einheitlich aufgebautes Dokument pro Entscheidung, das jederzeit nachlesbar bleibt, auch wenn sich niemand mehr an das Meeting erinnert.

1. Halte jede nennenswerte technische Entscheidung als ADR fest: Kontext, geprüfte Optionen, getroffene Entscheidung, erwartete Konsequenzen. Ein bis zwei Seiten reichen.
2. Lass dieses Dokument vor der Umsetzung von der verantwortlichen Person gegenlesen, nicht erst danach.
3. Stütze Argumente mit Messwerten, etwa Antwortzeiten, Fehlerquote oder Durchlaufzeit, statt mit Einschätzungen wie „fühlt sich besser an”.
4. Vermerke, wer wann zugestimmt hat. Eine spätere Rückfrage lässt sich dann in einer Minute klären statt in einer erneuten Diskussion.
5. Lege diese ADRs an einem festen, für das ganze Projektteam erreichbaren Ort ab, zum Beispiel als Markdown-Dateien im selben Repository wie der Code, nicht verteilt über einzelne Chat-Verläufe.

Beispiel

Ein Projektteam will Zugangsdaten von Umgebungsvariablen auf ein zentrales Secrets-Management-Werkzeug umstellen. Vor der Umsetzung entsteht ein kurzes Entscheidungsdokument: Ausgangslage, geprüfte Alternativen, Entscheidung, erwarteter Aufwand bei Einführung und Betrieb, und die konkrete Frage, wer für Rotation und Zugriffsrechte zuständig ist. Der zuständige technische Ansprechpartner liest es gegen, stellt eine Rückfrage zur Zugriffskontrolle und bestätigt die Entscheidung danach schriftlich. Als später, mitten in der Umsetzung, die Frage aufkommt, warum dieser Weg und nicht ein anderer gewählt wurde, beantwortet das Dokument sie direkt, ohne dass das Projektteam das Gespräch von vorn führen muss. Das Dokument muss dafür nicht lang sein. Entscheidend ist, dass es die Alternativen nennt, die verworfen wurden, und warum, denn genau diese Stelle wird später am häufigsten angezweifelt.

Typische Fehler

• Entscheidungen nur im Meeting besprechen, ohne schriftliche Nachverfolgung.
• Eine Position mit Meinung statt mit Messwert begründen.
• Das Entscheidungsdokument erst nach der Umsetzung schreiben, als Rechtfertigung statt als Grundlage.
• Dokumente an einem Ort ablegen, den nicht alle Beteiligten erreichen können.