這篇文章拆解系統分析師、系統設計師、系統工程師的工作內容、能力條件與職涯路徑，
附三者比較表與5題常見問題，幫PM正確派工、企業發包前看懂該找誰，
避免需求沒講清楚就貿然進入開發，衍生追加修改與報價爭議。
帶軟體專案的助理最常問我一句話：
「SA、SD、SE 到底哪裡不一樣？」
這三個縮寫看起來像同一種人，實際做的事情差很多。
分不清楚，派工就會亂，該找系統分析師的時候找了工程師，專案就卡住。
這篇文章把三種角色的工作內容、養成條件、生涯路徑講清楚，
讓帶團隊或發包外包的人，一次搞懂該找誰。
問「流程和邏輯」找 SA，
問「畫面和操作體驗」找 SD，
問「環境和運行穩定度」找 SE。
三者合起來，一個系統才走得完整。
SA（System Analyst）系統分析師
SA 的核心工作，是把客戶想要的結果拆解成一份份文件，讓開發團隊照著文件就能做出來。
做法上比較接近寫食譜：
食譜寫清楚要用哪些材料、先後順序、火候怎麼拿捏，才能做出色香味俱全的一道菜。
SA 寫的文件也是這樣，把系統該有的流程、資料怎麼流動、模組之間怎麼串接，全部落在紙上，而不是只留在少數幾個人的腦袋裡。
SA 處理的範圍不只在電腦裡。
很多專案導入新系統，同時也要調整現有的作業流程和組織分工，這部分通常也是 SA 在主導。
系統做得再漂亮，如果現場作業流程沒有配合調整，效益還是出不來。
SA 在專案裡實際做的事
- 依照需求訪談和現有作業流程，規劃出新流程與對應的系統功能、模組分工
- 根據功能模組規劃，定出初步的資料庫結構與使用者權限規則
- 制定軟體元件規範，例如物件定義、共用函式庫的邊界
- 設計新的標準作業流程，把系統功能綁進實際的工作步驟裡
- 依照客戶的環境和需求，找到合適的 SD 搭配執行
好的 SA 有這些特質
- 不特別在意用哪套開發工具，因為好的分析文件換任何一種語言或平台實作，結果都應該一致
- 偏重邏輯和流程順序的表達，而不是畫面呈現
- 需要熟悉一種程式語言，但重點是用語言把邏輯講清楚，不是追求會很多種語言
- 要有整體思維，規劃模組時同時考量到直接和間接相關的流程與邏輯，這也是找 SA 最難的一點
SA 和 SD 相比，比較不受特定開發工具或作業系統限制，但受限於產業領域的深度。
熟悉汽車業流程的 SA，放到金融業專案未必能立刻上手，
反過來也一樣，因為 SA 做的是流程分析與重新設計，核心作業流程往往需要長期累積的產業知識才摸得透。
成為 SA 需要具備的條件
- 至少熟悉一種程式開發語言
- 熟悉軟體工程的基本概念，理解常見開發工具的特性
- 熟悉管理制度或作業流程設計
- 會使用 UML 或類似的系統描述工具
- 邏輯能力要好，能把複雜情境拆成清楚的步驟
- 溝通能力好，這是釐清需求的關鍵
- 對所屬產業有一定的熟悉度
三個角色裡，SA 的工作內容和 PM 最接近，職涯規劃上，SA 轉 PM 是滿常見的一條路。
SD（System Designer）系統設計師
SD 的職涯路徑通常不會走向 SA 或 PM，因為 SD 偏幕後，
對客戶溝通協調的要求沒有 SA 高，也比較不需要管理層面的整體視角。
表面上 SD 的工作項目看起來比 SA 少，實際上 SD 是三者裡最吃天賦的角色。
畫面怎麼排、操作手感怎麼調、元件命名和物件規則怎麼定，都需要一點美感和直覺。
功能做得再強，如果操作起來卡卡的、看起來不順眼，功能帶來的價值也會被這些細節蓋掉，這正是 SD 要解決的問題。
SD 同時也是系統呈現最佳化的執行者。
SA 規劃出來的需求只是邏輯上的構想，換到不同平台或工具，實作方式可能差很多，
這需要 SD 對使用環境和開發工具足夠熟悉，才能做出對應調整。
舉例來說，同一套財務軟體在不同作業系統、搭配不同開發語言，畫面呈現和操作邏輯都會有差異，這些差異不只影響視覺，也牽動開發成本和時程。
SD 在客製化專案裡的工作內容
- 設計畫面元素規範
- 設計頁面結構和呈現規則
- 設計系統操作畫面，制定欄位規範與防呆機制
- 設計權限管理與操作機制
- 撰寫使用手冊
- 調整資料庫欄位定義，讓它對應畫面規範和操作流程
- 配合 SA 撰寫系統開發文件，供工程師撰寫程式碼使用
- 撰寫 UI 測試計畫書
稱職的 SD 需要具備的條件
- 至少對一種作業系統非常熟悉，了解其元件特性和 API
- 熟悉兩種以上開發工具，且專案所需的工具必須是擅長項目之一，
包含標準函式庫、系統常數、物件定義、語法及常用輔助工具 - 具備一定的美學素養
- 至少能使用一種繪圖工具軟體
- 擔任過軟體工程師三年以上
可以這麼說，SA 給了系統邏輯和運作脈絡，
SD 給了系統外觀和操作體驗，兩者搭配起來，才能做出正確又好用的系統。
如果你是不太喜歡頻繁對外溝通、但對使用者介面有堅持的 IT 工作者，SD 會是適合的方向。
SE（System Engineer）系統工程師
對 PM 來說，
SE 幾乎是萬用角色，只要是 IT 專案就用得到，差別只在該找哪個技術領域的 SE。
系統建置安裝、使用者端環境設定、硬體選型與佈建，都少不了 SE。
SE 雖然到處用得上，卻是專案裡最少發聲的一群。
他們的核心工作是建構出系統可以順利執行的環境，系統該怎麼呈現，SE 可以提供建議，但通常是在系統運行出現非預期問題後才會被拉進來討論。
SE 的基本條件和 SD 最接近，差別是不需要有很強的軟體開發經驗，
但要看得懂程式邏輯，尤其是自動化部署腳本，不然環境問題排查起來會比較卡。
對作業系統、伺服器環境、網路架構要有相當程度的了解，是基本門檻。
三者之中，SE 通常是知識面最廣的一個，好的 SE 不一定程式寫得快，但不能完全不懂程式，對開發工具和網路管理也要有一定涉獵。
2026 年的專案，純地端伺服器的案子越來越少，大部分開發案都會碰到雲端環境或容器化部署。
現在找 SE，除了傳統的主機和網路能力，雲端環境操作（AWS、Azure、GCP 其中之一）與基本的自動化部署概念（DevOps、CI/CD、Docker 容器化），已經是常見的必備項目，不只是加分而已。
SE 在專案裡執行的工作
- 規劃及建置系統執行環境
- 安裝與設定使用者端環境
- 伺服器安裝與設定，含雲端主機的環境部署與維運
- 撰寫或維護基本的自動化部署腳本（如 Shell、Python），搭配 Docker 容器化與 CI/CD 流程
- 提供環境設置建議給 SA 和 PM
- 最佳化系統可靠度與效能
- 撰寫可靠度及效能測試計畫書
- 對電腦及周邊設備有一定熟悉度
SE 的基本要求
- 至少熟悉一種作業系統，尤其是系統設定與微調
- 至少熟悉一種網路伺服器作業系統的設定與最佳化
- 曾任軟體工程師一年以上，或熟悉一種開發工具
- 對網路環境有一定認識，尤其是通訊設定
- 熟悉可靠度與效能評估方法，並了解相關的系統環境設定
- 熟悉至少一種雲端服務平台與容器化技術的基本操作，是現在專案越來越常見的門檻
如果你有 SD 的技術背景和個性，但美感這塊實在不太行，SE 會是不錯的方向。
SE 的下一步職涯，通常會偏向技術性職位，像是 DBA 或網管、SRE，對 IT 產品本身有熱情的人，走 SE 這條路會滿順的。
為什麼發包軟體開發前，要先搞懂這三種角色？
企業發包網站或系統開發時，最常卡住的地方，是需求沒有講清楚。
例如同樣是會員系統，有些人只需要登入註冊，有些人還需要會員分級、點數、優惠券、訂單紀錄、LINE 綁定、後台查詢與資料匯出。
需求差一點，報價、工期和測試範圍都會差很多。
SA、SD、SE 的分工，就是把模糊的想法拆成可以討論、可以估價、可以開發、可以測試的項目。
專案前期分工越清楚，後面追加修改和溝通誤差就會越少。
三種角色一次比較
| 比較項目 | SA 系統分析師 | SD 系統設計師 | SE 系統工程師 |
|---|---|---|---|
| 核心任務 | 把需求轉成邏輯與流程文件 | 把邏輯轉成畫面與操作體驗 | 建置與維護系統運行環境 |
| 主要產出 | 需求書、流程規劃、模組分工 | 介面設計、操作手冊、UI 測試計畫 | 環境建置紀錄、效能與可靠度測試計畫 |
| 對工具的依賴 | 低，重邏輯不重工具 | 高，需精通至少兩種開發工具 | 中高，需熟悉作業系統、伺服器與雲端環境 |
| 需要的天賦 | 整體思維、邏輯拆解 | 美感、操作直覺 | 環境判斷、問題排除 |
| 常見職涯下一步 | PM 專案經理 | 資深 SD、UI/UX 主管 | DBA、SRE、維運主管 |
一個開發案裡，三者怎麼搭配
會同時用到 SA、SD、SE 的專案，多半是客製化開發案。
SA 團隊先做需求調查和整體架構規劃，把開發內容轉成有條理的文件，並適度切分派工，同時確保切分後的成果未來能正確整合運作。
SD 接手後，在 SA 的文件裡找呈現方式的一致性和易用性，確保開發工具能正確呈現 SA 提出的要求，同時負責操作介面外觀設計、統一的呈現規範、操作畫面與流程設計，並配合 SA 完成開發文件，其中通常包含系統使用手冊的初稿。
SD 在設計階段需要和 SA 密集對齊，確保成品符合原始需求。
三個角色都要撰寫測試計畫，但重點不一樣：
SA 著重資料流動是否符合原訂順序和結果，
SD 著重操作畫面的防呆機制和介面正確性，
SE 則專注在系統可靠度的規劃與驗證。
專案越大、角色分工越細，找對人比找便宜的人重要。
SA 分析錯了，後面 SD 和 SE 做得再好也是白工。
常見問題
Q1. 小型專案一定要同時有 SA、SD、SE 三個角色嗎？
不一定。
中小型專案常由同一個人身兼多職，例如資深工程師同時做 SA 和 SD 的工作，SE 的部分交給主機代管廠商處理。
角色分工的細緻程度，取決於專案規模和預算，重點是這三種思考角度都要有人顧到，不是一定要三個不同的人。
Q2. PM 找外包廠商時，該怎麼確認對方有沒有真正的 SA 能力？
請對方提供過去專案的需求規格書或系統分析文件範例，
重點看文件有沒有把流程、資料關係、模組分工講清楚，而不是只有畫面截圖。
能拿出結構完整文件的團隊，通常 SA 能力比較扎實。
Q3. SD 和 UI/UX 設計師是同一種角色嗎？
工作範圍有重疊，但 SD 涵蓋的範圍更廣，除了介面視覺，還包含資料庫欄位對應、操作流程設計、防呆機制和測試計畫，
UI/UX 設計師則多半專注在視覺與使用者體驗這一塊。
Q4. 找不到專職 SE 的話，系統穩定度會受影響嗎？
會有一定風險。
沒有人專責環境建置和效能測試，問題常常要等系統上線後才浮現。
如果團隊沒有專職 SE，建議至少在上線前安排一輪環境壓力測試，或選擇有主機代管服務的廠商，把這塊風險轉移出去。
Q5. 企業發包軟體開發前，應該先準備哪些資料？
建議先整理目前作業流程、使用者角色、必備功能、後台權限、資料來源、表單欄位、報表需求與預計上線時間。
如果還沒有完整規格，也可以先請廠商協助做需求盤點，把想法整理成可以估價和開發的功能清單。
需求還沒整理清楚，也可以先從專案規劃開始
很多軟體開發專案卡住的原因，是前期需求沒有整理清楚。
益盛科技可協助企業盤點網站或系統需求，整理功能架構、前後台流程、使用者權限與開發範圍，讓專案比較容易估價、開發與驗收。
相關文章
作者：益盛科技 專案經理 Ring
通過 Google Ads Measurement Assessment 認證，15 年網站專案管理及人員管理實務經驗，具網站美編企劃繪製能力，具多媒體網頁設計與 RWD 設計實務經驗。
