記錄軟體架構決策對於儲存設計選擇背後的背景和理由非常重要，這對未來的自己和團隊來說都是無價之寶：
在過去的兩年裡，我一直在從事一個有趣的應用程式現代化專案。它涉及將業務線從數十年歷史的單體應用轉移到更現代的 SaaS 應用程式。作為這一旅程的一部分，我們必須做出很多決定！我們需要這個特定功能嗎？解決此功能可以透過多種方式完成，那麼哪種方式是正確的？我知道，在這個過程中，人們會質疑我們為什麼做出這個選擇。
我在《紐約時報》擔任設計工作的朋友有一個很棒的單頁模板，用於推銷創意或潛在專案。Olivia Cheng向我介紹了這個模板。這份單頁模板概述了問題以及將創意轉化為潛在專案的初步討論。目標是引導團隊、領導層和利益相關者。這份單頁模板的元素包括：
- 問題是什麼？在這裡，您可以描述要解決的問題及其關鍵影響。
- 機會是什麼？解決這個問題能給企業帶來什麼？
- 你的目標清單
- 成功指標。您如何衡量它？
- 挑戰是什麼？每個挑戰的簡要描述。
- 團隊和利益相關者受到影響。
我知道這個模板的真正目的是為你提出一個想法，但它包含了我所尋找的許多正確元素。
第一次記錄決策
開始使用這個詳細的模板來跟蹤專案中的決策：
模式和模式語言告訴我，任何問題的解決方案總是有背景。因此，我修改了這個模板以包含以下元素。這是一個自由流動的文件，每個元素都有標題。
- 上下文：我以段落中的上下文作為開頭。上下文描述了與我們必須解決的問題或困境相關的具體領域。
- 問題：我們具體要解決什麼問題？我儘量在這裡說得儘可能具體。由於人們已經閱讀了上下文，他們現在可以更好地理解這些問題。
- 機會：在這裡，我描述了為什麼解決這個問題至關重要，以及它如何改善企業或使用者的狀況。
- 成功指標：我們如何衡量成功指標？我們可以衡量哪些指標？
- 受影響的團隊：哪些人會受到此決定的影響？
- 已知的挑戰和限制：我們是否知道做出此決定時需要解決的任何具體問題或事情？我會在此處記錄所有重要問題。
- 未解決的問題：最初，在嘗試解決問題並尋找解決方案時，可能會出現許多未解決的問題，我們需要找到答案。我在本部分中記錄了這些問題。
- 建議的決定：經過審議和審查調查結果後，我將使用此部分來記錄商定的決定。
- 附錄：如果我在回答這個問題時有幾個選項需要評估，我會將每個選項記錄為附錄，並附上它的優點和缺點。
但發現模板過於冗長，難以快速瞭解當前狀態：
於是，從其他模板中汲取靈感，如 "one-pager pitch deck "和安德魯-哈梅爾-勞（Andrew Harmel-Law）關於 "Scaling the Practice of Architecture, Conversationally "的建議，對這一方法進行了迭代。
改進後的決策記錄模板的關鍵要素包括
- 狀態（草案/建議/透過/過期），以便快速檢視決策的當前狀態
- 行動專案，作為下一步措施的清單
- 需要決定的明確問題及其相關背景
- 建議的決策、支援性論據和潛在後果/制約因素
- 考慮過的其他方案、受影響的利益相關者以及相關參考資料
這種更簡潔、更直觀的格式對於在團隊中記錄和交流軟體架構決策更為有效。