MVP 最小可行產品開發指南：第一版該做什麼、不該做什麼
「我們先做一個 MVP 就好」這句話，在很多會議裡的實際意思是「先做一個便宜的版本」。這是 MVP 最常見也最昂貴的誤解。
MVP 的重點從來不是省錢，而是用最小的代價，取得一個你現在還不知道答案的資訊。搞清楚這一點，第一版該做什麼、不該做什麼，答案就會自己浮現。
MVP 不是半成品，是一場實驗
每個新產品的背後都有一堆假設：有人需要這個東西、他們願意付錢、他們會用我們設想的方式使用、我們能觸及到他們。這些假設在產品上線前都只是猜測。
MVP 的工作，是挑出最致命的那一個假設——錯了就整個生意不成立的那個——然後用最少的投入去驗證它。
所以正確的起手式不是「我們要做哪些功能」，而是：
「如果只有一件事可以搞錯，哪一件錯了會讓整件事沒有意義？」
舉例來說：如果你的假設是「餐廳老闆願意用手機管理外送訂單」，那第一版需要的是一個能真正跑完一張訂單的流程，而不是同時有會員系統、優惠券、數據報表、多語系的半成品。
判斷 MVP 是否設計得好的標準：做完之後，你能不能明確說出「這個假設成立／不成立」？如果做完仍然無法判斷，那它就不是 MVP，只是一個小產品。
常見的四種誤解
誤解一：MVP 就是功能砍半。 把十個功能各做一半，得到的是十個不能用的功能。正確作法是做「一個完整可用的流程」，其餘一律不做。
誤解二：MVP 可以做得很粗糙。 使用者不會因為你說「這是測試版」就降低標準。如果流程卡住、資料遺失、畫面難以理解，你收到的負面回饋無法區分是「不需要」還是「不好用」，等於什麼也沒驗證到。
誤解三：MVP 一定要是一個 App 或系統。 有時候最快的驗證方式是一個表單、一頁說明加上預約按鈕、甚至由人工在後台手動處理。先確認有人要，再決定要不要自動化。
誤解四：MVP 做完就等於產品做完了。 MVP 的產出是「知識」，不是最終產品。驗證完之後才是真正的建構期。
怎麼決定第一版做什麼、不做什麼
用一條主線來切：畫出使用者要完成的那件事，從頭到尾的最短路徑，路徑上的每一步都做，路徑外的一律不做。
以一個線上預約服務為例，主線可能是：看到服務 → 選時段 → 留資料 → 收到確認。
這條線上的每一步都必須完整可用。 不能有「選了時段但沒有確認信」這種缺口。
這條線之外的，先列進「之後再說」清單：
| 常見的「之後再說」項目 | 第一版的替代方案 |
|---|---|
| 會員系統與登入 | 用信箱或手機號碼識別即可 |
| 後台管理介面 | 直接看資料庫或試算表，人工處理 |
| 金流串接 | 先用轉帳或現場付款 |
| 數據報表 | 手動匯出統計 |
| 通知系統 | 人工發送訊息 |
| 多語系 | 先做主要語言 |
| 權限管理 | 第一版只有一種角色 |
這些替代方案在使用者少的時候完全可行，而且能讓你近距離看見真實的使用行為——這是自動化之後反而會失去的資訊。
要留意的分界：可以簡化的是「規模與自動化」，不能簡化的是「使用者體驗的完整性」與「資料的正確性」。使用者的資料如果在第一版遺失，你失去的不只是資料，還有那個人。
技術選型：夠用，而且能換
早期最容易犯的技術錯誤有兩種，方向相反但結果一樣糟。
過度建設：還沒有使用者，就先做好能承載大流量的架構、微服務拆分、完整的自動化測試與部署流程。這些投入在需求被驗證前，多半會隨著方向調整而作廢。
選了走不出去的路：為了快，選用一個綁定特別深的現成平台或工具，短期內確實快，但資料拿不出來、邏輯無法移植，等到要擴充時只能整個重做。
合理的原則是**「夠用，而且能換」**：
- 選成熟、文件齊全、找得到人維護的技術。冷門技術在你要擴充團隊時會變成招募障礙。
- 資料是你的，要能匯出。不論用什麼服務，確認你隨時可以把資料完整取出。
- 把會變的和不會變的分開。介面與商業規則會一直改，資料結構與帳號體系相對穩定，後者值得在第一天就想清楚——這兩項是日後最難改的東西。
- 不要為了假想的規模預先優化。使用者數量增加是好消息，那時候再處理來得及。
- 原始碼與帳號權限必須在你手上。這一點在外包時尤其重要。
技術選型若你自己難以判斷，可以借助中立的第三方意見。NETVANA 的軟體顧問服務包含技術選型與架構評估，內容見軟體服務介紹。
什麼時候該重寫
「MVP 做完就要重寫」是一種迷思，但也確實有該重寫的時刻。判斷依據不是程式碼寫得漂不漂亮，而是：
該重寫的訊號
- 產品方向發生根本轉變，原本的資料結構完全不適用
- 每加一個新功能，都要動到很多不相關的地方，改動成本持續上升
- 出現無法定位的錯誤，而且沒有人敢動那段程式碼
- 效能問題來自架構本身，調校已經到極限
不該重寫的訊號
- 只是「新來的工程師覺得程式碼很醜」
- 想換一個比較新的技術
- 有幾個地方寫得不好——那應該逐步改善，不是全部推倒
折衷作法：多數情況下，逐步替換比整個重寫安全。把系統切成幾塊，一次換一塊，每換完一塊都確認功能正常。整個重寫的期間，產品通常會停止進化好幾個月，那段時間的機會成本經常被低估。
和外包團隊一起做 MVP：五個注意事項
新創與中小企業的第一版，經常是委外做的。這個組合可以很有效率，但有幾個前提。
一、你方必須有一個能決定「不做什麼」的人。 MVP 的核心工作是刪減，而刪減只能由懂業務、有決策權的人拍板。廠商可以建議，但不能替你決定商業上的取捨。
二、把「要驗證的假設」寫進需求文件。 不要只給功能清單。當廠商知道你要驗證什麼，他們才有機會提出更省的作法（例如「這段用人工處理就好，可以省下數週」）。
三、分階段交付，而且每階段都要能實際操作。 「開發完再看」對 MVP 來說風險太高，因為 MVP 的價值在於盡早取得回饋。NETVANA 採用每兩週一個 Sprint、固定 Demo 節點的作法，流程見軟體開發流程。
四、把後續擴充的條件寫進合約。 原始碼與文件的歸屬、第三方服務帳號在誰名下、後續維護與新增功能的計價方式。MVP 成功之後才是投入的開始，那時候如果被單一廠商鎖住，議價能力會非常差。相關條款見如何挑選軟體開發公司。
五、預留驗證後的預算與時間。 常見的錯誤是把全部預算用在第一版，驗證出結果卻沒有資源往下走。合理的作法是第一版只花一部分，保留資源給「根據回饋調整」這件必然會發生的事。
至於該全部外包、自己組團隊，還是用顧問搭配小團隊，取捨見軟體外包 vs 自建團隊；App 型專案的成本結構見App 開發費用完整指南。
MVP 上線之後：要看什麼
做完只是開始，真正的價值在於你怎麼讀取結果。
看行為，不要只看意見。 使用者說「很好用」跟他真的回來用第二次，是兩回事。要看的是：有多少人走完整條主線、在哪一步離開、有沒有人主動回來。
親自跟使用者談。 早期使用者數量少，正是可以一個一個訪談的時候。這種質性資訊在規模變大後就取得不到了。
觀察他們怎麼「誤用」你的產品。 使用者拿它去做你沒設想過的事，往往是最有價值的線索。
設定明確的判斷標準。 在上線之前就先講好：什麼結果代表假設成立、什麼結果代表要調整方向、什麼結果代表該停。沒有事先設定，事後就會選擇性解讀對自己有利的數字。
MVP 真正困難的地方從來不是技術，而是紀律——忍住不把所有想得到的功能都塞進第一版，忍住不在還沒人要用的時候就先蓋一座大樓。
如果你手上有一個產品構想，想先確認第一版該做到哪裡、用什麼方式驗證最省，與 NETVANA 討論。先把要驗證的問題講清楚，再談要做什麼。
延伸閱讀：估算開發預算見App 開發費用完整指南與網站製作費用怎麼算；團隊配置的取捨見軟體外包 vs 自建團隊；要砍功能之前，需求得先寫到能被討論，可以看軟體需求文件怎麼寫；MVP 一旦失控，就會變成典型的延誤案例，可以看軟體專案為什麼延誤；第一版上線之後，功能排序才是真正的考驗，可以看產品上線之後怎麼走；規劃第一版功能時，低程式碼平台可能是更快的路，可以看低程式碼與無程式碼平台適合你嗎；第一版該做什麼不該做什麼，媒合平台一樣適用，可以看媒合平台與多邊市場開發指南；選好格式後接著決定第一版該做什麼，可以看做 App 還是網頁版。
