《The Pragmatic Programmer 務實的程式設計師》Podcast 準備稿：專案啟動前
書名： 務實的程式設計師 The Pragmatic Programmer（Your Journey to Mastery, 20th Anniversary Edition） 作者： David Thomas & Andrew Hunt 系列： 啃一本大書（恩普拉氏） 公開標題建議： 啃一本大書｜The Pragmatic Programmer．沒人知道自己要什麼、找到框框、敏捷不是名詞 (10/11) 涵蓋範圍： 第8章 專案啟動前（Topic 45-48：需求坑、解開不可能的謎題、一起工作、敏捷的本質）
背景速覽
從這一章開始，鏡頭從「個人編碼」拉高到「專案層級」。第八章談的是專案最開始那段最容易踩雷的階段：搞清楚要做什麼。作者刻意不用「需求蒐集」這個詞——因為「蒐集」暗示需求像蘋果一樣掛在那裡等你撿，事實是它們深埋在假設、誤解與政治之下，甚至根本還不存在。這集四個 Topic 串成一條線：需求要怎麼「學」而非「撿」、卡死的問題怎麼破、為什麼要「一起工作」、以及在 18 年後重新校準「敏捷」這個被玩壞的詞。
一句話重點
專案啟動前最該認清的真相是——沒有人確切知道自己要什麼（Tip 75），所以程式設計師的核心價值是「幫人們搞清楚他們想要什麼」，靠的是在回饋迴路中學需求、在「真正的約束 vs 先入為主的框框」裡找自由度、在實際編碼時和使用者一起工作；而貫穿這一切的「敏捷」不是一套照做就靈的流程，而是「蒐集回饋、走最小一步、再校正」的做事方式。
值得討論的重點
1. 需求坑：沒人知道自己要什麼，你的工作是幫他們搞清楚
Tip 75「No One Knows Exactly What They Want」、Tip 76「Programmers Help People Understand What They Want」。「需求蒐集」是個誤導的詞——需求很少浮在表面，它們埋在假設、誤解、政治之下，往往根本不存在。在電腦比人貴的年代我們相信「先取得精確規格再開工」，但真實世界是混亂、矛盾、未知的，精確規格極其罕見甚至不可能。所以程式設計師最有價值的能力，是幫人們理解他們到底想要什麼——像治療師一樣探索邊界。書裡「$50 免運費」的例子絕妙：看似一句話，好開發者會追問——含稅嗎？含現有運費嗎？電子書算嗎？國際訂單呢？門檻多久變一次？你的角色是解讀客戶的話、把含義回饋給他們。配套：Tip 77「需求是在回饋迴路中學來的」、Tip 78「和使用者一起工作，才能像使用者一樣思考」、Tip 79「政策是元資料」（別把「$50」這個會變的政策值寫死進邏輯，把它當資料）、Tip 80「使用專案詞彙表」（統一行話）。
2. 解開不可能的謎題：別在框框外思考，去找到框框
Tip 81「Don’t Think Outside the Box—Find the Box」。引高第安繩結的故事——沒人解得開，亞歷山大大帝一劍劈開，「只是對需求做了一點不同的詮釋」。當一個問題看似不可能，秘訣是識別真正的（而非想像的）約束，並在其中找自由度。約束分兩種：絕對約束（必須尊重，無論多不合理）與先入為主的觀念（看似約束其實不是）。「跳出框框思考」其實不準確——如果框框是約束的邊界，訣竅是找到那個框框，它往往比你以為的大得多。實作方法：列出所有可能途徑（再蠢都不要否定），逐一問「為什麼這條不能走？你確定嗎？你能證明嗎？」——特洛伊木馬就是「從正門進攻一定是自殺」這個假約束被打破的經典。還有一招呼應第七章：卡死時去散步、遛狗、睡一覺——意識腦其實很笨，把問題交給底下那個驚人的聯想神經網路，答案常自己跳出來（也可以找人解釋，又是橡皮鴨）。
3. 一起工作：在「實際編碼的當下」協作，而非隔著文件
Tip 82「Don’t Go into the Code Alone」。引言很辛辣：「我沒見過想讀一萬七千頁文件的人，要是有，我會把他從基因池裡除掉。」作者用他們初次相遇的那個「不可能專案」開場——成功的唯一關鍵是那位懂舊系統的專家就坐在開發室對面，隨時答問、做決定、看 demo。「一起工作」真正的意思不是開會、寫備忘錄，而是在你實際編碼的當下一起提問、討論、解決問題。具體形式是結對編程（一人打字、一人思考更高層的議題，旁邊有人看你就不會走捷徑把變數叫 foo，品質更高）與群體編程（mob programming）（十幾個人含使用者、贊助人、測試者一起，由一人打字——帶有即時編碼的緊密協作）。這裡帶出康威定律：系統的設計會反映組織的溝通結構——把使用者納入開發團隊，產出的軟體就會反映這種參與。
4. 敏捷的本質：敏捷是形容詞，不是名詞
Tip 83「Agile Is Not a Noun; Agile Is How You Do Things」。引《公主新娘》：「你一直用那個詞，但我不覺得它是你以為的意思。」作者是敏捷宣言起草人，18 年後回頭看到「另一面」——團隊渴望「盒裝敏捷」：更多管理層、更多正式報告、更花俏的頭銜（其實只是「拿著剪貼板和碼錶的人」）。所以回到基礎，重溫宣言四價值（個人互動 > 流程工具、可運行軟體 > 完整文件、客戶合作 > 合約談判、回應變化 > 遵循計畫——右邊仍有價值，但更重視左邊；任何想加重右邊、削弱左邊的東西都不符合宣言）。關鍵洞見：永遠不會有「敏捷流程」——只要有人說「照做這個你就敏捷了」，他就錯了，因為敏捷就是關於回應變化（奔跑的瞪羚不走直線、體操選手每秒修正數百次）。價值觀不告訴你該做什麼，只告訴你「自己決定時該注意什麼」。最後給了「敏捷的配方」：①弄清你在哪 ②朝目標邁出最小的有意義一步 ③評估到了哪、修好弄壞的——重複，並在每件事的每一層遞迴使用。
注意事項
⚠️ 「沒人知道自己要什麼」別講成貶低使用者或可以無視需求。作者的意思是「需求是學出來的、不是問出來的」——使用者知道他們的問題，但不一定知道解法的細節，把模糊變清晰正是程式設計師的專業價值。態度是合作探索，不是「客戶很笨」。
⚠️ 「敏捷的本質」這節最容易被聽成「所以流程都沒用、Scrum 都是垃圾」。作者反的是把敏捷當成可購買的固定流程（盒裝敏捷、為敏捷而敏捷的儀式），不是反對所有實踐。Scrum/看板等都可以是好工具——只要它們服務於「蒐集回饋、回應變化」這個本質，而非取代思考。把這條界線講清楚，避免聽眾走向虛無主義。
專家補充
💡 「需求是回饋迴路中學來的」這條，是整個敏捷/精實思想對瀑布式的根本反叛。瀑布假設「需求可以前期一次定清楚」，本書（及作者的敏捷背景）主張「需求只能透過做出東西、給人看、再修正來逐步逼近」——這正是第二章曳光彈（EP3）在專案層級的展現。可以串起來講：從曳光彈到迭代估算到回饋迴路學需求，本書整本都在反對「前期完美規劃」這個幻覺。
💡 康威定律（Conway’s Law, 1967）這幾年因微服務而大紅——「想要某種系統架構，先設計出對應的組織結構」（逆康威操縱，inverse Conway maneuver）。本書把它放在「一起工作」這節，角度很巧：把使用者納入團隊溝通圈，產出的軟體就會反映使用者的真實需求。組織的溝通結構不只影響架構，也影響「軟體有沒有解對問題」。
💡 「找到框框」而非「跳出框框」是個比流行口號更深刻的重構。創意不是憑空天馬行空，而是精確地辨識「哪些約束是真的、哪些是我自己腦補的」。這與第五章「設計可替換的 code」、第四章「別算命」一脈——務實程式設計師的創意，建立在誠實面對真實約束之上。亞歷山大劈繩結，不是無視規則，是看穿「必須用解的方式」這條根本不存在的假規則。
討論問題
🎙️ 開場鉤子：「客戶跟你說『我要一個 $50 免運費的功能』。聽起來夠清楚了吧？這集要告訴你：這句話底下藏著至少五個沒人回答過的問題——而幫客戶把這些問題挖出來、想清楚，正是程式設計師最值錢的能力。」
🎙️ 自問自答：「一個看起來『不可能』的問題，到底卡在哪？」——多半不是卡在問題本身，是卡在你腦中一條根本不存在的約束。把所有路徑列出來，逐一逼問『為什麼這條不能走、你能證明嗎』，你常會發現那個框框比你以為的大得多。亞歷山大沒有解開繩結，他發現『一定要用解的』這條規則是假的。
🎙️ 帶走的一題：「下次有人問你『我們算不算敏捷？』，別回答『是』或『不是』。問回去：我們有沒有在持續蒐集回饋、走最小的一步、然後根據結果調整？如果有，你就敏捷；如果只是在開站會跑儀式，那只是穿了敏捷的衣服。」
更大範圍關聯
- 與敏捷宣言：作者是 17 位起草人之二，本章（尤其敏捷的本質）是對「敏捷被產業玩壞」的第一手校正，極具權威性。接《Clean Agile》(Uncle Bob 也是起草人，本系列 Reading Uncle Bob 可互文——兩位宣言作者隔著二十年各自回來澄清「敏捷到底是什麼」)。
- 回扣曳光彈與回饋：「需求在回饋迴路中學」是第二章曳光彈（EP3）、第四章「別算命」（EP5）在專案層級的延伸——本書整本反對「前期完美規劃」。
- 康威定律脈絡：接微服務時代的「逆康威操縱」、《Team Topologies》(Skelton & Pais)、《Accelerate》。組織結構 = 系統結構。
- 問題解決思想：「找到框框」接 George Pólya《How to Solve It》、設計思考（design thinking）的「重新框定問題」；「卡住時去散步」接孵化效應（incubation effect）與第七章蜥蜴腦（EP8）。
錄製建議
- 建議時長：約 24-26 分鐘。配比：需求坑約 8 分（$50 免運費的追問是主菜、最實戰）、不可能的謎題約 6 分（高第安繩結、特洛伊木馬好講）、一起工作約 5 分（結對/群體 ＋ 康威定律）、敏捷的本質約 6 分（作為宣言起草人的權威校正，很有份量）。
- 討論策略：用「在不確定中前進」這條主線——需求、難題、協作、敏捷，四者都在回答「專案最開始那團迷霧怎麼穿過去」。需求坑用具體追問演示最有共鳴。敏捷那節善用作者的「宣言起草人」身份，講「我們當年想說的，被你們玩成了什麼樣」，份量十足。
- 結尾預告最後一集 EP11「務實的專案」——當專案真的跑起來，從需求迷霧進到團隊、自動化、測試、文件與使用者層級的議題，替整季收尾。