軟體專案團隊角色白話解說：PM、設計、前後端、QA、維運各做什麼

第一次外包軟體專案的業主，常在啟動會議上遇到這種場面：對方來了四、五個人，名片上寫著 PM、UI/UX、前端、後端、QA，每個人講的話都聽得懂一半。會後想補充一個需求，卻不知道該傳訊息給誰；上線前發現畫面跟想像不同，也不確定問題出在設計還是程式。

搞懂軟體專案團隊角色的分工，不是為了讓業主去管工程師，而是讓你在對的時間把對的資訊交給對的人。同一句「這個按鈕怪怪的」，交給設計、前端或 QA，得到的處理方式完全不同。

以下依序說明每個角色在做什麼、業主跟他們溝通時該講什麼、合約與會議上可以怎麼安排，最後談小團隊一人多職時要注意的地方。

先看全貌：一個功能從想法到上線經過哪些人

用一個具體例子串起來。設想一家公司想在官網加上「線上預約」功能，這件事在團隊內部大致會這樣流動：

1. PM 跟業主訪談：誰會預約、要選哪些項目、預約後誰要收到通知、可不可以取消。整理成需求文件，切成可以排進時程的工作項目。
2. UI/UX 設計師 根據需求畫出流程與畫面：預約入口放哪、選時段的方式、錯誤訊息怎麼呈現，交給業主確認。
3. 後端工程師 設計資料要怎麼存、時段衝突怎麼判斷、通知信怎麼寄，並開出讓畫面呼叫的介面（API）。
4. 前端工程師 把設計稿做成真的網頁，接上後端的介面，處理各種螢幕尺寸。如果也要做在 App 裡，就由 App 工程師 負責手機端。
5. QA 照著需求與設計稿測試：正常流程、重複預約、時段已滿、網路斷線等情況，把問題回報給對應的工程師。
6. 維運（DevOps／系統管理） 負責把程式部署到正式環境、設定網域與憑證、做備份與監控，上線後出狀況時第一個收到警報。

這條流程裡，業主主要的接觸點是 PM 和設計師，其他角色多半在後台運作。但了解整條線，你才知道一個問題卡在哪一站。

PM：專案經理是你的主要窗口

PM（Project Manager）是業主最常打交道的人，有些團隊也會分出 PO（Product Owner）或系統分析師，但對業主來說，職責核心是一樣的：把你的需求翻譯成團隊能執行的工作，並對時程與範圍負責。

PM 通常負責：

• 主持需求訪談，整理需求文件與功能範圍。
• 排定時程、拆分工作、追蹤每項進度。
• 收集並評估需求變更，說明對時程與範圍的影響。
• 定期回報進度、風險與需要業主決定的事項。
• 安排驗收與上線前的確認。

業主該對 PM 講什麼：所有「要做什麼、不做什麼、先做哪個」的決定，以及任何需求變更。即使你在會議上跟工程師談出了調整，也要請 PM 寫進紀錄。變更怎麼提、怎麼評估，可以參考軟體專案需求變更管理。

判斷 PM 稱不稱職的訊號：每次開會都能清楚說出目前完成了什麼、卡在哪裡、需要你決定什麼；你提出變更時，他會先講影響再答應，而不是一口答應或一口拒絕。

UI/UX 設計：決定使用者怎麼操作、看到什麼

UI 是使用者介面（畫面長相），UX 是使用者體驗（操作流程順不順）。小團隊常由同一位設計師負責，大型專案會再細分。

設計師負責：

• 整理使用者流程：從哪裡進來、經過幾步、在哪裡可能卡住。
• 畫線框圖（只有結構的草圖）與高擬真設計稿。
• 定義元件規範：按鈕、表單、顏色、字級在各頁保持一致。
• 交付設計稿與標註給前端與 App 工程師。

業主該對設計師講什麼：誰是使用者、他們在什麼情境下使用、品牌調性與不能違反的規範（例如企業識別色）、競品或參考網站中你喜歡與不喜歡的地方。最重要的是在設計階段就把意見講完，設計稿確認後再改版面，牽動的是前端與後端的工作量。

