Mein Kapitel aus dem Buch: Machines, Code, People: 50 things Zühlke engineers are passionate about
Stell dir vor, du kommst an einem Montagmorgen ins Büro, fährst deinen Computer hoch und ba-bam, ein Manager steht neben dir und fordert dich auf, ihm in ein Eskalationsmeeting zu folgen.
Es gibt ein Problem mit der Software, die du in Produktion bringst. Im Meeting sitzen der CIO, dein Vorgesetzter, der Linienmanager Technologie, der Linienmanager Betrieb, der zentrale Architektur-Linienmanager und du.
Es gibt ein Problem mit einer Library, die du vor einem Jahr in deine Software eingeführt hast. Sie verursacht Abstürze der Software in Produktion und das Unternehmen verliert Geld, weil die Anwender nicht arbeiten können.
Die Manager wollen wissen, warum du dich für diese Library entschieden hast und wer dir die Freigabe für die Verwendung dieser Library gegeben hat. Es gibt nun zwei Möglichkeiten:
A) Du beginnst mit hmmm, das war vor einem Jahr und hmmm, eigentlich weiss ich es nicht, aber das ist jetzt nicht von Interesse, lass mich gehen und das Problem beheben…. sehr schlechte Idee! Du bist erledigt…
B) Du nimmst den Laptop, navigierst zur Liste der Architekturentscheidungen, zeigst ihnen die Architekturentscheidung mit der Bewertung und der Freigabe. Und dann sagst du: «Entschuldigt ihr mich? Ich habe ein Problem zu lösen.»
Natürlich: Alle Personen und Ereignisse in diesem Artikel sind völlig fiktiv ;-).
Ich weiss, du hasst es, Dinge zu dokumentieren, und ich weiss, du denkst, du wirst dich an alles erinnern. Aber nimm einfach meinen Rat für deine Karriere an. Nutze CYA = Cover your ass. CYA hat eine einfache Regel: Document EVERY Decision => DED
Ja, dokumentiere jede Entscheidung. Egal ob du Software-Architekt, Business Analyst, Consultant, Engineer, Entwickler, Manager oder ein flauschiges Einhorn bist, das auf einem Regenbogen tanzt.
Wie dokumentierst du also eine Entscheidung?#
Du erstellst ein Decision Log in tabellarischer Form in einem geeigneten Medium (Git, Wiki, SharePoint, Word, Excel, …).
Nummer: Jede Entscheidung hat eine ID oder Nummer. Diese kann als Referenz verwendet werden.
Was: Was ist die Entscheidung, die getroffen wurde?
Warum: Die Begründung und Argumente, Einschränkungen, Implikationen und Referenzen.
- Kontext: In diesem Teil dokumentieren wir den Kontext der Entscheidung. Wir geben dem Leser einige Zusatzinformationen, damit er den Kontext der Entscheidung verstehen kann.
- Problem: Das Problem oder die Herausforderung, die zu dieser Entscheidung führt.
- Entscheidung: Die getroffene Entscheidung. Dokumentiere hier die Bewertung, die zu dieser Entscheidung geführt hat.
- Konsequenzen: Die Konsequenzen der Entscheidung.
Wann: Wann wurde die Entscheidung getroffen?
Wer: Wer war an dieser Entscheidung beteiligt? Hinweis: Je mehr Personen einer Entscheidung zugestimmt haben, desto besser.
Wir werden in unserem Projekt ein Decision Log verwenden
Entscheidungen müssen dokumentiert werden, damit jeder weiss, warum eine Entscheidung getroffen wurde.
Nicht jeder erinnert sich nach mehr als einem Jahr daran, warum eine Entscheidung getroffen wurde.
Wissensabfluss: Personen verlassen das Projekt
Wir führen ein Decision Log ein.
Jede Entscheidung wird im Decision Log dokumentiert
Hans Muster Simon Stucki
Was passiert, wenn eine Entscheidung widerrufen wird? Streiche die Entscheidung durch und definiere eine neue Entscheidung, in der du dokumentierst, warum Entscheidung Nr. X widerrufen wurde.
CYA = Cover your ass macht dir das Leben leicht und jeder in deinem Team weiss, wo er nachschauen kann, warum eine Entscheidung getroffen wurde, sodass du zum nächsten Projekt wechseln kannst, ohne von unbekannten alten Entscheidungen aus der Vergangenheit verfolgt zu werden.