MVP 軟體開發：範圍、成本與時程

MVP 軟體開發出錯的地方是範圍會議，不是開發過程本身。有人說出「最小可行產品」這幾個字，大家點頭同意，接著送來的功能清單裡卻寫著使用者帳號、後台管理介面、計費、通知、儀表板，還有一個行動應用程式。那不是最小可行產品。那是一個完整的產品，而它花掉的時間會是你心裡那個數字的三倍。

真正造成損害的字是「可行」。多數團隊把它讀成「好到可以賣給所有人」，但它的本意是「剛好夠用來判斷到底有沒有人想要這個東西」。

最省錢的範圍測試： 對每一項功能，問問自己會因為答案不同而做出什麼不一樣的事。如果一項功能改變不了任何決定，它就不屬於 MVP。後台管理介面不會告訴你人們是否想要這個產品；它只會告訴你，等人們想要之後，這個產品會更好管理。把它放到第二步再做。

MVP 軟體開發到底是為了什麼

MVP 存在的意義，是用真實使用者而不是各種意見來回答一個問題。這個問題通常是：會有人為它付錢嗎，或者會有人頻繁到足以說明問題地使用它嗎？

這就重新界定了什麼該被放進去。你需要的是那條能證明價值的唯一路徑，端到端跑得通，而且完成度要高到讓一個真實的人不必你坐在旁邊也能走完全程。在這條路徑給出答案之前，其餘的一切都是選配。判斷標準也很直白：把這條路徑交給一個從沒看過這個產品的人，看他能不能一次走通。

這也解釋了它與原型的差別。原型是用完就丟的，回答的是一個設計問題，往往連能跑的後端都沒有。MVP 則是面對真實使用者與真實資料的正式環境程式碼，一旦答案是肯定的就能繼續擴充。把兩者搞混，在兩個方向上都很貴：不是丟掉了你其實需要的程式碼，就是精心打磨了一個馬上要丟棄的東西。

哪些要進去，哪些要等一等

要進去的： 核心價值路徑、這條路徑所要求的最小限度身分驗證、如果問題是人們會不會付錢那就加上收款方式，以及足夠看清使用者實際在做什麼的埋點。

要等一等的： 後台管理介面、超出一兩種角色的角色與權限體系、通知偏好設定、新手引導流程、沒有人提過的第三方整合，以及所有以「反正都做到這裡了」開頭的東西。

有兩樣東西經常被砍掉，但其實不該砍。一是埋點，因為一個沒有分析資料就上線的 MVP 回答不了任何問題，錢等於白花了。二是刪除或更正資料的能力，因為真實使用者第一天就會出錯，而手動到資料庫裡做外科手術很快就會讓人受不了。

最常見的範圍膨脹就是後台管理介面，而它幾乎總是可以避免的。頭幾週裡，手動跑查詢架起來更快，在十個使用者的規模下也完全夠用。準備一個唯讀連線，再把幾條常用查詢存下來，基本上就能應付眼前所有的客服問題。等到人工支援使用者成為瓶頸時再去做管理介面，而那已經算是一個不錯的問題了。

英國的真實成本

MVP 的報價取決於它能做多少件不同的事，而不是它背後的點子。我們在英國交付中看到的區間是：

每天 £100 到 £200 的離岸交付會改變這道算術題，同時帶來我們在軟體開發外包 中討論過的協調成本。我們的客製化軟體開發成本拆解 說明了推高每一個級距的原因。

幾乎每一份 MVP 預算都會漏掉兩項成本。第一，上線之後總得有人來維運它，這是一個真實的月度數字，不是四捨五入的零頭。把主機、監控、告警值班，以及相依套件的升級都算進去，才是這筆錢的完整樣貌。第二是第二個版本，因為如果 MVP 好好回答了它的問題，緊接著的下一步就是在它之上繼續搭建，而一份到發布為止的預算，恰好在你剛弄清楚該做什麼的那一刻就花完了。

