從一個失敗的專案，看懂真正的 MVP 與「擁抱不完美」
在軟體開發這個行業，「敏捷（Agile）」早已是深入人心的顯學。但在我的實務經驗中，很多企業往往只學到了敏捷的「形式」，卻沒有掌握它的「核心」。
對於剛從傳統瀑布式開發（Waterfall）轉型到敏捷的團隊來說，最大的認知衝擊，往往來自於對 「最小可行性產品（MVP, Minimum Viable Product）」 的理解。
MVP 的真諦，是「只開發剛好滿足需求、能達到業務目標的軟體」。但問題來了：什麼叫「剛好」？每個人心中的那把尺，往往天差地遠：
Product Owner (PO)： 希望用最短的時間，生出一個「能用」的軟體去測試市場。
系統架構師： 擔心現在只做部分功能，未來擴充會很吃力，所以拼命想把「未來可能發生」的問題先釐清。
工程師： 在架構師把圖畫好之前無事可做，導致一個 Sprint（迭代）的前半段都在空轉等待。
QA 測試人員： 系統總是在迭代的最後一兩天才交付測試，根本不可能測完，品質大打折扣。
對於剛接觸敏捷的團隊來說，要在「需求、方案與時間」之間拿捏平衡，真的非常困難。我過去帶領的團隊，就曾因為抓不到平衡點，浪費了大量的時間。
正是那次慘痛的教訓，讓我真正明白：MVP，其實是一個讓團隊學會接受「不完美」的過程。 今天，我想分享這個失敗的經歷，希望能幫正在敏捷路上掙扎的團隊，少走一點彎路。
當高度不確定性遇上新手團隊
為了讓大家更有畫面，先簡單介紹一下當時的專案背景。
這是一個從零開始的自研產品專案，目標是開發一款讓大眾線上購物的 APP，同時需要一個管理後台供業務端看數據。因為是自研產品，我們必須緊貼市場與用戶喜好，隨時調整功能。
過去，我們團隊習慣做「外包專案」，也就是開工前就已經有明確的範疇。但這次不同，專案初期充滿高度不確定性，連要賣什麼（實體商品、門票還是課程？）都還沒完全定案。為了不讓專案停滯，我提議導入敏捷開發。
當時最大的挑戰是：團隊幾乎沒有敏捷經驗，只有一位經驗不太豐富的敏捷教練。我天真地以為，敏捷跟傳統開發應該差不多，只是「提早把部分功能做出來」而已。
我們就在這樣的背景下，展開了這場充滿血淚的開發之旅。
被「過度思考」綁架的團隊
在過去傳統的開發模式裡，團隊在寫下第一行程式碼之前，必須走完一套嚴謹的流程，以確保客戶滿意且減少後續修改：
系統概念圖： 讓客戶了解系統運作原理。
系統故事板（Storyboard）： 結合業務場景，畫出完整的操作流程。
UI 介面設計： 產出最終的視覺效果。
系統架構設計： 根據上述內容，設計底層架構。
也就是說，在過去的習慣裡，工程師拿到規格時，系統邏輯、介面佈局、資料欄位早就已經「完美確定」了。
當我們開始跑敏捷時，團隊不自覺地沿用了過去的習慣。大家在投入開發前，依然拼命想找出「確定的東西」，只是確認的對象從「客戶」變成了「PO」。
因為大家都害怕修改，「過度思考」成了團隊的常態。MVP 不再是「最小可行」，而是變成了一個試圖囊括所有極端情況的「功能大禮包」。
一個優惠券功能的災難
為了讓大家體會當時有多誇張，我舉一個真實的 User Story（使用者故事）為例：
「作為顧客，我在購物結帳前可選擇使用優惠券，以降低需支付的金額。」
要滿足這個需求，MVP 應該長什麼樣子？
團隊一開始想得很簡單：在已經做好的支付頁面上，加一個選擇優惠券的按鈕就好。但緊接著，災難開始了。團隊開始無止盡地發散：
「如果客戶付款後取消訂單，優惠券要退還嗎？」
「如果只取消訂單裡的『部分商品』，優惠券怎麼退？」
「優惠券是無條件使用嗎？已經打折的商品還能再用優惠券折抵嗎？」
為了解決這些「未來可能發生的場景」，團隊在概念圖、故事板和架構設計之間來回橫跳。結果是：整個迭代的時間都快過完了，我們開了無數的會，卻沒有寫出半行程式碼。
這就是工程師的慣性——在動手之前，想把所有可能性都抓出來。即使那些極端場景，根本已經偏離了這個 User Story 最核心的目標（讓用戶結帳時能扣減金額）。
學會擁抱不完美，先求有再求好
為什麼團隊會這麼執著於確定性？說穿了，就是「怕被罵」。過去做固定成本的專案，如果因為沒想清楚而導致後期大量重工，那對專案來說是致命的。
但敏捷的戰場不一樣。為了解救嚴重落後的進度，我強勢介入，重塑了團隊的開發思維，我稱之為「擁抱不完美」。
簡單來說：只針對當下的需求，做最強相關的事。其他延伸出來的邊界情況，全部交由未來的 User Story 來補充。
以優惠券為例，我們這次「只做」選擇優惠券並扣減金額。至於取消訂單退券、歷史紀錄查詢等功能，雖然跟優惠券有關，但跟「結帳扣減」的核心目標無關，這次一律不做！
同時，我們大刀闊斧地修改了流程：
廢除繁瑣的故事板： 改為在會議中快速畫出概念圖。
PO 點頭就開工： 只要 PO 同意核心概念，立刻進入架構設計與開發。
把細節留給審查會議（Sprint Review）： 如果有遺漏的場景，在迭代末期的會議上確認。由 PO 來決定是要排進下一個迭代補齊，還是根本不重要、先放著不管。
「把東西做完美」的執念，是拖垮團隊的魔咒。我們必須把思維切換成：「先把核心做出來，然後不斷地迭代修改。」 這個觀念的扭轉，花了我九牛二虎之力，但絕對值得。
市場的真實回饋，勝過會議室裡的完美推演
追求完美，是每個對產品有要求的人的本能。但過度追求完美，卻會讓我們停滯不前。
過去，我們團隊總想一次性考慮所有功能、一次性把事情做到極致。但現實是殘酷的：即使你在會議室裡考慮得再多，也難敵產品上線後市場的真實變化。你設想的「完美方案」，用戶可能根本不需要。
當然，先把東西做出來絕對不是鼓勵大家寫爛 Code 或交付充滿 Bug 的半成品。
敏捷開發妥協的從來不是品質，而是範圍。
下次當你的團隊又陷入無止盡的細節討論時，不妨停下來問問團隊，我們現在設計的這些擴充功能，是達到目標必須的嗎？沒有的話目標是否就不能達成？
放下對完美架構的執念吧！記住，MVP 的重點不在於產品有多小，而在於我們能多快驗證商業價值。先讓產品活下來，我們才有機會讓它變得更好。
喜欢我的作品吗？别忘了给予支持与赞赏，让我知道在创作的路上有你陪伴，一起延续这份热忱！
- 来自作者
- 相关推荐