不管是做一個軟體、寫一份報告、還是推一個新產品，當你面對的是一件沒有人做過、沒有 SOP 可以參考、連你自己都不確定最後會長什麼樣的事情，你會怎麼開始？
大部分人的直覺是：先把所有細節想清楚、規劃到鉅細靡遺，然後一次做出精美的成品。
但敏捷開發圈有一套心法，告訴你這樣做其實很危險。
敏捷開發不是一個單一的方法，它背後是一整套應對不確定性的思維。
在核心的「演進式設計」（Evolutionary Design）之外，還有來自精實創業、極限編程、軟體工程、專案管理、甚至顧問業的實戰心法。
這些心法彼此精神相通、常常一起用。
這篇文章會介紹其中 6 個最核心的心法：
- Walking Skeleton——會走路的骨架
- Wizard of Oz MVP——人工頂著就好
- YAGNI——你不會用到它的
- 過早封裝的代價——做瘦也要做對
- 系統會定義使用者的流程——不要替他決定他還沒想清楚的事
- 付費關係決定骨架粗細——商業現實的考量
它們放在一起，就是面對不確定性任務時的思維工具箱。
從最經典的一個開始講起：Walking Skeleton（會走路的骨架）。
用廚師研發新菜理解演進式設計
先從一個每個人都能理解的例子開始。
假設你是一位廚師，老闆要你研發一道全新的菜——不是改良既有料理，而是要創造一個從來沒人做過的味道組合。
你會怎麼做？
你不會一開始就開一桌十人份的宴席、把最貴的食材全部下鍋、擺盤也一次到位。
你會先用最少量的食材，在小鍋子裡快速做出一個「味道的雛型」。
這個雛型可能粗糙到不行——酸度不平衡、層次不夠、擺起來也不好看，但它已經是一道從頭吃到尾都完整的菜：有主味、有配角、有大致的口感輪廓。
然後你試味道、調整、再試一次、再調整——慢慢演進成最終那道可以上桌的料理。
這就是演進式設計在做的事情：先做一個很原始、但是能實際運作的版本，再慢慢加細節。
Walking Skeleton：能跑得動、但沒有細節的起始版本
演進式思維裡最容易理解的心法，叫做 Walking Skeleton——會走路的骨架。
這個概念由敏捷大師 Alistair Cockburn 提出，專門處理一種特定的不確定性：系統的各個部分組起來之後，真的能運作嗎？
在還沒把整條路徑跑通之前，這個問題永遠是懸著的。Walking Skeleton 的答案是——別等，先讓最瘦的版本從頭到尾跑一次，把那個懸念立刻解決掉。
用軟體開發的例子來看：
- 不是先把資料庫做到完美、再把後端做完、再把前端做完
- 而是做一個「從頭到尾都能跑」的最原始版本：使用者可以在前端按一個按鈕，資料可以送到後端，後端可以存到資料庫，最後可以顯示結果
這個版本可能很醜、功能很少、效能很差，但它不是只做了前端的半成品、也不是只做了後端的半成品。
使用者從按下按鈕、資料送出、處理、到看到結果，整條路徑每個環節都有東西、都串得起來——雖然每個環節都只是最簡陋的版本。
這才是演進式設計的起點。
演進式思維的三個共同好處：暴露風險、拿回饋、少做白工
Walking Skeleton 只是第一個例子。
所有演進式心法——包括後面的 Wizard of Oz MVP、YAGNI——都是為了換來這三件事。
你可能會想：為什麼不直接做完整的功能就好了？先做個半成品有什麼意義？
因為半成品能幫你做到三件事。
盡早暴露系統整合的風險（好處一）
軟體開發最怕的不是「這個功能很難寫」，而是「各個部分接起來才發現對不上」。
舉個例子：前端工程師以為後端會回傳 JSON，後端工程師以為前端要的是 XML；或是資料庫的欄位型別跟後端的資料模型對不上。
這些整合問題，只有當系統真的端到端跑一遍時才會跑出來。
當你先做一個「從頭到尾都能跑」的版本，這些問題會在第一週就爆出來，你還有很多時間修。
但如果你每個模組各自悶頭做兩個月，最後才要接起來，這時候才發現問題——你不只要修，還要回去改前面已經做好的東西，成本會高很多。
盡早拿到使用者的真實回饋（好處二）
很多時候我們以為自己懂使用者要什麼，但真的做出來之後才發現想錯了。
有了可以動的版本，你就可以給使用者看、給主管看、給團隊看。
他們的回饋會很具體——「這個按鈕我找不到」「我以為按下去會跳出確認畫面」「我其實不需要這個功能，我要的是另一個」。
這些回饋你在規劃階段用討論的、用文件的、用 mockup（視覺設計稿，看得到但不能真的操作）的，都問不出來。
因為人只有真的動手用過，才知道自己要的是什麼。
沒有可以動的版本，所有討論都只是在紙上談兵。
降低長期做白工的風險（好處三）
這是最血淋淋的一點。
如果你花三個月做一個功能完整的版本，結果最後發現使用者根本不需要，或是產品方向轉了、市場變了，那三個月就徹底浪費了。
但如果你先做一個兩週的原始版本讓使用者看，發現方向不對就趕快轉向，你損失的只有兩週。
這個差距，在新創或是需求不確定的專案裡，常常就是活下去和倒閉的差距。
Wizard of Oz MVP：有些功能讓人工處理一輩子就好
介紹完 Walking Skeleton，接著看另一個很不一樣的心法：Wizard of Oz MVP，有時候也叫 Concierge MVP。
它出自精實創業（Lean Startup）派，由 Eric Ries 等人推廣。
名字的典故來自《綠野仙蹤》——故事裡那個看似全能的「偉大巫師」，其實是一個躲在布幕後面操控機關的普通人。
它處理的是跟 Walking Skeleton 不同的不確定性：使用者真的會用這個功能嗎？值得我花三個月把它做出來嗎？
在沒有真實使用者驗證之前，這個問題也是懸著的——而且這個不確定性比技術問題更致命，因為你可能花半年做出來之後才發現根本沒人要。
Wizard of Oz 的答案是：連程式都先別寫。用人工假裝系統在運作，讓真實使用者用看看——等到確定有人買單再決定要不要自動化。
自動化不是免費的
工程師的直覺常常是「能自動化就自動化」。但這個直覺忽略了自動化的真實成本：
- 開發成本：寫程式、測試、上線的時間
- 維護成本：未來每一次需求變動，自動化的那塊都要跟著改
- 隱藏成本：自動化等於把流程寫死，使用者被迫照系統的假設走
當這些成本加起來比「人工處理」還高時，人工反而是正解。
先假裝系統存在，驗證完再自動化
Wizard of Oz MVP 最早的用法是：先用人工假裝系統在運作，驗證使用者買不買單，買單了再花錢做自動化。
最經典的例子是 Zappos——現在那家全球知名的線上鞋店，2009 年被 Amazon 用超過 12 億美金買下。
Zappos 創辦人 Nick Swinmurn 在 1999 年想賣鞋上網，但那個年代沒人相信「買鞋不試穿」會有市場。
他沒有去借錢囤一堆庫存、建後台倉儲系統。
他做的是：
- 到附近的實體鞋店，用數位相機拍鞋子的照片
- 把照片放到他自己做的簡陋網站上，標好價格開賣
- 有人下單時，他才去那家店把鞋子買下來、打包寄給客人
使用者體驗：完整的購物流程。
後台：一個老闆跑來跑去。
這個「假裝有一家鞋店」的 MVP 讓他幾乎零成本就驗證了「人真的願意上網買鞋」這件事。
驗證成功後，他才開始建真正的庫存和電商系統。
人工頂著頂著，就再也不需要自動化了
但實務上還有一個更常見的狀況：你一開始打算「驗證完就自動化」，結果用了一年人工還好好的，那就一直人工下去。
舉一個情境：一個團隊做的 SaaS 產品，每週要寄一份「本週使用摘要」給每個客戶。
工程師的第一直覺是：「這不就是資料查詢 + 模板套用 + 寄信排程嗎？寫個自動化服務吧。」
但如果這時候客戶只有 20 個，客製需求還很亂（A 客戶要看 X 指標、B 客戶要看 Y 指標），直接讓行銷或營運同事每週花兩小時手動寄 20 封信，反而最划算：
- 開發成本：0
- 維護成本：0
- 好處：每次手動寄信的過程，你都在觀察「客戶到底在意什麼」，這些觀察會變成未來真正做自動化時的需求規格
這些信可能要手動寄一年、甚至兩年。
但等到客戶變 500 個、需求也穩定下來的那天，你做出來的自動化系統會比現在直覺寫出來的版本貼合業務十倍。
很多經營得很健康的 SaaS 公司，內部都有這種「撐了三五年還在手動」的流程——不是因為他們不會寫程式，是因為算過就知道不用寫。
什麼時候該用 Wizard of Oz 而不是自動化？
當你遇到這幾個情況，優先考慮 Wizard of Oz 而不是立刻自動化：
- 這個功能使用頻率很低（一年用不到幾次）
- 流程還沒穩定，你不確定以後會長怎樣
- 驗證使用者需求比建構系統重要
- 人工處理的成本 < 開發 + 維護自動化的成本
YAGNI 與「知道什麼不該做」：演進式設計最難的一課
前面兩個心法都在強調「少做一點」——不管是做瘦的架構，還是根本不做自動化。
但「少做」這件事，實務上比想像中難。
演進式設計聽起來很簡單，但實務上最難的地方是：你要懂得不做什麼。
當你要打造一個很複雜的最終產品時，要刻意地把它砍到最原始的本質，只留下核心的部分。
這違反很多工程師的直覺。
我們被訓練成「把事情做好」的人，看到一個問題會自動想到所有應該處理的 edge case（極端或邊緣情況，通常不常發生但可能出錯）、所有應該支援的情境、所有應該預先架好的擴充點。
「既然要做，就要做好做滿」的念頭會很自動地冒出來。
但演進式設計要你反過來想：很多東西現在不做，不是因為做不到，是因為現在做沒意義。
為什麼沒意義？因為你對未來到底會用到什麼是不確定的。
今天覺得「一定會需要」的功能，半年後可能完全派不上用場——可能是需求變了、可能是你當初想錯了、可能是產品轉向了。對於這種不確定性，最便宜的做法不是先寫好備著，而是根本不寫。
你要把功能分成三類：
- 哪些東西是「絕對必要」的？→ 先做
- 哪些東西是「很重要但可以晚點做」的？→ 後面再說
- 哪些東西是「看起來重要但其實可以不做」的？→ 直接砍掉
用一個具體的例子來看：假設你要做一個線上購物網站。
絕對必要：使用者要能看到商品、放進購物車、結帳付款——少了任何一步，這就不叫購物網站。
可以晚點做：商品搜尋、商品推薦、願望清單、會員等級。這些很有用，但沒有它們，購物流程還是走得通。
可能根本不用做：你原本以為使用者需要的「AI 智慧推薦」「個人化首頁」「社群分享功能」。先上線看看，說不定使用者根本不在意，那就省下大把時間。
你要對自己很誠實地問：「如果只能留一樣東西，那會是什麼？」
YAGNI：極限編程用來擋不必要程式碼的原則
其實前面講的這個想法，在軟體工程界有一個正式的名字：YAGNI。
它出自極限編程（Extreme Programming，簡稱 XP），由 Ron Jeffries 提出。
YAGNI 是 You Aren’t Gonna Need It 的縮寫，意思是「你不會用到它的」。
它在演進式思維裡扮演的角色：貫穿整套思維的紀律。
演進式思維要你「少做一點」，但什麼叫「一點」？YAGNI 給你一個每次動手前都可以問自己的具體問題——「這個東西是現在真的要做，還是我只是預期以後會用到？」
如果是後者，就不要寫。
Ron Jeffries 講得很直白：永遠只在真正需要某個功能的時候才去實作它，而不是在你預期將來會用到的時候。
YAGNI 在實務上長什麼樣子
舉一個產品開發常見的情境：
PM 請你做一個「使用者個人資料」頁面，需求很單純——只要填姓名和 Email。
你開始規劃的時候，腦袋冒出這些念頭：
- 「既然表單都做了，順便加上生日、電話、地址吧，以後做會員系統一定會用到。」
- 「那乾脆也加上『興趣偏好』『訂閱電子報意願』，做精準行銷一定需要。」
- 「表單提交後要不要順便做一個『歡迎信』自動寄送？反正以後也要做。」
YAGNI 告訴你：停。
PM 請你做的只是「姓名 + Email」。
其他那些都是你「預期」會用到的，不是「現在」需要的。
根據經驗，那些「以防萬一」先做出來的功能，下場通常只有兩種：
- 沒人用。使用者填完姓名 Email 就按送出，那些額外欄位要嘛空白、要嘛被填假資料
- 需求變了。半年後產品轉型，個人資料頁整個砍掉重做，那些欄位一天都沒用到
兩種結果都一樣——你付出的時間，換到的是零。
最不會出問題的程式碼，是你沒寫的那一行
YAGNI 有一句很經典的話可以用來記住它的精神：
「最不會出問題的程式碼，就是你沒寫出來的那一行。」
沒寫的程式碼不會有 bug、不需要測試、不佔空間、不會讓別人讀不懂、也不會在需求變動時變成負擔。
YAGNI 最常派上用場的場景其實是會議上。
當團隊在討論功能設計時，常常會有人提議：「我們是不是應該順便加上 XXX，以後可能會用到。」
這時候你可以直接說：「YAGNI。我們現在不需要這個，等真的要用再加。」
這一個詞可以很有效地把不必要的需求擋在門外。
這個問題之所以難，是因為砍東西會痛。
每一個功能背後都是你花時間想過、有感情的東西。
砍掉它感覺像在承認「這個其實不重要」，但演進式設計告訴你：不是不重要，是「現在」不重要。
先把最核心的那一樣做出來，讓它可以運作。
當它跑起來、拿到回饋之後，你會更清楚下一個該加的是什麼——而且那個答案，常常跟你一開始想的不一樣。
過早封裝會綁死架構：少做才能保留彈性
「少做一點」不只是為了省時間——它也是為了保留面對未知的彈性。
因為你永遠不知道未來系統會怎麼變。今天寫得很整合、很緊密的結構，明天可能就要為了一個新需求被拆掉。
那些「為了以後好加功能」預先設計的結構，十次有九次會被未來的真實需求打臉。
這個心法背後其實結合了兩個軟體工程的經典原則：
- 關注點分離（Separation of Concerns）：不同職責的程式碼要放在不同地方
- 過早抽象化（Premature Abstraction）：不要在還不知道未來長怎樣之前，先蓋一堆「預留」的結構
這兩個都不是來自敏捷或精實派，而是更底層的工程智慧。
它在演進式思維裡扮演的角色：提醒你「做瘦」不等於「草率」。
演進式思維要你先做最瘦的版本、之後再慢慢加。但這個「加」要能加得動，關鍵在於：你一開始做瘦版本時，別把不該黏在一起的東西黏死。
檔案上傳寫死 vs 模組化：兩種做法的差別
假設你在做一個系統，其中有一個「檔案上傳」功能。
綁死的做法：把上傳邏輯直接寫在介面裡
把上傳邏輯直接寫在使用者介面裡——按鈕的 onClick 事件裡，就寫著怎麼連到伺服器、怎麼切片、怎麼處理失敗。
寫起來很快，看起來很整合。
但未來如果要換成雲端儲存（例如從自己的伺服器換成 S3）、或是想在另一個介面也用同一個上傳功能，你會發現——上傳邏輯跟介面黏死了，要拆出來比重寫還痛苦。
保留彈性的做法：把上傳獨立成可抽換的模組
把「檔案上傳」變成一個獨立模組，透過 API 注入到介面裡。介面只負責「觸發上傳」，上傳本身的實作在另一個地方。
一開始麻煩一點，要多寫一個介面、多定義幾個參數。
但未來想換、想重用、想測試，都輕鬆得多。
但這邊要澄清一個容易誤會的點：演進式設計不等於草率。
「先做原始版本」不是叫你隨便寫、反正之後會改。
而是叫你只做必要的事，但這些必要的事要做對——特別是模組之間的界線。
因為界線畫錯了，之後要「再改」會比你想像中困難得多。
系統會定義使用者的流程：少做才不會鎖死他
第二個好處跟技術架構無關，而是跟人有關。
這裡處理的不確定性跑到另一個維度：你根本不知道使用者最後會怎麼工作。甚至使用者自己可能也還在摸索。
前面的心法都在講技術層面——架構怎麼做、程式要寫不寫、界線怎麼畫。這個觀念提醒你：當使用者自己的流程都還在變動時，你做出來的系統會反過來把那個還沒成形的流程提前鎖死，讓他想調整都調不了。
系統 = 流程的固化
寫程式的人常常忘記一件事：你寫的系統，就是在替使用者決定他要怎麼工作。
你把「簽核流程」設計成三關？他就得走三關。
你把「表單必填欄位」設計成八個？他就得填八個。
你把「操作順序」鎖死成 A→B→C？他就不能先做 B 再回頭做 A。
系統就是流程的固化——這是個雙面刃。
當使用者的流程還沒穩定時，做太多就是在鎖死他
如果客戶的業務流程已經行之有年、非常穩定，把它做進系統沒問題，甚至是該做。
但如果客戶自己都還在摸索業務模式，你做太完整的系統，等於強迫他按你當下對他業務的假設走。
他原本可能有十種做事的方式，你做完系統之後，他只剩下一種——而且那種還不一定是最好的。
舉一個具體例子：
你幫一個還在早期的新創團隊做「內部管理系統」。
他們的簽核流程其實都還沒定下來——有時候兩關、有時候三關、看案子大小決定。
他們自己都還在摸索怎麼做最順。
這時候你如果把系統做死（固定三關簽核、固定哪些欄位必填），他們為了配合系統，得把原本彈性的流程硬塞進你的框架。
一個月後他們發現其實兩關就夠了，但系統做死了，改起來又是一筆成本。
更好的做法：先做一個簡單的表單收集資訊，簽核這步用 Email 或 Slack 處理。等他們跑了幾個月、流程真的穩定下來，再把那個穩定版本做進系統。
系統的完整度，應該跟流程的穩定度成正比
- 流程還在摸索 → 系統做瘦一點，留空間給人自己決定
- 流程已經穩定 → 系統可以做完整，固化流程反而能提效率
Walking Skeleton 不只是技術策略，也是尊重使用者主導權的策略。
付費關係決定你的骨架要多瘦
前面講的所有心法，都還停在「技術哲學」的層次。
但真實工作現場還有一個誰都繞不開的變數：錢。
這裡處理的是最現實的一種不確定性——這個案子到底值得我做多細？投入到什麼程度才划算？
因為你事先不會知道客戶到底願意付多少、案子會不會做完、後續會不會有維護費用。同樣一個系統，在不同付費關係下該做的深度完全不同。
這個心法不是理論，是顧問業和接案工作者的實戰常識。
骨架要多瘦，看你拿多少錢
同樣一個 Walking Skeleton，在不同案子裡該瘦到什麼程度，答案完全不同：
- 免費案子 / 內部幫忙：骨架能多瘦就多瘦，能用人工補就用人工補
- 低價案子：做到堪用就好，別給自己太多麻煩
- 高價案子：骨架可以粗一點、做得完整一點，對得起客戶付的錢
這不是市儈，是專業——知道什麼時候該省力氣，比一股腦做滿更重要。
兩邊都有代價時，選自己成本低的那個
顧問業有一個不會寫在合約裡、但每個有經驗的人都心裡有數的判斷原則：
「讓客戶自己處理行政流程會增加他的負擔，但把所有流程都做進系統，會逼他改變工作習慣——兩邊都有代價的時候，選你自己工作量比較少的那個。」
這聽起來好像有點功利，但背後的邏輯很實在。
當你過度投入、做出一套「看起來很完整、但客戶其實用起來也卡卡的」系統，結果往往是：
- 你做到筋疲力盡
- 客戶還是不滿意，因為系統不完全符合他的工作習慣
- 專案預算超支、口碑也沒建立起來
做太多反而雙輸。
付費客戶 vs 免費專案：同樣是報名系統的兩種規格
同樣是「做一個報名系統」：
付費客戶（收 30 萬）：一條龍自動化
報名 + 審核 + 繳費 + 通知 + 報表，每一步都做進系統。
免費的內部專案：做到堪用就好
做到「報名 + 自動發 Email 通知」就好，其他的用現有流程湊：
- 審核？讓承辦人直接用 Email 手動回覆
- 繳費？用現有的財務流程處理
- 報表？直接匯出 CSV 給他自己在 Excel 開
兩個都叫「報名系統」，但骨架的粗細完全不同。
這不是偷懶——免費案子做成 30 萬的規格，你累、案主也不一定感謝。
免費案子做到堪用，反而是對雙方都健康的選擇。
技術決策和商業判斷，其實在問同一個問題
如果你仔細想會發現：「付費關係決定骨架粗細」跟整套演進式思維的精神其實是一致的。
演進式思維一直在問一個問題：「以現有的條件，我能做出的最瘦版本是什麼？」
只是在不同層面，「條件」是不同的東西：
- 技術層面，條件是資源和時間
- 商業層面，條件是案子的報酬和重要性
條件不同、答案不同，但思考方式完全一樣——都是在定義一個合理的骨架。
演進式設計的四個步驟
到這邊為止，我們介紹完了 6 個核心心法。
但光知道心法還不夠，實務上你需要一個可以照著跑的流程。
接下來這四個步驟，是把前面所有心法整合起來用的操作指南。
找出最核心的本質（第一步）
從最終產品裡抽出最關鍵的那個骨架——沒有它，這個產品就不成立。
判斷的方法是問：「如果把這個拿掉，這個產品還是這個產品嗎？」
以購物網站為例，把「推薦系統」拿掉，它還是一個購物網站；但把「結帳付款」拿掉，它就變成一個展示網頁了。
所以結帳付款是核心、推薦系統不是。
這一步的常見錯誤，是把「重要」跟「核心」搞混。
很多功能很重要，但不是核心——它們可以之後再加。
優先處理風險最高的部分（第二步）
在做原始版本的時候，優先把風險最高、最不確定的部分做出來。
這裡的「風險」有兩種：
- 技術風險：你沒把握能不能做出來的部分。例如要串第三方 API、要處理即時影音、要跑機器學習模型。
- 產品風險：你不確定使用者會不會買單的部分。例如一個新的互動方式、一個新的收費模式。
很多工程師喜歡先做「有把握」的部分，因為寫起來順、有成就感。
但這是反直覺的陷阱——有把握的部分留到最後也不會壞事，沒把握的才該先做。
如果風險最高的那塊做不出來，你前面做的所有東西都會白費。
讓它真的能跑起來（第三步）
讓這個原始版本可以實際運作、可以被使用、可以被看到。
關鍵字是「真的能動」。
不是 mockup、不是設計稿、不是文件、不是 PPT、不是簡報——這些都只是在描述產品，不是產品本身。
你要的是一個使用者真的可以打開、真的可以點一點、真的會產生結果的東西。
就算它醜、就算它慢、就算只支援一種最簡單的情境，都沒關係。
重點是它會動。
收回饋、決定下一步、再跑一次（第四步）
把它拿去給人用、給人看，收回饋。
收回饋前，先搞清楚收的是誰的回饋
但這邊要補充一個實務上很重要的觀念：收回饋的時候，你要先搞清楚是在收誰的回饋。
這個觀念來自專案管理（Project Management）和產品管理（Product Management）領域，英文叫 Stakeholder Analysis（利害關係人分析）。
它在演進式思維裡扮演的角色：執行「收回饋」這一步時的實務技巧。
演進式思維的核心循環之一就是「收回饋、再迭代」。但實際收回饋時你會發現，不同人給的回饋常常不一致、甚至互相矛盾——這時候需要一個方法知道該聽誰的。
一個專案通常會有三種人，他們的回饋常常不一致、甚至互相矛盾：
- 使用者：實際操作系統的人（例如員工、終端消費者）
- 需求方：提出要做這個的人（例如你的窗口、部門主管、客戶的 PM）
- 決策者：能改變使用者行為、決定案子繼不繼續的人（例如更高層主管）
舉個具體例子：你幫一間公司做員工請假系統。
- 使用者（員工）說：希望流程越簡單越好，一鍵送出就好
- 需求方（HR 承辦）說：希望有完整的審核歷程和報表，方便她做事
- 決策者（人資長）說：希望跟考勤系統整合、產出合規報告
這三個人要的東西完全不一樣，你聽誰的？
短期聽需求方的——HR 是你每天對口的人，她如果覺得難用，案子就卡住。
長期要合決策者的胃口——人資長決定案子繼不繼續、預算給不給。
使用者的回饋要聽，但要知道使用者沒有預算決策權，他們的「希望簡單」不能蓋過合規需求。
搞清楚誰是誰，才知道哪些回饋該立刻採納、哪些該記下來但不馬上動、哪些可以禮貌性聽聽就好。
回饋能告訴你的三件事
回饋（來自各方）會告訴你三件事：
- 哪裡是對的，可以繼續加強
- 哪裡是錯的，需要修正或砍掉
- 哪裡是你沒想到的，可能是下一個要做的功能
根據回饋決定下一步要加什麼、改什麼、砍什麼。
然後再跑一次這個循環。
這裡最重要的心態是：演進式設計不是「做一次就結束」，是一個持續的循環。
每跑一圈，你對產品的理解就會更深一點，做出來的東西也會更貼近使用者真正想要的。
這 6 個心法不只能用在軟體開發
這套思維雖然從敏捷軟體開發長出來，但核心邏輯適用於任何「沒人做過、不確定性高」的工作。
下面示範這 6 個心法怎麼搬到非軟體場景：
Walking Skeleton 用在報告撰寫：先寫一頁骨架版
最常見的錯誤是埋頭苦寫兩週，寫到七、八成才拿給主管看，結果主管說「方向不對」——整份要重寫。
演進式做法是：先花半天寫一份一頁的骨架版，只有大綱和主要結論，拿給主管看。
如果方向錯了，你只損失半天，不是兩週。
方向對了，再一層一層加細節、加圖表、加附錄。
這就是把 Walking Skeleton 搬到寫作——先做一個端到端走得通的精簡版，再慢慢長肉。
Wizard of Oz MVP 用在辦活動：前幾場全部人工處理
假設你想經營一個「每月讀書會」社群。
你可能會想「要做一個報名網站、自動化通知、自動發提醒信、整合行事曆」。
但 Wizard of Oz MVP 的思路是：前幾場先全部手動做。
報名？用 Google Form。通知？自己用 Gmail 群發。提醒？用日曆手動設提醒並逐一傳訊息。
跑個幾場之後你會發現：可能根本沒有那麼多人來，做系統完全不划算；或是你發現真正耗時的是「找講者」，而不是報名流程，一開始想做的自動化都不是重點。
YAGNI 用在簡報製作：先不做「以後可能會用到」的投影片
很多人做簡報時會加一堆「備案投影片」——「這張講到 Q&A 可能會用到」「這張以防有人問細節」「這張加了好看但不一定放」。
YAGNI 說：停，現在不需要就不要做。
先把核心敘事的投影片做完。真的被問到細節？口頭講就好，或臨時打開資料回答。
那些「以防萬一」的投影片 99% 的場合都用不上，而且會讓整份簡報變得臃腫，自己找東西也找不到。
過早封裝用在寫書：章節結構別太早綁死
很多第一次寫書的人會先花一個月把整本書的目錄、每章節、每節的小標全部列完，才開始動筆。
結果寫到第三章發現：原本規劃的架構不對，真正有趣的點藏在另一個方向。但目錄已經綁死，所有章節都要重寫。
演進式做法是：先只規劃前三章，寫完之後根據寫作過程中的發現，再決定後面怎麼走。
這就是「別把不該黏在一起的東西黏死」搬到寫作——書的架構要能隨著你對主題理解的加深而調整。
系統定義流程用在訂 SOP：流程還沒穩定前別寫成手冊
團隊擴張時常見的陷阱：新主管一上任就寫一份厚厚的 SOP，把所有流程固化下來。
但如果團隊業務還在摸索、流程每週都在變，SOP 寫得越完整、越會鎖死大家的動作——每個人為了不違反 SOP，把原本彈性的做法硬塞進規定的框架。
更好的做法是：先讓團隊跑幾個月，觀察哪些動作真的穩定了，再把那些穩定的部分寫進 SOP。還在摸索的部分，先留空白、用判斷力處理。
這跟「系統完整度要跟流程穩定度成正比」是同一個邏輯——不只是系統，任何「把流程固化下來」的動作都一樣。
付費關係用在接案：不同案子該投入的深度不同
接案工作者都懂一件事：同樣做一個網站，付 30 萬的客戶和幫朋友免費做的，該投入的深度完全不同。
付費客戶：設計、開發、測試、上線、後續維護，一條龍。
朋友免費：Wordpress 套版改一改能用就好，不用寫客製功能、不用做 SEO 優化、不用設監控。
這不是偷工減料，是對兩邊都負責——免費案子做到 30 萬的規格，你累、朋友也不見得感謝。
其他還有很多領域可以套用這套思維：
- 研發新菜色：就像開頭的廚師例子——不用一次擺十人份的宴席，先用小鍋子做一份味道的雛型
- 學新技能：不要把所有教材讀完才動手，讀完最基礎的一點就開始做，邊做邊補
- 職涯規劃：不要訂「10 年大計畫」再開始，先給自己 3 個月試某個方向，用結果決定下一步
只要你在做的事有不確定性、一次做到完美的風險太高，這 6 個心法都幫得上忙。
敏捷開發 6 個核心心法：完整心法地圖
這篇介紹了演進式思維底下的 6 個核心心法，每個都來自不同的源頭，但解決的都是同一個問題：面對不確定性時，該怎麼開始？
6 個心法快速回顧
另外還有一個實務補充——收回饋時要分清楚使用者、需求方、決策者，知道該聽誰的。
把這些心法整合起來用的流程
找出核心本質 → 優先處理風險 → 讓它跑起來 → 收回饋、持續演進
下次當你又想「先把整個東西規劃到完美再開始」的時候，停一下，問自己：
我真正該先做出來的最瘦版本，是什麼？
然後從那個答案開始。