IT 組織角色演進與 AI 時代的重新定義
以前不到位，是因為角色分工讓你只看到自己那塊。現在沒有不到位的理由。
這篇在談什麼
這不是一篇「IT 組織架構圖」的說明文。這篇想探討的是：
- 傳統角色分工背後的假設是什麼？那些假設還成立嗎？
- 當一個人可以覆蓋更多面向時，思維方式該怎麼轉變？
- 「什麼都懂一點」和「真正理解全貌」之間的差距在哪裡？
傳統 IT 部門的角色光譜
先釐清一件事：這些角色的存在不是因為「工作太多所以要分」，而是因為每個角色代表一種思維模式。
| 角色 | 核心思維 | 他在問的問題 |
|---|---|---|
| PM (專案經理) | 時程與資源 | 「什麼時候能交付？風險在哪？」 |
| SA (系統分析師) | 需求到結構 | 「使用者要的到底是什麼？系統怎麼承接？」 |
| SD (系統設計師) | 結構到實作 | 「架構怎麼切？模組之間怎麼溝通？」 |
| PG (程式設計師) | 實作細節 | 「這個功能怎麼寫最乾淨？」 |
| QA (品質保證) | 破壞性思維 | 「哪裡會壞？使用者會怎麼誤用？」 |
| DBA (資料庫管理) | 資料完整性 | 「資料模型對嗎？查詢效能夠嗎？」 |
| SRE (站點可靠性) | 系統韌性 | 「掛了怎麼辦？怎麼讓它不掛？」 |
| Security (資安) | 攻擊者視角 | 「如果我要攻破這個系統，我會怎麼做？」 |
重點不是記住這些角色的職稱，而是理解：每一列代表一個你應該能切換的思維角度。
為什麼分工曾經是必要的
三個歷史原因：
1. 知識取得成本高
二十年前，要理解「怎麼做好系統分析」，你需要：
- 找到一個有經驗的 SA 願意帶你
- 或者讀完 Pressman 的《Software Engineering》那本磚頭書
- 或者在專案裡踩過足夠多的坑
知識是稀缺的，所以讓一個人專精一塊是效率最高的做法。
2. 工具鏈的複雜度
以前做效能測試要會 JMeter + 讀懂 GC log + 理解 OS kernel tuning。做資安滲透要會 Metasploit + 手寫 payload + 理解網路協議。每個領域的工具鏈都有陡峭的學習曲線。
3. 溝通成本的權衡
Brooks 在《人月神話》裡說的：人越多，溝通成本以 n(n-1)/2 成長。分工是為了減少需要溝通的人數——每個角色只需要跟相鄰的角色對接。
這三個假設現在怎麼了
| 舊假設 | 現在的現實 |
|---|---|
| 知識取得成本高 | AI 可以在幾分鐘內幫你整理出一個領域的核心概念，還能回答追問 |
| 工具鏈學習曲線陡 | AI 能幫你生成設定檔、解讀 log、寫測試腳本，大幅降低入門門檻 |
| 分工減少溝通成本 | 當一個人能理解多個角色的語言，溝通成本反而更低 |
但這不代表角色分工會消失。 它代表的是：一個人可以在需要的時候，切換到那個角色的思維模式。
「什麼都懂一點」vs「理解全貌」
這是最容易踩的坑。差別在於：
什麼都懂一點：
- 知道 TDD 是「先寫測試再寫功能」
- 知道 UML 是「畫圖的工具」
- 知道紅隊是「模擬攻擊」
理解全貌：
- 知道 TDD 的本質是用測試來定義需求，而不是「為了覆蓋率」
- 知道 UML 的價值是強迫你在寫 code 之前想清楚物件之間的關係，而不是「畫漂亮的圖給主管看」
- 知道紅隊思維的價值是培養你用攻擊者角度審視自己的系統，而不是「學會用 Kali Linux」
前者是知識點的蒐集，後者是思維模式的內化。AI 可以幫你加速前者，但後者需要你自己去反芻。
新的能力模型：T 型到 π 型
傳統說法是「T 型人才」——一個專長 + 廣泛的基礎。但現在更有用的模型是 π 型：
知識廣度
━━━━━━━━━━━━━━━━━━━━━━━━
┃ ┃
┃ ┃
┃ ┃
專長 A 專長 B
(例: 前端) (例: 系統設計)
兩根柱子的價值在於：你可以站在兩個不同角度看同一個問題。
更重要的是，AI 讓你可以把「廣度」那條橫線拉得更寬、更扎實。以前「廣度」可能只是「聽過」，現在可以做到「理解到能做出判斷」。
實際的轉變方向
如果你現在是一個前端/後端工程師，以下是你可以開始「跨界理解」的方向：
| 方向 | 為什麼值得理解 | 突破點 |
|---|---|---|
| SA 系統分析 | 你會開始在寫 code 之前就問對問題 | 看到需求時，腦中會自動跑出「資料流」和「狀態機」 |
| QA 測試思維 | 你寫出來的東西會更少 bug，不是因為測試多，而是因為你在寫的時候就在想邊界 | 從「寫完功能再想怎麼測」變成「測試定義了功能」 |
| Security 資安視角 | 你會開始在設計 API 的時候就想「這個 endpoint 可以被怎麼濫用」 | 安全不再是事後審查，而是設計時的內建思維 |
| SRE 可靠性思維 | 你會開始問「這個服務掛了會怎樣？恢復要多久？」 | 寫 code 時考慮 graceful degradation |
| PM 專案思維 | 你估時間會更準確，因為你理解每個環節的風險 | 從「這個功能要多久」變成「這個功能的不確定性在哪」 |
反思問題
這些問題沒有標準答案，但值得你定期回來想：
- 你現在看到一個新需求，腦中跑過幾種角色的思維？ 還是只有「這個功能我怎麼寫」？
- 你上次主動用「攻擊者視角」審視自己寫的東西是什麼時候？
- 你能不能用一段話跟 PM 解釋為什麼這個需求的時程估計有風險？ 如果不能，你可能還沒內化專案管理的思維。
- AI 幫你加速了哪些面向？ 哪些面向你依然覺得「不太行」？那些就是你下一個要突破的方向。