# 為什麼工程師應該承擔責任：讀《Going Direct》有感

參考出處：《[Going direct](https://theengineeringmanager.substack.com/p/going-direct?utm_source=substack&utm_campaign=post_embed&utm_medium=email)》

《Going Direct》主張「直接對話、直接承擔、直接修正」，核心在於移除不必要的轉述層與責任模糊，讓問題可以由最靠近真實狀況的人快速處理。對資深工程師而言，這不只是溝通風格的選擇，而是影響交付速度、風險暴露、團隊信任與技術債管理的關鍵能力。當專案規模擴大、跨部門依賴增多、系統複雜度攀升，責任劃分與決策透明度如果跟不上成長，代價通常以延遲、返工、值班負擔與士氣流失呈現。
本篇以《Going Direct》為骨幹，結合實務方法（如 DRI、RACI、ADR、事前預想與事後檢討）與工程師日常痛點（高壓決策、權責不清、跨團隊協作摩擦）提出具體可行的落實策略。

### 重點列表
- 主題與重要性：直接承擔責任能縮短問題回路、減少誤解與資訊耗損，對維運穩定性與交付可預期性有決定性影響。
- 工程情境的責任議題：複雜系統中的「誰決定、誰執行、誰背書」常被稀釋；缺乏明確 DRI 時，問題會在組織間彈跳。
- 決策壓力與風險：高風險變更、時間緊迫、資料不完備；此時「Going Direct」能避免層層轉述造成延宕。
- 團隊協作：跨部門需求多且頻繁，若沒有清楚責任歸屬與溝通契約，協作成本與情緒成本會急速累積。

### 補充範例／常見問答
- 示意：兩種處理同一事故的差異
1) 多層轉述：值班工程師 → Team Lead → PM → 供應商窗口 → SRE → 資料庫管理 → 再回傳 → 執行修復
2) Going Direct：值班工程師直接與資料庫值班、SRE 群組建立三方通話，現地診斷、即時變更、即時回報
後者明顯降低資訊丟失與等待時間。
- Q：如果我的職稱不高，直接對話會不會被視為越級？
A：先對齊「問題所有權」與「當值責任」。以既有的事故流程、通報頻道（如 on-call 群組、事故橋）為依據，鎖定 DRI 與相依 DRI。重點在透明同步進展，不是繞過主管；事後將決策紀錄進 ADR 或事故報告，確保可追溯。

---

## 文章核心觀點與摘要
### 說明
《Going Direct》的核心是「把問題帶到能解決它的人」，並以清楚責任歸屬與快速反饋迴圈，降低決策與溝通摩擦。不是要忽視管理層，而是避免把轉述與等待當成流程本身。它鼓勵工程師主動擁有結果（own the outcome），在失敗時直接面對、即時修正，並藉由清晰紀錄與可觀察性，讓風險與學習留在系統中持續滾動改善。

### 重點列表
- 直接對話（Go to the DRI）：明確指定 Directly Responsible Individual（DRI），遇到問題先找 DRI 與當值負責人，而非先走層級路徑。
- 擁有結果而非只做任務：責任不止於把 Jira 任務打勾，而是確保使用者價值達成、系統可用性維持、長尾風險被紀錄與追蹤。
- 決策清晰度：用簡潔的決策記錄（ADR）、RACI 與變更備案（rollback/feature flag）讓權責與風險可見，避免會議定義不清。
- 失敗的正向面對：落實無責備（blameless）但有責任（accountable）的事後檢討，將學習轉為守則（runbook、警示規則、SLO/error budget）。
- 循環短而頻：短迴路同步（Slack/事故橋/每日站會），週期性與里程碑同步（週會/里程碑審查/風險評估），形成多層次回饋系統。

### 補充範例／常見問答
- 決策紀錄（ADR）簡版樣板（示意）

  ADR-023: 切換搜尋服務的索引策略
  決策者（DRI）：搜尋服務負責人 A
  參與諮詢：資料庫管理、SRE、產品、法遵
  背景：高峰期查詢延遲升高，現行策略無法滿足 SLO
  選項：A）維持現況 B）改為增量索引 C）改為批次索引 + 快取
  決策：C（兩階段導入 + feature flag）
  風險：批次延遲、快取穿透
  緩解：分流 5%→20%→50%→100%、回滾腳本、額外監控面板
  結果追蹤：T+7 日評估 p95 延遲與錯誤率

- Q：直接對話會不會造成「多頭馬車」或資訊轟炸？
A：以 DRI 為樞紐集中決策，使用一頁式共識文件與單一同步頻道，其他人可訂閱但避免平行開分身討論。會後用 ADR/會議記錄固化結論，降低重複對齊成本。

