MVP 該砍到多小?第一版只做「不能沒有」的功能

幾乎每個第一次做系統的業主,功能清單都會越開越長:「既然都要做了,順便加個報表」「以後會用到,先做起來放」。我們的經驗是殘酷的:第一版塞進去的功能,上線後有八成沒人碰。每一個「順便」都是真金白銀的開發時數,更糟的是拉長上線時間——市場不等人,你花八個月做的完整版,可能三個月的精簡版就能開始收單驗證了。MVP(最小可行產品,意思是「小到不能再小、但已經能解決核心問題的第一版」)的功課,就是砍。

一個問題砍掉八成功能:沒有它就不能上線嗎?

我們幫業主收斂範圍時,只用一把刀:對清單上每個功能問「沒有它,系統就不能上線嗎?」注意,不是問「這功能有沒有用」——幾乎所有功能都「有用」,這樣問永遠砍不掉東西。要問的是「沒有它,第一天的核心流程會不會斷」。

拿一個接單系統當例子:客人下單、店家收到、出貨、收款——這條線斷任何一節都不能上線,是 MVP。那「會員等級」呢?第一天沒有會員等級,單照收、貨照出,所以不是。「自動對帳報表」呢?前三個月訂單量不大,人工對帳撐得住,所以也不是。被砍掉不代表不做,而是排進第二版——等真實使用回饋進來,你會發現當初想像的第二版清單,有一半會被真實需求取代。這反而是好事:你把錢花在確定有人要的功能上。

MVP 不等於粗糙版

常見的誤解是把 MVP 理解成「先做個爛爛的」。錯了。MVP 是範圍小,不是品質差。範圍內的功能必須做到穩:金流不能掉單、庫存不能算錯、資料不能遺失。我們自己營運進銷存 SaaS,第一版功能清單砍得很兇,但留下來的每一條流程都有自動化測試守著——因為加盟門市每天靠它營運,錯一筆帳的信任成本遠大於少一個功能。

另一個容易被砍錯的地方是「地基」:備份機制、基本資安、可以擴充的資料結構。這些東西使用者看不到,常被當成「以後再說」,但它們是少數「現在不做、以後補要十倍價」的項目。砍功能可以大膽,砍地基要非常小心。

MVP 的精神不是省錢,是把「猜測」的成本降到最低——用最小的投資換到真實市場的答案。

怎麼跟團隊一起排出第一版

實務上我們會帶業主做一輪分類,把所有功能丟進四個桶子:

1. 不能沒有:核心流程斷了就不能營業的。這是第一版。
2. 很快就要:上線後一到三個月內、量起來就撐不住的(例如人工對帳的自動化)。排第二版,但架構上先預留。
3. 想要:聽起來不錯、但沒有數據支持的。冷凍,等上線數據說話。
4. 其實不需要:通常是從別人的系統抄來的想像。直接刪,連清單都不要留,免得每次開會都復活一次。

分完之後看第一桶的報價和時程,如果超出預算,回頭再砍一輪——是的,第一桶裡通常還藏著第二桶的東西。這個過程業主常會心痛,但請記得:每個留在第一版的功能,都在讓你晚一點上線、晚一點開始學習。

砍完之後,守住範圍

範圍收斂完,最大的敵人是開發途中的「順便加一下」。我們的做法是把砍掉的功能白紙黑字寫進規格書的「本期不包含」清單,開發中冒出的新想法一律進第二版清單,不打斷當前衝刺。聽起來不近人情,但守住範圍才守得住時程和預算——這是對業主最實際的保護。

如果你手上有一張越長越失控的功能清單,不確定第一版該留什麼,歡迎帶著清單來找我們聊,或先看看我們的客製化系統與 SaaS 服務怎麼做範圍規劃。砍範圍這件事,旁觀者清,我們砍過很多次了。