很多人常常來問我,我有一個 idea ,要做出一個 MVP 到底要多久時間?到底要經歷哪些步驟?我現在已經做了什麼什麼,我到底要怎麼繼續進行下去呢?其實這些問題沒有標準答案,根據不同型態的產品也可能會做不同的預算分配跟調整,不過當朋友來問這問題的時候,根據我過去的十個產品開發經驗,歸納出以下的數據,希望對於想做產品的你,有參考的價值。

  • 做產品開發技術的循環到底是什麼?

其實根據我的第一篇文章,可以稍微瞭解一下技術開發的步驟;特別提醒,新創產品最好三個月內就上線,避免軍心渙散。深究其開發循環如下:

 滑動 05

1. MVP Plan 階段 – 建立開發目標

所需時間:最短一週、最長兩週

一個循環的開始,透過線稿(wireframe)去描述產品流程,不管是 App 還是網頁,一定要有,然後透過 user story 去描述使用者行為,有人會說可不可以只有其中一個,我的強烈建議是兩個最好都要有,而且定義的規模建議不要太大,做出最重要的功能就好,根據我過往數個產品的開發經驗,做完這個階段,包含專案經理跟產品團隊討論的過程,大約會花一週的時間,有的比較謹慎的產品團隊會花上兩週,定義得更仔細,不過如果超出兩週,通常想法會又開始發散,造成很多不必要的疑惑。

根據過去的經驗,第一個產品建議把行為簡化到 30~40 個以內,這樣 MVP 的開發才不會因為過於發散,而在第一次產品上線受到很大的阻礙,30~40 個 User Story 大約可以拆成 80~100 張 Ticket 再交由工程師進行開發,一張 Ticket 盡量不要超過 8 小時的實作時間,這些初期工作都是很容易讓人忽略的準備動作。

2. Design the mockup – 設計圖的提案流程

所需時間:160 hours with budgeting

設計的流程主要分成兩個,主視覺提案與所有頁面的按鈕提案,基本上主視覺如果可以快速定下來,後面的流程跟按鈕的設計,就會快上不少,設計在這個階段通常出一個提案需要 16~24 小時,也就是兩到三天的時間,有的專業設計師會花更久的時間,提出兩到三個方向,根據產品團隊選定的方向去進行後續頁面的設計,如果你的預算與時間充足,可以在這個階段多看幾遍,因為好的設計絕對會節省很多工程師的時間,你甚至可以請工程師花個 2 小時先看一下設計的狀況,看看有沒有什麼特效會造成工程時間拉長,如果沒有,才將設計定稿。

設計的時間通常會花到 2~4 週,後面還會有切圖的工作,現在有好用的 Sketch 可以幫忙處理切圖的事情,不過如果沒有用 Sketch,切圖也會花上大約 1 週的時間。這邊會有設計師的成本,建議至少抓 160 小時作為你的預算。

3. Design all the data structure and database schema(API Design included) – 打地基最重要的事情

所需時間:40~80 hours with Experienced structurer budgeting

做軟體產品,不管你是要做 App 、還是 Web Service ,請一定要設計好你的資料庫結構跟 API,因為這是影響開發循環最重要的事,我看過不少的開發團隊在還沒訂定 schema 的狀況下,就開始做產品,開發期間不斷的調整結構,其實這並不是不可行的方式,但是只限定於人少的團隊,通常是一人團隊比較有可能,一開始制定資料庫的結構跟 API 的傳輸方式,並且建立文件,是為了讓前後端的工程師都能有一個初階的規則去遵循,開發循環中當然 API 跟 Data Schema 一定會持續改變,不過維持一份良好的 API 文件,絕對會是重要的關鍵,所以這個階段,請務必找尋有產品建構經驗的架構師來做或是用顧問的方式來合作,根據過去的執行案例,這個階段通常花一到兩週就能建立第一版架構,但是架構好與不好會讓後面的工程時數有極大的差異。

4. API execute – 技術開發中很容易讓人遺忘的一段路,

所需時間:20 APIs with 80 ~ 120 hours budgeting / 30 APIs with 140 ~ 160 hours budgeting

