很多人常常來問我，我有一個 idea ，要做出一個 MVP 到底要多久時間？到底要經歷哪些步驟？我現在已經做了什麼什麼，我到底要怎麼繼續進行下去呢？其實這些問題沒有標準答案，根據不同型態的產品也可能會做不同的預算分配跟調整，不過當朋友來問這問題的時候，根據我過去的十個產品開發經驗，歸納出以下的數據，希望對於想做產品的你，有參考的價值。
做產品開發技術的循環到底是什麼？
其實根據我的第一篇文章，可以稍微瞭解一下技術開發的步驟；特別提醒，新創產品最好三個月內就上線，避免軍心渙散。深究其開發循環如下：
所需時間：最短一週、最長兩週
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
我看過不少的開發團隊在還沒訂定 schema 的狀況下，就開始做產品，開發期間不斷的調整結構，其實這並不是不可行的方式，但是只限定於人少的團隊，通常是一人團隊比較有可能，一開始制定資料庫的結構跟 API 的傳輸方式，並且建立文件，是為了讓前後端的工程師都能有一個初階的規則去遵循，開發循環中當然 API 跟 Data Schema 一定會持續改變，不過維持一份良好的 API 文件，絕對會是重要的關鍵，所以這個階段，請務必找尋有產品建構經驗的架構師來做或是用顧問的方式來合作，根據過去的執行案例，這個階段通常花一到兩週就能建立第一版架構，但是架構好與不好會讓後面的工程時數有極大的差異。
4. API execute – 技術開發中很容易讓人遺忘的一段路，
通常進行一個技術開發，後端的準備應該要在前端執行之前，也就是說假設三個 sprint 要做出一個 MVP，第一個 sprint 後端工程師可能有大量的工作，但是到第三個 sprint，後端工程師可能會比較悠哉一些。很多人可能不太能了解什麼是 API ，簡單來說，
，比如說如果你要登入，你需要有一個 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個工作月，如下圖所示：
雖然根據產品的規格，時間有可能有不同的反應，也是有過在一個月就讓產品上線、五天做出 prototype 等的經驗。一般來說，通常行為創新的產品技術沒有那麼艱深，耗時較短，而技術類創新則剛好相反。不過這樣時數的花費，對一般人來說，其實不管是請人也好，還是自己花上時間實作也好，真的是個不低的成本，更別說後面的更新並且讓產品長大，才是真正的挑戰。所以提醒各位，創業，真的務必要想清楚才行啊。
以上的這些程序，需要很多不同 Skill 的人，也有很多簡化的可能性，這都會是拿來衡量自己技術發展未來的重要指標，我想這部分就在下一篇繼續補充了。
Photo Credit：Jeremy Brooks