---

## 個人反思與實際應用建議
### 說明
從工程現場回望，《Going Direct》不是人格特質，而是一組系統化做法：責任歸屬、決策紀錄、風險管理、溝通契約、度量與學習。當我用它解開「權責不清、無限等待、會議再會議」的結構性問題時，交付速度與團隊信任同步提升。

### 重點列表
- 建立責任歸屬基礎設施
- 指派每個服務/專案的 DRI 清單（含代理人）、公開可查；跨團隊議題先由各方 DRI 對齊。
- 用 RACI 明確「誰負責（Responsible）/誰背書（Accountable）/誰諮詢（Consulted）/誰知會（Informed）」。
- 在每次重大變更附上 ADR 或變更票，將「決策脈絡」與「回滾機制」寫明。
- 風險預防與事後學習
- 大型發佈前做 premortem（事前預想）：列出失敗情境、警示訊號、緩解步驟與停損條件。
- 事故後 48 小時內完成無責備事後檢討：聚焦系統與流程，產出可執行改善，對齊 SLO/error budget。
- 溝通與協作契約
- 定義單一同步頻道（如 incident-bridge、#proj-foo），規範訊息格式（狀態、風險、下一步、需要協助）。
- 建立利害關係人地圖與節奏（每日站會、週同步、里程碑評審），讓資訊迴路可預期。
- 降低個人壓力與風險分攤
- 值班輪值制度、交接清單、runbook；避免「單點菁英」模式。
- 使用 feature flag、灰度釋出、金絲雀發佈，將風險切片，讓責任可被測量與分享。
- 指標與回饋
- 以 DORA 指標（部署頻率、變更失敗率、變更前置時間、MTTR）追蹤改進是否有效。
- 每季回顧前 3 大風險、前 3 個瓶頸，將學習回灌到模板與工具。

### 補充範例／常見問答
- 責任追蹤板樣板（示意）

  專案：支付風險管控改版（Q4）
  ----------------------------------------------------------------
  項目               DRI     截止日    風險等級  狀態     下一步
  規則引擎升級       Mei     10/12     中       進行中   T+2 日 20% 灰度
  交易監控告警       Han     10/15     高       待開始   撰寫告警門檻 ADR
  失敗回放機制       Lin     10/20     中       進行中   建置回滾腳本
  合規審查           Joy     10/25     低       完成     上傳審查紀錄
  ----------------------------------------------------------------
  單一同步頻道：#proj-risk-q4；週會時間：每週二 10:00

- Q：我不是正式 DRI，是否還應該「承擔」？
A：可以主動承擔清楚界定的「次責任」：如撰寫 ADR、維護 runbook、提出風險清單。Going Direct 的精神是縮短回路與提升清晰度，而非搶奪決策權。若觀察到責任真空，先提出「我願意先當臨時 DRI，直到找到適任者」並公開記錄。

---

## 常見問題與挑戰解答
### 說明
落地過程最常遇到的阻力包含：權責不清、跨部門摩擦、越級疑慮、非同步協作失靈，以及指標被誤用導致責怪文化。以下給出可立即採用的對策。

### 重點列表
- 權責不清怎麼辦
- 先產出 1 頁「問題定義＋候選 DRI 名單」，會內 15 分鐘決定 DRI 與代理人。
- 用 RACI 速記卡對齊邊界，避免「大家都關心、沒人負責」。
- 越級溝通的平衡
- 在「事故、阻塞、時效性高」時優先 Going Direct，同步在公開頻道與週報中標記主管知悉，避免黑箱。
- 跨部門摩擦
- 設立單一跨部門看板與節奏（例：每週 30 分鐘共識會）；決策以 ADR 為準，避免口語對齊失真。
- 遠端與非同步協作
- 使用結構化更新格式（狀態、風險、阻塞、請求），禁止只貼「進度 OK」的空訊息。
- 指標與責怪
- 指標服務於學習，不服務於究責個人。事故後只討論機制與流程，稱讚早期提報與勇於回滾的行為。

### 補充範例／常見問答
- 初期責任追蹤機制落地時間表（示意）

  週 1：列出所有服務的 DRI/代理人清單，建立 #services-owners 公開文件
  週 2：為每個進行中專案建立 RACI 與單一同步頻道
  週 3：制定 ADR 模板 + 事前預想（premortem）清單
  週 4：建立事故橋流程、事後檢討模板與 SLO 儀表板連結
  週 5：復盤採用情況，移除不必要表單，保留有效的最小集合