那個把三個月變成九個月的錯誤

為一個你還沒有的規模去建設。

這種本能可以理解。沒有人願意寫以後要替換掉的程式碼。於是 MVP 裡加上了訊息佇列、快取層、水平擴展與微服務邊界，在五十個使用者的規模下沒有一樣是真正承重的，可它們全都得在第一個人看到產品之前建好、測好並且維運起來。

誠實的說法是：MVP 完全可以在架構上很無聊。一個資料庫、一個應用程式、單純地部署上去。如果它成功了，你會在真正知道負載落在哪裡之後重寫其中一部分，而那次重寫會比你上線前的猜測更便宜，也瞄得準得多。

例外是那些以後改起來很貴的東西：你的資料模型、你的身分驗證方案，以及任何觸及個人資料的決定。在一開始就把這些大致定對，值得多花一週，因為它們正是日後拆解代價最高的部分。

如何在一個下午裡定好範圍

寫下描述使用者能達成什麼的那一句話。如果這句話寫不出來，問題就不在範圍上，而在於你還沒想清楚要驗證的到底是什麼。然後列出這句話所需要的畫面，別的什麼都不寫。對剩下的每一項功能，套用本文開頭的那個決策測試。

然後還是要把清單再砍掉三分之一。每個團隊在第一輪都會把範圍定得過大，而你現在刪掉的那三分之一，幾乎總是你在上線之後會刪掉的那三分之一。

訂一個日期，而不是一份功能清單。一個真的發布出去的三個月 MVP，比一個到第七個月還說「再兩週就好」的五個月 MVP 更有價值，而一個固定的日期會逼著範圍討論提前發生，那時候它還很便宜。

Mecanik 透過我們的軟體開發 團隊來界定並建構 MVP，包括由某個人勸你放棄後台管理介面的那一部分。如果你手上有一份功能清單卻沒有日期，那就從這裡開始。

相關文章: 英國客製化軟體開發：買家完整指南 、英國金融科技軟體開發：FCA、支付軌道與成本 、2026年如何建構Web應用：英國開發者指南 、面向代理商的白牌網站開發 。

常見問題

MVP 應該包含什麼？ 端到端跑得通的核心價值路徑、這條路徑所需的最小限度身分驗證、如果問題是人們會不會付錢那就加上支付，以及足夠看清使用者實際在做什麼的埋點。後台管理介面、角色體系、通知偏好設定，以及沒有人提過的第三方整合，全都要等到 MVP 回答完它的問題之後再說。

在英國做 MVP 軟體開發要花多少錢？ 單一路徑、只有一種使用者類型的 Web 應用，通常是六到十週內 £15,000 到 £35,000。兩種使用者類型加上支付與基礎管理功能，通常是三到五個月內 £35,000 到 £75,000。帶第三方整合或法遵要求的多邊產品，起跳價在 £75,000 左右，需要五個月甚至更久。

原型和 MVP 有什麼差別？ 原型是用完就丟的，回答的是一個設計問題，往往沒有能跑的後端。MVP 是面對真實使用者與真實資料的正式環境程式碼，一旦答案是肯定的就能繼續擴充。把兩者搞混在兩個方向上都很貴：不是丟掉了你需要的程式碼，就是為一個馬上要扔的東西做了過度設計。

做一個 MVP 應該花多長時間？ 單一路徑的應用是六到十週，一旦加上第二種使用者類型與支付就是三到五個月。如果你的估算超過五個月，範圍幾乎肯定已經大於一個 MVP，值得在動工之前而不是之後就先砍掉一部分。

MVP 最常見的錯誤是什麼？ 為一個還不存在的規模去建設。訊息佇列、快取層與微服務邊界在五十個使用者的規模下不承擔任何真實負載，卻都必須在發布前建好、測好並維運起來。MVP 完全可以在架構上很無聊。例外是資料模型、身分驗證，以及任何觸及個人資料的部分，這些以後改起來很貴。