Kommentiertes Denken bei BCxP
Eine Frage der Kultur
Teil 1: Pauls erste Woche im Projekt Nordstern
Paul ist neu. Seit Montag gehört er zum Projekt „Nordstern“ – einer Plattform-Modernisierung, an der das Team bereits seit knapp zwei Jahren arbeitet. Sein Onboarding-Gespräch war freundlich, aber knapp: „Schau dir am besten erst mal die Doku an, dann sprechen wir am Freitag über deine Fragen.“
Also öffnet Paul am Dienstagmorgen mit einer großen Tasse Kaffee das Projektwiki.
Der Blick in die Spezifikationen
Er beginnt mit dem obersten Dokument: der Systemspezifikation. Und schon nach den ersten Seiten merkt Paul, dass dieses Dokument anders ist als das, was er aus früheren Projekten kennt.
Normalerweise liest er dort Sätze wie: „Die Authentifizierung erfolgt über OAuth 2.0 mit einem zentralen Identity-Provider.“ Punkt. Fertig. Und dann sitzt er da und fragt sich: Warum eigentlich? Was war die Alternative? Wer hat das entschieden?
Hier aber liest er:
„Wir haben uns für OAuth 2.0 mit zentralem Identity-Provider entschieden. Verworfene Alternative war ein föderiertes Modell pro Mandant – schneller einzuführen, aber schwer rückgängig zu machen, sobald Kunden es nutzen. Da wir die Mandantenstruktur in Phase 3 noch anpassen wollen, war uns Reversibilität wichtiger als kurzfristige Geschwindigkeit.“
Paul lehnt sich zurück. Aha. Er versteht nicht nur, was entschieden wurde, sondern warum und was das Team dabei abgewogen hat. Er kennt jetzt sogar ein Entscheidungskriterium, das offenbar im Projekt eine wichtige Rolle spielt: Reversibilität.
Orientierung finden
Im nächsten Abschnitt der Spezifikation stößt er auf einen kurzen Kasten:
„Annahme (Stand Q2): Die Zahl der externen Integrationen wird sich in den nächsten 18 Monaten verdoppeln. Diese Annahme liegt der Wahl der Message Queue zugrunde. Falls sie kippt, sollten die Kapitel 4.2 und 5.1 neu bewertet werden.“
Paul markiert sich die Stelle. Er hat nicht nur eine technische Aussage gelesen, sondern auch gleich einen Prüfpfad bekommen: Falls sich diese Annahme später als falsch herausstellt, weiß er, wo er ansetzen muss. Kein Nachbohren bei Kolleginnen und Kollegen nötig, keine Rätselraterei.
Die Landkarte der Dokumente
Am Mittwoch arbeitet Paul sich in das Architekturdokument vor. Auch hier findet er kommentierte Denkspuren:
„Wir gliedern die Architektur nach Prozessschritten, nicht nach Fachabteilungen/Domänen. Grund: Die meisten Schmerzpunkte im Altsystem entstanden an den Übergaben zwischen Fachabteilungen. Eine prozessorientierte Struktur macht diese Brüche sichtbar, bevor sie zu technischen Brüchen werden.“
Für Paul ist das ein Aha-Moment. Er versteht die Strukturierungslogik des Dokuments und indirekt auch eine Grundhaltung des Teams: Prozesse zuerst, Technik danach.
Als er im Verlauf des Tages auf ein Detaildokument zu einem konkreten Microservice stößt, weiß er schon, was ihn erwartet: Es wird an einem Prozessübergang „hängen“. Und tatsächlich: das Dokument beginnt mit genau dieser Verortung.
Die verworfenen Wege
Am Donnerstag findet Paul ein Kapitel, das ihn besonders beeindruckt: „Verworfene Optionen und warum“. Drei Seiten lang. Er liest über einen Ansatz, den das Team ein halbes Jahr lang verfolgt und dann verworfen hat.
„Wir verwerfen diese Option nicht, weil sie falsch war, sondern weil der Betriebsaufwand in unserem Kontext nicht tragbar ist. Für ein Team ab ca. 15 Personen wäre sie wieder erwägenswert.“
Paul denkt: Genau das hätte ich sonst irgendwann vorgeschlagen und mich blamiert, weil ich nicht wusste, dass es schon durchdacht wurde. Jetzt weiß er es. Und er weiß sogar, unter welchen Bedingungen das Thema wieder auf den Tisch käme.
Unsicherheit als Wegweiser
Am Freitagmorgen stößt er auf einen Abschnitt, der offen mit Unsicherheit umgeht:
„In diesem Bereich fehlen uns noch belastbare Nutzungsdaten. Die aktuelle Umsetzung ist eine bewusst vorläufige Richtung. Wir erwarten, spätestens nach dem Pilotbetrieb im Herbst nachschärfen zu müssen.“
Für Paul ist das Gold wert. Er weiß jetzt, an welchen Stellen das Fundament trägt – und wo es noch wackelt. Kein Kollege muss ihm sagen: „Vorsicht, das ist gerade in Bewegung.“ Es steht da.
Das Freitagsgespräch
Als Paul am Freitag mit seiner Teamleiterin spricht, ist er nicht der überforderte Neue, der zwanzig Basisfragen mitbringt. Er sagt stattdessen:
„Ich habe verstanden, warum ihr auf Reversibilität so viel Wert legt und dass ihr Prozessbrüche als Leitmotiv nehmt. Zwei Annahmen im Architekturdokument würde ich gerne noch einmal mit euch prüfen. Die eine scheint mir inzwischen möglicherweise überholt. Und in Kapitel 5 habt ihr eine Option verworfen, zu der ich eine kleine Ergänzung anbieten könnte.“
Seine Teamleiterin lächelt. „Willkommen im Team, Paul. Du bist schneller drin als die meisten.“
Was Paul durch kommentiertes Denken in der Doku gewinnt:
- Schnelles Verständnis, weil „Warum eigentlich?“-Fragen bereits im Text beantwortet sind
- Sicherheit, Ergebnisse im richtigen Kontext einzuordnen
- Klarheit darüber, welche Optionen bereits abgewogen und verworfen wurden
- Ein deutliches Bild, welche Aussagen im Dokument fest und welche vorläufig sind
- Das Gefühl, einem denkenden Team zu begegnen, statt vor einer Wand aus Entscheidungen zu stehen
Teil 2: Paul wird selbst zum Autor
Die zweite Woche
Paul hat seinen Rhythmus gefunden. Er bekommt sein erstes eigenes Arbeitspaket: einen neuen Adapter für ein externes Steuersystem. Kein riesiger Brocken, aber groß genug, dass er eigene Entscheidungen treffen muss und diese dokumentieren soll.
Seine Teamleiterin sagt beiläufig: „Schreib es so, wie du selbst gerne einsteigen würdest.“
Paul lächelt. Er weiß genau, was gemeint ist.
Der erste eigene Absatz
Er beginnt sein Konzeptdokument nicht mit einer Lösung, sondern mit einer Orientierung:
„Bevor ich die technische Anbindung entwerfe, kläre ich zuerst, ob das eigentliche Problem ein Datenformat-Thema, ein Zeitverhalten-Thema oder ein Berechtigungs-Thema ist. Meine bisherige Analyse deutet auf Zeitverhalten hin. Die anderen zwei bleiben aber im Blick.“
Er merkt, wie ungewohnt das Schreiben ist. Sonst hätte er einfach angefangen: „Der Adapter nutzt einen asynchronen Message-Handler…“, und niemand hätte gewusst, warum. Jetzt zwingt ihn das Dokument, zuerst seinen eigenen Denkweg zu klären. Und dabei bemerkt er: Zwei seiner Annahmen waren gar nicht so belastbar, wie er dachte.
Ein hilfreicher Nebeneffekt
Am Mittwoch stolpert Paul über etwas Merkwürdiges: Beim Formulieren einer verworfenen Alternative in seinem Dokument fällt ihm auf, dass seine „gewählte“ Lösung eigentlich die schwächere ist.
„Ursprünglich hatte ich Option A gewählt, weil sie einfacher wirkte. Beim Aufschreiben der Kriterien habe ich gemerkt, dass Option B in fast allen Punkten besser abschneidet – nur die Einarbeitungszeit war für mich der schnellere Weg. Ich wechsle deshalb zu Option B.“
Er streicht drei fertige Absätze und beginnt neu. Kein schlechtes Gefühl, im Gegenteil: Das kommentierte Denken hat ihn vor einer schlechten Entscheidung bewahrt, noch bevor sie in Code gegossen wurde.
Das Review
Am Donnerstag stellt Paul sein Dokument im Team-Review vor. Er ist etwas nervös. Sein Kollege Jonas, der schon länger im Projekt ist, liest sich in Ruhe ein und sagt dann:
„Ich mag, dass du deine Annahme zum Lastverhalten explizit als Annahme markiert hast. Wir hatten vor einem Jahr ein ähnliches Thema und dort ist genau diese Annahme gekippt. Lass mich dir kurz zeigen, wo das dokumentiert ist.“
Innerhalb von zwei Minuten haben die beiden eine inhaltliche Diskussion: nicht darüber, ob Paul eine Annahme hat, sondern welche Konsequenzen sich daraus ergeben. Kein Ego, kein Rechthaben. Beide sprechen über dieselbe explizite Sache.
Paul denkt: Das wäre nie so schnell gegangen, wenn meine Annahme nur implizit im Code gesteckt hätte.
Ein Wechsel der Perspektive
Freitagnachmittag, kurz vor dem Wochenende. Paul bekommt eine Chat-Nachricht von Lena, die am Montag als Werkstudentin einsteigen wird:
„Hi Paul, ich habe gehört, du bist auch neu. Hast du einen Tipp, wo ich am besten anfange zu lesen?“
Paul lehnt sich zurück. Vor zwei Wochen war er in genau dieser Situation. Er schreibt:
„Fang mit der Systemspezifikation an, aber lies nicht linear. Lies die Kommentare zwischen den Zeilen. In diesem Projekt steht in fast jedem Kapitel nicht nur, was entschieden wurde, sondern auch warum, welche Alternativen verworfen wurden und welche Annahmen dahinterstehen. Wenn du diese Denkspuren mitliest, verstehst du das Projekt viel schneller als über die eigentlichen Lösungen.“
Er zögert kurz und ergänzt:
„Und keine Sorge, wenn du unsicher bist. Im Doku-Team ist Unsicherheit ausdrücklich erlaubt. Sie steht sogar an vielen Stellen offen im Dokument. Das hat mir sehr geholfen.“
Ein stilles Aha
Als Paul am Abend seinen Rechner zuklappt, wird ihm bewusst, was in diesen zwei Wochen eigentlich passiert ist:
- Er hat sich nicht durch die Dokumentation gekämpft. Er hat sich mit ihr unterhalten.
- Er hat die erfahrenen Kolleginnen und Kollegen kennengelernt, ohne mit ihnen zu sprechen.
- Er hat gelernt, wie im Projekt gedacht wird, nicht nur, was gebaut wurde.
- Und er hat selbst begonnen, seine Denkweise sichtbar zu machen – nicht als Pflicht, sondern weil er den Nutzen am eigenen Leib erfahren hat.
Der eigentliche Effekt
Was hier zwischen den Zeilen passiert ist, ist nicht nur Onboarding. Es ist Kulturweitergabe.
Diese Haltung überträgt sich fast automatisch auf Paul. Und über Lena, die er am Montag anlernen wird, ins nächste Glied der Kette.
Was das Team dadurch gewinnt
Als Paul am Abend seinen Rechner zuklappt, wird ihm bewusst, was in diesen zwei Wochen eigentlich passiert ist:
- Onboarding-Zeit sinkt drastisch – weil Wissen nicht mündlich weitergegeben werden muss.
- Entscheidungen bleiben nachvollziehbar – auch nach personellen Wechseln.
- Diskussionen werden inhaltlicher – weil Annahmen und Kriterien explizit vorliegen.
- Alte Sackgassen werden nicht wiederholt – weil verworfene Optionen dokumentiert sind.
- Vertrauen wächst – weil Unsicherheit als Teil des Denkens anerkannt wird, nicht als Schwäche.
Und das Beste: Es kostet nicht mehr Zeit als „normale“ Dokumentation. Es kostet nur die Bereitschaft, den eigenen Denkweg mit aufzuschreiben statt nur sein Ergebnis.
Kommentiertes Denken in der Dokumentation ist damit nicht bloß eine Schreibtechnik. Es ist die schriftliche Form dessen, was in Präsenzzeiten das Über-die-Schulter-Schauen war – nur dass sie zeit- und ortsunabhängig funktioniert. Und dass sie, einmal etabliert, sich selbst trägt.
Kommentiertes Denken – Kurzanleitung für die Praxis
Nicht nur zeigen, was entsteht, sondern aussprechen/aufschreiben, warum es so entsteht.
Kommentiertes Denken macht den unsichtbaren Denkweg sichtbar. Es überträgt das frühere „Über-die-Schulter-Schauen“ in die Remote-Arbeit und in schriftliche Dokumentation.
Beim Formulieren immer klar kennzeichnen:
Fakt – Interpretation – Annahme – offene Frage
Diese Trennung ist der Kern professioneller Klarheit. Sie ermöglicht anderen, gezielt an der richtigen Stelle nachzufragen oder weiterzudenken.
- Wirkung – Was verändert am meisten?
- Risiko – Was kann schiefgehen?
- Dringlichkeit – Was muss jetzt entschieden werden?
- Reversibilität – Können wir das leicht korrigieren?
- Aufwand – Was ist realistisch leistbar?
- Abhängigkeiten – Was blockiert andere Schritte?
- Stakeholder – Wer ist betroffen?
Live – im Meeting oder am Whiteboard: Denkweg aussprechen, während er entsteht. Nicht nur das Ergebnis zeigen, sondern die Bewegung dorthin.
Schriftlich – in Dokumentation: Denkweg in den Text integrieren. Kurze Kommentar-Absätze zu Entscheidungen, Alternativen, Annahmen und Unsicherheiten – direkt an der jeweiligen Stelle im Dokument.
1. Klein anfangen: Mit einem Aspekt beginnen (z. B. Annahmen sichtbar machen). Nicht alle acht auf einmal einführen.
2. Vorbild statt Vorschrift: Erfahrene Kolleginnen und Kollegen machen den Anfang: live in Meetings, schriftlich in Dokumenten. Andere übernehmen den Stil fast automatisch.
3. Im Review honorieren: Beim Durchsehen von Dokumenten oder Board-Ergebnissen gezielt nachfragen: „Was war die verworfene Alternative? Welche Annahme steckt dahinter?“ – So wird kommentiertes Denken zur Selbstverständlichkeit.
- Wissen wird übertragbar – auch ohne persönliche Anwesenheit.
- Onboarding beschleunigt sich – neue Kolleginnen und Kollegen verstehen nicht nur das Was, sondern das Warum.
- Entscheidungen bleiben nachvollziehbar – auch Monate später.
- Diskussionen werden konkreter – weil explizit ist, worum es geht.
- Kultur überträgt sich mit – Denkhaltung wird spürbar, nicht nur Inhalt.
Merksatz: Wer erklärt, wie er denkt, macht sein Wissen teilbar.
Über den Autor
Wolfgang Krug ist Senior Managing Consultant bei BettercallPaul in München. Als erfahrener IT-Berater beschäftigt er sich vor allem mit Anforderungsmanagement, Facharchitektur, Prozessmodellierung und Qualitätsmanagement. Dabei begleitet er komplexe Softwareprojekte von der fachlichen Analyse und Konzeption bis zur Einführung und verbindet langjährige Projekterfahrung mit einem besonderen Blick für klare Strukturen und tragfähige Lösungen.
Hinweis:
Falls du dir diesen Artikel hast vorlesen lassen: Die Audioversion wurde mithilfe einer KI-generierten Stimme erstellt.
