MVP 的時程都是在哪裡拉長的

問時程之前，先定一件事

詢問 MVP 開發，最想知道的當然是要做多久。可是同一份功能清單發給幾家，回來的時程各不相同。功能數量本身定不出時程。MVP 不是正式產品的縮小版，是拿來驗證假設的工具。「有沒有人願意為這件事付錢」需要的最小版本，跟「正式對外也拿得出手的第一版」，工作量差好幾倍。

要定的只有一件：這一版想確認什麼。確認的對象一明確，接案方就會幫你把範圍收掉，只是要驗證這個的話，這幾個畫面和這幾個功能就夠了。假設空著，功能清單會一直長，時程跟著清單走。

先挑第一版不做的東西

把清單再看一遍，現在不用做的項目其實不少。後台管理是最典型的。初期的訂單或報名，用試算表接住、人工處理，照樣轉得動。三種社群登入，第一版留一個信箱註冊。多語言、通知、對帳自動化，在使用者變多之前，人都頂得住。

砍功能不等於做得隨便。使用者直接碰到的畫面和流程要是鬆散，假設根本驗不出來。要砍的是營運端的方便，還有那些「以防萬一」的功能。人手處理得來的事就先不自動化，省下來的時間放到使用者看得見的那一面。

開工之後，回覆速度就是時程

專案跑起來以後，把時程往後推的通常不是程式。設計稿送出去等確認的那幾天、文案等定稿的那幾天，疊起來就是以週計的落後。確認沒回來，做的人沒辦法往下一個畫面走。等待的時間會原封不動地加進開發期。

先把確認的節奏訂好，拍板的人收斂成一位，這種延誤會少掉一大半。每週固定一天看當週做出來的東西，當場決定，回饋就不會積。決策的人一多，光是把彼此矛盾的意見喬攏就要花時間。這個階段，決定得快比決定得完美更影響時程。

商店審核和金流簽約走的是別人的行事曆

開發做完了，服務還是開不了張，這種事會發生。App 要過商店審核，被退回就得改完重新排隊。要收款，金流服務商的簽約和審核另外算，公司登記資料也得備齊。

這一段接案方拉不動。把它算在開發期裡面，上線日就會對不上。

所以這類流程在開發第一週就一起掛上去。金流申請、商店帳號開通、文件準備，跟畫面的工作並行跑。外部服務串接同理。要接的服務已經確定，報價階段就把名字一起寫進去。文件寫得單薄、或者自帶一套審核程序的服務，本身就是時程變數。

先給我們一個上線日期

想開張的日子已經排定，把日期直接告訴我們也可以。想驗證的假設還沒收成一句話，一樣沒問題。Weple 做 MVP 的順序是先對齊這一版要確認的事，把時程釘住，再決定這段時間裝得下的範圍。已經有功能清單的話，我們會一起挑出第一版可以不做的項目。計價的依據寫在價格說明，商店審核、金流簽約這些跑在外面的日程，也會一起畫進第一張時程表。