SaaS 第一版做哪些功能，哪些先不做？

第一版 SaaS 最常失控的，不是功能太少，而是每一項都聽起來合理，最後卻沒有任何一條流程真的能從開始走到完成。

直接的做法是：先定義一位主要使用者要完成的一件事，再只保留讓那件事第一次完整完成所需要的資料、動作、狀態與驗收結果。其餘功能不是被否定，而是先被放到「要先驗證」或「本版不做」的欄位。

先不要列功能，先寫出「第一次完成」

把第一版當成一張很長的功能清單，通常很難討論優先順序。比較有用的起點是這一句：

主要使用者在什麼情況下，用什麼資料，做完什麼動作後，能看到什麼可確認的結果？

例如，「使用者可以管理訂單」還太大。改成「門市協調者可以建立一筆報價需求、補齊品項與數量、交給負責人確認，並在同一處看到已確認狀態」就能開始判斷哪些功能不可少。

這種切法不是說每個 SaaS 都只有一條流程，而是先讓第一條最重要的流程完整。Scrum Guide 將 Product Backlog 說明為持續演進、依序排列的工作清單；靠近實作的項目會在 refinement 中拆得更清楚。Microsoft 的敏捷工作管理文件也強調將工作拆成可完成的需求，並寫清楚 acceptance criteria。把「第一次完成」寫清楚，正是為了讓後面的排序與驗收有共同語言。

奧微軟體的軟體外包服務在合作前，也會先把需求整理成頁面、功能與驗收條件，再拆分開發階段。

第一版的五個盤點點

以下是編輯整理的範圍盤點法，不是保證每個產品都必須照抄的規格。

1. 誰先完成這件事

先選一個最主要的使用者角色。若第一版同時要滿足客戶、客服、主管、合作夥伴與管理員，常常會把不同人的需要混成一堆「都很重要」的功能。

如果這條流程需要辨識不同人、保留各自資料或交接責任，再把帳號、角色與可見範圍列入第一版。若產品一開始是公開工具或不需辨識使用者，則不必為了形式硬塞登入功能。

2. 最小資料要留什麼

不是所有欄位都要一開始就做齊。先問：沒有哪一筆資料，使用者就無法做出下一個判斷或完成交接？

例如一筆需求可能只需要標題、內容、目前負責人、狀態與建立時間；複雜標籤、儀表板切法、批次匯出格式，可以先列為待驗證項目。資料欄位一旦和後續動作無關，往往只會增加填寫成本。

3. 必要動作和狀態怎麼接起來

一條能驗收的流程通常不是「可以新增」就結束，而是要看得出它走到了哪裡、下一位是誰、何時算完成。

把動作寫成具體的變化，例如「建立後進入待確認」、「確認後不可由原建立者直接覆寫」、「完成後可在列表找到」。這比寫「支援狀態管理」更容易估工與驗收。Microsoft 的文件把清楚 acceptance criteria 視為拆分需求時的實務要點；本文把它轉成第一版範圍的檢查問題。

4. 完成後，使用者怎麼知道真的完成了

第一版至少要能讓使用者找到結果、看懂目前狀態，並知道是否還需要下一步。這不一定等於要有華麗儀表板；有時一個可搜尋的列表、一個明確狀態和一個可讀取的紀錄，就已經足夠做第一輪驗收。

5. 哪些事現在不做，理由是什麼

最重要的範圍決策，往往不是多寫一項 Must，而是明講哪些項目暫時不做。可以把每項功能先放進三欄：

• 本版不可少：少了它，主要使用者無法完成那一件事。
• 先驗證再決定：需要真實使用回饋、需求證據或技術確認後才排進來。
• 本版不做：即使現在聽起來有用，也不影響第一次完整完成。

Atlassian 將 MVP 說明為可用來取得回饋、驗證需求的簡化可運作版本，也指出優先排序常會同時考量影響、投入與目標對齊。這不代表分類本身會替你做決定，尤其 MoSCoW 一類方法仍可能有主觀性；它的價值是讓團隊把取捨說出來，而不是把所有人想要的東西都叫作第一版。

明示虛構教學例：多門市報價協作 SaaS

以下完全是虛構教學情境，不是客戶案例。

假設主要使用者是「門市協調者」，他第一次要完成的事是：建立一筆報價需求，補齊品項與數量，交由負責人確認，最後回來查看已確認結果。

那麼第一版可先保留：建立需求、填寫必要品項、指派或辨識負責人、待確認／已確認兩種狀態，以及可找到已確認結果的列表。自訂儀表板、複雜標籤、多層通知規則、歷史資料大規模搬遷與各種報表，不會因為沒價值就永遠不做，只是尚未影響這一次的完整完成。

這個例子最該檢查的不是畫面數量，而是能不能把一句驗收話講清楚：協調者建立需求後，負責人可確認，協調者回到列表能看到明確結果。講不清楚時，通常還不該把功能直接排進第一版。

什麼情況不適合只靠這套切法

若產品最大的未知不是使用流程，而是技術可行性、外部系統整合、資安、法規或資料移轉，先列 MVP 功能不一定足夠。Atlassian 區分 MVP 與 PoC：前者偏向用可運作版本驗證需求，後者偏向驗證可行性。遇到關鍵整合、敏感資料或不可逆移轉時，應先把技術驗證、資料處理與風險條件拉成獨立工作，再決定第一版承諾到哪裡。

開始討論前，先做這張小表

把現有功能清單逐項問一次：它是否讓主要使用者更接近第一次完整完成？若答案不是明確的「是」，就先放進待驗證或本版不做。這不會自動讓專案變小，但能把「想做」和「這一版一定得做」分開。

若你正在整理 SaaS 第一版範圍，可以先把每項功能放進這三欄，再帶著「首次完整完成」這一句去討論，通常會比從功能名稱開始更容易收斂。

資料來源與核對日期

• Scrum Guides, The Scrum Guide，核對日期：2026-09-15。
• Microsoft Learn, Create your backlog；Best practices for Agile project management，核對日期：2026-09-15。
• Atlassian, What is a minimum viable product?；Prioritization frameworks，核對日期：2026-09-15。

作者：奧微軟體內容團隊。本文為一般軟體需求整理方法；奧微軟體開發企業社與軟體開發服務有商業關係，本文不構成對特定專案的時程、費用或成果承諾。