寫下日後可以重新檢視的決定

保留決策理由

決策會議產生選擇。決策紀錄保留該選擇為何合理。

缺少理由，後續團隊可能把暫時限制誤認為永久原則，也可能重做組織已完成的評估。

AWS 將架構決策紀錄描述為記錄決定及其背景的方法。同樣精簡的結構，也有助於記錄 AI 開發維運模式。控制篇幅，讓負責人願意讀完。

比較可行替代方案

虛構公司需要維護合約應用程式，考慮三個選項：

使用相同應用程式範圍、期間、資料假設和服務預期。避免拿成熟的採購服務，與內部系統只有原型階段的成本比較。

組合方案也可能適用。現有平台可以提供環境和部署，由軟體工廠協調開發。解釋介面與責任歸屬，不必強迫做出非此即彼的選擇。

寫下六個部分

1. 背景。 說明問題，以及不改變的後果。
2. 要求。 列出選項必須滿足的條件。
3. 替代方案。 記錄認真考慮的選項與主要取捨。
4. 證據。 連結評估、成本假設和未解問題。
5. 決定。 指出選定方案、範圍、負責人和接受的限制。
6. 複查。 定義必須重新評估的日期或可觀察事件。

區分觀察與預期。「評估期間完成了這項維護變更」是觀察。「服務將讓年度維護成本減半」則是預測，需要證據與明確假設。

納入最有力的反對理由

對合約應用程式而言，採購服務可能減少整合工作，卻形成對外部提供者的依賴。記錄這項反對理由，以及能處理部分疑慮的匯出演練。不要因團隊偏好該選項，就刪去反對理由。

說明哪些未解事項會阻擋啟用。其餘事項指定負責人與日期。決定繼續，不會把尚未回答的控制問題變成已驗證結果。

要求或證據改變時，重新檢視紀錄。選擇改變時，新增決定並保留先前理由。繼續前往Taiga 實用情境，將這些原則應用於產品流程。