審設計稿時不要只看漂不漂亮，要照著真實情境走一遍流程。具體怎麼審，可以看UI/UX 設計稿審查指南。

前端、後端與 App 工程師：三種「寫程式的人」

業主最容易混淆的就是這三種工程師。用餐廳比喻比較好懂：

• 前端是用餐區：客人看得到、摸得到的所有東西，包含網頁畫面、按鈕反應、表單檢查、手機版排版。
• 後端是廚房：客人看不到，但決定菜做不做得出來，包含資料庫、商業邏輯、權限、金流與第三方串接、寄信與通知。
• App 工程師是外送窗口：把同一份菜送到手機裡，處理 iOS 與 Android 各自的規範、推播、相機與定位等手機功能，以及上架審核。

問題該找誰：一張簡單的判斷表

你看到的狀況	比較可能是誰的範圍
畫面跑版、按鈕點了沒反應、手機版排列錯亂	前端
資料存錯、計算結果不對、權限看到不該看的資料	後端
通知信沒寄出、第三方串接失敗	後端（有時涉及維運）
只有在 App 裡出錯、推播收不到、上架被退	App
網站整個打不開、很慢、憑證過期	維運

業主不需要自己判斷到這麼細，回報問題時交給 PM 或 QA 分派即可。但知道這個分法，你在描述問題時就會自然帶出關鍵資訊，例如「在手機上」「只有某個帳號」「寄給客戶的信」。回報格式可以參考如何向廠商回報 Bug。

業主該對工程師講什麼：多數時候透過 PM 傳達即可。需要直接溝通的場合是技術細節確認，例如既有系統的帳號與資料格式、第三方服務的申請資料、某個欄位的商業規則。談完請記得同步給 PM。

QA：專門找問題的人

QA（Quality Assurance，品質保證）負責測試。很多業主會問：工程師自己不會測嗎？會，但工程師測的是「我寫的東西照我理解的方式能不能跑」，QA 測的是「照需求和真實使用情境，這東西會不會出錯」。兩者角度不同。

QA 通常負責：

• 依需求文件撰寫測試案例，包含正常流程與例外情境。
• 在測試環境逐項執行，記錄結果。
• 回報問題、追蹤修正、修正後再驗證一次（回歸測試）。
• 上線前做整體的冒煙測試，確認主要功能都還正常。

業主該對 QA 講什麼：你最擔心出錯的情境，以及真實使用時會遇到的例外。例如「客人常常預約後又改時間」「會計月底會一次匯出整個月」。這些資訊是 QA 寫測試案例時最缺的。

要注意：QA 的測試不能取代業主驗收。QA 確認的是系統照規格運作，業主驗收確認的是規格本身符合你的業務需求。驗收怎麼安排，請看軟體驗收測試（UAT）指南。

維運：讓系統上線後持續活著

維運常被叫做 DevOps、SRE 或系統管理員，負責的是程式寫完之後的世界：

• 規劃與建置主機或雲端環境，區分開發、測試與正式環境。
• 設定自動部署流程，讓更新可以安全上線、出錯能退回。
• 管理網域、SSL 憑證、資料庫備份。
• 設定監控與警報，系統變慢或掛掉時第一時間知道。
• 處理安全性更新與存取權限。

這個角色在專案初期最容易被忽略，直到上線前才發現沒人負責主機、網域在誰名下也說不清。環境與部署的概念，可以先看開發、測試、正式環境與部署白話解說。

業主該對維運講什麼：網域與主機的帳號歸屬、預期的使用量與尖峰時段、資料保存與備份要求、出事時希望多快被通知、誰在半夜可以被叫醒。這些內容最好在合約與上線前就談清楚，而不是事後補。

業主窗口溝通對照表：照這張分派就不會亂

把前面的內容整理成一張可以直接拿去用的表。建議在專案啟動會議時，請廠商在每一列填上實際負責人的名字與聯絡方式：

