Thema: decision-making
-
DACI und RACI für technische Entscheidungen: eine genehmigende Person, benannte Mitwirkende
DACI benennt eine treibende Person, die die Entscheidung vorantreibt, eine einzige genehmigende Person, die sie trifft, Mitwirkende, die eine Stimme, aber kein Stimmrecht haben, sowie informierte Parteien, die vom Ergebnis erfahren; RACI weist Aufgaben die Rollen verantwortlich, rechenschaftspflichtig, konsultiert und informiert zu. Beide funktionieren für technische Entscheidungen, wenn die Rollen vor Beginn der Diskussion schriftlich festgelegt werden.
-
Go oder Rust für einen neuen Dienst wählen: ein Entscheidungsverfahren ohne Benchmarks
Die Wahl zwischen Go und Rust für einen Dienst anhand dokumentierter Spracheigenschaften und Teambeschränkungen treffen statt anhand von Benchmark-Folklore: Speicherverwaltungsmodell, Fehler- und Nebenläufigkeitsstil, Form der Arbeitslast, die Bibliotheken, mit denen der Dienst sprechen muss, und wer ihn in zwei Jahren pflegen wird.
-
Technische Schulden als bewusste Entscheidung mit Buchführung
Cunninghams Metapher: Nicht ganz richtiger Code ist ein Kredit, jede Minute Mehrarbeit daran ist der Zins. Die Metapher trägt nur, wenn die Schuld bewusst aufgenommen, notiert und regelmässig bewertet wird; als Sammelbegriff für alles Unschöne oder als Entschuldigung für Schlamperei ist sie wertlos.
-
Technische Schulden als Metapher und als Entscheidung
Technische Schulden beschreiben die künftigen Kosten einer Abkürzung; die Metapher ist nützlich, wenn die Schulden bewusst eingegangen und nachverfolgt werden, und irreführend, wenn sie nachlässige Arbeit entschuldigt oder auf jede Unvollkommenheit angewendet wird.
-
Enthaltung als Agent: wenn Nicht-Handeln die richtige Ausgabe ist
Der Ausgaberaum eines Agenten sollte für jede automatisierte Aktion ein bewusstes «nicht entschieden» enthalten: was Enthaltung ist, warum ein Klassifikator oder Agent ohne sie jeden unklaren Fall in eine falsche Aktion verwandelt, und wie sich Enthaltung durch explizite Optionen, Konfidenz-Untergrenzen, einsatzabhängige Schwellenwerte und einen Weg für das Enthaltene einbauen lässt.
-
Architecture Decision Records (ADR)
Ein Architecture Decision Record hält eine bedeutsame Entscheidung mit ihrem Kontext, der Entscheidung selbst, ihrem Status und ihren Konsequenzen in einer kurzen, beim Code abgelegten Datei fest.
-
RICE- und ICE-Bewertung: was die Zahlen bedeuten und wo sie an ihre Grenzen stossen
RICE multipliziert Reichweite, Wirkung und Zuversicht und teilt durch den Aufwand; ICE lässt die Reichweite weg und behält Wirkung, Zuversicht und Einfachheit. Beide sind nützlich, um Priorisierungsargumente explizit und vergleichbar zu machen, und beide versagen, wenn die Eingaben als Zahlen verkleidete Vermutungen sind oder wenn Abhängigkeiten und Strategie ignoriert werden.
-
Entscheidungsprotokolleinträge mit einer schriftlichen Vorhersage verbessern spätere Schätzungen
Hypothese: Ein Team, das zu jeder nicht trivialen Entscheidung eine konkrete Vorhersage ihres Ausgangs und ein Überprüfungsdatum festhält und die Vorhersage später bewertet, wird über Monate hinweg besser kalibriert als ein Team, das Entscheidungen nur mit Begründung festhält; ein vorgeschlagener Vergleich.
-
Aufwand als Spanne mit angegebenem Vertrauen schätzen
Eine Schätzung als Spanne abgeben (bester Fall, erwarteter Wert, schlechtester Fall) plus die Zuversicht, dass der wahre Wert darin liegt; die Breite an den Ergebnissen vergleichbarer früherer Arbeit ausrichten statt am Plan, und an festen Punkten nachführen. Eine einzelne Zahl verbirgt genau die Unsicherheit, von der Entscheidungen abhängen.
-
Ein Design-Review durchführen: Kommentarfrist, benannte Entscheidungsperson und dokumentierte Entscheidung
Ein Vorschlags-Review braucht eine begrenzte Kommentarfrist, eine benannte Person oder Gruppe, die entscheidet, eine schriftlich festgehaltene Entscheidung (annehmen, ablehnen, zurückstellen) mit Begründung sowie eine Regel für die Wiedereröffnung; der Rust-RFC-Prozess und Pythons PEP-Prozess zeigen die Form, und diese Methodik passt sie an ein einzelnes Team an.
-
Grössenordnung schätzen, bevor gemessen wird
Eine unbekannte Grösse in Faktoren zerlegen, die sich eingrenzen lassen, die Schätzungen multiplizieren und das Ergebnis als Bereich angeben; eine Fünf-Minuten-Schätzung zeigt, ob ein Entwurf machbar ist und was zuerst gemessen werden sollte.
-
Governance für ein kleines Projekt: Entscheidungsrechte festgehalten, bevor sie gebraucht werden
Eine Governance-Datei beantwortet, wer mergen darf, wer einen Streit über den Projektumfang entscheidet, wie Maintainer hinzugefügt und entfernt werden und wie sich die Regeln selbst ändern. Pythons PEP 13 zeigt ein Ratsmodell mit einer Autorität, die absichtlich selten genutzt und öffentlich beraten werden soll; das Apache-Glossar definiert Lazy Consensus, wonach ein Vorschlag angenommen ist, wenn innerhalb einer festgelegten Frist niemand widerspricht. Ein Projekt mit ein bis drei Maintainern braucht nur eine Seite.
-
Ein persönliches Entscheidungsjournal: den Eintrag schreiben, bevor das Ergebnis bekannt ist
Ein vorgeschlagenes Format für das persönliche Entscheidungsjournal eines Individuums: ein Eintrag pro nicht trivialer Entscheidung, geschrieben vor dem Handeln, mit den erwogenen Optionen, dem erwarteten Ergebnis, der als Zahl angegebenen Zuversicht und einem Überprüfungsdatum; die spätere Überprüfung vergleicht Erwartung mit Ergebnis und trennt die Qualität der Entscheidung vom Glück des Ausgangs.
-
Roadmaps as bets with review dates
Write a roadmap as a short list of bets, each with the outcome it pays out, the time the team is willing to spend, and a date on which it is reviewed and either continued, re-scoped or stopped; Shape Up's betting model supplies the framing, the review date turns a plan into a decision that expires.
-
Reading vendor claims about decision models: schema conformance is not correctness
How to separate what is checkable in a decision-model launch (published prices, the by-construction guarantee that outputs stay inside the schema, documented limits) from what is self-reported (speed and cost multipliers on the vendor's own evaluations, intelligence parity on 'System One-shaped' tasks), using the Jev launch of September 2026 as the worked example.
-
When an agent should stop and ask: a decision procedure for clarifying questions
A short procedure for deciding, before acting on an ambiguous instruction, whether to proceed under a stated assumption or to ask: proceed when the readings lead to the same work or the difference is cheap to undo, ask when they lead to materially different results or an action that cannot be reversed, and in either case say which reading was taken.
Maschinenlesbar: JSON