通常進行一個技術開發,後端的準備應該要在前端執行之前,也就是說假設三個 sprint 要做出一個 MVP,第一個 sprint 後端工程師可能有大量的工作,但是到第三個 sprint,後端工程師可能會比較悠哉一些。很多人可能不太能了解什麼是 API ,簡單來說, API 就是網頁前端或是 Native App 要索取資料時,跟後端拿資料的介面格式,比如說如果你要登入,你需要有一個 API 讓前端可以將帳號密碼的資料送入 API, API 根據送入的資料查詢資料庫,最後吐出這個登入的人的使用資料, API 的角色其實有點像是 RPG 裡面的 NPC ,跟他講不同的話,會有制式的答覆。有人可能疑惑為什麼不用前端程式直接去索取資料庫的資料,在這邊強烈建議不要這麼做,雖然就系統層面來說,這是沒有問題的執行方式,但如果這麼做,在平台變多的狀況下,資料庫端不但難以管理,更有可能因為某一個前端串錯程式,就造成整個資料庫毀於一旦。

根據我過去的經驗,剛開始寫 API 的時候,因為必須顧及很多基礎的架構,所以寫前 20 隻 APIs 可能會花上較多的時間,一旦 API 架構固定,後面的開發則會更快速一些,通常 API 的開發在一個 MVP 開發循環內,會至少持續 3~4 週,不過通常 1 週開發過後,下一階段便可開始執行。

5. Front-end Coding (Web, iOS, Android included) & Backend and Frontend merge – 如果說做產品是蓋房子,那麼這個階段就是鋼骨結構做好後到完工前的所有工作

所需時間:160 ~240 hours per platform budgeting

這個階段的工作,完全是工程師發揮的階段,以矽谷目前盛行的狀況,是以 Scrum 的方式來進行管理,也就是說,在每一個 Sprint 訂下目標,然後快速執行,並且在 Sprint 結束後快速驗證,通常這個階段會跟上一個以及下一個一起用 Scrum 的方式進行,基本大約花上 4 ~ 6 週就必須完成。

6. Testing and debug – 這是個重要的步驟,建議不要小看調整跟修 Bug 的時間,

所需時間:80 ~ 120 hours per platform budgeting

修 Bug 有四種狀況,系統設計錯誤造成的致命錯誤、系統設計造成的使用經驗錯誤、程式設計造成的致命錯誤、程式設計造成的使用經驗錯誤,重要的程度分別是 1>3>2>4,但是修理的狀況建議只做 1,3,4,讓 2 送上架後再修,原因是像 iOS App 審核時間很久,有一些調整,只要不是造成系統問題的狀況,部分使用經驗的謬誤,可以隨著技術開發的循環,逐漸調整,之所以建議 4 可以做,是因為 4 的狀況,通常是寫程式的人出錯,修正這樣的錯誤通常不會花上太多的時間,因此可以快速修正。

根據經驗,這個階段加上前兩個步驟,會額外加上 1 ~ 2 週進行修正。

  • 產品上架後的更新,才是關鍵

產品上架後,如果您的服務是要長期營運的,建議再接下來每兩週都能進行產品的更新,不管是剛剛 debug 階段的第二種情形的修正,還是產品使用經驗的增強,甚至是新功能的開發,建議根據以上的循環,每兩個禮拜進行一次 (10 個工作天),也就是說下一階段的 MVP 在送產品上架的時候就要決定,約略 5 個工作天修正後端,5 個工作天修正前端並且進行 debug ,有時後端其實不用開發,前端就能進行修正,那前端就有 10 個工作天來進行,這個速度其實對工程團隊會是個挑戰,但是如若產品可以以這樣的開發循環時間進展,使用體驗通常可以在一個月內就趨向穩定,這樣會更有本錢開發新功能。

綜合上述數據,最短可以在 10 週,最長則是在 14 週開發完成,一個平台時數的花費則在 500 ~ 760 小時之間,也就是約略 3 到 5 個工作月,如下圖所示:

product cycle-with time

雖然根據產品的規格,時間有可能有不同的反應,也是有過在一個月就讓產品上線、五天做出 prototype 等的經驗。一般來說,通常行為創新的產品技術沒有那麼艱深,耗時較短,而技術類創新則剛好相反。不過這樣時數的花費,對一般人來說,其實不管是請人也好,還是自己花上時間實作也好,真的是個不低的成本,更別說後面的更新並且讓產品長大,才是真正的挑戰。所以提醒各位,創業,真的務必要想清楚才行啊。

以上的這些程序,需要很多不同 Skill 的人,也有很多簡化的可能性,這都會是拿來衡量自己技術發展未來的重要指標,我想這部分就在下一篇繼續補充了。

(本文轉自 ALPHACamp,作者:,未經授權不得轉載,Photo Credit:Jeremy Brooks