你要處理的事	主要對象	你要準備的資訊
新增或刪減功能、調整優先順序	PM	想改什麼、為什麼、多急
確認進度、時程、風險	PM	你關心的里程碑
畫面、流程、文案方向	設計師（經 PM 排程）	使用情境、品牌規範、參考範例
既有系統資料、第三方帳號	後端（同步 PM）	帳號、文件、資料樣本
回報問題	PM 或 QA	步驟、畫面截圖、裝置與帳號
驗收與簽核	PM	驗收清單、實際使用者
網域、主機、備份、緊急狀況	維運（同步 PM）	帳號歸屬、通知對象

再補三條實務原則：

1. 單一窗口對單一窗口。業主端指定一位主要窗口，廠商端對應 PM。其他人可以參與，但決定只從這兩個人出去。
2. 口頭結論要落成文字。每次會議後由 PM 發會議紀錄，業主回覆確認，有出入當下更正。
3. 知道誰在休假。請 PM 在進度回報中標註關鍵人員的休假與代理人，避免上線前一週才發現後端不在。

專案開始前要準備哪些東西、啟動會議要問哪些問題，可以搭配軟體專案啟動前業主檢查清單一起看。

小團隊一人多職：可以，但風險要先講清楚

不是每個專案都需要上面全部角色各一人。規模小的網站或 MVP，常見組合是 PM 兼設計、一位全端工程師同時寫前後端、維運由工程師順手處理。這本身沒有對錯，重點是你要知道誰兼了什麼，以及哪些環節少了一道檢查。

實務上常見的風險：

• 球員兼裁判：同一個人寫程式又負責測試，自己寫的盲點自己測不出來。對策是約定由另一個人或業主照測試清單驗一次。
• PM 兼工程師：寫程式忙起來時，進度回報與需求整理最先被犧牲。對策是固定回報節奏，例如每週一次、內容格式固定。
• 單點依賴：所有知識都在一個人身上，他生病或離職，專案就停擺。對策是要求原始碼放在你看得到的版本控制平台、文件隨進度更新，而不是結案才補。
• 維運沒人管：上線後主機、憑證、備份變成「好像是工程師在處理」。對策是在合約中寫明維運責任歸屬，或另外安排維護方案。

面對精簡團隊，可以直接問這幾個問題：

• 這個專案每個角色實際由誰擔任？有沒有人兼多職？
• 誰負責測試？寫程式的人以外，誰會再驗一次？
• 關鍵人員請假或離職時，由誰接手？接手需要多久？
• 原始碼、設計稿、文件放在哪裡？我是否隨時有存取權限？
• 上線後主機與監控由誰負責？

如果需要一個懂技術的人站在你這邊、幫你判斷團隊配置是否合理，可以參考兼任技術長服務的做法；還在挑廠商階段的話，如何挑選軟體開發公司裡也整理了評估團隊組成的問題。

結語：知道誰負責什麼，就能少掉多數溝通成本

業主不需要學會寫程式，但知道團隊裡每個角色在做什麼，就能讓每一次溝通都更精準：需求找 PM、畫面找設計、問題交給 QA 分派、主機與緊急狀況找維運。大多數專案的摩擦，並不是技術做不到，而是資訊交給了錯的人、或在傳遞中走樣。

如果你正準備啟動一個軟體專案，想先弄清楚需要哪些角色、哪些可以合併、業主端該派誰參與，NETVANA 可以從團隊配置與溝通流程開始陪你規劃。軟體服務一律採詢問報價制，我們會依專案範圍說明實際的人員分工後再談合作方式，歡迎與我們聯絡，或先到軟體服務介紹看看我們負責的範圍。

延伸閱讀：專案開始前的準備事項，看軟體專案啟動前業主檢查清單；需求文件怎麼寫給 PM，看軟體需求怎麼寫；審設計稿的方法，看UI/UX 設計稿審查指南；回報問題的格式，看如何向廠商回報 Bug；結案時該拿回哪些東西，看原始碼所有權與專案交接。