工程判斷與責任
在需求、時間、品質、成本與風險之間，做出適合當下條件的選擇
在需求、時間、品質、成本與風險之間，做出適合當下條件的選擇
工程問題通常沒有唯一答案
| 想得到的東西 | 可能付出的代價 |
|---|---|
| 更快交付 | 技術債、測試不足、範圍縮小 |
| 更高可用性 | 架構、基礎設施與維運成本 |
| 更彈性 | 更多抽象、設定與理解成本 |
| 更安全 | 流程摩擦、權限管理與額外驗證 |
先把決策條件說清楚
- 目標與成功標準是什麼？
- Deadline、budget、team skill 與既有資產
- 哪些風險可以接受，哪些絕對不能發生？
- 哪些資訊已知，哪些仍是假設？
- 決策可逆嗎？錯了要付出多少代價？
Scope 與優先順序
- Must、should、could、won’t
- 先交付 end-to-end 的最小可用切片
- 區分核心價值、必要護欄與可延後優化
- Dependency、critical path 與 sequencing
- Scope creep 出現時重新談成本與期限
Estimation 不是精準預言
- 拆解已知工作與未知探索
- 標示 dependency、風險、假設與信心區間
- Spike／prototype 用來降低未知
- 估算隨新證據更新，不把早期數字當承諾
- Lead time、cycle time、throughput 提供歷史參考
Risk Assessment
Risk = 發生機率 × 影響程度- Avoid、reduce、transfer、accept
- Prevention、detection、response、recovery
- 建 risk register，指定 owner 與觸發條件
- 高衝擊且不可逆的決策需要更深理解與更多證據
Build、Buy、Reuse 或停止
- 是否已有服務、套件或組織能力可以沿用？
- License、vendor lock-in、資料出口與長期成本
- 自建的差異化價值是否值得維運責任？
- 需求是否其實可以用流程調整解決？
- 「不做」也是需要說明理由的工程決策
何時應該 Refactor？
- 同一類變更反覆碰到多個地方
- 缺陷、衝突、理解與測試成本持續增加
- 新需求已使原本假設失效
- 先比較重構成本、未來修改頻率與替代方案
- 不為尚未出現的需求提前建立所有抽象
Decision Record
Context：當時的條件
Options：比較過哪些方案
Decision：選擇什麼
Trade-offs：交換了什麼
Evidence：依據哪些資料
Revisit trigger：何時重新評估
Owner：誰負責後續結果新證據出現後
原本決策 → 條件改變 → 觀察失效訊號
→ 比較維持、局部修改或推翻
→ 留下 Decision Delta成熟不是永遠第一次就選對，而是知道何時改變主意。
Ownership
- 誰 approve requirement、architecture、security、release？
- 誰在事故時有權停止、rollback 或切換流量？
- Agent、工具與顧問可以提供建議，不是責任主體
- 人工背書應集中在高風險、不可逆與領域核心位置
- 決策、證據與 owner 都要可以追溯
看到 Agent 提出方案時
要能要求它列出 assumption、alternative、trade-off、risk 與 evidence，
再由有責任的人做最後決定。