許多新學士經常問：「商業分析師是商業學士還是軟體學士？」實際答案是：兩者都是BA，但範圍和工件深度不同。
如果誤解了這兩個角色，就很容易學錯。有些人學了太多Jira工具但不了解業務。有些人寫了非常好的業務流程，但當他們加入軟體團隊時，他們不知道SRS、API、UAT、缺陷分類是什麼。
這篇文章可以幫助你看得更清楚。
1.什麼是BA？
三個操作重點關注業務問題：
- 企業面臨什麼問題？
- 目前進程卡在哪裡？
- 主要利害關係人是誰？
- 哪些政策、法規和 KPI 會影響決策？
- 該解決方案是否創造了真正的價值？
例如，一家保險公司希望將索賠處理時間從 5 天減少到 2 天。 BA將分析目前的理賠流程，採訪案件處理人員，找出瓶頸，定義未來流程並提出改善方向。
常見文物：
| 神器 | 用什麼 |
|---|---|
| 利害關係人地圖 | 知道誰影響、誰決定、誰需要被詢問 |
| 目前狀態/未來狀態 | 比較目前流程和所需流程 |
| 商業案例 | 解釋為什麼你應該投資 |
| 能力地圖 | 查看哪些組織缺乏能力 |
| 政策/規則目錄 | 備案業務規定 |
2.什麼是軟體BA？
軟體 BA 將業務需求轉化為可建置和可測試的系統需求。
軟體BA還是要懂業務，但是必須再往上一層：
- 系統該如何表現？
- 使用者故事和驗收標準是否足夠可測試？
- 是否有關於效能、安全性、可用性、可訪問性的 NFR？
- 哪些 API/資料受到影響？
- 錯誤狀況和權限狀況是否清楚？
- UAT會驗證哪些場景？
例如，針對上述保險問題，軟體BA將為索賠受理模組編寫SRS：記錄輸入螢幕、檢查缺失文件的規則、記錄狀態、通知、取得客戶資訊的API、查看記錄的權限、審核日誌和UAT場景。
常見文物：
| 神器 | 用什麼 |
|---|---|
| SRS | 軟體需求規格 |
| 使用者故事 + AC | 將需求納入敏捷積壓工作 |
| BPMN/UML | 流程建模與系統互動 |
| RTM | 將需求追蹤到故事和測試案例 |
| UAT計劃 | 測試計劃被企業接受 |
| API/資料說明 | 指定整合和驗證 |
3. 快速比較
| 標準 | 商業學士學位 | 軟體學士 |
|---|---|---|
| 重點 | 業務成果、流程、利害關係人 | 系統行為、需求、可測試性 |
| 經常工作的人 | 企業主、營運、合規、PM | PO、UX、開發、QA、架構師、資料 |
| 主神器 | 業務案例、流程圖、規則目錄 | SRS、使用者故事、AC、RTM、UAT |
| 你需要了解的技術 | 協助、流程分析、策略 | SDLC、API/資料基礎知識、NFR、測試 |
| 常見問題 | “為什麼需要改變？” | “這種情況系統該怎麼辦？” |
重點：軟體BA不能退出業務。如果您不了解業務目標，那麼您只是在寫罰單。如果最終解決方案是數位產品，業務 BA 也不應該迴避軟體。
4. 工作日範例
商業學士學位
上午：
- 與企業主一起檢視營運 KPI
- 與營運團隊面談瓶頸問題
- 繪製目前流程並標記痛點
下午：
- 促進研討會選擇改進方案
- 撰寫一頁的商業案例
- 更新利害關係人的擔憂和假設日誌
軟體學士
上午：
- 透過 PO、Dev、QA 完善使用者故事
- 明確驗收標準與邊緣情況
- 與技術主管一起審查 API/數據影響
下午：
- 更新SRS、RTM、變更日誌
- 編寫UAT場景
- 與 QA 和業務利害關係人一起對缺陷進行分類
5.你應該先學習哪個方向？
如果您是新手，請按以下順序學習：
- 業務分析基礎：問題架構、利害關係人、業務流程。 2.需求工程：BRD、SRS、業務規則、驗收標準。
- SDLC 和 Agile/Scrum：需求如何通過軟體團隊。
- 建模：BPMN、UML、線框圖、資料流。
- 科技素養：API、基本 SQL、NFR、安全/隱私。
- 交付：待辦事項細化、UAT、缺陷分類、發布準備。
- 評估：KPI、儀表板、效益追蹤。
如果你來自 QA 或 Dev，那麼你在軟體 BA 方面有優勢。增加業務分析基礎以避免陷入票據級思維。
如果您來自營運或業務領域，您就有業務優勢。新增 SDLC、SRS、API/資料和測試，以便與軟體團隊無縫對話。
6.練習練習
選擇一個熟悉的功能，例如「線上醫療預約」。
寫2部分：
商業BA觀點
- 問題陳述
- 利害關係人地圖
- 目前狀態流程
- 未來狀態流程
- 成功指標
軟體BA視角
- 5 個使用者故事
- 每個故事的接受標準
- 5條業務規則
- 5 個 NFR
- 5個UAT場景
完成本練習後，您將看到兩個不同但互補的角色。
7. 常見錯誤
錯誤1：認為BA只是做會議的人
BA 不僅僅記錄利害關係人所說的話。 BA 必須分析、發現衝突、再次詢問、提出選項並幫助團隊做出決策。
錯誤2：認為軟體BA必須了解深度編碼
無需像開發人員一樣編碼。但是您需要充分閱讀和理解 API 合約、資料欄位、錯誤程式碼、權限模型和測試方法，才能編寫明確的需求。
錯誤3：只寫需求而不追蹤業務價值
每個需求都應該能夠回答：它服務於什麼目標、什麼使用者、什麼指標。
端到端範例：安排線上諮詢
假設公司有一個財務諮詢團隊。客戶撥打熱線進行預約，工作人員將其手動輸入到 Google Sheet 中。問題是日程重疊、顧客忘記日程、經理沒有缺席數據。
業務BA的輸出
| 部分 | 好的寫作範例 |
|---|---|
| 問題陳述 | 客戶透過熱線預約平均需要12分鐘；18%的日程輸入錯誤或多次更改，增加了客戶服務負擔並降低了諮詢參與率。 |
| 經營目標 | 3 個月內與日程安排相關的熱線電話減少 40%；將重複預訂減少至 1% 以下；出席率從 62% 增加到 75%。 |
| 利害關係人 | 客戶、客戶服務、顧問、銷售經理、合規、IT 支援。 |
| 目前流程 | 客戶撥打熱線 -> 客戶服務檢查表 -> 詢問顧問 -> 輸入時間表 -> 手動發送電子郵件。 |
| 未來進程 | 客戶在網路上選擇顧問/插槽 -> 插槽持有系統 -> 發送電子郵件/簡訊 -> 客戶服務僅處理例外情況。 |
| 政策 | 客人可以在預約時間前至少4小時重新預約； 4 小時內取消必須撥打熱線。 |
軟體BA的輸出
| 神器 | 範例 |
|---|---|
| 使用者故事 | 作為客戶，我想在線預訂可用的諮詢時段，這樣我就可以安排時間而無需撥打熱線電話。 |
| 驗收標準 | 給定一個空槽位，當客戶確認預約時，系統會建立處於「已確認」狀態的預約並發送確認電子郵件。 |
| 業務規則 | BR-001：已確認的插槽不會顯示給其他客戶。 BR-002：客人只能在預約時間前至少 4 小時重新預約。 |
| 資料欄位 | 預約_id、客戶_id、顧問_id、插槽_id、狀態、頻道、確認碼、建立時間。 |
| 接觸點API | POST /appointments, PATCH /appointments/{id}/reschedule, GET /consultants/{id}/slots。 |
| 錯誤案例 | 如果該時段剛剛被其他人預訂，請將其退回 SLOT_UNAVAILABLE 並顯示 3 個備用插槽。 |
| UAT場景 | 客戶預約成功，4小時前改期，4小時內嘗試改期，顧問看到今天的行程。 |
點看：商業BA幫助組織統一問題、價值觀和流程。軟體 BA 幫助建立團隊統一行為、資料、規則、API、錯誤和測試。
參考來源
- IIBA BABOK 指引： https://www.iiba.org/standards-and-resources/babok/
- PMI 商業分析從業人員： https://www.pmi.org/shop/p-/book/business-analysis-for-practitioners-a-practice-guide/00101570601
- Scrum 指南 2020： https://scrumguides.org/scrum-guide.html
結論
商業學士學位幫助組織選擇正確的問題。軟體 BA 幫助團隊建立正確的解決方案。數位產品方面的優秀 BA 需要經歷這兩件事：足夠深入地了解業務，以免構建錯誤的方向；足夠深入地了解軟體，以便可以部署、測試和操作需求。