你的開發團隊製作 MVP需要多久時間? 半年、二周、 5天 ?
三種作法的比較表，你選擇哪一種呢?
前言
連續顧問了幾家公司，驚訝的發現，研發部門估算出來的MVP開發時間都要超過半年，讓人不經懷疑大家看過《精實創業》這本書嗎? 現在不是AI的時代嗎? 只是試一下市場的水溫，需要多少時間呢? 試著想想；當業務部門或是PO部門興沖沖地把想了很久的好主意，交給研發部門，想要「先做個 MVP 來測試市場」。
結果研發部門一估算，答案是：至少要 6 個月。
這讓業務同仁差點沒暈倒：「不是說好 MVP 嗎？怎麼跟半年產品沒兩樣？」
用影響 vs 努力矩陣分析MVP的位置
研發團隊眼中的「MVP」： 小而完整的產品
對研發來說，MVP（Minimum Viable Product，最小可行產品）不是實驗，而是「小型完整版」。所以他們會自然地考慮到系統的架構，便把一堆必備功能都加了進去：
登入機制
訊息加密
伺服器備份
API 安全性
維運監控
因為在他們的世界裡，「上線」才算成功。既然要上線，就要能跑穩、能維護，否則一出事就是研發的責任，而且事關績效馬虎不得。
這就好比有人請他們煮泡麵，他們覺得必須要：桌上擺好餐具、菜色要有營養、湯頭要調整鹹淡、最後還得加顆溫泉蛋。結果，原本三分鐘就可以搞定的泡麵，硬是搞成了三小時的全餐。
《精實創業》眼中的 MVP：驗證假設的實驗
Eric Ries 在 2011 年出版的《精實創業》（The Lean Startup）[註 1.] 中強調：MVP 的核心不是產品，而是 學習。
“A minimum viable product (MVP) is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” [1]
它可以是：
一個紙上原型（prototype）
一個假按鈕（背後全人工處理，Wizard of Oz test）
或者，只做單向傳訊功能，先觀察用戶有沒有興趣
換句話說，故事不在長短；是否精彩才是重點，泡麵 MVP 只需要：泡好麵，吃一口，看味道行不行。至於配菜、雞蛋、擺盤，等確定這碗麵受歡迎再說不遲。
誰說；學習沒有績效，有記錄、有回饋，數據都有了績效自然就有了。
常見誤解：拿 MVP 用來驗證系統架構？
在很多研發團隊裡，當聽到「做 MVP」時，RD 的第一直覺是：「那就先把系統架構做好，因為以後一定要撐得住。」
這種想法其實很合理，因為：
工程習慣：工程師受訓的思維是「設計穩固的系統」，自然會想先把基礎打好。
責任壓力：一旦 MVP 後來要擴充，他們怕被指責「當初架構沒設計好」。
定義模糊：在研發眼中，MVP 常常被誤解成「第一個能跑的產品」，於是就必須有完整架構。
然而，這正好偏離了 MVP 的本質。當然績效也是一個考量，實驗不成功就沒有績效了，這是錯誤的觀念，主管應該設法讓團隊知道，績效應該包含學到東西了也該算進來(這正是Devops 所主張的快速失敗 fail fast，註3.)。
架構驗證 ≠ 市場驗證
架構驗證：回答「系統能不能做」，例如能否撐住 10 萬人同時上線。
市場驗證：回答「做了有沒有人要」，例如是否有 30% 使用者願意點擊功能。
MVP 的重點是 市場驗證，而不是 架構驗證。如果一開始就拉高規格去驗證架構，等於花半年蓋了一個「沒有人確定要不要住」的高樓。
如何避免這個誤解？
先定義成功指標：在 Kick-off 階段明確說明：這次 MVP 的目標是「學到市場數據」，而不是「建出穩定架構」。
拆分工作：架構驗證可以獨立成為「技術 Spike」或 PoC（Proof of Concept），不要混在 MVP 裡。
設計衝刺助力：透過 Google 設計衝刺 [註 2.]，用五天就能做一個粗糙原型，讓 RD 看到「我們現在不是在建系統，而是在試市場」。
MVP 是用來問『有沒有人要』，不是問『系統撐不撐得住』。
Google 的設計衝刺
Google 設計衝刺：五天就能看到成果
除了《精實創業》，另一個廣為人知的快速驗證方法是 Google 設計衝刺（Design Sprint）。
由 Google Ventures 團隊的 Jake Knapp 在 2016 年出版《Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days》[2] 提出，目標是讓團隊在 五天之內，就能把一個想法從概念變成可以測試的雛型（Prototype）。
流程分成五天：
Understand（理解）：星期一，釐清挑戰、對齊目標。
Sketch（構想）：星期二，大家繪製解法草圖。
Decide（決策）：星期三，投票選出最佳解法，形成原型方案。
Prototype（原型）：星期四，做出可以測試的簡單原型。
Test（測試）：星期五，邀請真實用戶試用並回饋。
設計衝刺不是要做完整產品，而是 在一週內聚焦驗證核心假設。這樣能避免長達數月的開發後才發現方向錯誤。
“The sprint gives teams a superpower: the ability to fast-forward into the future to see their finished product and customer reactions, before making any expensive commitments.” [2]
小結
開發部門要知道，MVP 不是「最小產品」，而是「最小學習」。
精實創業（2011, Eric Ries）[1]：是提供「持續驗證假設」的心法。
Google 設計衝刺（2016, Jake Knapp）[2]：提供「一週完成驗證」的流程。
當研發說 MVP 需要半年，其實不是因為懶惰，而是因為組織文化與定義不清，導致研發傾向把 MVP 當成「小而完整的產品」或「架構驗證」。唯有重新建立「快速實驗、失敗也有價值」的文化(註3.)，MVP 才能真正落地，回到本質：最小學習、快速驗證。
所以下次當有人說要做 MVP，不妨先問一句：「我們是要煮三分鐘泡麵？還是要準備一桌全餐？」
註解
[1] 《精實創業》（The Lean Startup, 2011, Eric Ries）
MVP 定義：“A minimum viable product (MVP) is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
精神：以最小成本、最短時間，驗證市場或使用者假設，強調 Build–Measure–Learn 循環。
[2] 《Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days》（2016, Jake Knapp 與 Google Ventures 團隊）
Sprint 定義：“The sprint gives teams a superpower: the ability to fast-forward into the future to see their finished product and customer reactions, before making any expensive commitments.”
精神：用五天流程（Understand–Sketch–Decide–Prototype–Test）快速聚焦核心假設，得到用戶回饋。
Google Design Sprint 的起源，確實和 高風險、高金額的創投案 有關。
Jake Knapp 在 2009 年進入 Google Ventures（GV）後，開始將自己在 Google（Gmail、Google Hangouts 專案）累積的產品開發方法系統化。
Google Ventures 當時的任務，是幫助 GV 投資的 新創公司（一張支票動輒幾百萬、上千萬美金）盡快找到產品方向。
傳統流程是：投資後 → 團隊花 6–12 個月開發 → 才知道市場要不要。這對創投來說風險極高。
Knapp 設計了 Sprint，把時間壓縮到 五天，讓新創在「花大錢開發前」就能先看到用戶反應。
所以可以說：✅ 是的，設計衝刺 (Design Sprint) 確是 Google Ventures 用來「驗證數百萬到上千萬美金級別投資案方向」的方法論。
[3] DevOps 三步工作法
1️⃣ 流動原則（The First Way: Flow）
目標：加速從開發到營運的價值流動。
作法：
打通從需求 → 開發 → 測試 → 部署 → 營運的端到端流程。
消除瓶頸與浪費，縮短交付時間（Lead Time）。
強調自動化（CI/CD）、小批次交付、可視化工作流程。
2️⃣ 回饋原則（The Second Way: Feedback）
目標：建立快速、持續的回饋機制。
作法：
讓問題能盡早被發現並修正（Shift Left）。
建立監控、測試、使用者回饋系統，確保資訊能回流到開發。
鼓勵跨部門合作，形成透明、正向的回饋文化。
3️⃣ 持續學習與實驗（The Third Way: Continual Learning and Experimentation）
投資於員工學習，讓團隊不斷進化。
目標：打造持續改進與創新的文化。
作法：鼓勵小規模實驗與創新，不懼怕失敗。重視知識分享、導入「事後檢討（Blameless Postmortem）」文化。
>> 「快速失敗」(Fail Fast) 在 DevOps 三步工作法 裡是 第二步與第三步的交集。
分享此文：
分享到 Facebook(在新視窗中開啟)
分享到 X(在新視窗中開啟)
X
喜歡 正在載入...
相關