- Q：如何在初期就建立可追蹤的責任機制？
A：先小規模試點於 1～2 個專案，公開產出（DRI 清單、ADR、事後檢討），每週收集阻力點即時修剪模板。原則是「能自動化就自動化、能預設就預設、能公開就公開」。

---

## 延伸資源與後續學習
### 說明
責任歸屬、溝通與風險控制是一組需要長期練習的工程能力。以下資源有助深化制度設計與團隊實作。

### 重點列表
- 書籍與白皮書
- Accelerate（Nicole Forsgren, Jez Humble, Gene Kim）：以資料導向驅動軟體交付效能。
- Site Reliability Engineering（Google SRE Book）與 SRE Workbook：事件管理、SLO、錯誤預算。
- An Elegant Puzzle（Will Larson）、Staff Engineer（Will Larson）：資深工程師的影響力與系統思維。
- The Manager’s Path（Camille Fournier）：技術領導與組織協作。
- Extreme Ownership（Jocko Willink, Leif Babin）：責任與領導心態。
- 實務與社群
- Incident.io、PagerDuty Blog 的事故管理實務；Team Topologies（Matthew Skelton, Manuel Pais）。
- SREcon / QCon 演講、在地社群（g0v、Taipei.py、DevOps Taiwan）。
- 建議行動
- 將 ADR、RACI、事後檢討模板放入 repo；以 PR 流程維護與演進。
- 每季檢視 DORA 指標與前 3 大風險，持續微調流程。

### 補充範例／常見問答
- 自我檢討回饋迴圈（簡表）

  事件 → 記錄 → 分析 → 改善 → 標準化 → 教育 → 指標追蹤 → 迭代
  核心問題：這一步怎麼變得更容易？（工具化、模板化、自動化）

---

## 結論
Going Direct 的本質是「用清晰的責任與最短的回路，縮短從問題到解法的距離」。對工程師而言，承擔責任不等於孤軍奮戰，而是主動定義 DRI、用 ADR 固化決策、用 RACI 對齊邊界、用 SLO 與事故流程把風險導入系統可學的軌道。建議接下來 30/60/90 日行動：
- 30 日內完成服務 DRI 清單與單一同步頻道；導入 ADR 模板。
- 60 日內建立事前預想與事後檢討流程，串接監控面板與回滾機制。
- 90 日內以 DORA 指標與前 3 大風險為基準做一次流程優化。
當責任變得清楚、回路變得短，交付速度與可信度自然拉升；工程團隊也更有餘裕在高變動環境中穩定前進。

---

## 附錄：專有名詞解釋

* **DRI (Directly Responsible Individual)**：直接負責人，明確指定誰對某個任務或決策最終負責，避免責任模糊。
* **RACI**：責任分配矩陣，分為 Responsible（執行）、Accountable（背書/最終負責）、Consulted（諮詢）、Informed（知會）。
* **ADR (Architecture Decision Record / 決策紀錄)**：簡潔的文件，記錄某項架構或技術決策的背景、選項、決策內容與影響，方便追溯。
* **Premortem（事前預想）**：在計畫開始前預先假設失敗情境，列出可能原因與應對措施，以降低風險。
* **Postmortem（事後檢討）**：在事件或事故發生後，檢視問題成因與流程缺陷，聚焦於系統與流程改善，而非責怪個人。
* **Blameless（無責備文化）**：強調事故檢討聚焦於改善，不針對個人責怪，促進公開透明的分享與學習。
* **Runbook**：標準操作手冊，記錄常見問題與解決步驟，供值班工程師快速處理。
* **SLO (Service Level Objective)**：服務等級目標，定義系統在可用性、效能等方面的量化標準。
* **Error Budget**：錯誤預算，允許系統在一段時間內出現的最大誤差或失效比例，幫助平衡創新速度與穩定性。
* **DORA Metrics**：用於衡量軟體交付效能的四大指標，包括部署頻率（Deployment Frequency）、變更前置時間（Lead Time for Changes）、變更失敗率（Change Failure Rate）、平均修復時間（MTTR）。
* **Feature Flag**：功能開關，允許在不重新部署的情況下控制功能的啟用或停用，常用於灰度釋出或風險管控。
* **Canary Release（金絲雀發佈）**：僅先讓少部分使用者接觸新功能或版本，確認穩定後逐步擴大範圍，以降低全面失敗風險。
* **Incident Bridge（事故橋）**：即時協作通道，通常是語音或文字會議，用來在事故處理中快速同步狀態與決策。
* **On-call（值班）**：指定工程師於特定時間負責監控與處理系統異常。