人人會立志，但很少人達成，你身邊一定有一些說到做到的人，他們怎麼做到的？觀察後發現他們多用了【 MVP 最簡可行產品】技法，這種人我們會說「那個人哦，他很靈光！所以註定成功」，「靈光」是註定的？我們不註定就不能成功嗎？其實，「靈光」技巧是有清晰的方法論，而且你在學校有學，只是那些靈光的人，把學校學的用在人生，而其他很多人說學校教的沒用！
本文目錄
MVP 來自研究方法
研究方法聽起來很難？我遇到多數人這樣說，但其實你國中理化實驗就用過了，我小時候會發一本「實驗記錄簿」，因為上課都用背的很少用到，而且紙張又大又白，很適合塗鴉，在那張實驗記錄裡要寫下面這些內容：
| 標題 | 實驗報告/學術論文 | MVP |
|---|---|---|
| 你發現一個有趣的問題 | 研究問題 | 第一次段考英文 30 分，如何增進？ |
| 你讀了別人的研究 | 背景理論或相關文獻支持 | 上網搜尋都說能說出口比文法重要 |
| 提出你的假設 | 預期結果 | 只要能常常講，英文就會變好 預期結果：常講，下次期中考英文提高 20 分 |
| PLAN 你設計了一個實驗 | 實驗設計與條件 材料與設備 操作步驟 測量和記錄方式 | 實驗設計與條件：每天找 1 個同學講 10 分鐘英文，以及大聲朗讀，從現在到段考 1 個月 材料與設備：參加同學 10 人；朗讀素材一本 操作步驟：每天選 3 節下課，找不同的同學用英文討論前一堂課的內容 測量和記錄方式：每日用英文記錄討論主題 |
| DO 進行實驗 | 記錄及結果 | 按照設計進行實驗，最後段考成績 49 分，實驗證僞，假設不正確 |
| CHECK 驗證結果？分析與討論？ | 是否支持原先假設，並指出結果對於更廣泛研究的意義。 | 單字不夠用，英文口說還是比手劃腳，但敢講，考試重視文法字彙，與口說無關 |
| ACT 改進 | 下一步研究建議或改進之處，進一步推進研究。 | 以考及格為目標的話，要擬定單字、文法學習計劃 |
日常生活可以用 MVP 解決問題，像這位同學沒去補習，他把英文拆解開，分作口語表達、單字、文法、寫作、聽力… 等，他想出一個方法，每次段考修正一部分，理性地找到克服考試的關鍵。
如果你剛升上七年級，開學時發現鄰座王同學英文很爛，經過 3 次段考，他每次都進步一點點，七下時，英文考試每次都及格，甚至後幾次在班排前 5 名，老師同學都嘖嘖稱奇，你是不是覺得他很「靈光」？
幫你找出問題，一一克服，達成目標的方法，竟然是你國中學的研究方法！
讓我們比較不同的立志方法
Agile 是新的專案管理，與傳統 Waterfall 相對，讓我們用人生如何立志來瞭解方法的差異。
傳統 WATERFALL 專案管理，上級最愛，但不實用
劉同學英文也很爛，他決定立志，經過分析他把英文分作幾大項：
- 口語子專案
- 聽力子專案
- 單字子專案
- 文法子專案
- 寫作子專案
依照分類，他把每個子專案分解成不同的任務，畫成類似下面這樣的甘特圖，前後關係清晰，做完這件事做那件事，因為像瀑布一層接一層，這是瀑布式的專案管理。
劉同學整個週末都在家裡寫計劃，寫完以後，他看了洋洋灑灑 5 張 A4 紙，心中覺得心滿意足，幾乎已經看到一年後的英語大師了，於是他睡了一覺。
實際執行起來是這樣的：
- 每個子專案他都努力達成，但是要寫小作文時寫不出來，因為從來沒有一起用過；
- 他也發現了口說英語多好對考試似乎沒用，但是那洋洋灑灑 5 張紙是環環相扣的，如果不按照設計就大亂，他還要花一個週末調整計劃。
這是傳統 waterfall 專案管理的問題——自以為是上帝。它假設團隊有經驗、能預知風險和變化、一定能 100% 按照規劃做…，所以還沒開工就鉅細靡遺地從期初規劃到期末（美國登月就是這樣規劃的），人力、成本、資源… 都算得清清楚楚，也難怪非常受到自以為是上帝的老闆和政府單位的喜愛，上帝喜歡全然掌控，不喜歡意外，而你，身為上帝的子民、夠格的專案團隊，你就應該預知一切，連意外的預算都預先留好。
事實是，只發生一次的才叫專案，沒有先例必有意外，為了未卜先知，人類發明了各種算命技術，但都是破財後才說：「啊！大仙很早就跟我說今年會破財！」，足以說明人類非常不擅長預估，結果， waterfall 專案管理最大的功能是給上級過目，你真照做就辛苦了。
傳統 waterfall 的象徵就是 MS-Project 繪製的甘特圖，讓人看起來很放心，事情會像機械鐘一樣順序完成，不過，如果我們得像機械鐘一片齒輪一樣工作，我會覺得很煩心，既然人人都有自主意識，這口機械大鐘必然沒有銅造的那麼準。
腳踏實地 實用的 Agile 敏捷專案管理
因為 waterfall 不切實際且不實用，Agile 就出現了，它非常腳踏實地。
同樣要考好英文，王同學的拆分也是：
- 口語
- 聽力
- 單字
- 文法
- 寫作
他用下面的看板很簡單的把幾個目標寫好，但一次解決一個問題，如果口語不影響考試，接下來可以降低，看起來光讀好文法就能拿到 30 分，那就好好讀文法，每個小實驗都設計了驗收方式，每一兩週就驗收一次，不要等到最終結案才來驗收。
你看，Agile 的宗旨跟不喜歡變化的 Waterfall 相反，它先做最簡版 ➡︎ 測試 ➡︎ 修正原計劃，這樣一輪一輪用不停溝通（測試）解決人類很爛的預測能力，只需要知錯能改，可以把易經、紫薇、星座… 這些算命書全收起來了，我們再也不用未卜先知，因為明知道這些都不管用（在劉伯溫無法復生的前提下）。
在 Agile 常見的工具是「Kanban」，常用的有 Trello，其實因為原理簡單，類似軟體好多，例如 Notion 的 Kanban 更完善，但它太複雜很難做為團隊協作工具。
前面的拆分用幾個原則：
- Smallest：每一輪產出都只驗證最簡假設
- Testable：每一輪都可以測試
- PDCA：測試後都能獲得反饋（使用者覺得做對了嗎？），再依照反饋來調整專案
達成目標為前提設計 MVP
「OK，我懂了」我之前就這麼想，我懂 Waterfall 是上帝視角預測未來會發生的事，但預測不靠譜，換個腦袋改用 MVP 觀念小步快跑前進。實際上，當我有一個專案去做時，剛開始一定想得很美好，有各種功能，最後就會大大的成功，不免就把未來全部想像好了，那，我這麼大的計劃，第一個 MVP 要包含哪些？糟糕了，想做的太多，那我們可以設計一個功能多一點的 MVP？我統統想要。
所以實作的困難常常是如何簡化到「最簡」？實際上，只要能達成相同目標，任務越少越好。
方法就是設計實驗。
拿開發一台新車來說，你首先要發現一個「痛點」（pain point，在寫論文就是「開題」），我發現一般轎車只能載 5 人，但 7 人座的車又太大了，為了偶爾有需要載更多人的家庭，可以設計一台偶爾可以載 7 人的小轎車。
針對這個痛點提出了「假設」（Hypothesis）：
- 假設一：小家庭偶爾載 7 人，多變化空間狹窄 7 人座也可
- 假設二：容量>性能，一家四口，7 人狀態載老人家或寵物
決定先測試第一個假設，我們設計了幾個「使用者故事」(User stories)，使用者故事通常是用「who + I wish + why」的格式撰寫：
- 身為車主，我希望父母來時可以多一排座位，讓我比較好照顧他們
- 身為車主，我希望只有一家人時行李箱可以佈置為狗狗的位子，讓牠們不會干擾駕駛
- 身為老人家，我希望車輛底盤低一點有地方抓，讓我比較容易上車
第一版 MVP 要驗證上面 3 個 User stories，而當這 3 個 User stories 驗證時，就說明第一點假設被驗證了。MVP 根本不需要做出一台漂漂亮亮的車，只需要：
- 找台小發財，在後行李箱緊貼第二排座位固定兩張砍掉腳的餐椅，找一家人加老人家坐上去，出去開個 20 分鐘；
- 把餐椅拔掉，在行李箱安放圍欄圍成狗籠
- 找市面最低的小發財用滑動門，把避震器再降低，車上拴幾個把手
找幾家人坐坐看，問卷知道假設一是否驗證，接下來才去驗證假設二。
因為每個 MVP 都是實驗，當然不能愛加什麼就加什麼啊！
用「是否能回答假設」決定 MVP 及一切
每一輪推出 MVP 的目的是「是否能回答假設」？如果一次得不到答案怎麼辦？依照反饋修改迭代，再出第二代，這就是 PDCA 方法，那 PDCA 要迭代到什麼程度停止呢？重點是「是否能回答假設」？
Waterfall 有個 WBS (Work Breakdown Structure) 方法，把任務拆成更小的任務，所以會在還沒發生前列出一大堆任務，跳過驗證部分，這其實是破壞實驗，如果你認為英文學好要靠口說，但你又同時在拼文法，最後考試考好了，是口說還是文法的功勞？所以在敏捷裡的「簡單」不是「nice to have」，而是「must to have」，非必要的因素反而干擾實驗準確度。
例如，小車塞進 7 人舒適嗎，我加進了「超強冷氣」，反而讓受試者回覆「整體來說很不舒適」，可能是冷氣太冷不舒適，不是空間不舒適啊！
用戶的一場旅程 User Journey
這個 MVP 依據 3 個「使用者故事」（User Stories）設計，這台測試的小發財讓受測者經歷了一場「使用者旅程」（User journey），根據他的旅程，他可以感受並且提出建議，而團隊可以聽到真正使用者的意見，不是顧問調查後「認為」的意見。
比起顧問公司「認為」它的分析符合需求，敏捷開發的「設計思維」與使用者交互「保證」符合需求更精準。無怪近年業界都說「學管理去 D-School（設計學院），別去 B-School（商學院）」，這種消長，在 AI 時代將更明顯，迭代成本降低、變化速度更快，顧問研究還沒請尾款，報告已過時，還是使用者第一手反饋實際。
為了創造這個旅程，不是車身、引擎、空調… 某個實驗室能推出測試品，而是每次就算是一台破破爛爛的車，使用者要能坐上去駕駛，感受他的使用者旅程，所以每個單位都要往前走一步，而且這一步是有意義的，就是產出足以回答假設的 MVP。
這話是啥意思？
Waterfall 要求到期末做出成品，而不要求每次產出「可測試」（Testable）的 MVP，可想像週會時，動力系統部門說「本週想出可讓動力增加 20% 的創意」，「能測試嗎？」，「不行，要先等 XXX 零件定做完成才能測試。」每個單位都說出無法測試的「虛進度」，那麼這個專案進度要到里程碑或整合測試時才能「醜媳婦見公婆」，不過那時候可能來不及改了。
MVP 的好處，你會議說啥都行，總之交出能看到、能測試的進度就是了！就可以避免虛進度（摸魚）了。
有一個有趣的說法，每次的 MVP 就是個「切片」（Slicing），不是先追 A 的進度，再追 B 的進度，而是 A, B, C 都要每次都有個進度，組合成用戶體驗，就算只是非常「薄」的一點進度，就像蛋糕上切下一片，進度一起吃，才能吃出滋味。
大廚要推出巧克力水果蛋糕，因為水果還沒成熟、巧克力還沒進口、鮮奶油還沒打好，沒關係，我們研發了新的海綿蛋糕，先吃吃看好不好吃！
就算海綿蛋糕好吃，你怎麼知道加巧克力也好吃？你怎麼知道加鮮奶油會不會變很膩？你怎麼知道水果跟巧克力口味搭？也就是說雖然看起來有進度，其實這個進度不代表任何事。
用衝刺 Spring 管理進度
在現在這個情景下，聽說 Spring 是從美式足球借來的用語，那就容易體會。
在 Waterfall 下，各單位分頭搞（說好聽是「分工合作」），「你做完交給我，我做完交給他」的往後傳球，專案計劃就是規範「傳球順序」（早年企管界愛模仿工廠，把「下一球傳給誰」先規定好，濃濃 19 世紀感），如果腦中只有福特 T 型車產線，當然不懂 Spring 是什麼。
但在 Agile 敏捷開發，用「衝刺」就很容易懂了，整個團隊在第一、二週要一起交出 MVP-V1，所以團隊像是一個美式足球隊，不能拆分你的我的，沒有球從誰傳給誰的問題，接下來第三、四週從 MVP V1 衝刺到 MVP V2，第五、六週再修改衝刺到 MVP V3…，用衝刺還滿形象的，美式足球和橄欖球就是這樣每次往對方那裡衝刺幾碼，最後目標就是達陣。
我不懂美式足球，規則裡找不到 spring = 衝刺，但球隊一起沖的團隊精神，與傳統各做各的形成強烈對比
一次衝刺多長可自行決定，這裡每個衝刺 2 週不是規定。
結論
不管是 假設思維、PDCA、敏捷開發、精實創業、摸著石頭過河、黑貓白貓能抓老鼠的就是好貓… 一大堆厲害或很土的詞，都是換個說法在說你國中理化學到的科學方法，有些很靈光的人，就聰明到做事、立志、上班、做專案都用它，可以理性的找到關鍵，做最少的事達到最大的成就，你別想說「我又不做產品開發，MVP 關我啥事？」看起來不但關你的事，而且對你一生都有幫助！
免責聲明：我體會了它的用法，但不保證正確，畢竟這麼多人在用，應該各有各的堅持，總之你也應該改出一套適合你團隊的。