指南
規劃首個版本:只建立足以驗證構想的最小產品。
軟件中最昂貴的錯誤,是建造大量錯誤的東西。規劃良好的首個版本 — 常稱為 MVP(最小可行產品) — 是避免這種情況的方法。它不是廉價粗糙的版本,而是小而穩固、能回答您最大問題的版本。
重點摘要
- 由一類使用者的一項任務開始,並做好它。
- 首個版本應回答一個具體問題,例如「顧客會以這種方式預約嗎?」
- 削減功能,而不是品質。小而可靠勝過大而不穩。
- 事先決定成功是什麼模樣,以及何時檢討。
- 保留一份看得見的「留待之後」清單,令事情不被遺忘,也不會偷偷混入。
第一步:找出核心任務
完成這句話:「我們的產品協助[誰]做[什麼],從而[帶來什麼好處]。」如果需要用上多於一個「及」,您可能其實有數個產品。選出最重要的一個。第一版的一切都應服務這句話。
第二步:全部列出,然後分類
寫下您或團隊想到的每項功能,然後把每項歸入三個類別之一:
對「必須有」要嚴格。一個實用的測試:如果沒有它就上線,顧客還能完成核心任務嗎?如果可以,它就不是必須。
第三步:清楚哪些可以人手處理
並非一切都需要在開始時自動化。預約產品可以先由人員逐一以訊息確認;批核流程可以只發一封簡單電郵。為頭五十位顧客人手處理,會讓您知道什麼才值得好好自動化 — 而且成本遠低於憑空猜測。
對取捨要坦誠:人手步驟需要員工時間,所以只適合數量較少的情況。
不應削減的東西
- 核心流程的可靠性。如果它唯一做的事失敗了,其他都不重要。
- 保安及私隱基本要求。保護人們的資料不是日後才加入的功能。
- 主要任務清晰易用的畫面,並適用於顧客實際使用的裝置。
- 量度及聆聽使用者意見的方法,令這個版本能教曉您一些東西。
- 人們需要的語言。如果您的顧客使用英文及中文,兩者都是產品的一部分。
第四步:在上線前定義成功
選出幾項能回答您問題的指標,以及檢討日期。例子:
數字應符合您的規模。如果您說不出什麼才算成功,代表仍未準備好開始建造。
情境示例:一間小型補習中心
假設一間中心想要一個應用程式,包含預約、付款、進度報告、家長聊天及獎賞計劃。(此為示例情境,並非客戶。)
核心任務:讓家長查看時間表並申請補課。第一版是一個網頁,顯示時間表、補課申請,以及課堂有變時的訊息。付款暫時維持原狀;進度報告、聊天及獎賞留待之後。兩個月後,中心便知道有多少家長使用,以及哪些被延後的構想是他們真正要求的。
首個版本之後
延伸閱讀
相關指南:如何撰寫項目需求簡介、範疇釐定工作坊會做什麼、項目需時多久。
常見問題
MVP 與原型一樣嗎?
不一樣。原型展示某事物可能如何運作,通常會被丟棄。首個版本是真正的軟件,由真實的人使用,並以可擴展為目標而建。
首個版本應該花多長時間?
通常是數週至數個月。如果需要長得多,範圍可能太大,無法及早讓您學到東西。
顧客不會對小產品失望嗎?
只要它把主要任務做好便不會。人們通常遠比對故障更容易原諒缺少的功能。