如果你也被瀑布式 Waterfall 專案管理制約，或被 Scrum 的名詞搞得霧煞煞，本文是我企圖內化的筆記，讓我們一起研究 MVP 觀念。
我從傳統瀑布式（Waterfall）入門專案管理，認識了敏捷開發（Agile）後很驚豔，但大企業老闆們多只看懂瀑布式，沒機會實施，直到最近用 AI 輔助學習開發 web app，決定實作 Agile 專案管理。
開發一個月後發現，雖然我用敏捷管理工具，但卻是 Waterfall mindsets！要擁抱 Agile，要先「吃透」！我的困擾是 MVP (minimum viable product，最簡可行產品)，與很多人不知道要在企劃中塞什麼內容相反，長年產品設計及產品經理，我能想出大量功能細節，但想這麼多要如何「最簡」？為了學會「簡」，我花了心力理解，希望能真正掌握，本文就是從我的筆記轉寫。
「吃透」：上完課覺得「知道了但不太懂」？常自學的我把「吃透」定義為這套知識在我心裡是「One Piece」，怎麼說？學習開始時會學到很多片段，每個都不簡單，不知如何連在一起，如果學透才知道：A 是 B 的上一層、C + D 會產生了 E、E 可以被放入 A 之中…，當每個片段都能好好收納 = one piece，才會覺得「我懂了」。
本文目錄
為何要把 Waterfall 換成 Agile？比較一下
Agile 是新的專案管理，與傳統 Waterfall 相對。
傳統 WATERFALL 專案管理，上級最愛，但不實用
如果要開發一台新車，傳統 Waterfall 會這樣拆分專案：
- 底盤系統次專案
- 動力系統次專案
- 傳動系統次專案
- 操控系統次專案
- 電力系統次專案
- 車身系統次專案
很合理，每個系統都是一個專業，分工各自開發再組合起來就是了！問題是：
- 你確定各自開發可以組合起來嗎？經驗中，各自開發後組合，要花更多時間整合測試，就算規格寫得清清楚楚，分開的團隊就是會做出裝不上去的產品，一次就好真的是天方夜譚！
- 為團隊間溝通，設定階段（phases）、里程碑（milestones）？複雜專案如果久久一次開大會溝通，頻率不足，容易出錯，甚至是吵架大會。
- 就算能組合起來，沒人知道是否能符合（需求者）想要的：可能他當初沒想清楚、你聽需求時誤會了、他看到產出改變主意了，也可能一切都沒錯，但開發完市場空缺已經被填補了。
傳統 waterfall 的毛病就是自以為是上帝，它假設團隊有經驗、能用功能切專案而且不重疊、預知可能的風險和變化、人人 100% 對規劃言聽計從、開會就能搞懂別的團隊做了半年的成果…，它在還沒開工就鉅細靡遺地從期初規劃到期末（美國登月就是這樣規劃的），人力、成本、資源… 都算得清清楚楚，也難怪非常受到自以為是上帝的老闆和政府單位的喜愛，上帝喜歡全然掌控，不喜歡意外，而你，身為上帝的子民、夠格的專案團隊，你就應該預知一切，連意外的預算都預先留好。
留好意外的預算就表示知道會出什麼意外，預先知道了怎麼會讓意外發生呢？
事實是，除非每天早上要吃早餐這種任務，只發生一次的專案必有意外，就是無法預知才叫意外啊！為了未卜先知，人類發明了各種算命技術，但都是破財後才說：「啊！大仙很早就跟我說今年會破財！」，足以說明人類非常不擅長預估，結果， waterfall 專案管理最大的功能是給上級過目，你真照做就辛苦了。
傳統 waterfall 的象徵就是 MS-Project 繪製的甘特圖，讓人看起來很放心，事情會像機械鐘一樣順序完成，不過，如果我們得像機械鐘一片齒輪一樣工作，我會覺得很煩心，既然人人都有自主意識，這口機械大鐘必然沒有銅造的那麼準。
腳踏實地 實用的 Agile 敏捷專案管理
因為 waterfall 不切實際且不實用，Agile 就出現了，它非常腳踏實地。
同樣要開發一台汽車，它的拆分是：
- 產出滑板車
- 產出三輪車
- 產出小型賽車
- 產出四輪汽車
- 產出有裝修的四輪汽車
好啦有點怪，這是示意圖，要表達的是專案不該分部門、分功能，而是從「使用者的旅程」（User journey）來分。
動力部門開發出 8 缸引擎，很棒，但其他部件都還在各自實驗室還沒完成，使用者無法測試，就有極大可能出錯，例如小車裝上 8 缸引擎反而開起來很危險。
你看，Agile 的宗旨跟不喜歡變化的 Waterfall 相反，它先做最簡版 ➡︎ 測試 ➡︎ 修正原計劃，這樣一輪一輪用不停溝通來解決人類很爛的預測能力，只需要知錯能改，可以把易經、紫薇、星座… 這些算命書全收起來了，我們再也不用未卜先知，因為明知道這些都不管用（在劉伯溫無法復生的前提下）。
在 Agile 常見的工具是「Kanban」，常用的有 Trello，其實因為原理簡單，類似軟體好多，例如 Notion 的 Kanban 更完善，但它太複雜很難做為團隊協作工具。
前面的拆分用幾個原則：
- Smallest：每一輪產出都只驗證最簡假設
- Testable：每一輪都可以測試
- PDCA：測試後都能獲得反饋（使用者覺得做對了嗎？），再依照反饋來調整專案
這些原則我很早就知道了，不過還是不小心用功能或技術拆分子任務，這就是 MVP 的困難，它觀念簡單，實行不簡單，這些術語無法用來檢查計劃是否做對了，例如，多簡單叫 Smallest？
MVP 來自實驗設計
Agile 敏捷專案管理與一堆其他的書籍來自同一套哲學：「假設思維」、「精實創業」、「敏捷開發」、「Scrum」、「PDCA」… 甚至中國改革開放常用的句子「小步快跑前進」、「黑貓白貓能抓老鼠的就是好貓」用在不同地方就換個名字，外套脫下來裡面是同一個人！
拿前面產出一臺新車案例來說，首先要發現一個「痛點」（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 及一切
我想出了 20 個功能，MVP 要拿掉哪些、放上哪些？重點是「是否能回答假設」？不論證實或證僞，都是一種答案。
如果一次得不到答案怎麼辦？依照反饋修改迭代，再出第二代，這就是 PDCA 方法，那 PDCA 要迭代到什麼程度停止呢？重點是「是否能回答假設」？
有了這個原則就清楚了，這就像實驗一樣，「簡單」不是「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 週不是規定。
結論
敏捷開發的專案管理是跟傳統瀑布式不同的思維，把目光焦點從開發團隊轉向使用者，用不停的交互測試一步一步往前進，希望達到最符合用戶需求的產品，可惜只在新創團隊風行，大企業上級只看懂上帝視角的甘特圖。
雖說是一種好方法，但它很美式，很多詞語很難體會它要表達的是什麼，但是想出使用情景且與傳統比較，腦中的印象就鮮明了，這些零散的名詞一瞬間成為整體觀念，這是我的筆記，也希望對你有幫助。
免責聲明：我體會了它的用法，但不保證正確，畢竟這麼多人在用，應該各有各的堅持，總之你也應該改出一套適合你團隊的。