<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Books on Tarragon</title><link>https://tarrragon.github.io/blog/tags/books/</link><description>Recent content in Books on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Thu, 20 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/books/index.xml" rel="self" type="application/rss+xml"/><item><title>依資本責任選書</title><link>https://tarrragon.github.io/blog/books/finance/positions/</link><pubDate>Thu, 20 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/finance/positions/</guid><description>&lt;p>位置由&lt;strong>對什麼資本負責&lt;/strong>界定。同一本談資產配置的書，給一個現金流剛好打平的人讀，跟給一個替父母管理退休金的人讀，兩個人讀出來的重點完全不同——前者需要的是先把緩衝建起來，後者需要的是把決定的依據對別人說明白，而書裡談的比例與回撤兩邊都用得上、用法卻不一樣。&lt;/p>
&lt;p>資產規模與年齡都不當作軸。規模只說明現在有多少，說明不了這筆錢一旦虧損誰的生活會改變；年齡在收入形態差異大的時候更不可靠。責任這個軸的代價是它要自我診斷，所以下一段給的是可以直接對照的判準。&lt;/p>
&lt;p>書的完整描述都在四個主題篇，這裡多數段落只說哪一格對應哪一篇、以及為什麼。唯一的例外是最後一節，那一節寫的是第三格要多做的準備——那件事在四個主題篇裡沒有主場，理由寫在該節末尾。&lt;/p>
&lt;h2 id="四個位置">四個位置&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>位置&lt;/th>
 &lt;th>對什麼負責&lt;/th>
 &lt;th>最常見的失敗&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="#%e5%8f%aa%e6%9c%89%e8%96%aa%e8%b3%87%e7%8f%be%e9%87%91%e6%b5%81">只有薪資現金流&lt;/a>&lt;/td>
 &lt;td>下個月的支付能力&lt;/td>
 &lt;td>把緩衝投出去換一點報酬&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="#%e6%9c%89%e5%8f%af%e6%8a%95%e8%b3%87%e7%9a%84%e9%a4%98%e8%a3%95">有可投資的餘裕&lt;/a>&lt;/td>
 &lt;td>一個要走幾十年的計畫&lt;/td>
 &lt;td>全部時間花在挑標的，比例從來沒有決定過&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="#%e5%b0%8d%e4%bb%96%e4%ba%ba%e7%9a%84%e8%b3%87%e7%94%a2%e8%b2%a0%e8%b2%ac">對他人的資產負責&lt;/a>&lt;/td>
 &lt;td>別人的計畫，而承受度是別人的&lt;/td>
 &lt;td>用自己的風險承受度替對方決定&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="#%e5%b0%8d%e4%b8%80%e9%96%80%e7%94%9f%e6%84%8f%e7%9a%84%e6%90%8d%e7%9b%8a%e8%b2%a0%e8%b2%ac">對一門生意的損益負責&lt;/a>&lt;/td>
 &lt;td>員工與供應商收得到的現金&lt;/td>
 &lt;td>生意的現金流與自己的混在一起&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h3 id="只有薪資現金流">只有薪資現金流&lt;/h3>
&lt;p>這個位置的主要問題是緩衝：一次失業、一次醫療事件、或一台機車報銷，會不會逼出高利負債。收入本身可能不低，判斷的依據是扣掉固定支出之後剩下多少、以及那個餘額中斷幾個月會發生什麼。&lt;/p>
&lt;p>從 &lt;a href="../personal-finance/">個人理財與風險保障&lt;/a> 開始，先走支出端的換算與排序，把「哪一項的失敗最快到達」排出來。這一格暫時不必讀資產配置——那些內容預設有一筆可以長期不動的錢，在這裡是為不存在的問題做設計。&lt;/p>
&lt;p>最常見的失敗有一個具體形狀：緊急預備放著不動看起來是浪費，於是被投進市場換一點報酬，而需要動用它的那一次通常跟市場下跌同時發生——失業潮與資產價格下跌由同一組原因驅動。這一格的正確動作是先把緩衝建到自己算出來的深度，之後才進下一格。&lt;/p>
&lt;p>往下一格移動前預習的是 &lt;a href="../investing/">資本配置與投資&lt;/a> 的開頭那一段：配置與選擇的分界。第一筆有餘裕的錢最容易直接跳進選擇——挑一檔看起來會漲的標的——而比例的決定影響長期結果更多。&lt;/p>
&lt;h3 id="有可投資的餘裕">有可投資的餘裕&lt;/h3>
&lt;p>這個位置對一個要走幾十年的計畫負責，而計畫的成敗由兩個決定支配：資產之間的比例，以及在下跌期間持不持得住。&lt;/p>
&lt;p>主場是 &lt;a href="../investing/">資本配置與投資&lt;/a>：起點書建立配置與選擇的座標，長期報酬的實際分佈那一條讓人知道歷史數字本來長什麼樣，估值紀律那一條處理逐檔判斷時的規則。四本的順序與各自承擔什麼寫在該篇。&lt;/p>
&lt;p>同時要回頭確認 &lt;a href="../personal-finance/">個人理財與風險保障&lt;/a> 的排序跑過一次。配置的第一個輸入是「這筆錢多久不會被動用」，而那個數字由緊急預備與負債決定，不由市場決定。&lt;/p>
&lt;p>環境在改變什麼由 &lt;a href="../macroeconomics/">總體經濟&lt;/a> 承接，讀的時機在配置決定之後而非之前——先有比例，才有「這輪利率變動會怎麼影響這個比例」這個問題。&lt;/p>
&lt;p>要往「對他人的資產負責」移動的人，預習 &lt;a href="../accounting/">會計與財報&lt;/a>。替別人做決定的時候，判斷要能被對方追問，而追問到最後多半落在一家公司或一檔工具的數字上。&lt;/p>
&lt;h3 id="對他人的資產負責">對他人的資產負責&lt;/h3>
&lt;p>家庭共同的財務、代管長輩的退休金、替不熟悉市場的家人做決定——這個位置的差別在承受度屬於別人。同一段跌幅，自己承受得了不表示對方承受得了，而對方通常在下跌發生之後才第一次知道自己承受不了。&lt;/p>
&lt;p>先走 &lt;a href="../investing/">資本配置與投資&lt;/a> 的配置那一半，並且把選擇那一半的優先序往後放：逐檔判斷需要的時間投入在替別人管理時更難成立，而解釋成本更高。&lt;/p>
&lt;p>有一件事要在讀書之前處理：替家人管理資產牽涉授權是否有效——代為操作的權限從哪裡來、對方失去判斷能力之後那個權限還在不在、以及事後由誰認定。這一層由法律制度界定，這條線的四項描述判不了，做法是先確認授權關係，再回來談配置。&lt;/p>
&lt;p>&lt;strong>這一格的書單覆蓋最薄&lt;/strong>，缺的是溝通與紀錄那一層：怎麼把配置的依據講給不熟悉市場的人聽、決定與當時的理由要留下什麼、以及事後對照時該拿什麼出來。這一層在這條線沒有書可以指，而兩半的缺法不同——溝通那一半有書、住在管理線；紀錄那一半在這裡直接寫成規格。兩者各自的處置寫在 &lt;a href="#%e5%95%8f%e5%87%ba%e5%b0%8d%e6%96%b9%e7%9a%84%e6%a2%9d%e4%bb%b6%e4%b8%a6%e7%95%99%e4%b8%8b%e6%b1%ba%e5%ae%9a%e7%9a%84%e4%be%9d%e6%93%9a">問出對方的條件並留下決定的依據&lt;/a> 那一節。&lt;/p>
&lt;h3 id="對一門生意的損益負責">對一門生意的損益負責&lt;/h3>
&lt;p>這個位置對員工與供應商收得到的現金負責，而它跟前三格的差別在資金的來源與去處都不只一個人。判斷的單位從「這筆錢的報酬」換成「這門生意產生現金的能力」。&lt;/p>
&lt;p>主場是 &lt;a href="../accounting/">會計與財報&lt;/a>，先建立讀表的能力，再走 &lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/" data-link-title="企業財務分析與投資評估" data-link-desc="從損益表識讀到產業供應鏈分析的系統性商業評估方法——涵蓋報表判讀、公司定位、產業基準、估值方法、外部衝擊判讀，以及真實上市公司的批判性案例分析">企業財務分析與投資評估&lt;/a> 把能力用在自己的數字上——那個模組從一張實際的損益表出發，路線與工具在它的入口頁。到站之後有一層換算要自己做：那一篇的三本都以公開發行公司的報表為材料，附註、分部資訊與關係人交易揭露在自家帳上不存在，能對得上的是三表之間的關係與各科目的意義。&lt;/p>
&lt;p>&lt;a href="../macroeconomics/">總體經濟&lt;/a> 在這一格的用途比前三格具體：成本衝擊與利率變動先到達的是營運資金與應付利息，而判斷這一輪的壓力屬於一次性還是結構性，決定了要調價、吸收、還是換供應鏈。&lt;/p>
&lt;p>個人的財務同時仍在跑，所以這一格經常與前兩格重疊。重疊時的處理寫在下一段。&lt;/p>
&lt;h2 id="判準與它失準的地方">判準與它失準的地方&lt;/h2>
&lt;p>判準是&lt;strong>這筆錢虧掉的時候，誰的生活會改變&lt;/strong>：&lt;/p>
&lt;ul>
&lt;li>只有自己的下個月會變 → &lt;a href="#%e5%8f%aa%e6%9c%89%e8%96%aa%e8%b3%87%e7%8f%be%e9%87%91%e6%b5%81">只有薪資現金流&lt;/a>&lt;/li>
&lt;li>自己的長期計畫會變、而下個月不會 → &lt;a href="#%e6%9c%89%e5%8f%af%e6%8a%95%e8%b3%87%e7%9a%84%e9%a4%98%e8%a3%95">有可投資的餘裕&lt;/a>&lt;/li>
&lt;li>別人的計畫會變 → &lt;a href="#%e5%b0%8d%e4%bb%96%e4%ba%ba%e7%9a%84%e8%b3%87%e7%94%a2%e8%b2%a0%e8%b2%ac">對他人的資產負責&lt;/a>&lt;/li>
&lt;li>員工與供應商收不到錢 → &lt;a href="#%e5%b0%8d%e4%b8%80%e9%96%80%e7%94%9f%e6%84%8f%e7%9a%84%e6%90%8d%e7%9b%8a%e8%b2%a0%e8%b2%ac">對一門生意的損益負責&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>有四種處境會讓這個判準失準，各有各的處理方式。&lt;/p>
&lt;p>&lt;strong>收入本身不穩定&lt;/strong>（接案、業務獎金、以股權或分紅為主的報酬）時，「有沒有餘裕」在月與月之間翻轉，照當月判會在兩格之間來回。判的依據取一年裡的低點而非平均——餘裕的定義是中斷幾個月之後仍然存在的那一部分。&lt;/p>
&lt;p>&lt;strong>家庭共同財務&lt;/strong>裡決定權與責任經常分離：出錢的人與做決定的人不是同一位，或決定由一位做而後果由全家承擔。這種情況兩格同時成立，取責任那一格——書要解決的是後果落在誰身上的那個問題。&lt;/p>
&lt;p>&lt;strong>資產登記在別人名下或由家人代管&lt;/strong>時，名義與實質不一致。照實質判：實際承擔漲跌的人在哪一格，就讀哪一格；同時這種安排本身把「對他人的資產負責」那一格的溝通與紀錄問題帶進來，而那一格目前有缺口。&lt;/p>
&lt;p>&lt;strong>資產以自住房為主&lt;/strong>時，帳面淨值可能不小，而它不可分割、也不產生現金流。這一格照現金流判而非照淨值判，多數這種處境落在第一格，主要動作在負債與緩衝而不在配置。&lt;/p>
&lt;p>四種之外還有一種常見的重疊：同時對一門生意負責、也有個人的可投資餘裕。兩格都成立時照急迫度挑一篇開始，而混同本身是這一格最常見的失敗——兩邊的現金流分開記帳，是後續任何判斷的前提。&lt;/p>
&lt;p>判準本身之外另有一條時間邊界，判在哪一格都成立：距離動用那筆錢只剩幾年時，四個主題篇裡只有 &lt;a href="../personal-finance/">個人理財與風險保障&lt;/a> 的起點書有一節談提領，其餘各本預設的累積期都還長，長到短期波動可以被時間吸收——而接近動用的時候那個前提正好消失。&lt;/p>
&lt;h2 id="這幾格不涵蓋誰">這幾格不涵蓋誰&lt;/h2>
&lt;p>責任來源不同的幾種處境套進這四格會失真。&lt;strong>已經進入提領期的退休者&lt;/strong>面對的主要問題是提領順序與長壽風險，那跟累積期的排序是不同的問題，這條線目前沒有承接。&lt;strong>繼承、贈與與遺產安排&lt;/strong>的主體是制度而非配置，落在這條線明說不承接的制度性那一層。&lt;strong>受託為客戶管理資產的專業從業者&lt;/strong>的義務由法規界定，適合度、揭露與利益衝突各有法定要求，而這套四項描述判不了法遵。&lt;/p>
&lt;h2 id="問出對方的條件並留下決定的依據">問出對方的條件並留下決定的依據&lt;/h2>
&lt;p>替別人做決定時，這條線的四項描述有一項換了主體。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a> 問的是一本書預設的環境在讀它的那個人那裡存不存在，而第三格要問的是那個環境在&lt;strong>被決定的那個人&lt;/strong>那裡存不存在：資本形態、現金流的鬆緊與支出結構、那筆錢什麼時候會被動用，全部要換成對方的。讀者手上通常只有其中幾項——知道對方有多少存款，不知道每個月的固定支出佔多少；知道年齡，不知道對方遇到一次三成的下跌會做什麼。所以這一格比其他三格多兩件事要做：把缺的那幾項問出來，以及把問到的答案跟後續的決定一起留下來。&lt;/p>
&lt;p>&lt;strong>承受度問不出來的原因多半不是對方不肯講。&lt;/strong>「你能接受虧多少」對沒有經歷過下跌的人是一個抽象的百分比，答案會落在一個當下講得出口、而下跌發生的那一次又不作數的數字上。換成已經發生過的事、或換成具體的後果就答得出來：「前一次市場下跌的那幾個月，你當時想做什麼」「這筆錢少掉三分之一的話，原本要拿它做的哪一件事會取消」。&lt;/p>
&lt;p>這一層的技巧有主場：管理線的 &lt;a href="../../software-management/topics/influence-conversation/">困難對話與無權限影響力&lt;/a>。它的起點書把一場對話拆成同時進行的三層（事實、感受、身分），而家庭財務對話卡住的位置經常在第三層——同意調整配置等於承認自己原本的判斷不夠好。同一篇的《Humble Inquiry》處理的正是「問了，而拿回來的是自己想聽的那個版本」。移植成本要逐本看而不是整篇看：起點書的案例本來就涵蓋家庭與法律協商，直接可用；《The Secrets of Consulting》預設的是顧問對客戶的收費關係，退出方式與事後的問責形態都跟家庭不同，那一本要自己重估。&lt;/p>
&lt;p>&lt;strong>留下什麼，由事後會被問的問題反推。&lt;/strong> 這一格事後被問的問題有特定形態：當初為什麼這樣決定、我同意過嗎。報酬數字不必自己記，帳戶對帳單上就有。而且提問的人不一定是當初談的那一位——可能是其他家屬，或對方判斷能力改變之後接手的代理人。反推出來的內容因此是當時的目標與期限、對方用自己的話說出來的承受度、被否決的選項與否決的理由，以及什麼情況下要重新談。&lt;/p>
&lt;p>承受度那一項保留原話而不要換算成百分比。原話帶著對方當時對照的那件具體的事（「不能影響到孫子的學費」），而百分比在事後的爭議裡是一個誰都可以重新解釋的數字。&lt;/p>
&lt;p>清單上最後那一項是變更權：什麼情況下、由誰決定要不要改。缺這一項的時候，市場下跌那一次的對話會從「要不要調整」變成「當初是誰決定的」，而那是兩個完全不同的對話。&lt;/p>
&lt;p>&lt;strong>這兩件事在書單裡沒有條目，而這是判斷過的結果。&lt;/strong> 溝通那一半的書在管理線，同一組書在兩條線各寫一次說明，維護時只會改到其中一份。紀錄那一半在這裡直接寫成規格，理由是它短到寫得完，而 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 明說書單只放外部書籍與選讀判斷。&lt;/p>
&lt;p>這不表示沒有書處理紀錄那一半。以決策日誌與事後檢討為主題的書確實存在，本書單未評估的是它們的&lt;strong>角色歸屬&lt;/strong>——那類書該落在這條線，還是落在管理線的 &lt;a href="../../software-management/topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a>，因為它們處理的是同一組偏誤，而不是同一種資本。角色歸屬判定之前，在這條線開第五個主題篇會做出一個內容全部指向別條線的空頁，所以這一格目前的處置是這一節。&lt;/p>
&lt;h2 id="這幾格跟主題篇的分工">這幾格跟主題篇的分工&lt;/h2>
&lt;p>主題篇按問題組織，回答「這個問題該讀什麼」；這一篇按人組織，回答「我現在該讀什麼」。同一本書會出現在多格的建議裡，用法不同——&lt;a href="../personal-finance/">個人理財與風險保障&lt;/a> 的起點書給第一格的是排序的算式，給第四格的是把個人現金流從生意裡分出來的理由。&lt;/p>
&lt;p>書的性質判定（&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>、時效狀態、&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>、讀得出價值的前提）一律在主題篇，這裡不重複，避免同一本書的多份說明各自漂移。這一篇寫的是「哪種處境對應哪一篇、在這裡怎麼用」。&lt;/p>
&lt;p>管理線的同類頁面是 &lt;a href="../../software-management/roles/">依位置選書&lt;/a>，那裡的軸是對誰的產出負責。兩條線的位置互相獨立——技術負責人與只有薪資現金流可以同時成立，因為那兩個軸問的是不同的責任。&lt;/p></description><content:encoded><![CDATA[<p>位置由<strong>對什麼資本負責</strong>界定。同一本談資產配置的書，給一個現金流剛好打平的人讀，跟給一個替父母管理退休金的人讀，兩個人讀出來的重點完全不同——前者需要的是先把緩衝建起來，後者需要的是把決定的依據對別人說明白，而書裡談的比例與回撤兩邊都用得上、用法卻不一樣。</p>
<p>資產規模與年齡都不當作軸。規模只說明現在有多少，說明不了這筆錢一旦虧損誰的生活會改變；年齡在收入形態差異大的時候更不可靠。責任這個軸的代價是它要自我診斷，所以下一段給的是可以直接對照的判準。</p>
<p>書的完整描述都在四個主題篇，這裡多數段落只說哪一格對應哪一篇、以及為什麼。唯一的例外是最後一節，那一節寫的是第三格要多做的準備——那件事在四個主題篇裡沒有主場，理由寫在該節末尾。</p>
<h2 id="四個位置">四個位置</h2>
<table>
  <thead>
      <tr>
          <th>位置</th>
          <th>對什麼負責</th>
          <th>最常見的失敗</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="#%e5%8f%aa%e6%9c%89%e8%96%aa%e8%b3%87%e7%8f%be%e9%87%91%e6%b5%81">只有薪資現金流</a></td>
          <td>下個月的支付能力</td>
          <td>把緩衝投出去換一點報酬</td>
      </tr>
      <tr>
          <td><a href="#%e6%9c%89%e5%8f%af%e6%8a%95%e8%b3%87%e7%9a%84%e9%a4%98%e8%a3%95">有可投資的餘裕</a></td>
          <td>一個要走幾十年的計畫</td>
          <td>全部時間花在挑標的，比例從來沒有決定過</td>
      </tr>
      <tr>
          <td><a href="#%e5%b0%8d%e4%bb%96%e4%ba%ba%e7%9a%84%e8%b3%87%e7%94%a2%e8%b2%a0%e8%b2%ac">對他人的資產負責</a></td>
          <td>別人的計畫，而承受度是別人的</td>
          <td>用自己的風險承受度替對方決定</td>
      </tr>
      <tr>
          <td><a href="#%e5%b0%8d%e4%b8%80%e9%96%80%e7%94%9f%e6%84%8f%e7%9a%84%e6%90%8d%e7%9b%8a%e8%b2%a0%e8%b2%ac">對一門生意的損益負責</a></td>
          <td>員工與供應商收得到的現金</td>
          <td>生意的現金流與自己的混在一起</td>
      </tr>
  </tbody>
</table>
<h3 id="只有薪資現金流">只有薪資現金流</h3>
<p>這個位置的主要問題是緩衝：一次失業、一次醫療事件、或一台機車報銷，會不會逼出高利負債。收入本身可能不低，判斷的依據是扣掉固定支出之後剩下多少、以及那個餘額中斷幾個月會發生什麼。</p>
<p>從 <a href="../personal-finance/">個人理財與風險保障</a> 開始，先走支出端的換算與排序，把「哪一項的失敗最快到達」排出來。這一格暫時不必讀資產配置——那些內容預設有一筆可以長期不動的錢，在這裡是為不存在的問題做設計。</p>
<p>最常見的失敗有一個具體形狀：緊急預備放著不動看起來是浪費，於是被投進市場換一點報酬，而需要動用它的那一次通常跟市場下跌同時發生——失業潮與資產價格下跌由同一組原因驅動。這一格的正確動作是先把緩衝建到自己算出來的深度，之後才進下一格。</p>
<p>往下一格移動前預習的是 <a href="../investing/">資本配置與投資</a> 的開頭那一段：配置與選擇的分界。第一筆有餘裕的錢最容易直接跳進選擇——挑一檔看起來會漲的標的——而比例的決定影響長期結果更多。</p>
<h3 id="有可投資的餘裕">有可投資的餘裕</h3>
<p>這個位置對一個要走幾十年的計畫負責，而計畫的成敗由兩個決定支配：資產之間的比例，以及在下跌期間持不持得住。</p>
<p>主場是 <a href="../investing/">資本配置與投資</a>：起點書建立配置與選擇的座標，長期報酬的實際分佈那一條讓人知道歷史數字本來長什麼樣，估值紀律那一條處理逐檔判斷時的規則。四本的順序與各自承擔什麼寫在該篇。</p>
<p>同時要回頭確認 <a href="../personal-finance/">個人理財與風險保障</a> 的排序跑過一次。配置的第一個輸入是「這筆錢多久不會被動用」，而那個數字由緊急預備與負債決定，不由市場決定。</p>
<p>環境在改變什麼由 <a href="../macroeconomics/">總體經濟</a> 承接，讀的時機在配置決定之後而非之前——先有比例，才有「這輪利率變動會怎麼影響這個比例」這個問題。</p>
<p>要往「對他人的資產負責」移動的人，預習 <a href="../accounting/">會計與財報</a>。替別人做決定的時候，判斷要能被對方追問，而追問到最後多半落在一家公司或一檔工具的數字上。</p>
<h3 id="對他人的資產負責">對他人的資產負責</h3>
<p>家庭共同的財務、代管長輩的退休金、替不熟悉市場的家人做決定——這個位置的差別在承受度屬於別人。同一段跌幅，自己承受得了不表示對方承受得了，而對方通常在下跌發生之後才第一次知道自己承受不了。</p>
<p>先走 <a href="../investing/">資本配置與投資</a> 的配置那一半，並且把選擇那一半的優先序往後放：逐檔判斷需要的時間投入在替別人管理時更難成立，而解釋成本更高。</p>
<p>有一件事要在讀書之前處理：替家人管理資產牽涉授權是否有效——代為操作的權限從哪裡來、對方失去判斷能力之後那個權限還在不在、以及事後由誰認定。這一層由法律制度界定，這條線的四項描述判不了，做法是先確認授權關係，再回來談配置。</p>
<p><strong>這一格的書單覆蓋最薄</strong>，缺的是溝通與紀錄那一層：怎麼把配置的依據講給不熟悉市場的人聽、決定與當時的理由要留下什麼、以及事後對照時該拿什麼出來。這一層在這條線沒有書可以指，而兩半的缺法不同——溝通那一半有書、住在管理線；紀錄那一半在這裡直接寫成規格。兩者各自的處置寫在 <a href="#%e5%95%8f%e5%87%ba%e5%b0%8d%e6%96%b9%e7%9a%84%e6%a2%9d%e4%bb%b6%e4%b8%a6%e7%95%99%e4%b8%8b%e6%b1%ba%e5%ae%9a%e7%9a%84%e4%be%9d%e6%93%9a">問出對方的條件並留下決定的依據</a> 那一節。</p>
<h3 id="對一門生意的損益負責">對一門生意的損益負責</h3>
<p>這個位置對員工與供應商收得到的現金負責，而它跟前三格的差別在資金的來源與去處都不只一個人。判斷的單位從「這筆錢的報酬」換成「這門生意產生現金的能力」。</p>
<p>主場是 <a href="../accounting/">會計與財報</a>，先建立讀表的能力，再走 <a href="/blog/business/financial-analysis/" data-link-title="企業財務分析與投資評估" data-link-desc="從損益表識讀到產業供應鏈分析的系統性商業評估方法——涵蓋報表判讀、公司定位、產業基準、估值方法、外部衝擊判讀，以及真實上市公司的批判性案例分析">企業財務分析與投資評估</a> 把能力用在自己的數字上——那個模組從一張實際的損益表出發，路線與工具在它的入口頁。到站之後有一層換算要自己做：那一篇的三本都以公開發行公司的報表為材料，附註、分部資訊與關係人交易揭露在自家帳上不存在，能對得上的是三表之間的關係與各科目的意義。</p>
<p><a href="../macroeconomics/">總體經濟</a> 在這一格的用途比前三格具體：成本衝擊與利率變動先到達的是營運資金與應付利息，而判斷這一輪的壓力屬於一次性還是結構性，決定了要調價、吸收、還是換供應鏈。</p>
<p>個人的財務同時仍在跑，所以這一格經常與前兩格重疊。重疊時的處理寫在下一段。</p>
<h2 id="判準與它失準的地方">判準與它失準的地方</h2>
<p>判準是<strong>這筆錢虧掉的時候，誰的生活會改變</strong>：</p>
<ul>
<li>只有自己的下個月會變 → <a href="#%e5%8f%aa%e6%9c%89%e8%96%aa%e8%b3%87%e7%8f%be%e9%87%91%e6%b5%81">只有薪資現金流</a></li>
<li>自己的長期計畫會變、而下個月不會 → <a href="#%e6%9c%89%e5%8f%af%e6%8a%95%e8%b3%87%e7%9a%84%e9%a4%98%e8%a3%95">有可投資的餘裕</a></li>
<li>別人的計畫會變 → <a href="#%e5%b0%8d%e4%bb%96%e4%ba%ba%e7%9a%84%e8%b3%87%e7%94%a2%e8%b2%a0%e8%b2%ac">對他人的資產負責</a></li>
<li>員工與供應商收不到錢 → <a href="#%e5%b0%8d%e4%b8%80%e9%96%80%e7%94%9f%e6%84%8f%e7%9a%84%e6%90%8d%e7%9b%8a%e8%b2%a0%e8%b2%ac">對一門生意的損益負責</a></li>
</ul>
<p>有四種處境會讓這個判準失準，各有各的處理方式。</p>
<p><strong>收入本身不穩定</strong>（接案、業務獎金、以股權或分紅為主的報酬）時，「有沒有餘裕」在月與月之間翻轉，照當月判會在兩格之間來回。判的依據取一年裡的低點而非平均——餘裕的定義是中斷幾個月之後仍然存在的那一部分。</p>
<p><strong>家庭共同財務</strong>裡決定權與責任經常分離：出錢的人與做決定的人不是同一位，或決定由一位做而後果由全家承擔。這種情況兩格同時成立，取責任那一格——書要解決的是後果落在誰身上的那個問題。</p>
<p><strong>資產登記在別人名下或由家人代管</strong>時，名義與實質不一致。照實質判：實際承擔漲跌的人在哪一格，就讀哪一格；同時這種安排本身把「對他人的資產負責」那一格的溝通與紀錄問題帶進來，而那一格目前有缺口。</p>
<p><strong>資產以自住房為主</strong>時，帳面淨值可能不小，而它不可分割、也不產生現金流。這一格照現金流判而非照淨值判，多數這種處境落在第一格，主要動作在負債與緩衝而不在配置。</p>
<p>四種之外還有一種常見的重疊：同時對一門生意負責、也有個人的可投資餘裕。兩格都成立時照急迫度挑一篇開始，而混同本身是這一格最常見的失敗——兩邊的現金流分開記帳，是後續任何判斷的前提。</p>
<p>判準本身之外另有一條時間邊界，判在哪一格都成立：距離動用那筆錢只剩幾年時，四個主題篇裡只有 <a href="../personal-finance/">個人理財與風險保障</a> 的起點書有一節談提領，其餘各本預設的累積期都還長，長到短期波動可以被時間吸收——而接近動用的時候那個前提正好消失。</p>
<h2 id="這幾格不涵蓋誰">這幾格不涵蓋誰</h2>
<p>責任來源不同的幾種處境套進這四格會失真。<strong>已經進入提領期的退休者</strong>面對的主要問題是提領順序與長壽風險，那跟累積期的排序是不同的問題，這條線目前沒有承接。<strong>繼承、贈與與遺產安排</strong>的主體是制度而非配置，落在這條線明說不承接的制度性那一層。<strong>受託為客戶管理資產的專業從業者</strong>的義務由法規界定，適合度、揭露與利益衝突各有法定要求，而這套四項描述判不了法遵。</p>
<h2 id="問出對方的條件並留下決定的依據">問出對方的條件並留下決定的依據</h2>
<p>替別人做決定時，這條線的四項描述有一項換了主體。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a> 問的是一本書預設的環境在讀它的那個人那裡存不存在，而第三格要問的是那個環境在<strong>被決定的那個人</strong>那裡存不存在：資本形態、現金流的鬆緊與支出結構、那筆錢什麼時候會被動用，全部要換成對方的。讀者手上通常只有其中幾項——知道對方有多少存款，不知道每個月的固定支出佔多少；知道年齡，不知道對方遇到一次三成的下跌會做什麼。所以這一格比其他三格多兩件事要做：把缺的那幾項問出來，以及把問到的答案跟後續的決定一起留下來。</p>
<p><strong>承受度問不出來的原因多半不是對方不肯講。</strong>「你能接受虧多少」對沒有經歷過下跌的人是一個抽象的百分比，答案會落在一個當下講得出口、而下跌發生的那一次又不作數的數字上。換成已經發生過的事、或換成具體的後果就答得出來：「前一次市場下跌的那幾個月，你當時想做什麼」「這筆錢少掉三分之一的話，原本要拿它做的哪一件事會取消」。</p>
<p>這一層的技巧有主場：管理線的 <a href="../../software-management/topics/influence-conversation/">困難對話與無權限影響力</a>。它的起點書把一場對話拆成同時進行的三層（事實、感受、身分），而家庭財務對話卡住的位置經常在第三層——同意調整配置等於承認自己原本的判斷不夠好。同一篇的《Humble Inquiry》處理的正是「問了，而拿回來的是自己想聽的那個版本」。移植成本要逐本看而不是整篇看：起點書的案例本來就涵蓋家庭與法律協商，直接可用；《The Secrets of Consulting》預設的是顧問對客戶的收費關係，退出方式與事後的問責形態都跟家庭不同，那一本要自己重估。</p>
<p><strong>留下什麼，由事後會被問的問題反推。</strong> 這一格事後被問的問題有特定形態：當初為什麼這樣決定、我同意過嗎。報酬數字不必自己記，帳戶對帳單上就有。而且提問的人不一定是當初談的那一位——可能是其他家屬，或對方判斷能力改變之後接手的代理人。反推出來的內容因此是當時的目標與期限、對方用自己的話說出來的承受度、被否決的選項與否決的理由，以及什麼情況下要重新談。</p>
<p>承受度那一項保留原話而不要換算成百分比。原話帶著對方當時對照的那件具體的事（「不能影響到孫子的學費」），而百分比在事後的爭議裡是一個誰都可以重新解釋的數字。</p>
<p>清單上最後那一項是變更權：什麼情況下、由誰決定要不要改。缺這一項的時候，市場下跌那一次的對話會從「要不要調整」變成「當初是誰決定的」，而那是兩個完全不同的對話。</p>
<p><strong>這兩件事在書單裡沒有條目，而這是判斷過的結果。</strong> 溝通那一半的書在管理線，同一組書在兩條線各寫一次說明，維護時只會改到其中一份。紀錄那一半在這裡直接寫成規格，理由是它短到寫得完，而 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 明說書單只放外部書籍與選讀判斷。</p>
<p>這不表示沒有書處理紀錄那一半。以決策日誌與事後檢討為主題的書確實存在，本書單未評估的是它們的<strong>角色歸屬</strong>——那類書該落在這條線，還是落在管理線的 <a href="../../software-management/topics/estimation-decision/">估算、承諾與決策偏誤</a>，因為它們處理的是同一組偏誤，而不是同一種資本。角色歸屬判定之前，在這條線開第五個主題篇會做出一個內容全部指向別條線的空頁，所以這一格目前的處置是這一節。</p>
<h2 id="這幾格跟主題篇的分工">這幾格跟主題篇的分工</h2>
<p>主題篇按問題組織，回答「這個問題該讀什麼」；這一篇按人組織，回答「我現在該讀什麼」。同一本書會出現在多格的建議裡，用法不同——<a href="../personal-finance/">個人理財與風險保障</a> 的起點書給第一格的是排序的算式，給第四格的是把個人現金流從生意裡分出來的理由。</p>
<p>書的性質判定（<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>、時效狀態、<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>、讀得出價值的前提）一律在主題篇，這裡不重複，避免同一本書的多份說明各自漂移。這一篇寫的是「哪種處境對應哪一篇、在這裡怎麼用」。</p>
<p>管理線的同類頁面是 <a href="../../software-management/roles/">依位置選書</a>，那裡的軸是對誰的產出負責。兩條線的位置互相獨立——技術負責人與只有薪資現金流可以同時成立，因為那兩個軸問的是不同的責任。</p>
]]></content:encoded></item><item><title>依位置選書</title><link>https://tarrragon.github.io/blog/books/software-management/roles/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/</guid><description>&lt;p>位置篇按責任範圍組織，不按職稱。同一個職稱在不同組織對應的責任差很多——三十人公司的「資深工程師」經常同時對別人的產出與技術品質負責，五百人公司的同一個職稱可能只對自己的產出負責。職稱與實際責任一致時兩者等價，不一致時以責任為準；責任軸的代價是它要自我診斷；職稱則是外部給定、查得到的。下一段的判準就是為了讓這個診斷有可操作的做法。&lt;/p>
&lt;p>每篇處理三件事：這個位置一天實際在處理什麼、同一個責任範圍在制度成文與不成文的組織裡問題差在哪、以及往相鄰位置移動前該預習什麼。制度化程度才是那一段的軸，人數只是粗略訊號——三百人的家族企業可能沒有職級帶，八十人的新創可能整套沿用大廠的 ladder。判的方法是逐項確認四樣東西寫不寫得出來：晉升的條件、績效評估的流程、薪資帶的範圍、以及調動要經過誰。四樣都有文件、而且文件跟實際發生的事一致，是成文；四樣都靠個案決定，是不成文；最常見的是中間態——文件存在但實際決定不照它走，那種情況照不成文處理，因為位置篇談的是這個位置真正能用的工具。另外一個訊號在預算側：headcount 綁在年度預算裡、增補要跨部門核准的，制度化程度通常已經很高。&lt;/p>
&lt;p>遠距、跨國、公部門這三種情境會再疊上各自的變形（可見度、單一薪資市場的假設、法定薪級），那些差異這批內容沒有處理——跨時區非同步團隊尤其要先看&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>。書的完整描述都在 &lt;a href="../topics/">主題書單&lt;/a>，這裡只說「哪種處境對應哪本」與為什麼。&lt;/p>
&lt;h2 id="五個位置">五個位置&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>位置&lt;/th>
 &lt;th>對什麼負責&lt;/th>
 &lt;th>最常見的失敗&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="own-output/">只對自己的產出負責&lt;/a>&lt;/td>
 &lt;td>交出去的東西本身&lt;/td>
 &lt;td>做完了但沒人知道它做完了&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="technical-quality/">對技術品質負責、不帶人&lt;/a>&lt;/td>
 &lt;td>跨越多人的技術決策與標準&lt;/td>
 &lt;td>方案是對的，但推不動&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="others-output/">對別人的產出負責&lt;/a>&lt;/td>
 &lt;td>團隊交出去的東西&lt;/td>
 &lt;td>自己重寫比教會別人快，於是永遠自己重寫&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="people/">對人負責&lt;/a>&lt;/td>
 &lt;td>這些人留不留得住、成不成長&lt;/td>
 &lt;td>把「管理」做成「更大範圍的自己動手」&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="org-structure/">對組織結構負責&lt;/a>&lt;/td>
 &lt;td>團隊怎麼切、交接面誰負責&lt;/td>
 &lt;td>改組織圖而沒有改任何人的實際約束&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h2 id="怎麼判斷自己在哪一格">怎麼判斷自己在哪一格&lt;/h2>
&lt;p>判準是&lt;strong>交不出來的時候，誰會被問&lt;/strong>：&lt;/p>
&lt;ul>
&lt;li>只有自己被問 → &lt;a href="own-output/">只對自己的產出負責&lt;/a>&lt;/li>
&lt;li>沒有人交不出來、但技術決策錯了會問到自己 → &lt;a href="technical-quality/">對技術品質負責&lt;/a>&lt;/li>
&lt;li>別人交不出來而問到自己 → &lt;a href="others-output/">對別人的產出負責&lt;/a>&lt;/li>
&lt;li>人走了會問到自己 → &lt;a href="people/">對人負責&lt;/a>&lt;/li>
&lt;li>團隊之間卡住而沒有人特別該負責時會問到自己 → &lt;a href="org-structure/">對組織結構負責&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>這張清單判不出來的三種處境，答案都在本節後半，依出現順序是：還沒被指派而想先評估下一格（本節第五段）、好幾格同時成立（倒數第二段）、團隊人數不到一個團隊（最後一段）。夾在中間的兩段講的是判準本身在哪些組織會失準，跟這三種處境無關。&lt;/p>
&lt;p>另外有五種組織會讓判準本身失準。前三種是「被問」這件事在組織裡的分佈出了問題：什麼都問同一個人的、集體負責而沒有人被特別問的、以及被問的人不是有槓桿的人。第四種是&lt;strong>沒有人在看&lt;/strong>——沒有人來問不一定表示做得好，也可能是這件事還沒有人在追，這種情況下判準收不到任何訊號。第五種是&lt;strong>問責發生在組織外&lt;/strong>：受主管機關監理的組織，事故後由稽核與監理單位問責，組織內部可能沒有任何人被問，而責任是真實存在的。&lt;/p>
&lt;p>什麼都問同一個人的、集體負責的、以及沒有人在看的這三種，改看&lt;strong>手上能動的槓桿&lt;/strong>——能不能改變別人的優先序、能不能動人事、能不能改變交接面怎麼定，能動到哪一層就讀哪一篇。被問的人沒有槓桿那一種不適用這個處方（它的定義就是槓桿不存在），那種處境照被問的位置選書，同時把 &lt;a href="../topics/influence-conversation/">困難對話與無權限影響力&lt;/a> 排在前面。問責發生在組織外那一種照法定的責任歸屬判，那通常比組織內部的分工更明確。責任大於權限的處境不必因此退出選書：技術品質與別人的產出這兩格的定義本來就是責任大於權限，照被問的位置選書仍然對，只是要先補 &lt;a href="../topics/influence-conversation/">困難對話與無權限影響力&lt;/a>，否則選對了書也推不動。&lt;/p>
&lt;p>這個判準問的是現在。換位置的人需要的卻是下一格。&lt;strong>下一格不是現在這一格的人，照現況判都會落在舊的那一格&lt;/strong>——已經確定要轉換的（下個月開始帶人、下一季接下平台團隊）是一種，還在評估要不要轉換、連機會都還沒出現的是另一種。那不是判錯，只是判準只看得到當下。兩種處境讀兩篇：現在這個位置的「想往哪裡走」段說明該預習什麼，目標那一格的前兩段說明即將接手的問題長什麼樣。還在評估的人另外先看 &lt;a href="../topics/role-transitions/">角色轉換與職涯路徑&lt;/a>——那裡的書逐層寫出每個位置整天實際在處理什麼，而「值不值得走過去」要先看得到那個才答得出來。轉換之後再讀一次目標那篇，讀出來的東西會跟轉換前不同——這是刻意的，判準要等到承擔責任才長得出來。&lt;/p>
&lt;p>這五格是有僱傭關係、責任由組織分配的處境。獨立接案者、開源維護者、DevRel、研究型工程師、技術寫作者的責任來源不同——對客戶、對社群、對外部讀者——那些處境不在這條線的範圍內，套進五格會失真。五格之間也不是階梯：檔案的排序是責任範圍由小到大，不是該走的順序，橫向移動與留在原地都是正常路徑，每篇的「想往哪裡走」段有標出哪些方向存在。&lt;/p>
&lt;p>同時符合兩處時取當下解不掉的那一處——已經在解的那些問題不需要一本書指出怎麼開始。完全對不上的情況也存在——小公司的技術負責人可能同時負責技術品質、別人的產出、人與組織結構，那種處境的建議是照急迫度挑一篇開始，而不是四篇一起讀。&lt;/p>
&lt;p>有一個規模下限要先確認：&lt;a href="org-structure/">對組織結構負責&lt;/a> 那篇的書預設組織裡至少有三個團隊（這個數字的推導在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的約束段）。人數在一個團隊以內時，那些內容是為不存在的問題做設計，先看 &lt;a href="others-output/">對別人的產出負責&lt;/a>。&lt;a href="people/">對人負責&lt;/a> 那一格照樣成立——兩個人的去留一樣決定得了公司能不能活，只是那一格的書預設組織已經有分級、調薪與績效制度可用，沒有制度時讀到的是那些工具背後的判斷，而不是照著把制度建起來。這個規模真正該補的另一半在 &lt;a href="../../craft/">工程技藝&lt;/a>。&lt;/p>
&lt;p>其他會改變答案的約束（人員流動率、協作形態、法規義務、預算）見 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「哪些約束會改變答案」段。&lt;/p>
&lt;h2 id="這幾篇跟主題篇的分工">這幾篇跟主題篇的分工&lt;/h2>
&lt;p>主題篇按問題組織，回答「這個問題該讀什麼」；位置篇按人組織，回答「我現在該讀什麼」。同一本書會出現在多個位置的建議裡，用法不同——&lt;a href="../topics/retention-motivation/">Peopleware&lt;/a> 給只對自己產出負責的人的是「原來我的環境是這樣壞掉的」，給對人負責的人的是「我可以動哪些槓桿」。&lt;/p>
&lt;p>書的性質判定（&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>、時效狀態、&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>、讀得出價值的前提）一律在主題篇，位置篇不重複，避免同一本書的多份說明各自漂移。位置篇寫的是「哪種處境對應哪本、在這裡怎麼用」，而同一本書在多個位置各有一句用法時，那幾句也會漂移——防這一層的做法是各句只講該位置獨有的用途，不重述書的主張本身，書是什麼以主題篇為準。同一條規則也適用於主題篇之間：一本書的性質判定住在它的主場那一篇，別篇引用時只指路、不重述。&lt;/p></description><content:encoded><![CDATA[<p>位置篇按責任範圍組織，不按職稱。同一個職稱在不同組織對應的責任差很多——三十人公司的「資深工程師」經常同時對別人的產出與技術品質負責，五百人公司的同一個職稱可能只對自己的產出負責。職稱與實際責任一致時兩者等價，不一致時以責任為準；責任軸的代價是它要自我診斷；職稱則是外部給定、查得到的。下一段的判準就是為了讓這個診斷有可操作的做法。</p>
<p>每篇處理三件事：這個位置一天實際在處理什麼、同一個責任範圍在制度成文與不成文的組織裡問題差在哪、以及往相鄰位置移動前該預習什麼。制度化程度才是那一段的軸，人數只是粗略訊號——三百人的家族企業可能沒有職級帶，八十人的新創可能整套沿用大廠的 ladder。判的方法是逐項確認四樣東西寫不寫得出來：晉升的條件、績效評估的流程、薪資帶的範圍、以及調動要經過誰。四樣都有文件、而且文件跟實際發生的事一致，是成文；四樣都靠個案決定，是不成文；最常見的是中間態——文件存在但實際決定不照它走，那種情況照不成文處理，因為位置篇談的是這個位置真正能用的工具。另外一個訊號在預算側：headcount 綁在年度預算裡、增補要跨部門核准的，制度化程度通常已經很高。</p>
<p>遠距、跨國、公部門這三種情境會再疊上各自的變形（可見度、單一薪資市場的假設、法定薪級），那些差異這批內容沒有處理——跨時區非同步團隊尤其要先看<a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a>。書的完整描述都在 <a href="../topics/">主題書單</a>，這裡只說「哪種處境對應哪本」與為什麼。</p>
<h2 id="五個位置">五個位置</h2>
<table>
  <thead>
      <tr>
          <th>位置</th>
          <th>對什麼負責</th>
          <th>最常見的失敗</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="own-output/">只對自己的產出負責</a></td>
          <td>交出去的東西本身</td>
          <td>做完了但沒人知道它做完了</td>
      </tr>
      <tr>
          <td><a href="technical-quality/">對技術品質負責、不帶人</a></td>
          <td>跨越多人的技術決策與標準</td>
          <td>方案是對的，但推不動</td>
      </tr>
      <tr>
          <td><a href="others-output/">對別人的產出負責</a></td>
          <td>團隊交出去的東西</td>
          <td>自己重寫比教會別人快，於是永遠自己重寫</td>
      </tr>
      <tr>
          <td><a href="people/">對人負責</a></td>
          <td>這些人留不留得住、成不成長</td>
          <td>把「管理」做成「更大範圍的自己動手」</td>
      </tr>
      <tr>
          <td><a href="org-structure/">對組織結構負責</a></td>
          <td>團隊怎麼切、交接面誰負責</td>
          <td>改組織圖而沒有改任何人的實際約束</td>
      </tr>
  </tbody>
</table>
<h2 id="怎麼判斷自己在哪一格">怎麼判斷自己在哪一格</h2>
<p>判準是<strong>交不出來的時候，誰會被問</strong>：</p>
<ul>
<li>只有自己被問 → <a href="own-output/">只對自己的產出負責</a></li>
<li>沒有人交不出來、但技術決策錯了會問到自己 → <a href="technical-quality/">對技術品質負責</a></li>
<li>別人交不出來而問到自己 → <a href="others-output/">對別人的產出負責</a></li>
<li>人走了會問到自己 → <a href="people/">對人負責</a></li>
<li>團隊之間卡住而沒有人特別該負責時會問到自己 → <a href="org-structure/">對組織結構負責</a></li>
</ul>
<p>這張清單判不出來的三種處境，答案都在本節後半，依出現順序是：還沒被指派而想先評估下一格（本節第五段）、好幾格同時成立（倒數第二段）、團隊人數不到一個團隊（最後一段）。夾在中間的兩段講的是判準本身在哪些組織會失準，跟這三種處境無關。</p>
<p>另外有五種組織會讓判準本身失準。前三種是「被問」這件事在組織裡的分佈出了問題：什麼都問同一個人的、集體負責而沒有人被特別問的、以及被問的人不是有槓桿的人。第四種是<strong>沒有人在看</strong>——沒有人來問不一定表示做得好，也可能是這件事還沒有人在追，這種情況下判準收不到任何訊號。第五種是<strong>問責發生在組織外</strong>：受主管機關監理的組織，事故後由稽核與監理單位問責，組織內部可能沒有任何人被問，而責任是真實存在的。</p>
<p>什麼都問同一個人的、集體負責的、以及沒有人在看的這三種，改看<strong>手上能動的槓桿</strong>——能不能改變別人的優先序、能不能動人事、能不能改變交接面怎麼定，能動到哪一層就讀哪一篇。被問的人沒有槓桿那一種不適用這個處方（它的定義就是槓桿不存在），那種處境照被問的位置選書，同時把 <a href="../topics/influence-conversation/">困難對話與無權限影響力</a> 排在前面。問責發生在組織外那一種照法定的責任歸屬判，那通常比組織內部的分工更明確。責任大於權限的處境不必因此退出選書：技術品質與別人的產出這兩格的定義本來就是責任大於權限，照被問的位置選書仍然對，只是要先補 <a href="../topics/influence-conversation/">困難對話與無權限影響力</a>，否則選對了書也推不動。</p>
<p>這個判準問的是現在。換位置的人需要的卻是下一格。<strong>下一格不是現在這一格的人，照現況判都會落在舊的那一格</strong>——已經確定要轉換的（下個月開始帶人、下一季接下平台團隊）是一種，還在評估要不要轉換、連機會都還沒出現的是另一種。那不是判錯，只是判準只看得到當下。兩種處境讀兩篇：現在這個位置的「想往哪裡走」段說明該預習什麼，目標那一格的前兩段說明即將接手的問題長什麼樣。還在評估的人另外先看 <a href="../topics/role-transitions/">角色轉換與職涯路徑</a>——那裡的書逐層寫出每個位置整天實際在處理什麼，而「值不值得走過去」要先看得到那個才答得出來。轉換之後再讀一次目標那篇，讀出來的東西會跟轉換前不同——這是刻意的，判準要等到承擔責任才長得出來。</p>
<p>這五格是有僱傭關係、責任由組織分配的處境。獨立接案者、開源維護者、DevRel、研究型工程師、技術寫作者的責任來源不同——對客戶、對社群、對外部讀者——那些處境不在這條線的範圍內，套進五格會失真。五格之間也不是階梯：檔案的排序是責任範圍由小到大，不是該走的順序，橫向移動與留在原地都是正常路徑，每篇的「想往哪裡走」段有標出哪些方向存在。</p>
<p>同時符合兩處時取當下解不掉的那一處——已經在解的那些問題不需要一本書指出怎麼開始。完全對不上的情況也存在——小公司的技術負責人可能同時負責技術品質、別人的產出、人與組織結構，那種處境的建議是照急迫度挑一篇開始，而不是四篇一起讀。</p>
<p>有一個規模下限要先確認：<a href="org-structure/">對組織結構負責</a> 那篇的書預設組織裡至少有三個團隊（這個數字的推導在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的約束段）。人數在一個團隊以內時，那些內容是為不存在的問題做設計，先看 <a href="others-output/">對別人的產出負責</a>。<a href="people/">對人負責</a> 那一格照樣成立——兩個人的去留一樣決定得了公司能不能活，只是那一格的書預設組織已經有分級、調薪與績效制度可用，沒有制度時讀到的是那些工具背後的判斷，而不是照著把制度建起來。這個規模真正該補的另一半在 <a href="../../craft/">工程技藝</a>。</p>
<p>其他會改變答案的約束（人員流動率、協作形態、法規義務、預算）見 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「哪些約束會改變答案」段。</p>
<h2 id="這幾篇跟主題篇的分工">這幾篇跟主題篇的分工</h2>
<p>主題篇按問題組織，回答「這個問題該讀什麼」；位置篇按人組織，回答「我現在該讀什麼」。同一本書會出現在多個位置的建議裡，用法不同——<a href="../topics/retention-motivation/">Peopleware</a> 給只對自己產出負責的人的是「原來我的環境是這樣壞掉的」，給對人負責的人的是「我可以動哪些槓桿」。</p>
<p>書的性質判定（<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>、時效狀態、<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>、讀得出價值的前提）一律在主題篇，位置篇不重複，避免同一本書的多份說明各自漂移。位置篇寫的是「哪種處境對應哪本、在這裡怎麼用」，而同一本書在多個位置各有一句用法時，那幾句也會漂移——防這一層的做法是各句只講該位置獨有的用途，不重述書的主張本身，書是什麼以主題篇為準。同一條規則也適用於主題篇之間：一本書的性質判定住在它的主場那一篇，別篇引用時只指路、不重述。</p>
]]></content:encoded></item><item><title>只對自己的產出負責</title><link>https://tarrragon.github.io/blog/books/software-management/roles/own-output/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/own-output/</guid><description>&lt;p>工作內容是別人切好的、範圍是別人定的、時程通常也是；交不出來的時候，被問的就是做那件事的人自己。責任邊界清楚到這種程度，核心問題就不是「怎麼做完」，而是&lt;strong>怎麼讓別人相信做完的東西是對的&lt;/strong>，以及在沒有人明說的情況下判斷下一步該補什麼。&lt;/p>
&lt;p>兩種失敗在這個位置特別常見。一種是做完了但沒人知道它做完了：工作做得對，卻沒有留下讓別人能檢查、能接手、能信任的痕跡。另一種是把「更難的技術」當成成長方向，而卡住升遷的其實是協作與交付這一側。&lt;/p>
&lt;h2 id="只對自己產出負責時成文制度與否的差別">只對自己產出負責時，成文制度與否的差別&lt;/h2>
&lt;p>有職級階梯的組織裡，這個位置的問題是&lt;strong>標準存在但寫得抽象&lt;/strong>。職級描述寫「影響範圍」「獨立性」「複雜度」，這些詞到績效面談時才被主管翻譯成具體行為，翻譯規則不公開。真正的困難是把抽象描述反推回可觀察行為；反推錯了要一整個週期才知道。&lt;/p>
&lt;p>扁平的小公司沒有這個問題，因為它連抽象標準都沒有。這裡的問題是&lt;strong>沒有人定義什麼叫做好&lt;/strong>——做得好不好取決於當下有沒有人抱怨——沒人抱怨可能是因為做得好，也可能是因為沒人看。這種環境裡的成長風險是三年後換工作時，發現自己的經驗無法被外部標準衡量。應對方式是主動引入外部標準當校準點：找一份公開的工程職級框架（大廠的 career ladder 多半公開），對照自己現在做的事落在哪一級、下一級要求什麼。走這個對照的時機不是排一個週期，是每次手上的工作性質明顯換了一種（開始被找去看別人的設計、開始要對一個模組的長期狀態負責）——那種變化才是級別移動的訊號，而它不按月份發生。這件事不需要公司同意，而且換工作時那份對照就是履歷的骨架。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/role-transitions/">The Software Engineer&amp;rsquo;s Guidebook&lt;/a>&lt;/strong> 是這個位置的主要書。它把各級別的差異翻成可觀察的行為，直接處理上面說的「抽象標準反推」問題。有職級的組織可以拿它直接對照級別；沒有職級的組織讀到的是能力清單本身，而把清單排序的那根軸要另外找外部框架當錨——那正是上一段講的做法。剛入行就可以讀，不必先累積管理經驗。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/problem-definition/">Are Your Lights On?&lt;/a>&lt;/strong> 處理的是接到需求時「這到底是什麼問題」。這個位置的人拿到的需求通常已經被別人切過一次；切錯的需求照做出來仍然是錯的——能指出這件事，是這個位置最容易被看見的價值。一百多頁，一個下午讀得完。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">Peopleware&lt;/a>&lt;/strong> 的用法在這個位置跟在管理位置不同。這裡讀它讀出來的是「原來我做不完事不全是我的問題」——中斷成本、環境條件、頻繁重組對產出的影響都有具體論證。這件事本身有實用價值（知道哪些是環境問題就不會全部歸咎自己），也是往管理方向預習時最難自然累積的一塊。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/personal-workflow/">Getting Things Done&lt;/a>&lt;/strong> 處理承諾多到記不住之後怎麼辦。它跟上面那本接得起來——Peopleware 指出哪些負擔來自環境，這本處理剩下屬於自己的那些。這個位置特別要知道的邊界是：被指派進共用待辦、在群組頻道裡被喊住的那些工作不經過任何屬於個人的入口，而那正是這一格最常見的來源。那一層由同一篇的 A World Without Email 與 Four Thousand Weeks 處理，方法本身與它的處境限制在主題篇。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>轉換通常由別人啟動——有人離職、團隊變大、專案需要一個窗口，而不是誰主動申請。能控制的只有被想到的機率：可觀察的訊號是別人開始拿設計來問意見、新人的問題自然流過來、自己的估算被拿去當基準。這三件事發生時，開口說「我想試試看帶這個」的成功率比沒發生時高得多。&lt;/p>
&lt;p>&lt;strong>往技術路線&lt;/strong>（&lt;a href="../technical-quality/">對技術品質負責&lt;/a>）：現在該預習的是影響力，不是技術深度。技術深度會隨著工作自然累積，而「沒有職權時怎麼讓別人照著做」在這個位置上完全練不到——這裡的方案被採納，通常是因為它只影響提案的人自己。&lt;a href="../../topics/influence-conversation/">困難對話與無權限影響力&lt;/a> 那條線是這段路的預習。&lt;/p>
&lt;p>&lt;strong>往管理路線&lt;/strong>（&lt;a href="../others-output/">對別人的產出負責&lt;/a>）：現在該預習的是人與環境，同樣不是技術。還在判斷要不要走這條路的話，先看 &lt;a href="../../topics/role-transitions/">角色轉換與職涯路徑&lt;/a>——那裡的書寫出這些位置一天實際在做什麼，看得到那個才決定得了值不值得。決定要走之後，&lt;a href="../../topics/retention-motivation/">留任、動機與工作環境&lt;/a> 與 &lt;a href="../../topics/culture-safety/">組織文化與心理安全感&lt;/a> 這兩塊在只對自己負責的位置上沒有練習機會，它們卻決定管理做得好不好。&lt;/p>
&lt;p>&lt;strong>留在這裡繼續深化&lt;/strong>也是完整的路線。把一件事做到別人會來問，本身就是一個位置，而不是還沒選路的狀態；資深個人貢獻者是體面的終點，不是往管理路上的中繼站。往這個方向走要補的是技藝本身——怎麼寫出改得動的程式、怎麼安全地改別人的程式、怎麼知道自己沒弄壞，那整條線在 &lt;a href="../../../craft/">工程技藝書單&lt;/a>。&lt;/p>
&lt;p>三條路都不需要現在決定。這個階段值得做的是先讀 Guidebook 弄清楚各條路要什麼，再看哪一邊的問題讓自己比較有興趣。&lt;/p></description><content:encoded><![CDATA[<p>工作內容是別人切好的、範圍是別人定的、時程通常也是；交不出來的時候，被問的就是做那件事的人自己。責任邊界清楚到這種程度，核心問題就不是「怎麼做完」，而是<strong>怎麼讓別人相信做完的東西是對的</strong>，以及在沒有人明說的情況下判斷下一步該補什麼。</p>
<p>兩種失敗在這個位置特別常見。一種是做完了但沒人知道它做完了：工作做得對，卻沒有留下讓別人能檢查、能接手、能信任的痕跡。另一種是把「更難的技術」當成成長方向，而卡住升遷的其實是協作與交付這一側。</p>
<h2 id="只對自己產出負責時成文制度與否的差別">只對自己產出負責時，成文制度與否的差別</h2>
<p>有職級階梯的組織裡，這個位置的問題是<strong>標準存在但寫得抽象</strong>。職級描述寫「影響範圍」「獨立性」「複雜度」，這些詞到績效面談時才被主管翻譯成具體行為，翻譯規則不公開。真正的困難是把抽象描述反推回可觀察行為；反推錯了要一整個週期才知道。</p>
<p>扁平的小公司沒有這個問題，因為它連抽象標準都沒有。這裡的問題是<strong>沒有人定義什麼叫做好</strong>——做得好不好取決於當下有沒有人抱怨——沒人抱怨可能是因為做得好，也可能是因為沒人看。這種環境裡的成長風險是三年後換工作時，發現自己的經驗無法被外部標準衡量。應對方式是主動引入外部標準當校準點：找一份公開的工程職級框架（大廠的 career ladder 多半公開），對照自己現在做的事落在哪一級、下一級要求什麼。走這個對照的時機不是排一個週期，是每次手上的工作性質明顯換了一種（開始被找去看別人的設計、開始要對一個模組的長期狀態負責）——那種變化才是級別移動的訊號，而它不按月份發生。這件事不需要公司同意，而且換工作時那份對照就是履歷的骨架。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/role-transitions/">The Software Engineer&rsquo;s Guidebook</a></strong> 是這個位置的主要書。它把各級別的差異翻成可觀察的行為，直接處理上面說的「抽象標準反推」問題。有職級的組織可以拿它直接對照級別；沒有職級的組織讀到的是能力清單本身，而把清單排序的那根軸要另外找外部框架當錨——那正是上一段講的做法。剛入行就可以讀，不必先累積管理經驗。</p>
<p><strong><a href="../../topics/problem-definition/">Are Your Lights On?</a></strong> 處理的是接到需求時「這到底是什麼問題」。這個位置的人拿到的需求通常已經被別人切過一次；切錯的需求照做出來仍然是錯的——能指出這件事，是這個位置最容易被看見的價值。一百多頁，一個下午讀得完。</p>
<p><strong><a href="../../topics/retention-motivation/">Peopleware</a></strong> 的用法在這個位置跟在管理位置不同。這裡讀它讀出來的是「原來我做不完事不全是我的問題」——中斷成本、環境條件、頻繁重組對產出的影響都有具體論證。這件事本身有實用價值（知道哪些是環境問題就不會全部歸咎自己），也是往管理方向預習時最難自然累積的一塊。</p>
<p><strong><a href="../../topics/personal-workflow/">Getting Things Done</a></strong> 處理承諾多到記不住之後怎麼辦。它跟上面那本接得起來——Peopleware 指出哪些負擔來自環境，這本處理剩下屬於自己的那些。這個位置特別要知道的邊界是：被指派進共用待辦、在群組頻道裡被喊住的那些工作不經過任何屬於個人的入口，而那正是這一格最常見的來源。那一層由同一篇的 A World Without Email 與 Four Thousand Weeks 處理，方法本身與它的處境限制在主題篇。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>轉換通常由別人啟動——有人離職、團隊變大、專案需要一個窗口，而不是誰主動申請。能控制的只有被想到的機率：可觀察的訊號是別人開始拿設計來問意見、新人的問題自然流過來、自己的估算被拿去當基準。這三件事發生時，開口說「我想試試看帶這個」的成功率比沒發生時高得多。</p>
<p><strong>往技術路線</strong>（<a href="../technical-quality/">對技術品質負責</a>）：現在該預習的是影響力，不是技術深度。技術深度會隨著工作自然累積，而「沒有職權時怎麼讓別人照著做」在這個位置上完全練不到——這裡的方案被採納，通常是因為它只影響提案的人自己。<a href="../../topics/influence-conversation/">困難對話與無權限影響力</a> 那條線是這段路的預習。</p>
<p><strong>往管理路線</strong>（<a href="../others-output/">對別人的產出負責</a>）：現在該預習的是人與環境，同樣不是技術。還在判斷要不要走這條路的話，先看 <a href="../../topics/role-transitions/">角色轉換與職涯路徑</a>——那裡的書寫出這些位置一天實際在做什麼，看得到那個才決定得了值不值得。決定要走之後，<a href="../../topics/retention-motivation/">留任、動機與工作環境</a> 與 <a href="../../topics/culture-safety/">組織文化與心理安全感</a> 這兩塊在只對自己負責的位置上沒有練習機會，它們卻決定管理做得好不好。</p>
<p><strong>留在這裡繼續深化</strong>也是完整的路線。把一件事做到別人會來問，本身就是一個位置，而不是還沒選路的狀態；資深個人貢獻者是體面的終點，不是往管理路上的中繼站。往這個方向走要補的是技藝本身——怎麼寫出改得動的程式、怎麼安全地改別人的程式、怎麼知道自己沒弄壞，那整條線在 <a href="../../../craft/">工程技藝書單</a>。</p>
<p>三條路都不需要現在決定。這個階段值得做的是先讀 Guidebook 弄清楚各條路要什麼，再看哪一邊的問題讓自己比較有興趣。</p>
]]></content:encoded></item><item><title>設計判準與日常實踐</title><link>https://tarrragon.github.io/blog/books/craft/design-and-practice/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/craft/design-and-practice/</guid><description>&lt;p>這個主題處理兩件在日常裡分不開的事：把程式寫成之後改得動的樣子，以及讓那件事持續發生的工作習慣。它們分不開的理由是設計判準要靠習慣才生效——知道模組該小、介面該深，跟每次動手時真的去想這件事，中間隔著一整套日常做法。&lt;/p>
&lt;p>三本書的差別在&lt;strong>密度與主張數&lt;/strong>，不在誰對誰錯：《The Pragmatic Programmer》列幾十條短原則、《A Philosophy of Software Design》用一條主張貫穿全書、《Code Complete》鋪成百科式的對照表。手上的問題越具體，越適合主張集中的《A Philosophy of Software Design》；想建立通盤基礎，才輪得到百科式的《Code Complete》。&lt;/p>
&lt;p>處境相容性這一項三本都查過，都沒有列出限制。它們的判準落在程式碼本身的形狀與個人的動手習慣上，成立與否不取決於組織有沒有職級制度、成員是不是同一個僱主、大家在不在同一個時區，也不受事故追責義務左右。這是全批唯一每一本都查過、而且每一本都沒有依賴的一篇——同一條技藝線上的另外三篇不是這樣，架構、驗證與改既有程式那三篇各自都有書預設了特定的組織條件。&lt;/p>
&lt;h2 id="起點是-the-pragmatic-programmer">起點是 The Pragmatic Programmer&lt;/h2>
&lt;p>Dave Thomas 與 Andy Hunt 的《The Pragmatic Programmer》把技藝拆成幾十條自成一段、互不依賴的實踐——從 DRY、正交性這種設計判準，到版本控制、純文字、自動化這種工具習慣，再到知識組合、除錯紀律這種職業態度——任何一條都可以單獨拿走用。條目多而彼此不相依，是它在本篇管得最寬、因此當起點的原因。&lt;/p>
&lt;p>它最常被引用的是 DRY，而它的原文比多數轉述嚴格：系統裡的每一項知識都必須有單一、明確、權威的表述。這句話管的不只是程式碼——業務規則、設定值、資料定義同樣算，而多數 DRY 的誤用是把它讀成「不要複製貼上」，於是把兩段長得像但會各自變動的程式硬合併，製造出更難改的耦合。&lt;/p>
&lt;p>另一條沒有被廣泛轉述的是曳光彈（tracer bullets）：先打通一條從頭到尾都會動的最細路徑，再逐段加厚。它跟原型的差別在於曳光彈的程式碼會留下來成為骨架，原型是用完就丟——搞混這兩者的團隊會把探索用的臨時程式碼帶進生產。&lt;/p>
&lt;p>20 週年版是大幅改寫過的，不是加註解的重印本，並補進了並行、actor model、property-based testing 與資安基礎。要買就買這一版。時效上，第一版綁的工具與環境（CVS、特定編輯器）在改版時清掉了；DRY、正交性、曳光彈、破窗理論這些主張不依賴任何工具世代。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨客戶的顧問經驗，形式是格言加短例而非資料——這也決定了它的用法：拿來當檢查表對照自己的習慣，而不是拿去說服別人。&lt;/p>
&lt;p>這本書幾乎不需要前置準備，入行第一年就可以讀；而且每隔幾年重讀會讀出不同的東西，因為同一條原則在不同經驗量下對得上的情境不一樣。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Pragmatic-Programmer-journey-mastery-Anniversary/dp/0135957052">Amazon（The Pragmatic Programmer, 20th Anniversary Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010856354">博客來（The Pragmatic Programmer 20 週年紀念版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想把設計問題想清楚時讀-a-philosophy-of-software-design">想把設計問題想清楚時讀 A Philosophy of Software Design&lt;/h2>
&lt;p>John Ousterhout 的這本整本只推一個主張：&lt;strong>軟體設計的根本問題是控制複雜度&lt;/strong>，其餘的判準都從這一條長出來。這種寫法的好處是它給得出一個可以隨身帶的判準，而不是一份要背的清單。&lt;/p>
&lt;p>書中最可操作的是深模組（deep module）這個概念：好的模組是介面小而實作厚，壞的模組是介面跟實作一樣大。這條判準直接推翻了「函式應該盡量短」這種常見指導——把一個模組切成十個各自很淺的函式，介面總量反而變大，複雜度是上升的。另一組是紅旗清單（淺模組、資訊洩漏、時序分解、重複、註解重述程式碼），設計時可以逐條掃。&lt;/p>
&lt;p>它跟 Pragmatic Programmer 的關係是深度換廣度：那本列出有哪些事該做，這本把其中一件（怎麼切模組）挖到底。兩本一起讀不會重複。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗，而形態特別：素材來自作者多年開設軟體設計課的學生專案觀察，樣本受控但規模小、且偏向課堂專案，這是它跟業界顧問經驗不同的地方。作者是 Tcl 的作者、Stanford 教授。第二版於 2021 年出版，補了更多例子並回應了對第一版的批評。時效上沒有綁定任何工具世代。&lt;/p>
&lt;p>讀這本要先有一段維護經驗當對照：維護過自己或別人寫的東西超過半年，經歷過「當初這樣切好像不對」。沒有這個對照時，深模組會讀成一個偏好而不是判準——可以先讀《The Pragmatic Programmer》，等維護經驗累積起來再回來讀這本。&lt;/p>
&lt;p>繁體中文版查不到，簡體中文版《軟件設計的哲學》第二版由人民郵電出版社出版。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Philosophy-Software-Design-2nd/dp/173210221X">Amazon（A Philosophy of Software Design, 2nd Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.tenlong.com.tw/products/9787115655615">天瓏（軟件設計的哲學 2/e，簡體中文版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要一份百科式的對照時讀-code-complete">要一份百科式的對照時讀 Code Complete&lt;/h2>
&lt;p>Steve McConnell 的《Code Complete》第二版是這個主題涵蓋面最大的一本，把建構期的每個決定都拆開處理：變數命名、迴圈結構、防禦性編程、程式碼佈局、審查方式。它跟前兩本的差別在於它不推銷單一主張，而是把當時能找到的研究與實務歸納整理成對照表。&lt;/p>
&lt;p>它的獨特之處是引用密度。多數技藝書的主張來自作者經驗，這本大量引用了實證研究——哪種審查方式抓到的缺陷比例較高、缺陷在哪個階段被發現的修復成本差幾倍，這類數字它會標出處。要拿數據去支持一個工程實踐的改變時，這本是站上少數能給引用來源的書。&lt;/p>
&lt;p>時效要分層看，而這本的分層特別明顯。&lt;strong>建構期的具體技術&lt;/strong>（那個年代的語言特性、命名慣例、程式碼佈局的爭論）大量過時，讀的時候會一直遇到已經不成立的例子；&lt;strong>它引用的實證研究&lt;/strong>多數停在 2004 年之前，後續二十年的研究沒有納入；而&lt;strong>它整理問題的方式&lt;/strong>——把每個建構決定拆成有哪些選項、各自的取捨是什麼——不依賴那些例子，那才是現在讀它的理由。&lt;/p>
&lt;p>證據來源是理論建構（把當時的實證文獻與實務歸納整理成對照表）加上單一路徑的個人經驗，是這個主題裡唯一有系統引用實證研究的一本。這本不適合通讀，適合遇到具體問題時當工具書查——需要的是查閱的耐心，經驗門檻反而不高。繁體中文版譯名《CODE COMPLETE 2 中文版：軟體開發實務指南》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670">Amazon（Code Complete, Second Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010805887">博客來（CODE COMPLETE 2 中文版：軟體開發實務指南，第二版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>同樣回答「怎麼寫得更好」，這三本的密度差一個量級：Pragmatic Programmer 廣而每條短，A Philosophy of Software Design 窄而挖到底，Code Complete 大而全。手上的問題越具體越往《A Philosophy of Software Design》走，想建立通盤基礎才輪到《Code Complete》。&lt;/p>
&lt;p>技藝類的書市極擁擠，而多數集中在兩個位置：特定語言的最佳實踐彙編，以及把某一套規則推銷成普適判準的書。前者屬於教學系列而非書單的責任範圍，後者的問題是規則脫離了推導它的取捨——分辨的方法是看它有沒有講清楚什麼情況下這條規則不適用，只給規則不給邊界的表示它把判斷收走了。&lt;/p>
&lt;p>Robert Martin 的《Clean Code》常被列在這個位置，本書單未評估它。它的部分主張（函式應該極短、註解是失敗的象徵）在近年受到相當多的技術批評，而判斷那些批評成不成立需要逐條對照原文與反方論證，這裡沒有做。要讀的話值得同時找反方的討論一起看，不要當成無爭議的標準。&lt;/p>
&lt;p>離收得進來最近的一門課是 MIT 的 6.005 Software Construction。大綱涵蓋規格、測試、抽象資料型別、物件導向設計模式、並行與函數式程式設計，跟本篇三本書重疊得最多，OpenCourseWare 上也放了考題、習題與程式作業——差的只有影音，而成因是那門課刻意不把課堂時間拿來講課（FAQ 自陳），因此沒有可錄的講課。&lt;strong>這不代表設計判準拍不出來&lt;/strong>，理由寫在 &lt;a href="../">工程技藝書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>設計判準要在既有程式碼上生效，靠的是改動的技術：手上有測試時怎麼移動結構、沒有測試時怎麼先弄出測試、以及小改動要不要現在做。那條路徑走 &lt;a href="../changing-existing-code/">改既有的程式&lt;/a>。&lt;/p>
&lt;p>寫得好而團隊切錯時，交付一樣會卡，那條路徑走 &lt;a href="../../software-management/topics/team-design/">組織結構與團隊設計&lt;/a>。想知道自己在職涯位置上該補什麼，走 &lt;a href="../../software-management/roles/">依位置選書&lt;/a>。&lt;/p>
&lt;p>各語言的具體寫法與慣例看 &lt;a href="https://tarrragon.github.io/blog/python/" data-link-title="Python 維護工程師實戰指南" data-link-desc="以 Hook 系統為範例的 Python 開發教學">Python 維護指南&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/go/" data-link-title="Go 入門實戰指南" data-link-desc="理解 Go 語言精神與核心開發能力">Go 維護指南&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/flutter/" data-link-title="Flutter 實戰指南" data-link-desc="Flutter 與 Dart 的實作層教材：型別設計與語言機制、狀態與渲染、測試策略、工具鏈，從實際專案 case 抽出判準。">Flutter 實戰指南&lt;/a>；測試怎麼分層與設計看 &lt;a href="https://tarrragon.github.io/blog/testing/" data-link-title="開發測試實務指南" data-link-desc="測試全過而實機全壞、或程式碼由 agent 產出而無法逐行讀時，用來決定驗證該掛在哪幾層、每一層各自守不住什麼">Testing 測試策略&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理兩件在日常裡分不開的事：把程式寫成之後改得動的樣子，以及讓那件事持續發生的工作習慣。它們分不開的理由是設計判準要靠習慣才生效——知道模組該小、介面該深，跟每次動手時真的去想這件事，中間隔著一整套日常做法。</p>
<p>三本書的差別在<strong>密度與主張數</strong>，不在誰對誰錯：《The Pragmatic Programmer》列幾十條短原則、《A Philosophy of Software Design》用一條主張貫穿全書、《Code Complete》鋪成百科式的對照表。手上的問題越具體，越適合主張集中的《A Philosophy of Software Design》；想建立通盤基礎，才輪得到百科式的《Code Complete》。</p>
<p>處境相容性這一項三本都查過，都沒有列出限制。它們的判準落在程式碼本身的形狀與個人的動手習慣上，成立與否不取決於組織有沒有職級制度、成員是不是同一個僱主、大家在不在同一個時區，也不受事故追責義務左右。這是全批唯一每一本都查過、而且每一本都沒有依賴的一篇——同一條技藝線上的另外三篇不是這樣，架構、驗證與改既有程式那三篇各自都有書預設了特定的組織條件。</p>
<h2 id="起點是-the-pragmatic-programmer">起點是 The Pragmatic Programmer</h2>
<p>Dave Thomas 與 Andy Hunt 的《The Pragmatic Programmer》把技藝拆成幾十條自成一段、互不依賴的實踐——從 DRY、正交性這種設計判準，到版本控制、純文字、自動化這種工具習慣，再到知識組合、除錯紀律這種職業態度——任何一條都可以單獨拿走用。條目多而彼此不相依，是它在本篇管得最寬、因此當起點的原因。</p>
<p>它最常被引用的是 DRY，而它的原文比多數轉述嚴格：系統裡的每一項知識都必須有單一、明確、權威的表述。這句話管的不只是程式碼——業務規則、設定值、資料定義同樣算，而多數 DRY 的誤用是把它讀成「不要複製貼上」，於是把兩段長得像但會各自變動的程式硬合併，製造出更難改的耦合。</p>
<p>另一條沒有被廣泛轉述的是曳光彈（tracer bullets）：先打通一條從頭到尾都會動的最細路徑，再逐段加厚。它跟原型的差別在於曳光彈的程式碼會留下來成為骨架，原型是用完就丟——搞混這兩者的團隊會把探索用的臨時程式碼帶進生產。</p>
<p>20 週年版是大幅改寫過的，不是加註解的重印本，並補進了並行、actor model、property-based testing 與資安基礎。要買就買這一版。時效上，第一版綁的工具與環境（CVS、特定編輯器）在改版時清掉了；DRY、正交性、曳光彈、破窗理論這些主張不依賴任何工具世代。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨客戶的顧問經驗，形式是格言加短例而非資料——這也決定了它的用法：拿來當檢查表對照自己的習慣，而不是拿去說服別人。</p>
<p>這本書幾乎不需要前置準備，入行第一年就可以讀；而且每隔幾年重讀會讀出不同的東西，因為同一條原則在不同經驗量下對得上的情境不一樣。</p>
<ul>
<li><a href="https://www.amazon.com/Pragmatic-Programmer-journey-mastery-Anniversary/dp/0135957052">Amazon（The Pragmatic Programmer, 20th Anniversary Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010856354">博客來（The Pragmatic Programmer 20 週年紀念版）</a></li>
</ul>
<h2 id="想把設計問題想清楚時讀-a-philosophy-of-software-design">想把設計問題想清楚時讀 A Philosophy of Software Design</h2>
<p>John Ousterhout 的這本整本只推一個主張：<strong>軟體設計的根本問題是控制複雜度</strong>，其餘的判準都從這一條長出來。這種寫法的好處是它給得出一個可以隨身帶的判準，而不是一份要背的清單。</p>
<p>書中最可操作的是深模組（deep module）這個概念：好的模組是介面小而實作厚，壞的模組是介面跟實作一樣大。這條判準直接推翻了「函式應該盡量短」這種常見指導——把一個模組切成十個各自很淺的函式，介面總量反而變大，複雜度是上升的。另一組是紅旗清單（淺模組、資訊洩漏、時序分解、重複、註解重述程式碼），設計時可以逐條掃。</p>
<p>它跟 Pragmatic Programmer 的關係是深度換廣度：那本列出有哪些事該做，這本把其中一件（怎麼切模組）挖到底。兩本一起讀不會重複。</p>
<p>證據來源是單一路徑的個人經驗，而形態特別：素材來自作者多年開設軟體設計課的學生專案觀察，樣本受控但規模小、且偏向課堂專案，這是它跟業界顧問經驗不同的地方。作者是 Tcl 的作者、Stanford 教授。第二版於 2021 年出版，補了更多例子並回應了對第一版的批評。時效上沒有綁定任何工具世代。</p>
<p>讀這本要先有一段維護經驗當對照：維護過自己或別人寫的東西超過半年，經歷過「當初這樣切好像不對」。沒有這個對照時，深模組會讀成一個偏好而不是判準——可以先讀《The Pragmatic Programmer》，等維護經驗累積起來再回來讀這本。</p>
<p>繁體中文版查不到，簡體中文版《軟件設計的哲學》第二版由人民郵電出版社出版。</p>
<ul>
<li><a href="https://www.amazon.com/Philosophy-Software-Design-2nd/dp/173210221X">Amazon（A Philosophy of Software Design, 2nd Edition）</a></li>
<li><a href="https://www.tenlong.com.tw/products/9787115655615">天瓏（軟件設計的哲學 2/e，簡體中文版）</a></li>
</ul>
<h2 id="要一份百科式的對照時讀-code-complete">要一份百科式的對照時讀 Code Complete</h2>
<p>Steve McConnell 的《Code Complete》第二版是這個主題涵蓋面最大的一本，把建構期的每個決定都拆開處理：變數命名、迴圈結構、防禦性編程、程式碼佈局、審查方式。它跟前兩本的差別在於它不推銷單一主張，而是把當時能找到的研究與實務歸納整理成對照表。</p>
<p>它的獨特之處是引用密度。多數技藝書的主張來自作者經驗，這本大量引用了實證研究——哪種審查方式抓到的缺陷比例較高、缺陷在哪個階段被發現的修復成本差幾倍，這類數字它會標出處。要拿數據去支持一個工程實踐的改變時，這本是站上少數能給引用來源的書。</p>
<p>時效要分層看，而這本的分層特別明顯。<strong>建構期的具體技術</strong>（那個年代的語言特性、命名慣例、程式碼佈局的爭論）大量過時，讀的時候會一直遇到已經不成立的例子；<strong>它引用的實證研究</strong>多數停在 2004 年之前，後續二十年的研究沒有納入；而<strong>它整理問題的方式</strong>——把每個建構決定拆成有哪些選項、各自的取捨是什麼——不依賴那些例子，那才是現在讀它的理由。</p>
<p>證據來源是理論建構（把當時的實證文獻與實務歸納整理成對照表）加上單一路徑的個人經驗，是這個主題裡唯一有系統引用實證研究的一本。這本不適合通讀，適合遇到具體問題時當工具書查——需要的是查閱的耐心，經驗門檻反而不高。繁體中文版譯名《CODE COMPLETE 2 中文版：軟體開發實務指南》。</p>
<ul>
<li><a href="https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670">Amazon（Code Complete, Second Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010805887">博客來（CODE COMPLETE 2 中文版：軟體開發實務指南，第二版）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>同樣回答「怎麼寫得更好」，這三本的密度差一個量級：Pragmatic Programmer 廣而每條短，A Philosophy of Software Design 窄而挖到底，Code Complete 大而全。手上的問題越具體越往《A Philosophy of Software Design》走，想建立通盤基礎才輪到《Code Complete》。</p>
<p>技藝類的書市極擁擠，而多數集中在兩個位置：特定語言的最佳實踐彙編，以及把某一套規則推銷成普適判準的書。前者屬於教學系列而非書單的責任範圍，後者的問題是規則脫離了推導它的取捨——分辨的方法是看它有沒有講清楚什麼情況下這條規則不適用，只給規則不給邊界的表示它把判斷收走了。</p>
<p>Robert Martin 的《Clean Code》常被列在這個位置，本書單未評估它。它的部分主張（函式應該極短、註解是失敗的象徵）在近年受到相當多的技術批評，而判斷那些批評成不成立需要逐條對照原文與反方論證，這裡沒有做。要讀的話值得同時找反方的討論一起看，不要當成無爭議的標準。</p>
<p>離收得進來最近的一門課是 MIT 的 6.005 Software Construction。大綱涵蓋規格、測試、抽象資料型別、物件導向設計模式、並行與函數式程式設計，跟本篇三本書重疊得最多，OpenCourseWare 上也放了考題、習題與程式作業——差的只有影音，而成因是那門課刻意不把課堂時間拿來講課（FAQ 自陳），因此沒有可錄的講課。<strong>這不代表設計判準拍不出來</strong>，理由寫在 <a href="../">工程技藝書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>設計判準要在既有程式碼上生效，靠的是改動的技術：手上有測試時怎麼移動結構、沒有測試時怎麼先弄出測試、以及小改動要不要現在做。那條路徑走 <a href="../changing-existing-code/">改既有的程式</a>。</p>
<p>寫得好而團隊切錯時，交付一樣會卡，那條路徑走 <a href="../../software-management/topics/team-design/">組織結構與團隊設計</a>。想知道自己在職涯位置上該補什麼，走 <a href="../../software-management/roles/">依位置選書</a>。</p>
<p>各語言的具體寫法與慣例看 <a href="/blog/python/" data-link-title="Python 維護工程師實戰指南" data-link-desc="以 Hook 系統為範例的 Python 開發教學">Python 維護指南</a>、<a href="/blog/go/" data-link-title="Go 入門實戰指南" data-link-desc="理解 Go 語言精神與核心開發能力">Go 維護指南</a>、<a href="/blog/flutter/" data-link-title="Flutter 實戰指南" data-link-desc="Flutter 與 Dart 的實作層教材：型別設計與語言機制、狀態與渲染、測試策略、工具鏈，從實際專案 case 抽出判準。">Flutter 實戰指南</a>；測試怎麼分層與設計看 <a href="/blog/testing/" data-link-title="開發測試實務指南" data-link-desc="測試全過而實機全壞、或程式碼由 agent 產出而無法逐行讀時，用來決定驗證該掛在哪幾層、每一層各自守不住什麼">Testing 測試策略</a>。</p>
]]></content:encoded></item><item><title>資本配置與投資</title><link>https://tarrragon.github.io/blog/books/finance/investing/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/finance/investing/</guid><description>&lt;p>做投資的決定有兩種決策需求，各自要用不同的指標來評估。&lt;/p>
&lt;p>第一個是配置：錢會分到哪些資產類別、各佔多少、多久調整一次。&lt;/p>
&lt;p>第二個是選擇：在一個資產類別內部挑哪幾檔、什麼時候進出。&lt;/p>
&lt;p>兩者在決策上並不是獨立因素，配置的最適權重取決於個人的選擇能力，而如果要高度集中持股，那是做了兩個決策後的結果。要分開評估兩種決策的指標，但是做決定的時候不應該單獨只考慮一邊的問題。&lt;/p>
&lt;p>把兩種決策分開的理由是兩者的證據形態不同。配置對長期結果的影響有跨國、跨世紀的實際報酬分佈可以對照，這個數據是可核對的紀錄；選擇的持續有效性要的是另一種東西，同一套方法在不同時空背景下得到的紀錄本身經過倖存者篩選，留下文字的都是可複製結果，排除掉不可複製的結果。&lt;/p>
&lt;p>這個主題的《漫步華爾街》與《智慧型投資人》都探討這兩個問題——它們對「選擇能不能持續有效」給出相反的前提。另外三本補上這兩個問題之外的角色：《Triumph of the Optimists》與《Expected Returns》校準報酬數字本身，《窮查理的普通常識》處理做判斷的人的心理。多數投資書把篇幅放在選擇上，因為那是讀者以為自己唯一要考慮的問題。&lt;/p>
&lt;p>本篇屬於 &lt;a href="../">財務與投資書單&lt;/a>，每本書都用同一組四項描述：&lt;strong>證據來源&lt;/strong>（它的結論建立在什麼材料上）、&lt;strong>時效狀態&lt;/strong>（哪些部分依賴已經改變的前提）、&lt;strong>處境相容性&lt;/strong>（讀者具不具備它預設的環境）、&lt;strong>讀得出價值的前提&lt;/strong>（要有什麼經驗才讀得出它的價值）。四項的完整定義與這些判定的可信度說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>。&lt;/p>
&lt;p>這四項描述的對象是書。長篇文字讀不動的讀者可以改走課程：本篇後段的課程段列出承接同一組內容的公開課，收錄門檻與已知限制見 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。&lt;/p>
&lt;h2 id="起點是漫步華爾街">起點是漫步華爾街&lt;/h2>
&lt;p>Burton G. Malkiel 的《漫步華爾街》是本篇涵蓋面最廣的一本，配置與選擇兩層都處理，並且把兩層的證據強度差異直接寫進論證，讀者不需要自己推。&lt;/p>
&lt;p>涵蓋範圍包括泡沫史、技術面與基本面分析各自的實證紀錄、投資組合理論、行為財務學，以及一份按年齡調整的生命週期配置範例，附錄另有基金與 ETF 的選用說明。這個涵蓋面讓它可以當成唯一的一本讀完，再決定要不要往下走。&lt;/p>
&lt;p>核心主張是主動選股在扣除成本後長期難以持續勝過大盤，支撐它的是數十年的基金績效實證。這個主張的用法要注意方向：它說的是持續勝出很難，個別的勝出仍然會發生。書裡也列出難以用運氣解釋的個案，處理方式是問樣本量夠不夠，個案的存在照樣承認。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是理論建構，形式是把數十年的學術實證組織成一套解釋，所以這本書的效力有一部分繼承自那些被整合的研究；引用最密集的基金績效部分，本身就是大規模實證。&lt;/p>
&lt;p>時效上，2023 年的 50 週年增訂版把泡沫史延伸到近期。Smart Beta、ESG 產品與費用水準變動快，書裡的具體品項要當成寫作當時的快照；核心主張與生命週期配置的邏輯不依賴那些品項。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上有兩項要分開處理。第一項是制度：退休帳戶與稅務優惠的討論預設美國制度，屬於書單不承接的制度性內容（見 &lt;a href="../">財務與投資書單&lt;/a> 的「有些財務知識不該用書當載體」段）。&lt;/p>
&lt;p>第二項是計價幣別：全書以美元計價、以美國投資人為預設，書裡沒有處理新台幣讀者面對的匯率暴露。它的失效長這樣：照書的比例買進以美元計價的全球股票工具之後，某一段期間標的本身上漲，換回台幣的帳面卻是負的。帳戶顯示的是標的幣別的報酬，書裡的歷史數字也全部以美元計價，兩邊互相對得起來；實際要花的台幣則不出現在任何一個畫面上。所以新台幣讀者要自己補一層匯率的決定，而做這個決定需要的材料，書裡沒有。&lt;/p>
&lt;p>這本書幾乎不需任何前置作業，是本篇唯一一本零基礎就能讀的書，不需要通讀，即使只讀其中一個章節都會有幫助。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.tenlong.com.tw/products/9786263551886">天瓏（漫步華爾街：超越股市漲跌的成功投資策略，50 週年增訂版，天下文化）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/010819535">三民（A Random Walk Down Wall Street, 13th Edition, W. W. Norton, 2023）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要知道報酬數字本來長什麼樣時讀-triumph-of-the-optimists-與-expected-returns">要知道報酬數字本來長什麼樣時讀 Triumph of the Optimists 與 Expected Returns&lt;/h2>
&lt;p>這兩本合成一個條目，因為它們處理同一層問題而各做一半：《Triumph of the Optimists》給資料，回答「長期報酬實際的分佈長什麼樣」；《Expected Returns》給框架，回答「這批資料要怎麼轉成對未來的預期」。&lt;/p>
&lt;p>Elroy Dimson、Paul Marsh 與 Mike Staunton 的《Triumph of the Optimists》整理了 16 個市場、101 年的股票、債券與現金實質報酬（扣除通膨之後的報酬）。它在這個主題的位置是校準基準：多數投資書引用的長期股票報酬數字取自美國，把其他市場放進同一張表之後，那個數字明顯較低，而且有些市場在期間內中斷過。這是 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a> 落在分析者選樣上的實測幅度：挑哪個市場當長期序列的代表，本身就是一次篩選。&lt;/p>
&lt;p>Antti Ilmanen 的《Expected Returns》接下一步：歷史報酬要怎麼轉成對未來的預期。它把股債之外的報酬來源逐項拆開——期限、信用、流動性、動能、價值——各自給出實證基礎與已知的失效條件。單獨讀《Triumph of the Optimists》會停在「過去是這樣」，做決定還需要「未來可以預期什麼」，這一半由《Expected Returns》承接。&lt;/p>
&lt;p>兩本的證據來源都是大規模實證，形式是歷史市場資料。這種形式的強度值得單獨說明：數萬筆觀察值背後仍然只有一條時間線，跟跨組織問卷那種樣本彼此獨立的實證不是同一種強度。把這批數字讀成對未來分佈的估計，前提是那條時間線會重演；兩本的方法段裡查不到「時間線會重演」這個主張。這一條判定是從「查不到」反推的，本書單沒有通讀核對過全文，可信度照 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 說明的分級打折看。&lt;/p>
&lt;p>時效要分開看。《Triumph of the Optimists》的資料停在 2000 年底（涵蓋 1900 到 2000 這 101 年），同一組作者後續以《Global Investment Returns Yearbook》的形式逐年延續這批資料；要引用最新數字時查當年度的年鑑，不要抄書中的表。「單一市場的長期報酬會高估」這個結論不隨資料延長改變，因為新增的年份同樣落在被選過的樣本裡。《Expected Returns》出版於 2011 年，書中對各類資產的預期報酬估計建立在當時的利率與估值水準上，那個水準已經改變，作者本人在 2022 年另寫了一本處理低預期報酬環境的書；拆解報酬來源的框架不依賴那個水準。&lt;/p>
&lt;p>處境相容性上，兩本的樣本都以已開發市場為主，台股不在《Triumph of the Optimists》的原始樣本裡，把結論套到單一新興市場之前要先確認那個市場的資料序列有多長。取得成本是這個條目的實際障礙，而 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的約束段已標明本書單不以價格篩選：兩本都查不到中譯本，取得成本也高於本主題其餘各本（學術與專業出版，台灣通路多半要另外訂）。&lt;/p>
&lt;p>兩本需要的前置知識不同。《Triumph of the Optimists》的主體是圖表而非敘述，讀它會用到幾個報酬統計的概念：實質報酬、算術平均與幾何平均的差異、以及推估長期報酬為什麼用幾何平均。對這幾個概念還不熟的話，可以先從《漫步華爾街》把報酬的基本概念建立起來，再回來讀這本。《Expected Returns》要先有資產類別與風險溢酬的基本語彙，《漫步華爾街》提供的程度就夠。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/003107626">三民（Triumph of the Optimists: 101 Years of Global Investment Returns, Princeton University Press, 2002）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/002199978">三民（Expected Returns: An Investor&amp;rsquo;s Guide to Harvesting Market Rewards, John Wiley &amp;amp; Sons, 2011）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="智慧型投資人跟漫步華爾街的前提相反">智慧型投資人跟漫步華爾街的前提相反&lt;/h2>
&lt;p>Benjamin Graham 的《The Intelligent Investor》（中譯《智慧型投資人》）在這個主題承擔估值紀律：買進的價格要比估出來的價值低多少，判斷出錯時損失才落在可承受的範圍內。安全邊際、市場先生、以及防禦型與進取型投資人的分工，這三個概念從這本書進入這個領域的共同語言。&lt;/p>
&lt;p>它跟《漫步華爾街》的關係是前提相反，不是同一套方法的入門與進階。Malkiel 處理的是「在無法持續勝過大盤的前提下該怎麼配置」，Graham 處理的是「若要逐檔判斷，紀律該是什麼」。兩本並收的理由：讀者遲早要在這兩個前提之間自己選一個，選之前該看過雙方最強的版本。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗加理論建構，來自 Graham 自己的投資實務與哥倫比亞大學的教學。樣本是一。而且這個樣本能流傳下來，本身就是 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a> 由出版這個環節執行的典型形態：方法成功的那一位寫了書，用類似方法失敗的人沒有出書，讀者看得到的只有成功的版本。選書上的判讀寫在 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源分類&lt;/a>。&lt;/p>
&lt;p>時效是這本書最需要切分的一項，切法也最清楚。具體的篩選門檻——本益比上限、流動比率、股利連續發放年數——依賴 1949 到 1973 年間的市場結構與會計實務，照抄到今天的市場多半篩不出標的。安全邊際、市場先生、防禦型與進取型的分工這三條不依賴那個年代，因為它們處理的是價格與價值的關係而不是某個數值。&lt;/p>
&lt;p>Jason Zweig 自 2003 年的修訂版起為各章加寫評註，2024 年的第三版是那批評註的更新，兩版都處理了這段年代落差；沒有評註的是 Graham 自己那幾版。這一項的切分點落到章節層級，而按 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「這些判定從哪來」段，章節層級的判定要密讀才下得了；本書單沒有做到那個深度，所以這條切法當線索用，讀的時候自己再驗一次。&lt;/p>
&lt;p>處境相容性上，Graham 的方法預設市場上存在數量足夠的明顯低估標的，也預設個人有能力逐檔讀完財報並持有到價格回歸。第一個條件在資訊取得成本極低的市場上比當時稀少，第二個條件要求的時間投入在書裡沒有被計價。兩項都不否決全書：概念層照讀，操作層要自己重估。&lt;/p>
&lt;p>這本書要求讀者讀得懂資產負債表與損益表。缺這個底子時，篩選條件那幾章是一串看不懂的比率，而這本書最常見的失敗方式就發生在這裡：翻完那幾章、歸檔成讀過了，之後真正要用時想不起內容。這個底子由 &lt;a href="../accounting/">會計與財報&lt;/a> 承接，該篇的起點書《財報就像一本故事書》提供的程度就夠；要直接照著判讀一份實際報表，走站內的 &lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/sme-listed-company-financial-analysis/" data-link-title="企業財報判讀：中小企業經營評估與上市櫃公司供需及資金鏈分析" data-link-desc="評估中小企業的經營體質或判讀上市櫃公司的供需週轉與資金鏈健康度時，從三張報表的關係、營運週轉效率、負債結構、財報紅旗等維度做結構性分析的方法">企業財報判讀&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>做投資的決定有兩種決策需求，各自要用不同的指標來評估。</p>
<p>第一個是配置：錢會分到哪些資產類別、各佔多少、多久調整一次。</p>
<p>第二個是選擇：在一個資產類別內部挑哪幾檔、什麼時候進出。</p>
<p>兩者在決策上並不是獨立因素，配置的最適權重取決於個人的選擇能力，而如果要高度集中持股，那是做了兩個決策後的結果。要分開評估兩種決策的指標，但是做決定的時候不應該單獨只考慮一邊的問題。</p>
<p>把兩種決策分開的理由是兩者的證據形態不同。配置對長期結果的影響有跨國、跨世紀的實際報酬分佈可以對照，這個數據是可核對的紀錄；選擇的持續有效性要的是另一種東西，同一套方法在不同時空背景下得到的紀錄本身經過倖存者篩選，留下文字的都是可複製結果，排除掉不可複製的結果。</p>
<p>這個主題的《漫步華爾街》與《智慧型投資人》都探討這兩個問題——它們對「選擇能不能持續有效」給出相反的前提。另外三本補上這兩個問題之外的角色：《Triumph of the Optimists》與《Expected Returns》校準報酬數字本身，《窮查理的普通常識》處理做判斷的人的心理。多數投資書把篇幅放在選擇上，因為那是讀者以為自己唯一要考慮的問題。</p>
<p>本篇屬於 <a href="../">財務與投資書單</a>，每本書都用同一組四項描述：<strong>證據來源</strong>（它的結論建立在什麼材料上）、<strong>時效狀態</strong>（哪些部分依賴已經改變的前提）、<strong>處境相容性</strong>（讀者具不具備它預設的環境）、<strong>讀得出價值的前提</strong>（要有什麼經驗才讀得出它的價值）。四項的完整定義與這些判定的可信度說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>。</p>
<p>這四項描述的對象是書。長篇文字讀不動的讀者可以改走課程：本篇後段的課程段列出承接同一組內容的公開課，收錄門檻與已知限制見 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。</p>
<h2 id="起點是漫步華爾街">起點是漫步華爾街</h2>
<p>Burton G. Malkiel 的《漫步華爾街》是本篇涵蓋面最廣的一本，配置與選擇兩層都處理，並且把兩層的證據強度差異直接寫進論證，讀者不需要自己推。</p>
<p>涵蓋範圍包括泡沫史、技術面與基本面分析各自的實證紀錄、投資組合理論、行為財務學，以及一份按年齡調整的生命週期配置範例，附錄另有基金與 ETF 的選用說明。這個涵蓋面讓它可以當成唯一的一本讀完，再決定要不要往下走。</p>
<p>核心主張是主動選股在扣除成本後長期難以持續勝過大盤，支撐它的是數十年的基金績效實證。這個主張的用法要注意方向：它說的是持續勝出很難，個別的勝出仍然會發生。書裡也列出難以用運氣解釋的個案，處理方式是問樣本量夠不夠，個案的存在照樣承認。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是理論建構，形式是把數十年的學術實證組織成一套解釋，所以這本書的效力有一部分繼承自那些被整合的研究；引用最密集的基金績效部分，本身就是大規模實證。</p>
<p>時效上，2023 年的 50 週年增訂版把泡沫史延伸到近期。Smart Beta、ESG 產品與費用水準變動快，書裡的具體品項要當成寫作當時的快照；核心主張與生命週期配置的邏輯不依賴那些品項。</p>
<p><a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上有兩項要分開處理。第一項是制度：退休帳戶與稅務優惠的討論預設美國制度，屬於書單不承接的制度性內容（見 <a href="../">財務與投資書單</a> 的「有些財務知識不該用書當載體」段）。</p>
<p>第二項是計價幣別：全書以美元計價、以美國投資人為預設，書裡沒有處理新台幣讀者面對的匯率暴露。它的失效長這樣：照書的比例買進以美元計價的全球股票工具之後，某一段期間標的本身上漲，換回台幣的帳面卻是負的。帳戶顯示的是標的幣別的報酬，書裡的歷史數字也全部以美元計價，兩邊互相對得起來；實際要花的台幣則不出現在任何一個畫面上。所以新台幣讀者要自己補一層匯率的決定，而做這個決定需要的材料，書裡沒有。</p>
<p>這本書幾乎不需任何前置作業，是本篇唯一一本零基礎就能讀的書，不需要通讀，即使只讀其中一個章節都會有幫助。</p>
<ul>
<li><a href="https://www.tenlong.com.tw/products/9786263551886">天瓏（漫步華爾街：超越股市漲跌的成功投資策略，50 週年增訂版，天下文化）</a></li>
<li><a href="https://www.sanmin.com.tw/product/index/010819535">三民（A Random Walk Down Wall Street, 13th Edition, W. W. Norton, 2023）</a></li>
</ul>
<h2 id="要知道報酬數字本來長什麼樣時讀-triumph-of-the-optimists-與-expected-returns">要知道報酬數字本來長什麼樣時讀 Triumph of the Optimists 與 Expected Returns</h2>
<p>這兩本合成一個條目，因為它們處理同一層問題而各做一半：《Triumph of the Optimists》給資料，回答「長期報酬實際的分佈長什麼樣」；《Expected Returns》給框架，回答「這批資料要怎麼轉成對未來的預期」。</p>
<p>Elroy Dimson、Paul Marsh 與 Mike Staunton 的《Triumph of the Optimists》整理了 16 個市場、101 年的股票、債券與現金實質報酬（扣除通膨之後的報酬）。它在這個主題的位置是校準基準：多數投資書引用的長期股票報酬數字取自美國，把其他市場放進同一張表之後，那個數字明顯較低，而且有些市場在期間內中斷過。這是 <a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a> 落在分析者選樣上的實測幅度：挑哪個市場當長期序列的代表，本身就是一次篩選。</p>
<p>Antti Ilmanen 的《Expected Returns》接下一步：歷史報酬要怎麼轉成對未來的預期。它把股債之外的報酬來源逐項拆開——期限、信用、流動性、動能、價值——各自給出實證基礎與已知的失效條件。單獨讀《Triumph of the Optimists》會停在「過去是這樣」，做決定還需要「未來可以預期什麼」，這一半由《Expected Returns》承接。</p>
<p>兩本的證據來源都是大規模實證，形式是歷史市場資料。這種形式的強度值得單獨說明：數萬筆觀察值背後仍然只有一條時間線，跟跨組織問卷那種樣本彼此獨立的實證不是同一種強度。把這批數字讀成對未來分佈的估計，前提是那條時間線會重演；兩本的方法段裡查不到「時間線會重演」這個主張。這一條判定是從「查不到」反推的，本書單沒有通讀核對過全文，可信度照 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 說明的分級打折看。</p>
<p>時效要分開看。《Triumph of the Optimists》的資料停在 2000 年底（涵蓋 1900 到 2000 這 101 年），同一組作者後續以《Global Investment Returns Yearbook》的形式逐年延續這批資料；要引用最新數字時查當年度的年鑑，不要抄書中的表。「單一市場的長期報酬會高估」這個結論不隨資料延長改變，因為新增的年份同樣落在被選過的樣本裡。《Expected Returns》出版於 2011 年，書中對各類資產的預期報酬估計建立在當時的利率與估值水準上，那個水準已經改變，作者本人在 2022 年另寫了一本處理低預期報酬環境的書；拆解報酬來源的框架不依賴那個水準。</p>
<p>處境相容性上，兩本的樣本都以已開發市場為主，台股不在《Triumph of the Optimists》的原始樣本裡，把結論套到單一新興市場之前要先確認那個市場的資料序列有多長。取得成本是這個條目的實際障礙，而 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的約束段已標明本書單不以價格篩選：兩本都查不到中譯本，取得成本也高於本主題其餘各本（學術與專業出版，台灣通路多半要另外訂）。</p>
<p>兩本需要的前置知識不同。《Triumph of the Optimists》的主體是圖表而非敘述，讀它會用到幾個報酬統計的概念：實質報酬、算術平均與幾何平均的差異、以及推估長期報酬為什麼用幾何平均。對這幾個概念還不熟的話，可以先從《漫步華爾街》把報酬的基本概念建立起來，再回來讀這本。《Expected Returns》要先有資產類別與風險溢酬的基本語彙，《漫步華爾街》提供的程度就夠。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/003107626">三民（Triumph of the Optimists: 101 Years of Global Investment Returns, Princeton University Press, 2002）</a></li>
<li><a href="https://www.sanmin.com.tw/product/index/002199978">三民（Expected Returns: An Investor&rsquo;s Guide to Harvesting Market Rewards, John Wiley &amp; Sons, 2011）</a></li>
</ul>
<h2 id="智慧型投資人跟漫步華爾街的前提相反">智慧型投資人跟漫步華爾街的前提相反</h2>
<p>Benjamin Graham 的《The Intelligent Investor》（中譯《智慧型投資人》）在這個主題承擔估值紀律：買進的價格要比估出來的價值低多少，判斷出錯時損失才落在可承受的範圍內。安全邊際、市場先生、以及防禦型與進取型投資人的分工，這三個概念從這本書進入這個領域的共同語言。</p>
<p>它跟《漫步華爾街》的關係是前提相反，不是同一套方法的入門與進階。Malkiel 處理的是「在無法持續勝過大盤的前提下該怎麼配置」，Graham 處理的是「若要逐檔判斷，紀律該是什麼」。兩本並收的理由：讀者遲早要在這兩個前提之間自己選一個，選之前該看過雙方最強的版本。</p>
<p>證據來源是單一路徑的個人經驗加理論建構，來自 Graham 自己的投資實務與哥倫比亞大學的教學。樣本是一。而且這個樣本能流傳下來，本身就是 <a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a> 由出版這個環節執行的典型形態：方法成功的那一位寫了書，用類似方法失敗的人沒有出書，讀者看得到的只有成功的版本。選書上的判讀寫在 <a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源分類</a>。</p>
<p>時效是這本書最需要切分的一項，切法也最清楚。具體的篩選門檻——本益比上限、流動比率、股利連續發放年數——依賴 1949 到 1973 年間的市場結構與會計實務，照抄到今天的市場多半篩不出標的。安全邊際、市場先生、防禦型與進取型的分工這三條不依賴那個年代，因為它們處理的是價格與價值的關係而不是某個數值。</p>
<p>Jason Zweig 自 2003 年的修訂版起為各章加寫評註，2024 年的第三版是那批評註的更新，兩版都處理了這段年代落差；沒有評註的是 Graham 自己那幾版。這一項的切分點落到章節層級，而按 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「這些判定從哪來」段，章節層級的判定要密讀才下得了；本書單沒有做到那個深度，所以這條切法當線索用，讀的時候自己再驗一次。</p>
<p>處境相容性上，Graham 的方法預設市場上存在數量足夠的明顯低估標的，也預設個人有能力逐檔讀完財報並持有到價格回歸。第一個條件在資訊取得成本極低的市場上比當時稀少，第二個條件要求的時間投入在書裡沒有被計價。兩項都不否決全書：概念層照讀，操作層要自己重估。</p>
<p>這本書要求讀者讀得懂資產負債表與損益表。缺這個底子時，篩選條件那幾章是一串看不懂的比率，而這本書最常見的失敗方式就發生在這裡：翻完那幾章、歸檔成讀過了，之後真正要用時想不起內容。這個底子由 <a href="../accounting/">會計與財報</a> 承接，該篇的起點書《財報就像一本故事書》提供的程度就夠；要直接照著判讀一份實際報表，走站內的 <a href="/blog/business/financial-analysis/sme-listed-company-financial-analysis/" data-link-title="企業財報判讀：中小企業經營評估與上市櫃公司供需及資金鏈分析" data-link-desc="評估中小企業的經營體質或判讀上市櫃公司的供需週轉與資金鏈健康度時，從三張報表的關係、營運週轉效率、負債結構、財報紅旗等維度做結構性分析的方法">企業財報判讀</a>。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/015104596">三民（智慧型投資人：價值投資權威著作，75 週年紀念．全新譯本，寰宇）</a></li>
<li><a href="https://www.sanmin.com.tw/product/index/013460326">三民（The Intelligent Investor, 3rd Edition, Harper Business, 2024）</a></li>
</ul>
<h2 id="其他主題讀完之後才動窮查理的普通常識">其他主題讀完之後才動窮查理的普通常識</h2>
<p>Charlie Munger 的《窮查理的普通常識》由 Peter Kaufman 編成，內容是演講與談話的彙編。本主題其餘各本談的是市場、報酬與估值，這一本談做判斷的人。投資判斷失敗的原因常常落在判斷本身而非財務分析，這本書提供的是一組指認判斷錯誤的詞彙。</p>
<p>最可直接使用的是〈人類誤判心理學〉那一篇。它列出二十多種傾向——誘因造成的偏誤、社會認同、剝奪反應、承諾與一致性——並各自給出情境。用途是在自己正要做決定的當下叫得出名字；事後解釋別人為什麼錯，是它最容易被誤用的方向。</p>
<p>另一條主線是多元思維模型：把數個學科的核心概念當成常備的檢查清單，避免用單一學科的工具處理所有問題。這個主張本身成立，而它在書中的呈現形式決定了讀它的時機，說明放在下面講前置要求的那一段。</p>
<p>證據來源是單一路徑的個人經驗加理論建構。個人經驗那部分的樣本是一，而且那個位置本身罕見——永久資本、沒有贖回壓力、對被投資公司有影響力；理論建構那部分把既有學科組織成一套解釋，自己不產生新證據，誤判心理那一篇引用的實驗研究屬於二手引用。</p>
<p>時效切成兩半。心理誤判的機制不依賴年代。投資操作那部分依賴一個已經改變的前提：那個年代的資訊不對稱程度遠高於現在，願意讀完年報本身就構成優勢，而現在那個門檻低得多。</p>
<p>處境相容性是這本書最尖銳的一項，也是不把這本書設定為起點書的主要理由。書中的操作建議——高度集中、極長的持有期、在市場恐慌時加碼——建立在一種特定的資本形態上：不會被贖回、不必按季對外交代、規模大到足以影響被投資公司。</p>
<p>這組前提是從書中的操作建議反推出來的，書裡沒有明說，跟上一段的時效切分同屬待驗證的線索。一般讀者的資本會被生活需求打斷（購屋、育兒、失業），承受不了長期的大幅回撤，對持股也沒有影響力。這些建議的前提不適用於一般讀者，這些因素的差別是有或無而非程度上的高低。</p>
<p>這本書的前置要求是本篇各本裡最重的，而且這個要求決定了它在整份書單的位置。多元思維模型是壓縮引用：它點名經濟學、心理學、統計、物理與會計的概念，但不展開它們。缺那些底子時，讀到的是一串名詞加一種有道理的感覺。這是最貴的失敗形態：留下讀過了的印象，之後真正需要時不會回頭再讀。因此它在這份書單是終點而非起點，前置是其他各個條目。</p>
<p>版本要注意：Stripe Press 的英文版在該社頁面上自陳為節選本（abridged edition），由 Peter Kaufman 編、Stripe 共同創辦人 John Collison 加寫新序。節選的對象不是演講本身——英文節選本與中譯本同樣是十一講，所以數演講篇數分不出版本；比對引文時以手上那一本的版權頁為準。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/013152041">三民（窮查理的普通常識，紀念典藏版，商業周刊）</a></li>
<li><a href="https://press.stripe.com/poor-charlies-almanack">Stripe Press（Poor Charlie&rsquo;s Almanack，節選版）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>配置、報酬的實際分佈、估值紀律、判斷本身，四個條目各接一段。順序按依賴關係排而不按難度：報酬分佈、估值紀律與判斷這三個條目，都預設讀者已經知道「主動選股能不能持續勝過大盤」這個爭點在爭什麼，而那是《漫步華爾街》處理的問題。</p>
<p>不收的最大一類是操作法書：整本推一套進出場規則、一組指標或一份選股清單，而不寫它在什麼條件下失效。這個主題排除它們的判準有一個比別處更強的依據——幾種篩選在這一類書上通常同時到齊：作者是有紀錄的那一位（篩在出版，見 <a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源分類</a>）、回測用的資料庫不含下市證券、樣本期間落在對該方法有利的區段（後兩者見 <a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a>）。翻目錄就分得出來：有章節在寫這套方法什麼時候不管用、以及作者怎麼知道的，才跨得過這條線。</p>
<p>當期商品比較與稅務規劃書同樣不收，理由寫在 <a href="../">財務與投資書單</a> 的「有些財務知識不該用書當載體」段。</p>
<p>個別基金經理人的回憶錄與訪談集本書單未評估，未評估的是它們在這個主題的角色歸屬：它們可能跟《窮查理的普通常識》承擔同一件事（談做判斷的人），也可能承擔一個目前沒有條目的角色，這一點沒有判斷過。</p>
<h2 id="yale-的兩門課跟漫步華爾街結論相同理由不同">Yale 的兩門課跟漫步華爾街結論相同，理由不同</h2>
<p>Open Yale Courses 的兩門課接本篇前半。<strong>ECON 252 Financial Markets</strong> 由 Robert Shiller 主講、2011 年春季的課堂實錄、23 講，涵蓋分散投資與支撐它的制度、保險、效率市場、行為財務與心理、房地產、選擇權、銀行與專業資產管理人。</p>
<p>它跟《漫步華爾街》的關係要先標出來：《漫步華爾街》用效率市場（價格已經反映公開資訊，持續找到被錯估的標的因此很難）支撐「主動選股扣除成本後長期難以持續勝出」，而 Shiller 自己的研究提出過效率市場的系統性反例（股價的波動大過股利現值能解釋的幅度）。兩人在配置上的結論重疊，在「為什麼成立」上不一致。先看這門課再讀《漫步華爾街》的人，會比只讀一本的人早一步看到這個主題的爭點落在哪裡。</p>
<p><strong>ECON 251 Financial Theory</strong> 由 John Geanakoplos 主講、2009 年秋季、26 講，走另一條路：現值與實質利率、殖利率曲線、風險的量化、CAPM 與共同基金定理，最後兩講處理槓桿循環與次貸危機。它承接的是報酬數字怎麼被算出來那一層，也就是本篇《Expected Returns》那個條目的數學骨架。這門課自己標了門檻——要能解聯立方程式、看得懂微分與指數函數。這一項在課程上比在書上硬：書可以跳過某一章繼續讀，課程的後半建立在前半推導出來的結果上。</p>
<p>時效上，兩門課都有一段依賴錄製當時：ECON 252 的監理那一講以金融危機後的立法為當期材料，ECON 251 的最後兩講以次貸危機為近事。不依賴年代的是它們的主體——分散投資的算術、保險的原理、現值與殖利率曲線、CAPM 與共同基金定理，這些跟本篇兩本英文專業書的核心結論一樣不隨資料延長改變。</p>
<p>兩門課都提供影片、音檔與逐字稿，所以聽、看、必要時查字可以分開選。取用門檻上要標一件事：兩門都是英語授課、逐字稿也是英文，對「英文長文讀不動」而非「文字讀不動」的讀者，替代效果有限。中文側這一輪只查到台大的財務管理，而它問的是另一個問題，說明在本節末段。</p>
<p>《智慧型投資人》的估值紀律與《窮查理的普通常識》的判斷心理，目前沒有標出對應課程。估值紀律的缺口是形態問題：安全邊際與市場先生是判斷紀律而非可授課的推導，這一輪查到的範圍內與它最接近的是財報分析，而那已經由 <a href="../accounting/">會計與財報</a> 那一篇的課程段承接。</p>
<p>中文這一側，台大開放式課程的財務管理（陳明賢、20 講）落在另一個問題上：它問的是一家公司怎麼配置自己的資本，本篇問的是一個人怎麼配置自己的資本。兩者共用折現與風險的語彙，決定的主體不同。</p>
<ul>
<li><a href="https://oyc.yale.edu/economics/econ-252">Open Yale Courses（ECON 252 Financial Markets，Robert Shiller，2011，23 講）</a>、<a href="https://www.youtube.com/playlist?list=PL8FB14A2200B87185">YouTube 播放清單</a></li>
<li><a href="https://oyc.yale.edu/economics/econ-251">Open Yale Courses（ECON 251 Financial Theory，John Geanakoplos，2009，26 講）</a>、<a href="https://www.youtube.com/playlist?list=PLEDC55106E0BA18FC">YouTube 播放清單</a></li>
</ul>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>配置的決定要接到自己的現金流上（多少錢是可投資的、緊急預備留多少、負債該不該先還），那是 <a href="../personal-finance/">個人理財與風險保障</a> 的主場。本篇任何一條配置建議要能執行，前提都是那一篇的排序已經跑過一次。</p>
<p>《智慧型投資人》那個條目需要的財報閱讀能力由同一條書線的 <a href="../accounting/">會計與財報</a> 承接，該篇同時說明哪些部分會隨準則改版而失效。</p>
<p>要判斷一門生意為什麼賺錢、護城河在哪、估值語言怎麼運作，走 <a href="/blog/business/" data-link-title="商業概念與策略分析" data-link-desc="整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識，並提供閱讀商業分析的框架">商業概念與策略分析</a>。個體經濟主題不在這條書線另設條目，原因就是這一層由商業分析承接。</p>
<p>誤判心理那一篇跟管理線有直接接點：<a href="../../software-management/topics/estimation-decision/">估算、承諾與決策偏誤</a> 收的 Thinking, Fast and Slow 處理同一批機制，而它的證據來源是受控實驗而非彙編，要追機制的來源往那裡走。</p>
]]></content:encoded></item><item><title>證據來源分類（evidence provenance）</title><link>https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/</guid><description>&lt;p>證據來源指一本書的結論建立在什麼材料上，而那個材料決定結論可以支持多大範圍的決定。同一句主張由數萬份跨組織調查推出，跟由作者在三家公司的經歷推出，讀起來的說服力可以一樣，能拿去做的事卻不同：前者支持得了組織層級的改變，後者只支持得了「拿來對照自己的處境」。它跟 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a> 分工明確——證據來源問的是這個結論能推到多遠，處境相容性問的是它預設的環境在這裡存不存在。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>這一項是&lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>那組維度裡最先問的一個，因為其餘幾項都在它之後才有意義：結論的效力範圍決定了要不要繼續問它過不過時、環境對不對得上、什麼時候讀。&lt;/p>
&lt;p>它跟 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a> 之外的另一個對照是時效狀態，兩者是彼此獨立的軸。時效問「這段論證依賴的前提現在還在不在」，證據來源問「這段論證的材料本來就支持得了什麼」。1987 年的顧問經驗與 2018 年的顧問經驗在時效上差三十年，在能支持的決定範圍上沒有差別——那個範圍由材料的形態決定，跟出版年無關；反過來，同一年出版的大規模調查與個人回憶錄時效相同，能支持的範圍差一個量級。&lt;/p>
&lt;p>判定的材料多半來自書本身：前言或方法章節通常會自述資料從哪來。取自第三方評述或體裁推斷的判定可信度較低，&lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>的做法是寫出這個判定是從哪裡看出來的。&lt;/p>
&lt;h2 id="證據類別與各自的效力範圍">證據類別與各自的效力範圍&lt;/h2>
&lt;p>這些類別由本書單從它收錄的書的實際落點歸納，不對應任何既有的分類法，而且&lt;strong>不排成一條線&lt;/strong>。前半組（大規模實證、跨組織案例、單一組織的深度重建、跨客戶的顧問經驗、單一路徑的個人經驗）之間可以比樣本廣度，但那把尺也不乾淨——單一組織的深度重建廣度是一，排序卻靠前，因為記錄的深度與可查證性在那裡補了回來。後半組各自另有限制軸：受控實驗的限制是生態效度，理論建構的是它繼承的東西，作者自建的方法是干預與觀察同源，虛構敘事是沒有資料。表格的順序不是效力排序。一本書可以同時落在兩類，顧問經驗加理論建構是最常見的組合。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>類別&lt;/th>
 &lt;th>材料形態&lt;/th>
 &lt;th>支持得了什麼&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>大規模實證&lt;/td>
 &lt;td>數萬份調查、跨組織統計&lt;/td>
 &lt;td>組織層級的改變&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>跨組織案例&lt;/td>
 &lt;td>多個組織並列比較，敘述而非統計&lt;/td>
 &lt;td>「這條路別人走過」，不含「在我們這裡也會成立」&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>單一組織的深度重建&lt;/td>
 &lt;td>一個組織或一次事件被完整記錄，包括制度紀錄&lt;/td>
 &lt;td>機制的完整樣子，代價是那些機制常依賴該組織的條件&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>跨客戶的顧問經驗&lt;/td>
 &lt;td>作者數十年在多個組織的現場觀察&lt;/td>
 &lt;td>別處拿不到的細節與語言，答不了「在我的組織成立嗎」&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>單一路徑的個人經驗&lt;/td>
 &lt;td>作者自己走過的那一條路，含在少數幾家公司的任職&lt;/td>
 &lt;td>對照自己的處境，樣本是一&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>受控實驗&lt;/td>
 &lt;td>心理學或行為科學的實驗研究&lt;/td>
 &lt;td>對它測的那個機制很硬，實驗室到工作現場那一段要自己接&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>理論建構&lt;/td>
 &lt;td>把零散的做法、或既有的研究，組織成一套解釋&lt;/td>
 &lt;td>串連已知的事。它自己不產生新證據，而整合研究的那一種會繼承被它整合的研究的一部分效力，判斷時要回頭看它整合的是什麼&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>作者自建的方法&lt;/td>
 &lt;td>方法由作者提出，效果宣稱來自訓練現場的自陳而沒有獨立驗證&lt;/td>
 &lt;td>自己團隊的實驗協議，組織層級要另外找依據&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>虛構敘事&lt;/td>
 &lt;td>結論由劇情推出，沒有資料佐證&lt;/td>
 &lt;td>建立共同語言，不當論證的依據&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>分類本身不是評價：虛構敘事在「讓一群立場不同的人開始用同一組詞討論」這件事上，效果經常勝過統計報告，只是那個用途跟「拿數字去說服決策者」不是同一件事。&lt;/p>
&lt;p>表裡最容易誤讀的是受控實驗那一類，因為它讀起來最像科學。「實驗室到工作現場那一段要自己接」落到操作是：實驗測的可能是二十分鐘內的一個受控任務，而要用它的地方是連續三個月的專案排程。拿它去支持排程政策時，被問的第一個問題會是實驗的時間尺度，而那個落差在書裡不會被標出來——原作者交付的是機制，接到現場那一段本來就不在他的責任範圍。&lt;/p>
&lt;h2 id="材料的成員憑什麼進來決定同一類能推到多遠">材料的成員憑什麼進來，決定同一類能推到多遠&lt;/h2>
&lt;p>判完類別之後還有一項檢查：&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a>問的是樣本的進入條件。材料形態再硬，只要那個條件本身包含「後來活下來了」，那個硬度就不會轉成結論的可推廣範圍。定義、篩選會發生在哪些地方、以及判讀程序都住在那張卡；這裡只寫它在選書上的形態。&lt;/p>
&lt;p>在書上，篩選發生在&lt;strong>出版&lt;/strong>這一關：寫書的機會來自已經有的成績，所以結果分佈的下半部不留下文字。失敗自述確實是存在的書種，而能出版的是戲劇性的失敗，不是中位數的那種——缺席的正好是「平庸地失敗」，也正是估機率最需要的那一格。結果變異越大的領域這一層越強：投資與創業的變異大到單一樣本分不出方法與運氣，於是作者履歷再漂亮，樣本仍然是一，而且是被結果先選過的一。&lt;/p>
&lt;p>選書上的動作跟資料集不同：翻目錄找「這套方法什麼時候不管用、作者怎麼知道」那一章——作者交代過自己的失效條件，這一項才算通過。宣稱範圍該怎麼限定、以及為什麼不能拿它當一票否決，見那張卡。&lt;/p>
&lt;h2 id="判錯的代價要到出示依據時才現形">判錯的代價要到出示依據時才現形&lt;/h2>
&lt;p>判錯這一項的後果有延遲，而延遲正是它需要被寫下來的理由。拿一本靠劇情推出結論的書去支持部署流程的改動，提案在會議上被問資料在哪，而書裡沒有數字可以指。敘事型的書讀起來說服力不低於統計型的，差別在讀的當下沒有任何訊號。代價不只是那次被擋下來——提案被歸成個人偏好之後，下一次帶著統計資料來還得先洗掉這個印象。&lt;/p>
&lt;p>反向的判錯同樣有代價，只是延遲更久：把一本大規模實證的書當成個人經驗談讀過去，讀完記下的是作者的一個看法。等到要推動一項全部門的改動、需要指出一個數字時，手上只剩印象——那本書裡本來就有一個可以指的，而讀的當下沒有任何訊號提示要標記它。&lt;/p>
&lt;h2 id="判讀方式">判讀方式&lt;/h2>
&lt;p>同一本書拿去做兩件不同的事，這一項會給出兩個答案，所以它要連著用途一起問。要說服別人時找大規模實證，要理解機制時找深度重建，要建立共同語言時虛構敘事就夠了，要拿一套做法在自己團隊試時作者自建的方法反而最直接。&lt;/p>
&lt;p>兩本書講同一件事而結論相反時，先比證據類別再比論證。類別不同時，比完之後的動作是把支持範圍窄的那一本降級成「該處境下的一則觀察」，而不是判誰對——類別不同的兩個結論本來就在回答不同大小的問題，衝突不必解。兩本都是單一路徑的個人經驗時，相反的結論同時成立並不矛盾——那表示這件事取決於兩位作者處境的某個差異，而找出那個差異比選邊站有用。&lt;/p>
&lt;p>同一個作者的多本書通常共用同一組材料，因此證據類別相同。&lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的收錄規則據此把在同一個主題裡承擔同一種用途的多本書合寫成同一個條目，而不是各佔一條。&lt;/p></description><content:encoded><![CDATA[<p>證據來源指一本書的結論建立在什麼材料上，而那個材料決定結論可以支持多大範圍的決定。同一句主張由數萬份跨組織調查推出，跟由作者在三家公司的經歷推出，讀起來的說服力可以一樣，能拿去做的事卻不同：前者支持得了組織層級的改變，後者只支持得了「拿來對照自己的處境」。它跟 <a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a> 分工明確——證據來源問的是這個結論能推到多遠，處境相容性問的是它預設的環境在這裡存不存在。</p>
<h2 id="概念位置">概念位置</h2>
<p>這一項是<a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>那組維度裡最先問的一個，因為其餘幾項都在它之後才有意義：結論的效力範圍決定了要不要繼續問它過不過時、環境對不對得上、什麼時候讀。</p>
<p>它跟 <a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a> 之外的另一個對照是時效狀態，兩者是彼此獨立的軸。時效問「這段論證依賴的前提現在還在不在」，證據來源問「這段論證的材料本來就支持得了什麼」。1987 年的顧問經驗與 2018 年的顧問經驗在時效上差三十年，在能支持的決定範圍上沒有差別——那個範圍由材料的形態決定，跟出版年無關；反過來，同一年出版的大規模調查與個人回憶錄時效相同，能支持的範圍差一個量級。</p>
<p>判定的材料多半來自書本身：前言或方法章節通常會自述資料從哪來。取自第三方評述或體裁推斷的判定可信度較低，<a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>的做法是寫出這個判定是從哪裡看出來的。</p>
<h2 id="證據類別與各自的效力範圍">證據類別與各自的效力範圍</h2>
<p>這些類別由本書單從它收錄的書的實際落點歸納，不對應任何既有的分類法，而且<strong>不排成一條線</strong>。前半組（大規模實證、跨組織案例、單一組織的深度重建、跨客戶的顧問經驗、單一路徑的個人經驗）之間可以比樣本廣度，但那把尺也不乾淨——單一組織的深度重建廣度是一，排序卻靠前，因為記錄的深度與可查證性在那裡補了回來。後半組各自另有限制軸：受控實驗的限制是生態效度，理論建構的是它繼承的東西，作者自建的方法是干預與觀察同源，虛構敘事是沒有資料。表格的順序不是效力排序。一本書可以同時落在兩類，顧問經驗加理論建構是最常見的組合。</p>
<table>
  <thead>
      <tr>
          <th>類別</th>
          <th>材料形態</th>
          <th>支持得了什麼</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>大規模實證</td>
          <td>數萬份調查、跨組織統計</td>
          <td>組織層級的改變</td>
      </tr>
      <tr>
          <td>跨組織案例</td>
          <td>多個組織並列比較，敘述而非統計</td>
          <td>「這條路別人走過」，不含「在我們這裡也會成立」</td>
      </tr>
      <tr>
          <td>單一組織的深度重建</td>
          <td>一個組織或一次事件被完整記錄，包括制度紀錄</td>
          <td>機制的完整樣子，代價是那些機制常依賴該組織的條件</td>
      </tr>
      <tr>
          <td>跨客戶的顧問經驗</td>
          <td>作者數十年在多個組織的現場觀察</td>
          <td>別處拿不到的細節與語言，答不了「在我的組織成立嗎」</td>
      </tr>
      <tr>
          <td>單一路徑的個人經驗</td>
          <td>作者自己走過的那一條路，含在少數幾家公司的任職</td>
          <td>對照自己的處境，樣本是一</td>
      </tr>
      <tr>
          <td>受控實驗</td>
          <td>心理學或行為科學的實驗研究</td>
          <td>對它測的那個機制很硬，實驗室到工作現場那一段要自己接</td>
      </tr>
      <tr>
          <td>理論建構</td>
          <td>把零散的做法、或既有的研究，組織成一套解釋</td>
          <td>串連已知的事。它自己不產生新證據，而整合研究的那一種會繼承被它整合的研究的一部分效力，判斷時要回頭看它整合的是什麼</td>
      </tr>
      <tr>
          <td>作者自建的方法</td>
          <td>方法由作者提出，效果宣稱來自訓練現場的自陳而沒有獨立驗證</td>
          <td>自己團隊的實驗協議，組織層級要另外找依據</td>
      </tr>
      <tr>
          <td>虛構敘事</td>
          <td>結論由劇情推出，沒有資料佐證</td>
          <td>建立共同語言，不當論證的依據</td>
      </tr>
  </tbody>
</table>
<p>分類本身不是評價：虛構敘事在「讓一群立場不同的人開始用同一組詞討論」這件事上，效果經常勝過統計報告，只是那個用途跟「拿數字去說服決策者」不是同一件事。</p>
<p>表裡最容易誤讀的是受控實驗那一類，因為它讀起來最像科學。「實驗室到工作現場那一段要自己接」落到操作是：實驗測的可能是二十分鐘內的一個受控任務，而要用它的地方是連續三個月的專案排程。拿它去支持排程政策時，被問的第一個問題會是實驗的時間尺度，而那個落差在書裡不會被標出來——原作者交付的是機制，接到現場那一段本來就不在他的責任範圍。</p>
<h2 id="材料的成員憑什麼進來決定同一類能推到多遠">材料的成員憑什麼進來，決定同一類能推到多遠</h2>
<p>判完類別之後還有一項檢查：<a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a>問的是樣本的進入條件。材料形態再硬，只要那個條件本身包含「後來活下來了」，那個硬度就不會轉成結論的可推廣範圍。定義、篩選會發生在哪些地方、以及判讀程序都住在那張卡；這裡只寫它在選書上的形態。</p>
<p>在書上，篩選發生在<strong>出版</strong>這一關：寫書的機會來自已經有的成績，所以結果分佈的下半部不留下文字。失敗自述確實是存在的書種，而能出版的是戲劇性的失敗，不是中位數的那種——缺席的正好是「平庸地失敗」，也正是估機率最需要的那一格。結果變異越大的領域這一層越強：投資與創業的變異大到單一樣本分不出方法與運氣，於是作者履歷再漂亮，樣本仍然是一，而且是被結果先選過的一。</p>
<p>選書上的動作跟資料集不同：翻目錄找「這套方法什麼時候不管用、作者怎麼知道」那一章——作者交代過自己的失效條件，這一項才算通過。宣稱範圍該怎麼限定、以及為什麼不能拿它當一票否決，見那張卡。</p>
<h2 id="判錯的代價要到出示依據時才現形">判錯的代價要到出示依據時才現形</h2>
<p>判錯這一項的後果有延遲，而延遲正是它需要被寫下來的理由。拿一本靠劇情推出結論的書去支持部署流程的改動，提案在會議上被問資料在哪，而書裡沒有數字可以指。敘事型的書讀起來說服力不低於統計型的，差別在讀的當下沒有任何訊號。代價不只是那次被擋下來——提案被歸成個人偏好之後，下一次帶著統計資料來還得先洗掉這個印象。</p>
<p>反向的判錯同樣有代價，只是延遲更久：把一本大規模實證的書當成個人經驗談讀過去，讀完記下的是作者的一個看法。等到要推動一項全部門的改動、需要指出一個數字時，手上只剩印象——那本書裡本來就有一個可以指的，而讀的當下沒有任何訊號提示要標記它。</p>
<h2 id="判讀方式">判讀方式</h2>
<p>同一本書拿去做兩件不同的事，這一項會給出兩個答案，所以它要連著用途一起問。要說服別人時找大規模實證，要理解機制時找深度重建，要建立共同語言時虛構敘事就夠了，要拿一套做法在自己團隊試時作者自建的方法反而最直接。</p>
<p>兩本書講同一件事而結論相反時，先比證據類別再比論證。類別不同時，比完之後的動作是把支持範圍窄的那一本降級成「該處境下的一則觀察」，而不是判誰對——類別不同的兩個結論本來就在回答不同大小的問題，衝突不必解。兩本都是單一路徑的個人經驗時，相反的結論同時成立並不矛盾——那表示這件事取決於兩位作者處境的某個差異，而找出那個差異比選邊站有用。</p>
<p>同一個作者的多本書通常共用同一組材料，因此證據類別相同。<a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的收錄規則據此把在同一個主題裡承擔同一種用途的多本書合寫成同一個條目，而不是各佔一條。</p>
]]></content:encoded></item><item><title>主題書單</title><link>https://tarrragon.github.io/blog/books/software-management/topics/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/</guid><description>&lt;p>主題篇是每本書的完整描述所在，位置路由指過來。每篇先給一本起點書，接著依讀者的經驗與處境分出其他選項，最後說明為什麼這個主題只收這幾本。&lt;/p>
&lt;p>書的描述依四個維度——&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>、時效狀態、&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>、讀得出價值的前提，定義與這些判定的來源說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>。&lt;/p>
&lt;p>帶著具體症狀來的，直接看下面的主題表：「承擔的問題」欄寫的是症狀而不是術語，對得上哪一列就走哪一篇。中間那一段講的是起點書怎麼被選出來，那是選書方法、不是選書入口。&lt;/p>
&lt;p>從這裡直接進主題篇的話，有一組檢查會被跳過：&lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「哪些約束會改變答案」段列出組織規模、人員流動率、協作形態、法規與稽核義務、取得成本，踩到其中任何一項時同一個主題的正確答案會不同。受主管機關監理的組織、以及跨時區的非同步團隊，尤其要先看那一段再選書。&lt;/p>
&lt;h2 id="起點書怎麼選出來的">起點書怎麼選出來的&lt;/h2>
&lt;p>每篇的起點書用同一組判準，且判準之間有優先序，衝突時往下讓：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>涵蓋面&lt;/strong>：一本書能涵蓋該主題多少個面向（面向＝該篇「為什麼只收這幾本」段開頭列出的那組分工）。優先，因為起點書的任務是建立座標，涵蓋面窄的書會讓讀者以為主題就這麼大。&lt;/li>
&lt;li>&lt;strong>證據夠不夠支持這個用途&lt;/strong>：涵蓋面相當（差一個面向以內）時，取證據來源足以支持「被拿去佐證實際決定」這個用途的那本。這裡排的不是書的好壞，是它的結論可以支持多大範圍的主張——起點書的說法最容易被讀者引用出去，所以這一層看的是引用出去之後對方追問依據時答不答得出來。&lt;/li>
&lt;li>&lt;strong>可操作性&lt;/strong>：前兩項相當時取能直接照著做的那本。&lt;/li>
&lt;/ol>
&lt;p>「相當」指涵蓋的面向差一個以內，而面向不是憑感覺數的：各篇「為什麼只收這幾本」段開頭寫出的那組分工就是該主題的面向清單——事故檢討那篇開頭列的調查、判讀、制度化就是它的三個面向，起點書覆蓋其中幾個直接可數。&lt;/p>
&lt;p>這個定義有一個循環要知道：那段分工是收錄結果的說明，於是「覆蓋幾個面向」有一部分由收了哪幾本反推，第一層判準因此不容易被反駁。要讓它可反駁，面向清單得先於選書寫出來——目前十九篇都不是這樣做的，那是這套判準已知的弱點。&lt;/p>
&lt;p>這組判準同時適用管理線十一篇、技藝線四篇與財務線四篇。十九篇裡有十六篇的起點書在第一層就定案——涵蓋面拉開差距時，後兩層不會被走到，用它們解釋落選是把判準倒過來套。這十六篇的起點書段裡若還提到證據強度或可操作性也是本篇最高，那是附帶說明它的性質，不是它勝出的理由。&lt;/p>
&lt;p>第二層在財務線的三篇被實際走到：個人理財、會計與財報、總體經濟各有兩本涵蓋面差在一個面向以內，取的是證據來源足以支持「被拿去佐證實際決定」這個用途的那本。落選的三本分別是作者自建的九步驟、從一批公司歸納出的比率門檻、以及作者自建並用自己的操作驗證的模板，共同點是追問依據時指回作者本人；勝出的三本各自指回可以重做的計算、公開的準則、以及其他研究者的紀錄。第三層目前仍未被走到。&lt;/p>
&lt;p>判準本身的例外目前登記三條。技藝線的驗證那篇取 Beck，理由是後面兩本都在跟它對話，那條「歷史先行性」不在這三層裡。財務線有兩條，都跟該線的三層分法綁在一起：解釋層（總體經濟）不比預測準不準、改判「寫不寫得出自己的失效條件」，讀懂層（會計與財報）不把可操作性算進加分，因為給一組可以照抄的比率屬於決定層的事。要新增例外的篇章在這裡登記一列，理由寫在該篇。&lt;/p>
&lt;p>五個位置的起點書用的是另一組判準：哪一本最直接對應該位置當下的主要問題，不看涵蓋面。位置起點書的任務是讓人今天就有東西可讀，不是建立主題座標。&lt;/p>
&lt;p>起點書與「門檻最低的那本」經常不是同一本，這是刻意的——起點書服務的是建立主題座標，門檻最低的書服務的是完全沒有相關經驗的讀者。兩者不同時，主題篇會分別點出來。&lt;/p>
&lt;p>要挑給一群程度不一的人共讀時，取門檻最低的那本而非起點書：共讀的瓶頸是讀得最吃力的那個人，而涵蓋面可以靠討論補，讀不下去不行。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>主題&lt;/th>
 &lt;th>承擔的問題&lt;/th>
 &lt;th>起點書&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="problem-definition/">問題定義與系統思考&lt;/a>&lt;/td>
 &lt;td>同一種問題重複發生、每次解法看起來都合理&lt;/td>
 &lt;td>Thinking in Systems&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="continuous-delivery/">持續交付與交付效能&lt;/a>&lt;/td>
 &lt;td>怎麼知道一個工程做法真的有效、該追什麼指標&lt;/td>
 &lt;td>Accelerate&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="team-design/">組織結構與團隊設計&lt;/a>&lt;/td>
 &lt;td>團隊怎麼切、交接面誰負責、這個團隊還能不能再接一個服務&lt;/td>
 &lt;td>Team Topologies&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="culture-safety/">組織文化與心理安全感&lt;/a>&lt;/td>
 &lt;td>沒人講壞消息、錯誤被藏起來、檢討變成表演&lt;/td>
 &lt;td>The Fearless Organization&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="retention-motivation/">留任、動機與工作環境&lt;/a>&lt;/td>
 &lt;td>人為什麼走、環境怎麼影響產出、回饋怎麼給&lt;/td>
 &lt;td>Peopleware&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="personal-workflow/">個人工作流與工作負荷&lt;/a>&lt;/td>
 &lt;td>事情永遠做不完、清單越來越長、換過幾套方法都維持不久&lt;/td>
 &lt;td>Getting Things Done&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="estimation-decision/">估算、承諾與決策偏誤&lt;/a>&lt;/td>
 &lt;td>估算永遠樂觀、明知做不完還是承諾、風險沒人願意講&lt;/td>
 &lt;td>How Big Things Get Done&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="incident-blame/">事故、歸因與無指責檢討&lt;/a>&lt;/td>
 &lt;td>事故檢討變成找戰犯、同類事故一再發生&lt;/td>
 &lt;td>The Field Guide to Understanding &amp;lsquo;Human Error&amp;rsquo;&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="influence-conversation/">困難對話與無權限影響力&lt;/a>&lt;/td>
 &lt;td>該講的話講不出口、沒有職權時怎麼推動改變&lt;/td>
 &lt;td>Difficult Conversations&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="meeting-facilitation/">會議引導與群體決策&lt;/a>&lt;/td>
 &lt;td>討論收斂不了、提案一出口就變成攻防&lt;/td>
 &lt;td>Facilitator&amp;rsquo;s Guide to Participatory Decision-Making&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="role-transitions/">角色轉換與職涯路徑&lt;/a>&lt;/td>
 &lt;td>不知道 tech lead、EM、staff 一天在做什麼、該不該轉過去&lt;/td>
 &lt;td>The Manager&amp;rsquo;s Path&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>依位置而非依主題選書時，回到 &lt;a href="../">軟體管理與組織書單&lt;/a> 的位置表。&lt;/p>
&lt;h2 id="沒查到課的那十個主題理由分三種">沒查到課的那十個主題，理由分三種&lt;/h2>
&lt;p>十一個主題套用公開課的收錄門檻之後，接得住的只有 &lt;a href="estimation-decision/">估算、承諾與決策偏誤&lt;/a> 一個，課程列在該篇文末；其餘十個沒查到。門檻與這件事為什麼要做，寫在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。&lt;/p>
&lt;p>先講這個結果的權重，因為它決定下面那三組該被讀得多重。這一輪是拿主題名去找同名的課，而估算那個主題接得住，靠的是改用該主題底下的&lt;strong>機制&lt;/strong>去找鄰近學科（誘因結構 → 賽局理論）。那個換法只在那一個主題上跑過，其餘十個一個也沒跑。所以「沒查到」目前的意思是「用主題名沒查到」，而下面的三組是照著各個主題為什麼空歸納出來的整理方式，不是獨立成立的規律——拿它回頭解釋同一批主題當然都通，那不算驗證。&lt;/p>
&lt;p>&lt;strong>學院有對應的課，只是沒有影片&lt;/strong>。這一類離收得進來只差影音這一項。問題定義與系統思考這個主題對應到 MIT Sloan 的 15.871 Introduction to System Dynamics（John Sterman 與 Hazhir Rahmandad），它教的正是該篇起點書那套因果回路與存量流量的建模方法，而它在 OpenCourseWare 上提供的是 readings、recitations 與作業，沒有影片。同樣的形態在技藝線出現過一次，寫在 &lt;a href="../../craft/">工程技藝書單&lt;/a> 的公開課段。&lt;/p>
&lt;p>&lt;strong>市場供給充足而形態不對&lt;/strong>。困難對話、會議引導、個人工作流這三個主題搜得到大量課程，內容集中在技巧演練與商業培訓，跨不過本質恆定這一條——它們的教材綁在當期的工具與流程上。持續交付也暫時放在這一組：以 CI/CD 為題的課程幾乎都是特定工具的操作教學，而該篇起點書要交付的是怎麼判斷一個工程做法確實有效。&lt;strong>這一個最可能被改判&lt;/strong>——它要的機制是研究設計與因果推論，而那個領域的公開課多得很，只是這一輪沒有拿那組詞去搜。困難對話與會議引導同理，它們要的承諾可信度、訊號傳遞與集體決策，正是估算那一篇已經收了的 ECON 159 第 14、15、23 講在講的事。&lt;/p>
&lt;p>&lt;strong>主要在商學院教，而商學院的課最少免費全釋出&lt;/strong>。組織結構、心理安全感、留任動機、事故歸因、角色轉換這五個主題共用這一點。這一組是三組裡最經得起追問的，因為它給得出一個可以拿去核對的規律：三條線裡接得住的六個主題，全部是被經濟系或資訊系的課接住的——Yale 的三門 ECON、台大的經濟與財金、MIT 6.824、劍橋的分散式系統——沒有一個是被管理學院的課接住的。經濟與資工的大學部講堂課是開放式課程錄製計畫的核心，組織行為與談判則是商學院的收入產品。&lt;/p>
&lt;p>它也給得出推翻自己的方式：它預測大學部科目不空缺、商學院科目普遍空缺。目前兩邊都對得上——社會學是大學部科目，Open Yale 的 SOCY 151 有完整影片；組織行為是商學院科目，MIT Sloan 的 15.668 People and Organizations 只有講義與書面作業。重掃時找到一門商學院自己完整釋出的組織類課程，這一條就要改寫。&lt;/p>
&lt;p>要自己去找的話，兩個方向現在就走得了。一是照上面那個換法自己搜：把手上的主題換成它底下的機制再去找鄰近學科，上面每一組都寫出了那些機制詞（研究設計與因果推論、承諾可信度、訊號傳遞、集體決策、因果回路與存量流量），拿它們去搜比拿主題名去搜命中率高。二是本輪盤點刻意排除的那一類——單場演講、研討會錄影、以及沒有課程頁只有播放清單的教學系列——組織與事故這幾個題材的供給正好集中在那裡，它們進不了這個書單是因為收錄門檻要的是課，不是因為它們沒用。&lt;/p>
&lt;p>重掃的第一件事是把這十個主題各跑一次機制式搜尋，觸發條件登記在 &lt;a href="../">軟體管理與組織書單&lt;/a> 的 Backlog。上面的判定做於 2026 年 8 月。&lt;/p></description><content:encoded><![CDATA[<p>主題篇是每本書的完整描述所在，位置路由指過來。每篇先給一本起點書，接著依讀者的經驗與處境分出其他選項，最後說明為什麼這個主題只收這幾本。</p>
<p>書的描述依四個維度——<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>、時效狀態、<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>、讀得出價值的前提，定義與這些判定的來源說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>。</p>
<p>帶著具體症狀來的，直接看下面的主題表：「承擔的問題」欄寫的是症狀而不是術語，對得上哪一列就走哪一篇。中間那一段講的是起點書怎麼被選出來，那是選書方法、不是選書入口。</p>
<p>從這裡直接進主題篇的話，有一組檢查會被跳過：<a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「哪些約束會改變答案」段列出組織規模、人員流動率、協作形態、法規與稽核義務、取得成本，踩到其中任何一項時同一個主題的正確答案會不同。受主管機關監理的組織、以及跨時區的非同步團隊，尤其要先看那一段再選書。</p>
<h2 id="起點書怎麼選出來的">起點書怎麼選出來的</h2>
<p>每篇的起點書用同一組判準，且判準之間有優先序，衝突時往下讓：</p>
<ol>
<li><strong>涵蓋面</strong>：一本書能涵蓋該主題多少個面向（面向＝該篇「為什麼只收這幾本」段開頭列出的那組分工）。優先，因為起點書的任務是建立座標，涵蓋面窄的書會讓讀者以為主題就這麼大。</li>
<li><strong>證據夠不夠支持這個用途</strong>：涵蓋面相當（差一個面向以內）時，取證據來源足以支持「被拿去佐證實際決定」這個用途的那本。這裡排的不是書的好壞，是它的結論可以支持多大範圍的主張——起點書的說法最容易被讀者引用出去，所以這一層看的是引用出去之後對方追問依據時答不答得出來。</li>
<li><strong>可操作性</strong>：前兩項相當時取能直接照著做的那本。</li>
</ol>
<p>「相當」指涵蓋的面向差一個以內，而面向不是憑感覺數的：各篇「為什麼只收這幾本」段開頭寫出的那組分工就是該主題的面向清單——事故檢討那篇開頭列的調查、判讀、制度化就是它的三個面向，起點書覆蓋其中幾個直接可數。</p>
<p>這個定義有一個循環要知道：那段分工是收錄結果的說明，於是「覆蓋幾個面向」有一部分由收了哪幾本反推，第一層判準因此不容易被反駁。要讓它可反駁，面向清單得先於選書寫出來——目前十九篇都不是這樣做的，那是這套判準已知的弱點。</p>
<p>這組判準同時適用管理線十一篇、技藝線四篇與財務線四篇。十九篇裡有十六篇的起點書在第一層就定案——涵蓋面拉開差距時，後兩層不會被走到，用它們解釋落選是把判準倒過來套。這十六篇的起點書段裡若還提到證據強度或可操作性也是本篇最高，那是附帶說明它的性質，不是它勝出的理由。</p>
<p>第二層在財務線的三篇被實際走到：個人理財、會計與財報、總體經濟各有兩本涵蓋面差在一個面向以內，取的是證據來源足以支持「被拿去佐證實際決定」這個用途的那本。落選的三本分別是作者自建的九步驟、從一批公司歸納出的比率門檻、以及作者自建並用自己的操作驗證的模板，共同點是追問依據時指回作者本人；勝出的三本各自指回可以重做的計算、公開的準則、以及其他研究者的紀錄。第三層目前仍未被走到。</p>
<p>判準本身的例外目前登記三條。技藝線的驗證那篇取 Beck，理由是後面兩本都在跟它對話，那條「歷史先行性」不在這三層裡。財務線有兩條，都跟該線的三層分法綁在一起：解釋層（總體經濟）不比預測準不準、改判「寫不寫得出自己的失效條件」，讀懂層（會計與財報）不把可操作性算進加分，因為給一組可以照抄的比率屬於決定層的事。要新增例外的篇章在這裡登記一列，理由寫在該篇。</p>
<p>五個位置的起點書用的是另一組判準：哪一本最直接對應該位置當下的主要問題，不看涵蓋面。位置起點書的任務是讓人今天就有東西可讀，不是建立主題座標。</p>
<p>起點書與「門檻最低的那本」經常不是同一本，這是刻意的——起點書服務的是建立主題座標，門檻最低的書服務的是完全沒有相關經驗的讀者。兩者不同時，主題篇會分別點出來。</p>
<p>要挑給一群程度不一的人共讀時，取門檻最低的那本而非起點書：共讀的瓶頸是讀得最吃力的那個人，而涵蓋面可以靠討論補，讀不下去不行。</p>
<table>
  <thead>
      <tr>
          <th>主題</th>
          <th>承擔的問題</th>
          <th>起點書</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="problem-definition/">問題定義與系統思考</a></td>
          <td>同一種問題重複發生、每次解法看起來都合理</td>
          <td>Thinking in Systems</td>
      </tr>
      <tr>
          <td><a href="continuous-delivery/">持續交付與交付效能</a></td>
          <td>怎麼知道一個工程做法真的有效、該追什麼指標</td>
          <td>Accelerate</td>
      </tr>
      <tr>
          <td><a href="team-design/">組織結構與團隊設計</a></td>
          <td>團隊怎麼切、交接面誰負責、這個團隊還能不能再接一個服務</td>
          <td>Team Topologies</td>
      </tr>
      <tr>
          <td><a href="culture-safety/">組織文化與心理安全感</a></td>
          <td>沒人講壞消息、錯誤被藏起來、檢討變成表演</td>
          <td>The Fearless Organization</td>
      </tr>
      <tr>
          <td><a href="retention-motivation/">留任、動機與工作環境</a></td>
          <td>人為什麼走、環境怎麼影響產出、回饋怎麼給</td>
          <td>Peopleware</td>
      </tr>
      <tr>
          <td><a href="personal-workflow/">個人工作流與工作負荷</a></td>
          <td>事情永遠做不完、清單越來越長、換過幾套方法都維持不久</td>
          <td>Getting Things Done</td>
      </tr>
      <tr>
          <td><a href="estimation-decision/">估算、承諾與決策偏誤</a></td>
          <td>估算永遠樂觀、明知做不完還是承諾、風險沒人願意講</td>
          <td>How Big Things Get Done</td>
      </tr>
      <tr>
          <td><a href="incident-blame/">事故、歸因與無指責檢討</a></td>
          <td>事故檢討變成找戰犯、同類事故一再發生</td>
          <td>The Field Guide to Understanding &lsquo;Human Error&rsquo;</td>
      </tr>
      <tr>
          <td><a href="influence-conversation/">困難對話與無權限影響力</a></td>
          <td>該講的話講不出口、沒有職權時怎麼推動改變</td>
          <td>Difficult Conversations</td>
      </tr>
      <tr>
          <td><a href="meeting-facilitation/">會議引導與群體決策</a></td>
          <td>討論收斂不了、提案一出口就變成攻防</td>
          <td>Facilitator&rsquo;s Guide to Participatory Decision-Making</td>
      </tr>
      <tr>
          <td><a href="role-transitions/">角色轉換與職涯路徑</a></td>
          <td>不知道 tech lead、EM、staff 一天在做什麼、該不該轉過去</td>
          <td>The Manager&rsquo;s Path</td>
      </tr>
  </tbody>
</table>
<p>依位置而非依主題選書時，回到 <a href="../">軟體管理與組織書單</a> 的位置表。</p>
<h2 id="沒查到課的那十個主題理由分三種">沒查到課的那十個主題，理由分三種</h2>
<p>十一個主題套用公開課的收錄門檻之後，接得住的只有 <a href="estimation-decision/">估算、承諾與決策偏誤</a> 一個，課程列在該篇文末；其餘十個沒查到。門檻與這件事為什麼要做，寫在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。</p>
<p>先講這個結果的權重，因為它決定下面那三組該被讀得多重。這一輪是拿主題名去找同名的課，而估算那個主題接得住，靠的是改用該主題底下的<strong>機制</strong>去找鄰近學科（誘因結構 → 賽局理論）。那個換法只在那一個主題上跑過，其餘十個一個也沒跑。所以「沒查到」目前的意思是「用主題名沒查到」，而下面的三組是照著各個主題為什麼空歸納出來的整理方式，不是獨立成立的規律——拿它回頭解釋同一批主題當然都通，那不算驗證。</p>
<p><strong>學院有對應的課，只是沒有影片</strong>。這一類離收得進來只差影音這一項。問題定義與系統思考這個主題對應到 MIT Sloan 的 15.871 Introduction to System Dynamics（John Sterman 與 Hazhir Rahmandad），它教的正是該篇起點書那套因果回路與存量流量的建模方法，而它在 OpenCourseWare 上提供的是 readings、recitations 與作業，沒有影片。同樣的形態在技藝線出現過一次，寫在 <a href="../../craft/">工程技藝書單</a> 的公開課段。</p>
<p><strong>市場供給充足而形態不對</strong>。困難對話、會議引導、個人工作流這三個主題搜得到大量課程，內容集中在技巧演練與商業培訓，跨不過本質恆定這一條——它們的教材綁在當期的工具與流程上。持續交付也暫時放在這一組：以 CI/CD 為題的課程幾乎都是特定工具的操作教學，而該篇起點書要交付的是怎麼判斷一個工程做法確實有效。<strong>這一個最可能被改判</strong>——它要的機制是研究設計與因果推論，而那個領域的公開課多得很，只是這一輪沒有拿那組詞去搜。困難對話與會議引導同理，它們要的承諾可信度、訊號傳遞與集體決策，正是估算那一篇已經收了的 ECON 159 第 14、15、23 講在講的事。</p>
<p><strong>主要在商學院教，而商學院的課最少免費全釋出</strong>。組織結構、心理安全感、留任動機、事故歸因、角色轉換這五個主題共用這一點。這一組是三組裡最經得起追問的，因為它給得出一個可以拿去核對的規律：三條線裡接得住的六個主題，全部是被經濟系或資訊系的課接住的——Yale 的三門 ECON、台大的經濟與財金、MIT 6.824、劍橋的分散式系統——沒有一個是被管理學院的課接住的。經濟與資工的大學部講堂課是開放式課程錄製計畫的核心，組織行為與談判則是商學院的收入產品。</p>
<p>它也給得出推翻自己的方式：它預測大學部科目不空缺、商學院科目普遍空缺。目前兩邊都對得上——社會學是大學部科目，Open Yale 的 SOCY 151 有完整影片；組織行為是商學院科目，MIT Sloan 的 15.668 People and Organizations 只有講義與書面作業。重掃時找到一門商學院自己完整釋出的組織類課程，這一條就要改寫。</p>
<p>要自己去找的話，兩個方向現在就走得了。一是照上面那個換法自己搜：把手上的主題換成它底下的機制再去找鄰近學科，上面每一組都寫出了那些機制詞（研究設計與因果推論、承諾可信度、訊號傳遞、集體決策、因果回路與存量流量），拿它們去搜比拿主題名去搜命中率高。二是本輪盤點刻意排除的那一類——單場演講、研討會錄影、以及沒有課程頁只有播放清單的教學系列——組織與事故這幾個題材的供給正好集中在那裡，它們進不了這個書單是因為收錄門檻要的是課，不是因為它們沒用。</p>
<p>重掃的第一件事是把這十個主題各跑一次機制式搜尋，觸發條件登記在 <a href="../">軟體管理與組織書單</a> 的 Backlog。上面的判定做於 2026 年 8 月。</p>
]]></content:encoded></item><item><title>問題定義與系統思考</title><link>https://tarrragon.github.io/blog/books/software-management/topics/problem-definition/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/problem-definition/</guid><description>&lt;p>這個主題處理兩件互相扣住的事：手上這個問題到底是什麼，以及動作與結果之間隔著什麼。多數組織的重複失敗來自兩者之一——要嘛解的是錯的問題，要嘛解對了問題但介入點在迴路上效果最弱的位置。兩種都不會在動手時報錯。這兩件事都在動手之前決定成敗，因此這個主題適合在職涯早期就讀，而且不需要管理職權才用得上。&lt;/p>
&lt;p>這裡的書都不談軟體技術，轉譯要自己做。它們的共通特徵是概念少、應用面廣，因此讀完的當下感覺抽象，真正的價值在幾個月後遇到具體情境時才兌現。&lt;/p>
&lt;p>處境相容性這一項，前三本查過而沒有列出限制：它們的推導分別落在問題陳述的結構、系統的存量與回饋迴路、以及組織對資訊的反應方式上，成立與否不取決於有沒有職級制度、成員待多久、大家在不在同一個時區、事故後有沒有法定追責義務。第四本有一項，寫在該節。&lt;/p>
&lt;h2 id="起點是-thinking-in-systems">起點是 Thinking in Systems&lt;/h2>
&lt;p>Donella Meadows 的《Thinking in Systems》給的是語言本身，本篇另外三本——《Are Your Lights On?》、溫伯格第 1 卷、《穀倉效應》——都在這套語言裡運作。它用存量、流量、回饋迴路三個元件把整組詞彙鋪完，例子刻意選日常情境——浴缸水位、庫存補貨、兄弟互推——每個例子都在示範結構如何決定行為。&lt;a href="../">起點書判準&lt;/a>的第一項問的是涵蓋面，而把整組概念鋪完的只有它。門檻最低的那本不是它，是下一節的《Are Your Lights On?》；要挑給一群程度不一的人共讀時取後者。&lt;/p>
&lt;p>書中最直接可用的是槓桿點排序。Meadows 把介入系統的方式從效果最弱到最強排成十二層：參數調整在最底層，往上依序是資訊流、規則、目標、典範。這個排序可以直接拿來檢查自己的動作落在哪一層——調整 sprint 長度是參數，改變誰能看到哪些資料是資訊流，改變「延期要付什麼代價」是規則。三者花的力氣接近，效果差好幾個量級。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是理論建構（系統動力學）加上跨組織案例，不是統計。因此它適合用來組織自己的觀察，用來說服別人時力道有限。時效上，書中的環境與資源案例引用的是 1990 年代的數據，那些數字已經過時；存量流量、回饋迴路與槓桿點排序這幾組概念沒有發現依賴時代條件的部分。它要有一個標的才排得出高下：手上有一個反覆出現、每次處理完又回來的問題。十二層槓桿點要壓在那樣一個問題上才排得出高下——單看排序本身，每一層都同樣有道理。作者是《成長的極限》主要作者、系統動力學創始人 Jay Forrester 的學生。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557">Amazon（Thinking in Systems: A Primer）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010702990">博客來（系統思考：克服盲點、面對複雜性、見樹又見林的整體思考）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="問題陳述本身出錯時讀-are-your-lights-on">問題陳述本身出錯時讀 Are Your Lights On&lt;/h2>
&lt;p>Donald Gause 與 Gerald Weinberg 的《Are Your Lights On?》處理比「怎麼解」更前面的問題：這個問題是什麼、是誰的問題、真的想解嗎。它給的定義短到可以背——問題是期望與感受之間的落差——整本書都在示範這個定義有多難正確套用。書名來自隧道口該不該立牌提醒駕駛開燈的案例，以及牌子怎麼寫才不會製造新問題。&lt;/p>
&lt;p>它在這個主題的位置是前置動作。系統思考讓讀者看見迴路，但若一開始鎖定的問題陳述就錯了，畫出來的迴路只會精確描述一件不重要的事。書中反覆出現的一句話是這本書的主軸：每一個解決方案都是下一個問題的根源。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗與教學經驗，形式是寓言與短案例而非資料。時效上，書中案例的場景（電梯、隧道、辦公大樓）與軟體無關但也不會過時，因為它們示範的是問題陳述的結構而非任何技術條件。這本一百多頁、有插圖，讀完花的時間在本篇最短。讀得出價值的前提標不出具體條件：接到一個需求、覺得哪裡不對但說不出來的時候就可以讀。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Are-Your-Lights-Figure-Problem/dp/0932633161">Amazon（Are Your Lights On?: How to Figure Out What the Problem Really Is）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010754502">博客來（你想通了嗎？解決問題之前，你該思考的 6 件事）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想看軟體組織的具體形狀時讀溫伯格第-1-卷">想看軟體組織的具體形狀時讀溫伯格第 1 卷&lt;/h2>
&lt;p>Weinberg 的《Quality Software Management, Vol. 1: Systems Thinking》把同一組概念放進軟體組織。它的工具是效應圖，把因果與回饋畫成節點與箭頭，用來拆解非線性效應。最常被拿來示範的是 Brooks&amp;rsquo;s Law——對已經落後的專案加人只會更落後，出自 Brooks 的《人月神話》，完整說明在 &lt;a href="../team-design/">組織結構與團隊設計&lt;/a>。效應圖的貢獻是把那條定律展開成可以逐段檢查的迴路：加人導致老手花時間帶新人、產出短期下降、進度更落後、壓力上升、品質下降、缺陷增加、修復佔用時間、進度再落後。定律說明會發生什麼，迴路指出在哪一段可以介入。&lt;/p>
&lt;p>另一條主線是六種文化模式，從模式 0「渾然不知」到模式 5「全面關照」。它跟 CMM 成熟度等級關注的東西不同——CMM 看流程文件與可重複性，這套分類看的是人在裡面怎麼互動、遇到壞消息時組織會發生什麼。用來定位自己所在的組織處於哪個模式，比用來規劃改進路線直接。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗，書中自述取材自他經手的組織。時效上，書中的專案情境預設以年為單位的交付週期與瀑布式階段劃分，讀者要自行折算到現在的節奏；文化模式與效應圖處理的是組織對資訊的反應方式，不依賴交付節奏。六種模式要有第二個對照組才立體：只待過一間公司的人容易把那間的做事方式當成唯一的做事方式。讀得出價值的前提因此是待過兩個以上文化明顯不同的組織。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226">Amazon（Quality Software Management: Systems Thinking）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010341309">博客來（溫伯格的軟體管理學：系統化思考，第 1 卷）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想看這些機制在真實組織裡跑完一輪時讀穀倉效應">想看這些機制在真實組織裡跑完一輪時讀穀倉效應&lt;/h2>
&lt;p>Gillian Tett 的《The Silo Effect》是本篇唯一的深度個案，八個組織各被完整報導過一輪。它跟前三本的分工在證據形態而非主題：那三本給概念與判準，這本給同一組機制在真實組織裡運作好幾年的樣子，包括當事人當下怎麼想、事後怎麼解釋。&lt;/p>
&lt;p>作者是社會人類學博士出身的《金融時報》記者，核心論點來自那個訓練：&lt;strong>筒倉是分類系統的產物，而分類系統決定了組織看得見什麼&lt;/strong>。這跟「部門之間要多溝通」是不同的診斷。UBS 那一章最能說明差別——信用、市場、作業三組風控各管各的固然是事實，但更關鍵的是 CDO 在他們的分類裡被歸為 AAA 資產，而不是風險中等的房貸包裹。清點曝險的時候，那筆風險在它被歸檔的類別下根本不顯示為風險——它不是被忽略的。人可以互相講話，分類不會因此改變。&lt;/p>
&lt;p>這一點接得上 Meadows 槓桿點排序的上層——典範是效果最強的幾個介入位置之一。Meadows 用兩頁講完的那一層，這本書用八個個案演示它怎麼運作，以及為什麼身在裡面的人看不見自己的分類。八個案例分兩組：Sony、UBS 與英格蘭銀行是分類造成的失敗，紐約市府、芝加哥警局、克里夫蘭診所、Facebook 與 BlueMountain 對沖基金是嘗試打破的一方。&lt;/p>
&lt;p>這本書有一個明確的缺口，而補它的書在別的主題。IMF《Finance &amp;amp; Development》2015 年 12 月號（Vol. 52, No. 4）的書評 &lt;a href="https://www.imf.org/external/pubs/ft/fandd/2015/12/book3.htm">Kick the Buckets&lt;/a>（Geoff Mulgan 撰，時任英國創新基金會 Nesta 執行長）列出三項缺口，第一項是：書中沒有一套理論說明什麼時候水平結構優於垂直結構。拆掉筒倉有它自己的代價——責任變模糊，或者把太多垂直邊界換成一樣多的水平邊界——而判斷這件事需要的判準不在這本書裡。它在 &lt;a href="../team-design/">組織結構與團隊設計&lt;/a> 的 Team Topologies：團隊認知負荷有上限，因此邊界是承重結構而非官僚產物。兩本一起讀才完整，這本負責診斷，那本負責邊界該畫在哪。&lt;/p>
&lt;p>證據來源是跨組織案例，形式是記者對八個組織的深度報導，框架取自人類學（她大量引用 Bourdieu 的文化再生產與慣習）。時效上，這本書帶出一種個案型書籍特有的風險：&lt;strong>過期的不是論證，是案例本身還在動&lt;/strong>。Tett 在 2015 年把 Facebook 的反筒倉設計（新人 bootcamp、輪調、hackathon）放在正面那一組，而後續十年的公開紀錄讓那一章很難照原樣讀。讀個案型的書要比讀理論書多問一句：這個案例後來怎麼了。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，八個個案全是部門已經分化的大型組織——跨國銀行、中央銀行、市政府、大型醫院、上市科技公司——書中的機制要有數個彼此看不見對方的單位才長得出來。部門還沒分化的小組織讀它，讀到的是規模長上去之後會遇到的問題，不是當下用得上的診斷。&lt;/p>
&lt;p>書末的結語把前面的個案收攏成一組人類學原則，形式是通則而非步驟。這決定了它的用途落在診斷與辨認：要的是照著做的順序時，材料在別的書裡。讀得出價值的前提是：待過一個部門各自都合理、合起來卻做出蠢事的組織。認得出那個形狀，八個案例是八次確認；認不出，它們是八則商業報導。繁體中文版《穀倉效應》由三采文化 2016 年出版、林力敏譯；2026 年 3 月的十週年紀念版仍是三采文化、同一位譯者；比對兩版目錄，章節結構與原書一致，新增的是中文推薦序而非回頭處理個案後續的章節或後記——上一段那句「這個案例後來怎麼了」對紀念版一樣要問。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Silo-Effect-Expertise-Breaking-Barriers/dp/1451644744">Amazon（The Silo Effect: The Peril of Expertise and the Promise of Breaking Down Barriers）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0011045837">博客來（穀倉效應【暢銷十週年紀念版】）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010703860">博客來（穀倉效應，2016 年版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>前三本各處理推導鏈的一段：問題陳述（Are Your Lights On）、通用的系統結構語言（Thinking in Systems）、軟體組織的具體形狀（溫伯格第 1 卷）。三段接得起來，任何一本都不能替代另外兩本。&lt;/p>
&lt;p>第四本不在那條鏈上，它換的是證據形態。前三本都是概念與判準，讀完當下最常見的反應是覺得抽象；《穀倉效應》給的是同一組機制在八個真實組織裡跑好幾年的樣子，用途是把抽象的部分接上畫面。深度個案的位置由這本承擔，而個案正是縮短「讀完」到「用得上」那段距離的材料。&lt;/p>
&lt;p>系統思考的書多半分成兩類：需要數學與模擬工具的系統動力學教材，以及把回饋迴路簡化成勵志語言的商管書。前者的門檻超出這個主題想服務的讀者，後者拿掉了讓概念可用的部分——分辨的方法是找有沒有槓桿點這種可以拿來檢查自己動作的排序，只講「凡事都是系統」的沒有。&lt;/p>
&lt;p>Tett 另有《穀倉效應2：未來思考》（原書 Anthro-Vision）的繁體中文版在架，本書單未評估它在這個主題裡承擔什麼角色——它把同一套人類學視角推廣到個人與市場判斷，是不是仍在組織分類這條線上，要讀過才判得出來。&lt;/p>
&lt;p>再往外擴會進入決策科學與專案風險，那些分屬 &lt;a href="../estimation-decision/">估算、承諾與決策偏誤&lt;/a>。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而它是三種成因裡最接近有解的一種——學院有對應的課（MIT Sloan 的 15.871 Introduction to System Dynamics），只是它在 OpenCourseWare 上沒有影片。整條線的供給狀況寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理兩件互相扣住的事：手上這個問題到底是什麼，以及動作與結果之間隔著什麼。多數組織的重複失敗來自兩者之一——要嘛解的是錯的問題，要嘛解對了問題但介入點在迴路上效果最弱的位置。兩種都不會在動手時報錯。這兩件事都在動手之前決定成敗，因此這個主題適合在職涯早期就讀，而且不需要管理職權才用得上。</p>
<p>這裡的書都不談軟體技術，轉譯要自己做。它們的共通特徵是概念少、應用面廣，因此讀完的當下感覺抽象，真正的價值在幾個月後遇到具體情境時才兌現。</p>
<p>處境相容性這一項，前三本查過而沒有列出限制：它們的推導分別落在問題陳述的結構、系統的存量與回饋迴路、以及組織對資訊的反應方式上，成立與否不取決於有沒有職級制度、成員待多久、大家在不在同一個時區、事故後有沒有法定追責義務。第四本有一項，寫在該節。</p>
<h2 id="起點是-thinking-in-systems">起點是 Thinking in Systems</h2>
<p>Donella Meadows 的《Thinking in Systems》給的是語言本身，本篇另外三本——《Are Your Lights On?》、溫伯格第 1 卷、《穀倉效應》——都在這套語言裡運作。它用存量、流量、回饋迴路三個元件把整組詞彙鋪完，例子刻意選日常情境——浴缸水位、庫存補貨、兄弟互推——每個例子都在示範結構如何決定行為。<a href="../">起點書判準</a>的第一項問的是涵蓋面，而把整組概念鋪完的只有它。門檻最低的那本不是它，是下一節的《Are Your Lights On?》；要挑給一群程度不一的人共讀時取後者。</p>
<p>書中最直接可用的是槓桿點排序。Meadows 把介入系統的方式從效果最弱到最強排成十二層：參數調整在最底層，往上依序是資訊流、規則、目標、典範。這個排序可以直接拿來檢查自己的動作落在哪一層——調整 sprint 長度是參數，改變誰能看到哪些資料是資訊流，改變「延期要付什麼代價」是規則。三者花的力氣接近，效果差好幾個量級。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是理論建構（系統動力學）加上跨組織案例，不是統計。因此它適合用來組織自己的觀察，用來說服別人時力道有限。時效上，書中的環境與資源案例引用的是 1990 年代的數據，那些數字已經過時；存量流量、回饋迴路與槓桿點排序這幾組概念沒有發現依賴時代條件的部分。它要有一個標的才排得出高下：手上有一個反覆出現、每次處理完又回來的問題。十二層槓桿點要壓在那樣一個問題上才排得出高下——單看排序本身，每一層都同樣有道理。作者是《成長的極限》主要作者、系統動力學創始人 Jay Forrester 的學生。</p>
<ul>
<li><a href="https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557">Amazon（Thinking in Systems: A Primer）</a></li>
<li><a href="https://www.books.com.tw/products/0010702990">博客來（系統思考：克服盲點、面對複雜性、見樹又見林的整體思考）</a></li>
</ul>
<h2 id="問題陳述本身出錯時讀-are-your-lights-on">問題陳述本身出錯時讀 Are Your Lights On</h2>
<p>Donald Gause 與 Gerald Weinberg 的《Are Your Lights On?》處理比「怎麼解」更前面的問題：這個問題是什麼、是誰的問題、真的想解嗎。它給的定義短到可以背——問題是期望與感受之間的落差——整本書都在示範這個定義有多難正確套用。書名來自隧道口該不該立牌提醒駕駛開燈的案例，以及牌子怎麼寫才不會製造新問題。</p>
<p>它在這個主題的位置是前置動作。系統思考讓讀者看見迴路，但若一開始鎖定的問題陳述就錯了，畫出來的迴路只會精確描述一件不重要的事。書中反覆出現的一句話是這本書的主軸：每一個解決方案都是下一個問題的根源。</p>
<p>證據來源是跨客戶的顧問經驗與教學經驗，形式是寓言與短案例而非資料。時效上，書中案例的場景（電梯、隧道、辦公大樓）與軟體無關但也不會過時，因為它們示範的是問題陳述的結構而非任何技術條件。這本一百多頁、有插圖，讀完花的時間在本篇最短。讀得出價值的前提標不出具體條件：接到一個需求、覺得哪裡不對但說不出來的時候就可以讀。</p>
<ul>
<li><a href="https://www.amazon.com/Are-Your-Lights-Figure-Problem/dp/0932633161">Amazon（Are Your Lights On?: How to Figure Out What the Problem Really Is）</a></li>
<li><a href="https://www.books.com.tw/products/0010754502">博客來（你想通了嗎？解決問題之前，你該思考的 6 件事）</a></li>
</ul>
<h2 id="想看軟體組織的具體形狀時讀溫伯格第-1-卷">想看軟體組織的具體形狀時讀溫伯格第 1 卷</h2>
<p>Weinberg 的《Quality Software Management, Vol. 1: Systems Thinking》把同一組概念放進軟體組織。它的工具是效應圖，把因果與回饋畫成節點與箭頭，用來拆解非線性效應。最常被拿來示範的是 Brooks&rsquo;s Law——對已經落後的專案加人只會更落後，出自 Brooks 的《人月神話》，完整說明在 <a href="../team-design/">組織結構與團隊設計</a>。效應圖的貢獻是把那條定律展開成可以逐段檢查的迴路：加人導致老手花時間帶新人、產出短期下降、進度更落後、壓力上升、品質下降、缺陷增加、修復佔用時間、進度再落後。定律說明會發生什麼，迴路指出在哪一段可以介入。</p>
<p>另一條主線是六種文化模式，從模式 0「渾然不知」到模式 5「全面關照」。它跟 CMM 成熟度等級關注的東西不同——CMM 看流程文件與可重複性，這套分類看的是人在裡面怎麼互動、遇到壞消息時組織會發生什麼。用來定位自己所在的組織處於哪個模式，比用來規劃改進路線直接。</p>
<p>證據來源是跨客戶的顧問經驗，書中自述取材自他經手的組織。時效上，書中的專案情境預設以年為單位的交付週期與瀑布式階段劃分，讀者要自行折算到現在的節奏；文化模式與效應圖處理的是組織對資訊的反應方式，不依賴交付節奏。六種模式要有第二個對照組才立體：只待過一間公司的人容易把那間的做事方式當成唯一的做事方式。讀得出價值的前提因此是待過兩個以上文化明顯不同的組織。</p>
<ul>
<li><a href="https://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226">Amazon（Quality Software Management: Systems Thinking）</a></li>
<li><a href="https://www.books.com.tw/products/0010341309">博客來（溫伯格的軟體管理學：系統化思考，第 1 卷）</a></li>
</ul>
<h2 id="想看這些機制在真實組織裡跑完一輪時讀穀倉效應">想看這些機制在真實組織裡跑完一輪時讀穀倉效應</h2>
<p>Gillian Tett 的《The Silo Effect》是本篇唯一的深度個案，八個組織各被完整報導過一輪。它跟前三本的分工在證據形態而非主題：那三本給概念與判準，這本給同一組機制在真實組織裡運作好幾年的樣子，包括當事人當下怎麼想、事後怎麼解釋。</p>
<p>作者是社會人類學博士出身的《金融時報》記者，核心論點來自那個訓練：<strong>筒倉是分類系統的產物，而分類系統決定了組織看得見什麼</strong>。這跟「部門之間要多溝通」是不同的診斷。UBS 那一章最能說明差別——信用、市場、作業三組風控各管各的固然是事實，但更關鍵的是 CDO 在他們的分類裡被歸為 AAA 資產，而不是風險中等的房貸包裹。清點曝險的時候，那筆風險在它被歸檔的類別下根本不顯示為風險——它不是被忽略的。人可以互相講話，分類不會因此改變。</p>
<p>這一點接得上 Meadows 槓桿點排序的上層——典範是效果最強的幾個介入位置之一。Meadows 用兩頁講完的那一層，這本書用八個個案演示它怎麼運作，以及為什麼身在裡面的人看不見自己的分類。八個案例分兩組：Sony、UBS 與英格蘭銀行是分類造成的失敗，紐約市府、芝加哥警局、克里夫蘭診所、Facebook 與 BlueMountain 對沖基金是嘗試打破的一方。</p>
<p>這本書有一個明確的缺口，而補它的書在別的主題。IMF《Finance &amp; Development》2015 年 12 月號（Vol. 52, No. 4）的書評 <a href="https://www.imf.org/external/pubs/ft/fandd/2015/12/book3.htm">Kick the Buckets</a>（Geoff Mulgan 撰，時任英國創新基金會 Nesta 執行長）列出三項缺口，第一項是：書中沒有一套理論說明什麼時候水平結構優於垂直結構。拆掉筒倉有它自己的代價——責任變模糊，或者把太多垂直邊界換成一樣多的水平邊界——而判斷這件事需要的判準不在這本書裡。它在 <a href="../team-design/">組織結構與團隊設計</a> 的 Team Topologies：團隊認知負荷有上限，因此邊界是承重結構而非官僚產物。兩本一起讀才完整，這本負責診斷，那本負責邊界該畫在哪。</p>
<p>證據來源是跨組織案例，形式是記者對八個組織的深度報導，框架取自人類學（她大量引用 Bourdieu 的文化再生產與慣習）。時效上，這本書帶出一種個案型書籍特有的風險：<strong>過期的不是論證，是案例本身還在動</strong>。Tett 在 2015 年把 Facebook 的反筒倉設計（新人 bootcamp、輪調、hackathon）放在正面那一組，而後續十年的公開紀錄讓那一章很難照原樣讀。讀個案型的書要比讀理論書多問一句：這個案例後來怎麼了。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，八個個案全是部門已經分化的大型組織——跨國銀行、中央銀行、市政府、大型醫院、上市科技公司——書中的機制要有數個彼此看不見對方的單位才長得出來。部門還沒分化的小組織讀它，讀到的是規模長上去之後會遇到的問題，不是當下用得上的診斷。</p>
<p>書末的結語把前面的個案收攏成一組人類學原則，形式是通則而非步驟。這決定了它的用途落在診斷與辨認：要的是照著做的順序時，材料在別的書裡。讀得出價值的前提是：待過一個部門各自都合理、合起來卻做出蠢事的組織。認得出那個形狀，八個案例是八次確認；認不出，它們是八則商業報導。繁體中文版《穀倉效應》由三采文化 2016 年出版、林力敏譯；2026 年 3 月的十週年紀念版仍是三采文化、同一位譯者；比對兩版目錄，章節結構與原書一致，新增的是中文推薦序而非回頭處理個案後續的章節或後記——上一段那句「這個案例後來怎麼了」對紀念版一樣要問。</p>
<ul>
<li><a href="https://www.amazon.com/Silo-Effect-Expertise-Breaking-Barriers/dp/1451644744">Amazon（The Silo Effect: The Peril of Expertise and the Promise of Breaking Down Barriers）</a></li>
<li><a href="https://www.books.com.tw/products/0011045837">博客來（穀倉效應【暢銷十週年紀念版】）</a></li>
<li><a href="https://www.books.com.tw/products/0010703860">博客來（穀倉效應，2016 年版）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>前三本各處理推導鏈的一段：問題陳述（Are Your Lights On）、通用的系統結構語言（Thinking in Systems）、軟體組織的具體形狀（溫伯格第 1 卷）。三段接得起來，任何一本都不能替代另外兩本。</p>
<p>第四本不在那條鏈上，它換的是證據形態。前三本都是概念與判準，讀完當下最常見的反應是覺得抽象；《穀倉效應》給的是同一組機制在八個真實組織裡跑好幾年的樣子，用途是把抽象的部分接上畫面。深度個案的位置由這本承擔，而個案正是縮短「讀完」到「用得上」那段距離的材料。</p>
<p>系統思考的書多半分成兩類：需要數學與模擬工具的系統動力學教材，以及把回饋迴路簡化成勵志語言的商管書。前者的門檻超出這個主題想服務的讀者，後者拿掉了讓概念可用的部分——分辨的方法是找有沒有槓桿點這種可以拿來檢查自己動作的排序，只講「凡事都是系統」的沒有。</p>
<p>Tett 另有《穀倉效應2：未來思考》（原書 Anthro-Vision）的繁體中文版在架，本書單未評估它在這個主題裡承擔什麼角色——它把同一套人類學視角推廣到個人與市場判斷，是不是仍在組織分類這條線上，要讀過才判得出來。</p>
<p>再往外擴會進入決策科學與專案風險，那些分屬 <a href="../estimation-decision/">估算、承諾與決策偏誤</a>。</p>
<p>這個主題沒查到可以收的公開課，而它是三種成因裡最接近有解的一種——學院有對應的課（MIT Sloan 的 15.871 Introduction to System Dynamics），只是它在 OpenCourseWare 上沒有影片。整條線的供給狀況寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>看見迴路之後，控制系統還需要知道實際狀況與有能力行動。量測那一半走 <a href="../continuous-delivery/">持續交付與交付效能</a>，那裡的書提供有統計佐證的指標。結構調整那一半走 <a href="../team-design/">組織結構與團隊設計</a>。</p>
<p>如果讀完的感覺是「我看得見迴路，但組織裡沒人願意承認迴路存在」，那是另一組問題，走 <a href="../culture-safety/">組織文化與心理安全感</a>。</p>
]]></content:encoded></item><item><title>軟體管理與組織書單</title><link>https://tarrragon.github.io/blog/books/software-management/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/</guid><description>&lt;p>這條線涵蓋受僱於某個組織、責任範圍從只對自己的產出到對整個組織結構的五種位置。位置決定當下煩惱什麼：初中級工程師煩惱怎麼讓自己的產出被信任，Tech Lead 煩惱怎麼讓別人的產出達標，EM 煩惱人留不留得住，管理管理者煩惱組織切法對不對。這些煩惱各自對應不同的書，但涵蓋的知識領域大量重疊——同一本談心理安全感的書，四個位置都用得到，用法完全不同。&lt;/p>
&lt;p>這條線不處理技藝——程式怎麼寫、怎麼改得動、怎麼驗證，那些在 &lt;a href="../craft/">工程技藝&lt;/a>。兩條線的失敗互相看不見，因此分開。另有一條線 &lt;a href="../finance/">財務與投資&lt;/a> 處理的是自己的資本與現金流，跟這裡的分界不是同一個軸：那條線的決定不在工作場域裡發生，本篇的位置表與規模、流動率這些約束在那裡都不適用。&lt;/p>
&lt;p>書的完整描述住在主題篇，位置與主題兩張路由表只給書名與連結。這個分工的理由是同一本書會出現在多個位置的建議清單裡，若每個位置各寫一份說明，幾份說明會隨時間漂移成幾種不同的講法。&lt;/p>
&lt;h2 id="完全不熟悉這個領域時先讀這一本">完全不熟悉這個領域時先讀這一本&lt;/h2>
&lt;p>&lt;a href="topics/continuous-delivery/">Accelerate&lt;/a> 是這條線的單一起點。選它的理由是它同時滿足兩個條件，而與品質排名無關：結論建立在數萬份跨組織調查上，因此可以拿來支持實際決定；而且它的四項指標已經是業界共同語言，讀完之後其他書的討論才有共同座標。&lt;/p>
&lt;p>它的限制要先知道：它談的是組織層級的交付效能，不談個人怎麼寫程式、也不談怎麼跟人相處。如果目前的困擾是「我下個月開始要帶人」「我想知道管理職實際在做什麼」「我不知道怎麼跟主管講壞消息」或「我不知道自己夠不夠格升等」，這本書不會回答，直接往下面的位置表走。&lt;/p>
&lt;h2 id="依當下的位置選書">依當下的位置選書&lt;/h2>
&lt;p>位置的判準是對什麼負責，不是職稱——同一個職稱在大企業與小公司對應的責任範圍經常不同。判準的操作版本是：&lt;strong>交不出來的時候，誰會被問&lt;/strong>。下表給每個位置的起點書；那個位置一天實際在處理什麼、在有階梯與沒階梯的組織裡問題差在哪、往相鄰位置移動前該預習什麼，在 &lt;a href="roles/">依位置選書&lt;/a> 的五篇裡。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>位置&lt;/th>
 &lt;th>當下的主要問題&lt;/th>
 &lt;th>起點&lt;/th>
 &lt;th>主要主題&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="roles/own-output/">只對自己的產出負責&lt;/a>&lt;/td>
 &lt;td>怎麼讓產出被信任、怎麼知道自己下一步該補什麼&lt;/td>
 &lt;td>The Software Engineer&amp;rsquo;s Guidebook&lt;/td>
 &lt;td>&lt;a href="topics/role-transitions/">角色轉換與職涯路徑&lt;/a>、&lt;a href="topics/problem-definition/">問題定義與系統思考&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/technical-quality/">對技術品質負責、不帶人&lt;/a>&lt;/td>
 &lt;td>沒有指揮權時怎麼讓別人照著做、技術決策怎麼被採納&lt;/td>
 &lt;td>The Staff Engineer&amp;rsquo;s Path&lt;/td>
 &lt;td>&lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a>、&lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/others-output/">對別人的產出負責（Tech Lead）&lt;/a>&lt;/td>
 &lt;td>怎麼讓團隊的產出達標而不變成自己重寫&lt;/td>
 &lt;td>The Manager&amp;rsquo;s Path&lt;/td>
 &lt;td>&lt;a href="topics/continuous-delivery/">持續交付與交付效能&lt;/a>、&lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/people/">對人負責（EM）&lt;/a>&lt;/td>
 &lt;td>人留不留得住、回饋怎麼給、壞消息為什麼傳不上來&lt;/td>
 &lt;td>Peopleware&lt;/td>
 &lt;td>&lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a>、&lt;a href="topics/culture-safety/">組織文化與心理安全感&lt;/a>、&lt;a href="topics/personal-workflow/">個人工作流與工作負荷&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/org-structure/">對組織結構負責（管理管理者）&lt;/a>&lt;/td>
 &lt;td>團隊怎麼切、交接面誰負責、承諾為什麼總是跳票&lt;/td>
 &lt;td>Team Topologies&lt;/td>
 &lt;td>&lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>、&lt;a href="topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>起點書的完整描述與購書連結在對應的主題篇：前三本在 &lt;a href="topics/role-transitions/">角色轉換與職涯路徑&lt;/a>，Peopleware 在 &lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a>，Team Topologies 在 &lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>。&lt;/p>
&lt;p>有三種處境這張表判不出來：好幾格同時成立、還沒被指派而想先評估下一格、以及團隊人數不到一個團隊。三種各自的做法在 &lt;a href="roles/">依位置選書&lt;/a> 的「怎麼判斷自己在哪一格」段，該段開頭就標出三者分別在哪一小段。&lt;/p>
&lt;p>想往上或往旁邊移動時，預習的方向跟當下的問題不同。純個人貢獻者想走管理，第一站是 &lt;a href="topics/role-transitions/">角色轉換與職涯路徑&lt;/a>：那裡的書逐層寫出管理位置整天在處理什麼，而「值不值得走過去」得先看得到那個。決定要走之後才輪到 &lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a> 與 &lt;a href="topics/culture-safety/">組織文化與心理安全感&lt;/a>——這兩塊在只對自己負責的位置上完全用不到，因此也最沒有機會自然累積。想走 Staff+ 技術路線的人，預習的是 &lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a> 與 &lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>，因為技術決策要能推得動，靠的是能不能把方案講進別人的約束裡，職權在這條路線上幫不上忙。&lt;/p>
&lt;h2 id="依主題選書">依主題選書&lt;/h2>
&lt;p>十一個主題與各自的首選書在 &lt;a href="topics/">主題書單目錄&lt;/a>。那一頁是主題與首選的唯一清單，這裡不重複列，避免兩份清單各自漂移。&lt;/p>
&lt;h2 id="經典套書怎麼買">經典套書怎麼買&lt;/h2>
&lt;p>各主題篇按問題組織，因此同一套書會分散在不同篇。實際購買時面對的是套書決定，這一段只處理那個決定，每本書的性質判定回各主題篇看。&lt;/p>
&lt;p>Gerald Weinberg 的《溫伯格的軟體管理學》四卷分別對應四個主題：第 1 卷系統化思考在 &lt;a href="topics/problem-definition/">問題定義與系統思考&lt;/a>，第 2 卷第一級評量在 &lt;a href="topics/continuous-delivery/">持續交付與交付效能&lt;/a>，第 3 卷關照全局的管理作為在 &lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a>，第 4 卷擁抱變革在 &lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>。第 1、2 卷處理的問題現在有大規模實證的書可以對照，第 3 卷處理的管理者即時反應在這條線的其他書裡沒有對應。只買一卷買第 3 卷；買套書適合想看完整論述的讀者。四卷合購頁在&lt;a href="https://www.books.com.tw/products/0010553999">博客來&lt;/a>。&lt;/p>
&lt;p>Tom DeMarco 與 Timothy Lister 的兩本分屬不同主題：《Peopleware》在 &lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a>，《Waltzing with Bears》（繁中《與熊共舞》）在 &lt;a href="topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a>。兩本沒有合購版本，分開買。&lt;/p>
&lt;h2 id="相關的實作內容">相關的實作內容&lt;/h2>
&lt;p>書單處理選讀判斷，技術實作在教學系列：交付管線與部署 gate 看 &lt;a href="https://tarrragon.github.io/blog/ci/" data-link-title="CI/CD 教學" data-link-desc="整理 CI/CD 的驗證、建置、發布 gate 與不同部署場域的流程差異，讓每次變更都能被穩定驗證與交付">CI/CD 教學&lt;/a>，服務探活、容量規劃與高可用看 &lt;a href="https://tarrragon.github.io/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運&lt;/a>，事故分級、指揮角色與復盤制度看 &lt;a href="https://tarrragon.github.io/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤&lt;/a>，客戶端遙測的四類事件與收集鏈路看 &lt;a href="https://tarrragon.github.io/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系&lt;/a>，交付生命週期全景看 &lt;a href="https://tarrragon.github.io/blog/devops/" data-link-title="DevOps 全景：軟體交付生命週期" data-link-desc="想釐清 infra、CI/CD、運行期維運怎麼串成一條軟體交付生命週期、或不確定手上的問題該進哪個系列時回來讀">DevOps 全景&lt;/a>。既有團隊的結構評估協議看 &lt;a href="https://tarrragon.github.io/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計&lt;/a>。&lt;/p>
&lt;h2 id="backlog">Backlog&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>項目&lt;/th>
 &lt;th>類型&lt;/th>
 &lt;th>前置條件&lt;/th>
 &lt;th>規模&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>十個主題各跑一次機制式搜尋&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>機制詞候選事前寫死在主題書單的公開課段（研究設計與因果推論 / 承諾可信度 / 訊號傳遞 / 集體決策 / 因果回路與存量流量），產物是十組詞各查到什麼，可重跑&lt;/td>
 &lt;td>1 次&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>沒查到課的十個主題重掃一次&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>2027 年 8 月之後重跑，判準是本質恆定加實際有影音；是哪十個主題與各自為什麼空，見 &lt;a href="topics/">主題書單&lt;/a> 的公開課段&lt;/td>
 &lt;td>1 次&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>系統思考這個主題改判&lt;/td>
 &lt;td>主章&lt;/td>
 &lt;td>MIT 15.871 補上影片，或找到另一門教因果回路與存量流量而有影音的課；沒有人會主動去看，實際觸發點是 2027 年那次重掃&lt;/td>
 &lt;td>1 段&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table></description><content:encoded><![CDATA[<p>這條線涵蓋受僱於某個組織、責任範圍從只對自己的產出到對整個組織結構的五種位置。位置決定當下煩惱什麼：初中級工程師煩惱怎麼讓自己的產出被信任，Tech Lead 煩惱怎麼讓別人的產出達標，EM 煩惱人留不留得住，管理管理者煩惱組織切法對不對。這些煩惱各自對應不同的書，但涵蓋的知識領域大量重疊——同一本談心理安全感的書，四個位置都用得到，用法完全不同。</p>
<p>這條線不處理技藝——程式怎麼寫、怎麼改得動、怎麼驗證，那些在 <a href="../craft/">工程技藝</a>。兩條線的失敗互相看不見，因此分開。另有一條線 <a href="../finance/">財務與投資</a> 處理的是自己的資本與現金流，跟這裡的分界不是同一個軸：那條線的決定不在工作場域裡發生，本篇的位置表與規模、流動率這些約束在那裡都不適用。</p>
<p>書的完整描述住在主題篇，位置與主題兩張路由表只給書名與連結。這個分工的理由是同一本書會出現在多個位置的建議清單裡，若每個位置各寫一份說明，幾份說明會隨時間漂移成幾種不同的講法。</p>
<h2 id="完全不熟悉這個領域時先讀這一本">完全不熟悉這個領域時先讀這一本</h2>
<p><a href="topics/continuous-delivery/">Accelerate</a> 是這條線的單一起點。選它的理由是它同時滿足兩個條件，而與品質排名無關：結論建立在數萬份跨組織調查上，因此可以拿來支持實際決定；而且它的四項指標已經是業界共同語言，讀完之後其他書的討論才有共同座標。</p>
<p>它的限制要先知道：它談的是組織層級的交付效能，不談個人怎麼寫程式、也不談怎麼跟人相處。如果目前的困擾是「我下個月開始要帶人」「我想知道管理職實際在做什麼」「我不知道怎麼跟主管講壞消息」或「我不知道自己夠不夠格升等」，這本書不會回答，直接往下面的位置表走。</p>
<h2 id="依當下的位置選書">依當下的位置選書</h2>
<p>位置的判準是對什麼負責，不是職稱——同一個職稱在大企業與小公司對應的責任範圍經常不同。判準的操作版本是：<strong>交不出來的時候，誰會被問</strong>。下表給每個位置的起點書；那個位置一天實際在處理什麼、在有階梯與沒階梯的組織裡問題差在哪、往相鄰位置移動前該預習什麼，在 <a href="roles/">依位置選書</a> 的五篇裡。</p>
<table>
  <thead>
      <tr>
          <th>位置</th>
          <th>當下的主要問題</th>
          <th>起點</th>
          <th>主要主題</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="roles/own-output/">只對自己的產出負責</a></td>
          <td>怎麼讓產出被信任、怎麼知道自己下一步該補什麼</td>
          <td>The Software Engineer&rsquo;s Guidebook</td>
          <td><a href="topics/role-transitions/">角色轉換與職涯路徑</a>、<a href="topics/problem-definition/">問題定義與系統思考</a></td>
      </tr>
      <tr>
          <td><a href="roles/technical-quality/">對技術品質負責、不帶人</a></td>
          <td>沒有指揮權時怎麼讓別人照著做、技術決策怎麼被採納</td>
          <td>The Staff Engineer&rsquo;s Path</td>
          <td><a href="topics/influence-conversation/">困難對話與無權限影響力</a>、<a href="topics/team-design/">組織結構與團隊設計</a></td>
      </tr>
      <tr>
          <td><a href="roles/others-output/">對別人的產出負責（Tech Lead）</a></td>
          <td>怎麼讓團隊的產出達標而不變成自己重寫</td>
          <td>The Manager&rsquo;s Path</td>
          <td><a href="topics/continuous-delivery/">持續交付與交付效能</a>、<a href="topics/influence-conversation/">困難對話與無權限影響力</a></td>
      </tr>
      <tr>
          <td><a href="roles/people/">對人負責（EM）</a></td>
          <td>人留不留得住、回饋怎麼給、壞消息為什麼傳不上來</td>
          <td>Peopleware</td>
          <td><a href="topics/retention-motivation/">留任、動機與工作環境</a>、<a href="topics/culture-safety/">組織文化與心理安全感</a>、<a href="topics/personal-workflow/">個人工作流與工作負荷</a></td>
      </tr>
      <tr>
          <td><a href="roles/org-structure/">對組織結構負責（管理管理者）</a></td>
          <td>團隊怎麼切、交接面誰負責、承諾為什麼總是跳票</td>
          <td>Team Topologies</td>
          <td><a href="topics/team-design/">組織結構與團隊設計</a>、<a href="topics/estimation-decision/">估算、承諾與決策偏誤</a></td>
      </tr>
  </tbody>
</table>
<p>起點書的完整描述與購書連結在對應的主題篇：前三本在 <a href="topics/role-transitions/">角色轉換與職涯路徑</a>，Peopleware 在 <a href="topics/retention-motivation/">留任、動機與工作環境</a>，Team Topologies 在 <a href="topics/team-design/">組織結構與團隊設計</a>。</p>
<p>有三種處境這張表判不出來：好幾格同時成立、還沒被指派而想先評估下一格、以及團隊人數不到一個團隊。三種各自的做法在 <a href="roles/">依位置選書</a> 的「怎麼判斷自己在哪一格」段，該段開頭就標出三者分別在哪一小段。</p>
<p>想往上或往旁邊移動時，預習的方向跟當下的問題不同。純個人貢獻者想走管理，第一站是 <a href="topics/role-transitions/">角色轉換與職涯路徑</a>：那裡的書逐層寫出管理位置整天在處理什麼，而「值不值得走過去」得先看得到那個。決定要走之後才輪到 <a href="topics/retention-motivation/">留任、動機與工作環境</a> 與 <a href="topics/culture-safety/">組織文化與心理安全感</a>——這兩塊在只對自己負責的位置上完全用不到，因此也最沒有機會自然累積。想走 Staff+ 技術路線的人，預習的是 <a href="topics/influence-conversation/">困難對話與無權限影響力</a> 與 <a href="topics/team-design/">組織結構與團隊設計</a>，因為技術決策要能推得動，靠的是能不能把方案講進別人的約束裡，職權在這條路線上幫不上忙。</p>
<h2 id="依主題選書">依主題選書</h2>
<p>十一個主題與各自的首選書在 <a href="topics/">主題書單目錄</a>。那一頁是主題與首選的唯一清單，這裡不重複列，避免兩份清單各自漂移。</p>
<h2 id="經典套書怎麼買">經典套書怎麼買</h2>
<p>各主題篇按問題組織，因此同一套書會分散在不同篇。實際購買時面對的是套書決定，這一段只處理那個決定，每本書的性質判定回各主題篇看。</p>
<p>Gerald Weinberg 的《溫伯格的軟體管理學》四卷分別對應四個主題：第 1 卷系統化思考在 <a href="topics/problem-definition/">問題定義與系統思考</a>，第 2 卷第一級評量在 <a href="topics/continuous-delivery/">持續交付與交付效能</a>，第 3 卷關照全局的管理作為在 <a href="topics/influence-conversation/">困難對話與無權限影響力</a>，第 4 卷擁抱變革在 <a href="topics/team-design/">組織結構與團隊設計</a>。第 1、2 卷處理的問題現在有大規模實證的書可以對照，第 3 卷處理的管理者即時反應在這條線的其他書裡沒有對應。只買一卷買第 3 卷；買套書適合想看完整論述的讀者。四卷合購頁在<a href="https://www.books.com.tw/products/0010553999">博客來</a>。</p>
<p>Tom DeMarco 與 Timothy Lister 的兩本分屬不同主題：《Peopleware》在 <a href="topics/retention-motivation/">留任、動機與工作環境</a>，《Waltzing with Bears》（繁中《與熊共舞》）在 <a href="topics/estimation-decision/">估算、承諾與決策偏誤</a>。兩本沒有合購版本，分開買。</p>
<h2 id="相關的實作內容">相關的實作內容</h2>
<p>書單處理選讀判斷，技術實作在教學系列：交付管線與部署 gate 看 <a href="/blog/ci/" data-link-title="CI/CD 教學" data-link-desc="整理 CI/CD 的驗證、建置、發布 gate 與不同部署場域的流程差異，讓每次變更都能被穩定驗證與交付">CI/CD 教學</a>，服務探活、容量規劃與高可用看 <a href="/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運</a>，事故分級、指揮角色與復盤制度看 <a href="/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤</a>，客戶端遙測的四類事件與收集鏈路看 <a href="/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系</a>，交付生命週期全景看 <a href="/blog/devops/" data-link-title="DevOps 全景：軟體交付生命週期" data-link-desc="想釐清 infra、CI/CD、運行期維運怎麼串成一條軟體交付生命週期、或不確定手上的問題該進哪個系列時回來讀">DevOps 全景</a>。既有團隊的結構評估協議看 <a href="/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計</a>。</p>
<h2 id="backlog">Backlog</h2>
<table>
  <thead>
      <tr>
          <th>項目</th>
          <th>類型</th>
          <th>前置條件</th>
          <th>規模</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>十個主題各跑一次機制式搜尋</td>
          <td>案例</td>
          <td>機制詞候選事前寫死在主題書單的公開課段（研究設計與因果推論 / 承諾可信度 / 訊號傳遞 / 集體決策 / 因果回路與存量流量），產物是十組詞各查到什麼，可重跑</td>
          <td>1 次</td>
      </tr>
      <tr>
          <td>沒查到課的十個主題重掃一次</td>
          <td>案例</td>
          <td>2027 年 8 月之後重跑，判準是本質恆定加實際有影音；是哪十個主題與各自為什麼空，見 <a href="topics/">主題書單</a> 的公開課段</td>
          <td>1 次</td>
      </tr>
      <tr>
          <td>系統思考這個主題改判</td>
          <td>主章</td>
          <td>MIT 15.871 補上影片，或找到另一門教因果回路與存量流量而有影音的課；沒有人會主動去看，實際觸發點是 2027 年那次重掃</td>
          <td>1 段</td>
      </tr>
  </tbody>
</table>
]]></content:encoded></item><item><title>個人理財與風險保障</title><link>https://tarrragon.github.io/blog/books/finance/personal-finance/</link><pubDate>Thu, 20 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/finance/personal-finance/</guid><description>&lt;p>個人理財處理的是同一筆現金流在幾個用途之間的先後順序：償還負債、留下緊急預備、把風險移轉出去、投入市場。四個用途互相排擠，所以這個主題交付的是排序規則，而各項目自己的最佳解另有主場。順序錯了的代價不對稱——投資報酬少一個百分點會慢慢顯現，緊急預備不足遇上一次失業則當月就要用高利負債補回來。&lt;/p>
&lt;p>排序規則有一半可以用書承接，另一半不行，分界跟這條線的載體判準是同一條。排序的邏輯（哪一項的失敗最快到達、哪一項的成本可以攤到最長）不隨制度改變；排序要代進去的參數（負債利率、社會保險給付、退休帳戶的稅務待遇、保單條款）每年都在動。這一篇收的書服務前者，後者由主管機關的公開資訊與保單條款本身承接，理由寫在 &lt;a href="../">財務與投資書單&lt;/a> 的「有些財務知識不該用書當載體」段。&lt;/p>
&lt;p>本篇屬於 &lt;a href="../">財務與投資書單&lt;/a>，每本書都用同一組四項描述：&lt;strong>證據來源&lt;/strong>（它的結論建立在什麼材料上）、&lt;strong>時效狀態&lt;/strong>（哪些部分依賴已經改變的前提）、&lt;strong>處境相容性&lt;/strong>（讀者具不具備它預設的環境）、&lt;strong>讀得出價值的前提&lt;/strong>（要有什麼經驗才讀得出它的價值）。四項的完整定義與這些判定的可信度說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>。這四項描述的是書；讀不動長篇文字時，本篇文末另標出承接同一組內容的公開課，收錄門檻與已知限制見 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。&lt;/p>
&lt;h2 id="起點是持續買進">起點是持續買進&lt;/h2>
&lt;p>Nick Maggiulli 的《持續買進》是本篇涵蓋面最廣的一本，把排序問題的各個路口逐一走過：該存多少、緊急預備留多深、負債要不要先清、該不該租屋、一次投入還是分批、退休後怎麼提領。&lt;/p>
&lt;p>起點書的選定在這一篇走到了第二層判準。它跟本篇第三本的涵蓋面差在一個面向以內——起點書覆蓋各路口的算式那一面，並碰到支出與累積終點那一面的提領那一角，第三本完整覆蓋支出與累積終點——這時取證據來源足以支持「被拿去佐證實際決定」這個用途的那本（三層判準的完整說明在 &lt;a href="../../software-management/topics/">主題書單&lt;/a> 的判準段）。這一本的結論附著在可以重做的計算上，第三本的九個步驟由作者提出而沒有獨立驗證，追問到底時，一邊指回可以重做的計算，一邊指回作者本人。&lt;/p>
&lt;p>它跟同類書的差別在每個路口都給出一次計算而非一條規則。儲蓄率與投資報酬的相對重要性隨資產規模翻轉——資產還小的時候多存一個月的錢，效果大過報酬率高一個百分點；資產累積到一定規模之後兩者對調。這個翻轉點讀者可以拿自己的數字重算，而規則型的理財書給的是翻轉之後那一側的建議，套在翻轉之前會讓人把力氣花在挑標的上。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是大規模實證加理論建構，材料是歷史市場資料的再分析。書名副標自陳是資料科學家的解答，而書裡的主張確實多半附著在一次可重做的計算上，也讓它繼承那批資料本身的限制：書中拿來回測的指數序列由仍在編製的市場構成，&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a> 落在資料源上的那一種形態在這裡是存在的，而書中的結論多屬相對比較（一次投入對照分批），兩邊被同一份資料篩過，受影響的程度低於絕對報酬的估計。&lt;/p>
&lt;p>時效上，方法與計算框架不依賴當期水準，代進去的數字依賴：書中的房貸利率、房價租金比與估值水準取自撰寫當時。判斷方式是看每一節的結論是一個數字還是一個算式，是算式的照讀，是數字的自己代一次。&lt;/p>
&lt;p>處境相容性上有兩項要換算。退休帳戶與稅務優惠的段落預設美國制度，屬於書單不承接的制度性內容。第二項比較不直觀：書中討論租屋與購屋的權衡時，把購屋的成本結構當成一組可比較的數字，而房價所得比極高的市場裡購屋同時是一個家庭結構的決定，那一層在書裡沒有材料可以處理。&lt;/p>
&lt;p>讀得出價值的前提幾乎沒有，有一份可支配所得就對照得起來。中譯本由商業周刊出版。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/011841001">三民（持續買進：資料科學家的投資終極解答，存錢及致富的實證方法，商業周刊，2023）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/010098953">三民（Just Keep Buying: Proven Ways to Save Money and Build Your Wealth, Harriman House, 2022）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="決定為什麼偏離算式讀致富心態">決定為什麼偏離算式，讀致富心態&lt;/h2>
&lt;p>Morgan Housel 的《致富心態》承擔的是排序的另一側：算得出最優解之後，人為什麼仍然選了別的。它把財務決定拆成一組跟數字無關的變數——對意外的預期、對同儕的比較、對自己過去經驗的過度採信——並說明這些變數如何讓兩個條件相同的人做出相反的決定。&lt;/p>
&lt;p>它最可直接使用的一條是「合理勝過最優」：留下超出計算所需的緩衝、或持有一部分報酬率較低而波動小的資產，在算式上是次優解，而它換到的是持有得下去。這一條在排序問題上有直接用途——緊急預備該留多深，算式給的是一個範圍，範圍內取哪一點由這一條決定。&lt;/p>
&lt;p>證據來源是理論建構加軼事，這是本篇最需要注意材料形態的一本。書中的案例成對出現，一端是結果極好的人、另一端是結果極壞的人，而那兩端都是被結果挑出來的，&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a> 落在敘事選材上的形態在這裡很明顯。書自己的主張正好指向同一件事——別從單一結果反推方法——所以案例的用途是讓機制長出畫面，把它讀成「這樣做會有什麼結果」的時候，讀的方向跟作者的主張相反。&lt;/p>
&lt;p>時效上，書中處理的行為機制不依賴年代，這一項沒有查到已經改變的前提。&lt;/p>
&lt;p>處境相容性上有一項限制值得標出來：書中多數情境的主角握有可以選擇的餘裕，而「留下緩衝」這個建議的可執行範圍由現金流的鬆緊決定。收入扣掉固定支出所剩無幾的讀者讀到的是一個目前做不到的動作，那不改變機制的正確性，改變的是這本書該排在哪個位置讀——它在本篇的順序位於起點書之後。&lt;/p>
&lt;p>讀得出價值的前提是有過一次事後看來錯了的財務決定。缺這個經驗時，二十篇短文讀起來像一串合理的說法，而它們要對照的那次決定不在手上。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/015197445">三民（致富心態：關於財富、貪婪與幸福的 20 堂理財課，全球暢銷千萬增訂版，天下文化，2026）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/007823405">三民（The Psychology of Money, Harriman House, 2020）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="把支出換算成生命時間的是跟錢好好相處">把支出換算成生命時間的是跟錢好好相處&lt;/h2>
&lt;p>Vicki Robin 與 Joe Dominguez 的《跟錢好好相處》從支出端進入同一個排序問題。它的核心動作是把每一筆支出換算成賺那筆錢所花掉的生命時間，換算之後支出的排序會自己浮現——同樣一筆金額，換算成小時之後有些項目留下、有些項目不再值得。&lt;/p>
&lt;p>它處理「夠了在哪裡」的方式跟起點書不同：累積的目標由生活支出反推，而不是先設一個資產數字再回推要存多久，這個方向決定了另外幾個決定：要累積到什麼程度、什麼時候可以換工作、加班換到的錢在換算之後還剩多少。&lt;/p>
&lt;p>證據來源是作者自建的方法加個人經驗，九個步驟由作者提出，效果宣稱來自實踐者的自陳而沒有獨立驗證。這個類別適合當自己的實驗協議，拿它去支持「這套方法對多數人有效」要另外找依據。&lt;/p>
&lt;p>時效這一項在這本書上有一個可以直接核對的過時前提，也是本篇最清楚的一則。原版把累積的終點設定成以長期公債利息覆蓋生活支出，那一步依賴當時的利率水準；利率長期下行之後那個終點在同樣的資產規模上達不到，2018 年的修訂版改寫了這一段，改以指數型投資工具承接。中譯本譯自修訂版。這則判定同時示範了時效與載體的分工：作者改得了書，而已經印出來的那一版改不了，讀者手上拿的是哪一版決定了他讀到的是哪一個終點。&lt;/p>
&lt;p>處境相容性上，稅務與退休帳戶的段落預設美國制度。方法本身另有一個前提：支出的可壓縮幅度要夠大，換算成小時之後才會出現可以砍掉的項目。房租或房貸佔可支配所得比重極高的讀者，換算的結果多半集中在一個動不了的科目上，那時這本書給的動作要換成別的方向。&lt;/p>
&lt;p>讀得出價值的前提是願意逐筆記錄一段時間的支出。跳過記錄而只讀方法時，換算沒有輸入。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/012048106">三民（跟錢好好相處：幸福的關鍵，是找到金錢與人生的平衡點，商業周刊，2023）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>三本各接排序問題的一個面：各路口的算式、決定偏離算式的原因、支出端的換算與累積終點。順序按依賴關係排——起點書給出各路口的算式之後，另外兩本處理的是算式的輸入與算式之外的部分。&lt;/p>
&lt;p>不收的最大一類是當期規劃書：整本在講當期稅務規劃、當期保單比較或當期補助方案的書，理由是載體而非品質，寫在 &lt;a href="../">財務與投資書單&lt;/a> 的「有些財務知識不該用書當載體」段。第二類是只給規則不給邊界的推廣書——一套編號步驟通往財務自由，而不寫這套步驟在什麼收入結構、什麼家庭形態下走不通。這是 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 那條排除判準在本主題的形狀，翻目錄就分得出來：有沒有一章在寫這套方法對誰不管用。&lt;/p>
&lt;p>&lt;strong>風險保障這一格目前空著&lt;/strong>，而空著的理由有兩層，值得分開說。第一層是制度性內容的排除線：保單條款、費率、給付範圍、以及它跟社會保險的銜接每年都在動，寫進書裡的部分在印出來的當下就進入待查狀態。第二層是本書單未評估——只講風險移轉機制而不寫當期商品的書有沒有存在、以及它會落在這個主題還是落在機率與風險判斷那一類，這一點沒有判斷過。「未評估」在這裡指的是這兩項，不是委婉的否決。&lt;/p>
&lt;p>在這一格補上之前，這個主題能交付的是分工而不是答案：哪些損失自己承擔得起、哪些承擔不起，是排序問題的一部分，答案要用自己的緊急預備與現金流算；承擔不起的那些各有什麼移轉工具、費率多少、條款怎麼寫，去主管機關的公開資訊與保單條款本身。待辦記在 &lt;a href="../">財務與投資書單&lt;/a> 的 Backlog 段。&lt;/p>
&lt;h2 id="有一門課同時落在本篇的兩側而制度那一堂在錄影裡衰減得比在書裡更快">有一門課同時落在本篇的兩側，而制度那一堂在錄影裡衰減得比在書裡更快&lt;/h2>
&lt;p>這個主題有一門課，它的六堂分別落在本篇開頭那條分界的兩側——排序邏輯那幾堂可以直接用，制度那一堂不行。台大開放式課程的財務幸福自我養成計畫由陳彥行（財務金融學系）主講、中文授課、6 講，教材改編自介惠基金會的「偏鄉婦女財務幸福計畫」，課程頁明說預設讀者沒有商學背景。六堂依序是理財規劃流程及家庭財務報表、我國退休金制度及金錢詐騙剝削預防、職涯規劃與借貸評估、投資報酬與風險、人生風險與保險，最後一堂複習並邀請實際用這套方法做過規劃的個案分享。&lt;/p>
&lt;p>分界的位置跟本篇對書的處理完全一致。第一、三、四堂是排序邏輯：家庭財務報表怎麼編、借貸值不值得、報酬與風險怎麼對應，這些不隨制度改變。第二堂的我國退休金制度是制度性內容，屬於 &lt;a href="../">財務與投資書單&lt;/a> 的「有些財務知識不該用書當載體」段劃出的那一類。&lt;/p>
&lt;p>而錄影在這一項上比書更糟，理由要說清楚。書至少會改版重印，讀者拿到的是當期版本；錄影不會——這門課錄於 2023 年 2 月，講的是當時的給付條件，而畫面上沒有任何訊號提示那一堂已經過了幾年。同一堂課的另一半（金錢詐騙與剝削的手法）則不依賴任何當期規範。實際的用法是第二堂當成「有哪些制度要查」的清單，而不是「制度是什麼」的答案，落點回主管機關的當期公告。&lt;/p>
&lt;p>第五堂的人生風險與保險碰到的是這條線目前還沒有書可以承接的那個主題（見 &lt;a href="../">財務與投資書單&lt;/a> 的 Backlog）。它是不是只講風險移轉的機制、避開了當期商品與費率，本頁沒有判定——這一項要看過課程內容才下得了，屬於 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「這些判定從哪來」段所說、可信度較低的那一類。&lt;/p>
&lt;p>本篇起點書處理的資產配置與長期複利那一面，這門課的第四堂只給到概念層。要更完整的，走 &lt;a href="../investing/">資本配置與投資&lt;/a> 那一篇的課程段。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://ocw.aca.ntu.edu.tw/courses/111S203">台大開放式課程（111S203 財務幸福自我養成計畫，陳彥行，6 講）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>排序走到「有一筆錢可以長期不動」之後，配置的決定在 &lt;a href="../investing/">資本配置與投資&lt;/a>。反過來，投資篇裡任何一條配置建議要能執行，前提都是這一篇的排序已經跑過一次。&lt;/p>
&lt;p>要讀懂一家公司的報表——受僱的公司、往來的客戶、或準備投入的標的——走 &lt;a href="../accounting/">會計與財報&lt;/a>。想知道利率與通膨在改變什麼，走 &lt;a href="../macroeconomics/">總體經濟&lt;/a>。&lt;/p>
&lt;p>四個位置各自該從哪一篇開始，在 &lt;a href="../positions/">依資本責任選書&lt;/a>。收入以接案或業務獎金為主、現金流本身不穩定的讀者，先看那一篇的判準失準段。&lt;/p></description><content:encoded><![CDATA[<p>個人理財處理的是同一筆現金流在幾個用途之間的先後順序：償還負債、留下緊急預備、把風險移轉出去、投入市場。四個用途互相排擠，所以這個主題交付的是排序規則，而各項目自己的最佳解另有主場。順序錯了的代價不對稱——投資報酬少一個百分點會慢慢顯現，緊急預備不足遇上一次失業則當月就要用高利負債補回來。</p>
<p>排序規則有一半可以用書承接，另一半不行，分界跟這條線的載體判準是同一條。排序的邏輯（哪一項的失敗最快到達、哪一項的成本可以攤到最長）不隨制度改變；排序要代進去的參數（負債利率、社會保險給付、退休帳戶的稅務待遇、保單條款）每年都在動。這一篇收的書服務前者，後者由主管機關的公開資訊與保單條款本身承接，理由寫在 <a href="../">財務與投資書單</a> 的「有些財務知識不該用書當載體」段。</p>
<p>本篇屬於 <a href="../">財務與投資書單</a>，每本書都用同一組四項描述：<strong>證據來源</strong>（它的結論建立在什麼材料上）、<strong>時效狀態</strong>（哪些部分依賴已經改變的前提）、<strong>處境相容性</strong>（讀者具不具備它預設的環境）、<strong>讀得出價值的前提</strong>（要有什麼經驗才讀得出它的價值）。四項的完整定義與這些判定的可信度說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>。這四項描述的是書；讀不動長篇文字時，本篇文末另標出承接同一組內容的公開課，收錄門檻與已知限制見 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。</p>
<h2 id="起點是持續買進">起點是持續買進</h2>
<p>Nick Maggiulli 的《持續買進》是本篇涵蓋面最廣的一本，把排序問題的各個路口逐一走過：該存多少、緊急預備留多深、負債要不要先清、該不該租屋、一次投入還是分批、退休後怎麼提領。</p>
<p>起點書的選定在這一篇走到了第二層判準。它跟本篇第三本的涵蓋面差在一個面向以內——起點書覆蓋各路口的算式那一面，並碰到支出與累積終點那一面的提領那一角，第三本完整覆蓋支出與累積終點——這時取證據來源足以支持「被拿去佐證實際決定」這個用途的那本（三層判準的完整說明在 <a href="../../software-management/topics/">主題書單</a> 的判準段）。這一本的結論附著在可以重做的計算上，第三本的九個步驟由作者提出而沒有獨立驗證，追問到底時，一邊指回可以重做的計算，一邊指回作者本人。</p>
<p>它跟同類書的差別在每個路口都給出一次計算而非一條規則。儲蓄率與投資報酬的相對重要性隨資產規模翻轉——資產還小的時候多存一個月的錢，效果大過報酬率高一個百分點；資產累積到一定規模之後兩者對調。這個翻轉點讀者可以拿自己的數字重算，而規則型的理財書給的是翻轉之後那一側的建議，套在翻轉之前會讓人把力氣花在挑標的上。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是大規模實證加理論建構，材料是歷史市場資料的再分析。書名副標自陳是資料科學家的解答，而書裡的主張確實多半附著在一次可重做的計算上，也讓它繼承那批資料本身的限制：書中拿來回測的指數序列由仍在編製的市場構成，<a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a> 落在資料源上的那一種形態在這裡是存在的，而書中的結論多屬相對比較（一次投入對照分批），兩邊被同一份資料篩過，受影響的程度低於絕對報酬的估計。</p>
<p>時效上，方法與計算框架不依賴當期水準，代進去的數字依賴：書中的房貸利率、房價租金比與估值水準取自撰寫當時。判斷方式是看每一節的結論是一個數字還是一個算式，是算式的照讀，是數字的自己代一次。</p>
<p>處境相容性上有兩項要換算。退休帳戶與稅務優惠的段落預設美國制度，屬於書單不承接的制度性內容。第二項比較不直觀：書中討論租屋與購屋的權衡時，把購屋的成本結構當成一組可比較的數字，而房價所得比極高的市場裡購屋同時是一個家庭結構的決定，那一層在書裡沒有材料可以處理。</p>
<p>讀得出價值的前提幾乎沒有，有一份可支配所得就對照得起來。中譯本由商業周刊出版。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/011841001">三民（持續買進：資料科學家的投資終極解答，存錢及致富的實證方法，商業周刊，2023）</a></li>
<li><a href="https://www.sanmin.com.tw/product/index/010098953">三民（Just Keep Buying: Proven Ways to Save Money and Build Your Wealth, Harriman House, 2022）</a></li>
</ul>
<h2 id="決定為什麼偏離算式讀致富心態">決定為什麼偏離算式，讀致富心態</h2>
<p>Morgan Housel 的《致富心態》承擔的是排序的另一側：算得出最優解之後，人為什麼仍然選了別的。它把財務決定拆成一組跟數字無關的變數——對意外的預期、對同儕的比較、對自己過去經驗的過度採信——並說明這些變數如何讓兩個條件相同的人做出相反的決定。</p>
<p>它最可直接使用的一條是「合理勝過最優」：留下超出計算所需的緩衝、或持有一部分報酬率較低而波動小的資產，在算式上是次優解，而它換到的是持有得下去。這一條在排序問題上有直接用途——緊急預備該留多深，算式給的是一個範圍，範圍內取哪一點由這一條決定。</p>
<p>證據來源是理論建構加軼事，這是本篇最需要注意材料形態的一本。書中的案例成對出現，一端是結果極好的人、另一端是結果極壞的人，而那兩端都是被結果挑出來的，<a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a> 落在敘事選材上的形態在這裡很明顯。書自己的主張正好指向同一件事——別從單一結果反推方法——所以案例的用途是讓機制長出畫面，把它讀成「這樣做會有什麼結果」的時候，讀的方向跟作者的主張相反。</p>
<p>時效上，書中處理的行為機制不依賴年代，這一項沒有查到已經改變的前提。</p>
<p>處境相容性上有一項限制值得標出來：書中多數情境的主角握有可以選擇的餘裕，而「留下緩衝」這個建議的可執行範圍由現金流的鬆緊決定。收入扣掉固定支出所剩無幾的讀者讀到的是一個目前做不到的動作，那不改變機制的正確性，改變的是這本書該排在哪個位置讀——它在本篇的順序位於起點書之後。</p>
<p>讀得出價值的前提是有過一次事後看來錯了的財務決定。缺這個經驗時，二十篇短文讀起來像一串合理的說法，而它們要對照的那次決定不在手上。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/015197445">三民（致富心態：關於財富、貪婪與幸福的 20 堂理財課，全球暢銷千萬增訂版，天下文化，2026）</a></li>
<li><a href="https://www.sanmin.com.tw/product/index/007823405">三民（The Psychology of Money, Harriman House, 2020）</a></li>
</ul>
<h2 id="把支出換算成生命時間的是跟錢好好相處">把支出換算成生命時間的是跟錢好好相處</h2>
<p>Vicki Robin 與 Joe Dominguez 的《跟錢好好相處》從支出端進入同一個排序問題。它的核心動作是把每一筆支出換算成賺那筆錢所花掉的生命時間，換算之後支出的排序會自己浮現——同樣一筆金額，換算成小時之後有些項目留下、有些項目不再值得。</p>
<p>它處理「夠了在哪裡」的方式跟起點書不同：累積的目標由生活支出反推，而不是先設一個資產數字再回推要存多久，這個方向決定了另外幾個決定：要累積到什麼程度、什麼時候可以換工作、加班換到的錢在換算之後還剩多少。</p>
<p>證據來源是作者自建的方法加個人經驗，九個步驟由作者提出，效果宣稱來自實踐者的自陳而沒有獨立驗證。這個類別適合當自己的實驗協議，拿它去支持「這套方法對多數人有效」要另外找依據。</p>
<p>時效這一項在這本書上有一個可以直接核對的過時前提，也是本篇最清楚的一則。原版把累積的終點設定成以長期公債利息覆蓋生活支出，那一步依賴當時的利率水準；利率長期下行之後那個終點在同樣的資產規模上達不到，2018 年的修訂版改寫了這一段，改以指數型投資工具承接。中譯本譯自修訂版。這則判定同時示範了時效與載體的分工：作者改得了書，而已經印出來的那一版改不了，讀者手上拿的是哪一版決定了他讀到的是哪一個終點。</p>
<p>處境相容性上，稅務與退休帳戶的段落預設美國制度。方法本身另有一個前提：支出的可壓縮幅度要夠大，換算成小時之後才會出現可以砍掉的項目。房租或房貸佔可支配所得比重極高的讀者，換算的結果多半集中在一個動不了的科目上，那時這本書給的動作要換成別的方向。</p>
<p>讀得出價值的前提是願意逐筆記錄一段時間的支出。跳過記錄而只讀方法時，換算沒有輸入。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/012048106">三民（跟錢好好相處：幸福的關鍵，是找到金錢與人生的平衡點，商業周刊，2023）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>三本各接排序問題的一個面：各路口的算式、決定偏離算式的原因、支出端的換算與累積終點。順序按依賴關係排——起點書給出各路口的算式之後，另外兩本處理的是算式的輸入與算式之外的部分。</p>
<p>不收的最大一類是當期規劃書：整本在講當期稅務規劃、當期保單比較或當期補助方案的書，理由是載體而非品質，寫在 <a href="../">財務與投資書單</a> 的「有些財務知識不該用書當載體」段。第二類是只給規則不給邊界的推廣書——一套編號步驟通往財務自由，而不寫這套步驟在什麼收入結構、什麼家庭形態下走不通。這是 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 那條排除判準在本主題的形狀，翻目錄就分得出來：有沒有一章在寫這套方法對誰不管用。</p>
<p><strong>風險保障這一格目前空著</strong>，而空著的理由有兩層，值得分開說。第一層是制度性內容的排除線：保單條款、費率、給付範圍、以及它跟社會保險的銜接每年都在動，寫進書裡的部分在印出來的當下就進入待查狀態。第二層是本書單未評估——只講風險移轉機制而不寫當期商品的書有沒有存在、以及它會落在這個主題還是落在機率與風險判斷那一類，這一點沒有判斷過。「未評估」在這裡指的是這兩項，不是委婉的否決。</p>
<p>在這一格補上之前，這個主題能交付的是分工而不是答案：哪些損失自己承擔得起、哪些承擔不起，是排序問題的一部分，答案要用自己的緊急預備與現金流算；承擔不起的那些各有什麼移轉工具、費率多少、條款怎麼寫，去主管機關的公開資訊與保單條款本身。待辦記在 <a href="../">財務與投資書單</a> 的 Backlog 段。</p>
<h2 id="有一門課同時落在本篇的兩側而制度那一堂在錄影裡衰減得比在書裡更快">有一門課同時落在本篇的兩側，而制度那一堂在錄影裡衰減得比在書裡更快</h2>
<p>這個主題有一門課，它的六堂分別落在本篇開頭那條分界的兩側——排序邏輯那幾堂可以直接用，制度那一堂不行。台大開放式課程的財務幸福自我養成計畫由陳彥行（財務金融學系）主講、中文授課、6 講，教材改編自介惠基金會的「偏鄉婦女財務幸福計畫」，課程頁明說預設讀者沒有商學背景。六堂依序是理財規劃流程及家庭財務報表、我國退休金制度及金錢詐騙剝削預防、職涯規劃與借貸評估、投資報酬與風險、人生風險與保險，最後一堂複習並邀請實際用這套方法做過規劃的個案分享。</p>
<p>分界的位置跟本篇對書的處理完全一致。第一、三、四堂是排序邏輯：家庭財務報表怎麼編、借貸值不值得、報酬與風險怎麼對應，這些不隨制度改變。第二堂的我國退休金制度是制度性內容，屬於 <a href="../">財務與投資書單</a> 的「有些財務知識不該用書當載體」段劃出的那一類。</p>
<p>而錄影在這一項上比書更糟，理由要說清楚。書至少會改版重印，讀者拿到的是當期版本；錄影不會——這門課錄於 2023 年 2 月，講的是當時的給付條件，而畫面上沒有任何訊號提示那一堂已經過了幾年。同一堂課的另一半（金錢詐騙與剝削的手法）則不依賴任何當期規範。實際的用法是第二堂當成「有哪些制度要查」的清單，而不是「制度是什麼」的答案，落點回主管機關的當期公告。</p>
<p>第五堂的人生風險與保險碰到的是這條線目前還沒有書可以承接的那個主題（見 <a href="../">財務與投資書單</a> 的 Backlog）。它是不是只講風險移轉的機制、避開了當期商品與費率，本頁沒有判定——這一項要看過課程內容才下得了，屬於 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「這些判定從哪來」段所說、可信度較低的那一類。</p>
<p>本篇起點書處理的資產配置與長期複利那一面，這門課的第四堂只給到概念層。要更完整的，走 <a href="../investing/">資本配置與投資</a> 那一篇的課程段。</p>
<ul>
<li><a href="https://ocw.aca.ntu.edu.tw/courses/111S203">台大開放式課程（111S203 財務幸福自我養成計畫，陳彥行，6 講）</a></li>
</ul>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>排序走到「有一筆錢可以長期不動」之後，配置的決定在 <a href="../investing/">資本配置與投資</a>。反過來，投資篇裡任何一條配置建議要能執行，前提都是這一篇的排序已經跑過一次。</p>
<p>要讀懂一家公司的報表——受僱的公司、往來的客戶、或準備投入的標的——走 <a href="../accounting/">會計與財報</a>。想知道利率與通膨在改變什麼，走 <a href="../macroeconomics/">總體經濟</a>。</p>
<p>四個位置各自該從哪一篇開始，在 <a href="../positions/">依資本責任選書</a>。收入以接案或業務獎金為主、現金流本身不穩定的讀者，先看那一篇的判準失準段。</p>
]]></content:encoded></item><item><title>工程技藝書單</title><link>https://tarrragon.github.io/blog/books/craft/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/craft/</guid><description>&lt;p>這條線處理的是&lt;strong>一個人怎麼把軟體寫好、改好、維持得住&lt;/strong>。它跟 &lt;a href="../software-management/">軟體管理與組織&lt;/a> 的分界在決定的對象：那條線的決定落在人與制度上，這條線的決定落在產物上。分界不落在「有沒有離開編輯器」——系統架構那篇的取捨要跨越團隊、資料與既有承諾，代價有一半落在組織上，但被決定的仍然是系統長什麼形狀。另有一條線 &lt;a href="../finance/">財務與投資&lt;/a> 的決定落在自己的錢上，跟這裡不共用讀者位置。各線為什麼按這個軸分開，說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「書單線」段。&lt;/p>
&lt;p>書的描述沿用同一套維度（&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>、時效狀態、&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>、讀得出價值的前提），定義與這些判定的來源說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>。這四篇的起點書用的也是同一組判準（涵蓋面優先、其次證據來源夠不夠支持那個用途、再其次可操作性），判準寫在 &lt;a href="../software-management/topics/">主題書單&lt;/a> 的「起點書怎麼選出來的」段。驗證那篇是唯一的例外：它的起點取 Beck，理由是後面兩本都在跟它對話，那條「歷史先行性」不在三層判準裡。&lt;/p>
&lt;h2 id="這條線特別要注意時效">這條線特別要注意時效&lt;/h2>
&lt;p>技藝類的書比管理類更容易局部過時，因為它們的例子綁在語言、工具與當時的工程環境上。判斷方式不變——問這一段的論證依賴什麼前提——但套用時要多分一層：&lt;strong>主張本身&lt;/strong>（模組該怎麼切、重複意味著什麼）通常比&lt;strong>示範它的程式碼&lt;/strong>活得久。看到過時的語法不要連著把主張一起丟掉，那是這類書最常見的誤判。&lt;/p>
&lt;p>反過來也成立：一本書的示範用了最新的語言特性，不代表它的主張比較新。&lt;/p>
&lt;h2 id="主題">主題&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>主題&lt;/th>
 &lt;th>承擔的問題&lt;/th>
 &lt;th>起點書&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="design-and-practice/">設計判準與日常實踐&lt;/a>&lt;/td>
 &lt;td>怎麼寫出改得動的程式、日常工作該有哪些習慣&lt;/td>
 &lt;td>The Pragmatic Programmer&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="changing-existing-code/">改既有的程式&lt;/a>&lt;/td>
 &lt;td>要動一段自己沒寫的、或沒有測試保護的程式碼&lt;/td>
 &lt;td>Refactoring&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="system-architecture/">系統架構&lt;/a>&lt;/td>
 &lt;td>整個系統該長什麼形狀、拆分時每個選項的代價&lt;/td>
 &lt;td>Fundamentals of Software Architecture&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="verification/">驗證自己寫對了&lt;/a>&lt;/td>
 &lt;td>該測到什麼程度、這裡到底該不該 mock&lt;/td>
 &lt;td>Test-Driven Development: By Example&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h2 id="三個主題其實是同一組概念在三個尺度上運作">三個主題其實是同一組概念在三個尺度上運作&lt;/h2>
&lt;p>這條線有四個主題，其中三個排在同一道刻度上。耦合與內聚這兩個概念貫穿它們，只是作用的範圍不同。Kent Beck 用它們算「這幾行現在要不要整理」，Ousterhout 用它們判斷「這個模組的介面該多深」，Richards 與 Ford 在元件層用同一組概念談切分與粒度。三個主題不是三種學問，是同一把尺在三個刻度上讀。這道刻度上的三本跟各篇的起點書只有一本重疊：架構那一層兩者都是 Richards 與 Ford，另外兩層不同——照起點書走的讀者在最小尺度落到的是 Fowler 而不是 Beck，在模組尺度落到的是 Pragmatic Programmer 而不是 Ousterhout。那兩本各自是所屬主題涵蓋面最廣的入口，而不是這把尺的刻度。要看這把尺，最小與模組兩層直接取 Beck 與 Ousterhout。&lt;/p>
&lt;p>知道這件事有一個實用後果：&lt;strong>換尺度是一種可以主動做的判斷&lt;/strong>。同一類問題反覆出現而每次都在原尺度處理，通常代表問題不在那一層——整理這段程式碼整理了五次而它還是難改，該往上看模組邊界；模組怎麼切都不對，該往上看系統的責任分配；而系統怎麼切都有人抱怨，那可能已經不是技術問題，走 &lt;a href="../software-management/topics/team-design/">組織結構與團隊設計&lt;/a>。&lt;/p>
&lt;p>反過來也成立。架構圖畫得再乾淨，落到每次修改仍然要有人決定先整理還是後整理，而那個決定沒有架構層的答案。&lt;/p>
&lt;p>&lt;a href="verification/">驗證自己寫對了&lt;/a> 不在這道刻度上，它是橫跨三個尺度的另一軸——每個尺度都要回答「我怎麼知道自己沒弄壞」，而那個問題在一次修改、模組邊界與系統拆分上會得到不同的答案。&lt;/p>
&lt;h2 id="這條線不做角色分眾">這條線不做角色分眾&lt;/h2>
&lt;p>管理那條線按讀者對什麼負責分成五個位置，這條線刻意不做同樣的事，理由是技藝問題跟職涯位置的相關性遠低於管理問題。&lt;/p>
&lt;p>資深工程師與剛入行的人在重構同一段程式碼時，需要的是同一本書；差別在讀得出多少，而那個差別已經寫在每本書的「讀得出價值的前提」裡，不需要再開一層路由承接。更根本的是這條線的主題本身就是分眾機制——讀者依當下在做什麼自己選尺度（我正在改這幾行、我在切模組、我在決定系統形狀），而那個選擇比職稱準確得多：同一個人在同一週可能三個尺度都碰到。&lt;/p>
&lt;p>因此這條線的入口是主題表，不是位置表。要按職涯位置選書的讀者，那條路在 &lt;a href="../software-management/roles/">依位置選書&lt;/a>，而那五篇也會在需要技藝內容時指過來。&lt;/p>
&lt;h2 id="四個主題裡只有系統架構接得住公開課">四個主題裡只有系統架構接得住公開課&lt;/h2>
&lt;p>讀不動長篇文字時，同一份知識的影音路徑由公開課承接，收錄門檻寫在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。這條線套用那兩條之後，接得住的只有 &lt;a href="system-architecture/">系統架構&lt;/a>，另外三個主題都沒查到，而它們空著的理由各自不同，寫在各篇的「為什麼只收這幾本」段內。這條線與 &lt;a href="../finance/">財務與投資&lt;/a> 的差別在沒查到的主題數：那條線四篇都有課，所以它不需要這樣一段線層說明，各篇自己交代就夠。&lt;/p>
&lt;p>那三個主題的共同點只到觀察為止：跟它們最相關的學院課都只有文字材料。這裡不往下推論知識類型，因為最順的那個推論站不住。順的推論是「判準沒有可以對答案的形式，所以進不了以作業與考試為骨架的課程」，而 MIT 的 6.005 Software Construction 直接否證它——大綱涵蓋規格、測試、抽象資料型別、物件導向設計模式、並行與函數式程式設計，跟這條線的設計判準重疊得最多，而它在 OpenCourseWare 上放的資源是考題、考題解答、習題與程式作業，判準出得了題也評得了分。它缺的只有影片，成因與知識類型無關：課程的 FAQ 自陳刻意不把課堂時間花在講課上，改成課前讀、課堂做練習，於是沒有可錄的講課。&lt;/p>
&lt;p>更廣的反例在同一所學校：Sloan 的 15.401 Finance Theory I（2008）與 15.S50 Poker Theory and Analytics（2015）都有完整的 lecture videos，可見同院同期的判斷型題材拍得出來。所以能說的只有結果——對讀不動文字的人，這三個主題目前沒有影音路徑——而成因逐篇不同，寫在各篇自己的收錄段。管理線那邊把同一件事分成三類成因（見 &lt;a href="../software-management/topics/">主題書單&lt;/a> 的公開課段），這條線對得上其中兩類：設計判準是「學院有課、只是沒有影片」，驗證是「市場供給充足而形態不對」；改既有的程式對不上任何一類，那正是這裡不往下推論的部分。&lt;/p>
&lt;p>市場那一側的供給充足而問的問題不同。以軟體測試或軟體工程為題的公開課數量不少，2026 年 8 月這一輪查到的多半是職涯訓練與面試準備，它們交付的是怎麼當一個測試工程師；驗證那一篇要交付的是三本書彼此不同意在哪。驗證那個主題因此不是被本質恆定那一條擋下來的——它是搜到的那些課與該主題不在同一層，逐篇的說明在各篇自己的收錄段。&lt;/p>
&lt;p>中文側的落差落在更前面一段。台大開放式課程的 &lt;a href="https://ocw.aca.ntu.edu.tw/courses/111S107">程式設計&lt;/a>（孔令傑，資訊管理學系，15 講，C++）教的是寫得出程式，課程頁自陳不預設任何程式背景，目標是讓學生之後能自學任何一種語言；這條線的四本起點書都預設讀者已經寫過一陣子程式，所以它落在這條線的入口之前而不在線上。程式經驗還沒建立起來的讀者從那裡開始，&lt;a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpBuSFO8-TtF_q5QlBfeb6Q0">YouTube 播放清單&lt;/a> 有全部 15 講。&lt;/p>
&lt;h2 id="跟教學系列的邊界">跟教學系列的邊界&lt;/h2>
&lt;p>書單給選讀判斷，實作在教學系列：各語言的寫法與慣例看 &lt;a href="https://tarrragon.github.io/blog/python/" data-link-title="Python 維護工程師實戰指南" data-link-desc="以 Hook 系統為範例的 Python 開發教學">Python&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/go/" data-link-title="Go 入門實戰指南" data-link-desc="理解 Go 語言精神與核心開發能力">Go&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/flutter/" data-link-title="Flutter 實戰指南" data-link-desc="Flutter 與 Dart 的實作層教材：型別設計與語言機制、狀態與渲染、測試策略、工具鏈，從實際專案 case 抽出判準。">Flutter&lt;/a>，測試分層與 mock 判斷看 &lt;a href="https://tarrragon.github.io/blog/testing/" data-link-title="開發測試實務指南" data-link-desc="測試全過而實機全壞、或程式碼由 agent 產出而無法逐行讀時，用來決定驗證該掛在哪幾層、每一層各自守不住什麼">Testing 測試策略&lt;/a>，領域模型的切法看 &lt;a href="https://tarrragon.github.io/blog/ddd/" data-link-title="DDD 領域驅動設計指南" data-link-desc="領域模型的理論與判準層：一袋欄位還是領域模型、什麼時候值得建 entity、不變式該落在哪一層強制、狀態轉換怎麼留下稽核軌跡、建構路徑怎麼設計。語言無關，實作限制路由到各語言模組。">DDD 領域驅動設計指南&lt;/a>。&lt;/p>
&lt;h2 id="backlog">Backlog&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>項目&lt;/th>
 &lt;th>類型&lt;/th>
 &lt;th>前置條件&lt;/th>
 &lt;th>規模&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>Open Yale Courses 四十門逐門判定&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>該站規模可窮盡，這一輪只按主題名取用；逐門過完才能把「沒查到」升級成「枚舉後沒有」&lt;/td>
 &lt;td>1 次&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>沒查到課的三個主題重掃一次&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>2027 年 8 月之後重跑，判準是本質恆定加實際有影音&lt;/td>
 &lt;td>1 次&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>設計判準這個主題改判&lt;/td>
 &lt;td>主章&lt;/td>
 &lt;td>MIT 6.005 補上影音，或找到另一門教設計判準而有影音的課；沒有人會主動去看，實際觸發點是 2027 年那次重掃&lt;/td>
 &lt;td>1 段&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table></description><content:encoded><![CDATA[<p>這條線處理的是<strong>一個人怎麼把軟體寫好、改好、維持得住</strong>。它跟 <a href="../software-management/">軟體管理與組織</a> 的分界在決定的對象：那條線的決定落在人與制度上，這條線的決定落在產物上。分界不落在「有沒有離開編輯器」——系統架構那篇的取捨要跨越團隊、資料與既有承諾，代價有一半落在組織上，但被決定的仍然是系統長什麼形狀。另有一條線 <a href="../finance/">財務與投資</a> 的決定落在自己的錢上，跟這裡不共用讀者位置。各線為什麼按這個軸分開，說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「書單線」段。</p>
<p>書的描述沿用同一套維度（<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>、時效狀態、<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>、讀得出價值的前提），定義與這些判定的來源說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>。這四篇的起點書用的也是同一組判準（涵蓋面優先、其次證據來源夠不夠支持那個用途、再其次可操作性），判準寫在 <a href="../software-management/topics/">主題書單</a> 的「起點書怎麼選出來的」段。驗證那篇是唯一的例外：它的起點取 Beck，理由是後面兩本都在跟它對話，那條「歷史先行性」不在三層判準裡。</p>
<h2 id="這條線特別要注意時效">這條線特別要注意時效</h2>
<p>技藝類的書比管理類更容易局部過時，因為它們的例子綁在語言、工具與當時的工程環境上。判斷方式不變——問這一段的論證依賴什麼前提——但套用時要多分一層：<strong>主張本身</strong>（模組該怎麼切、重複意味著什麼）通常比<strong>示範它的程式碼</strong>活得久。看到過時的語法不要連著把主張一起丟掉，那是這類書最常見的誤判。</p>
<p>反過來也成立：一本書的示範用了最新的語言特性，不代表它的主張比較新。</p>
<h2 id="主題">主題</h2>
<table>
  <thead>
      <tr>
          <th>主題</th>
          <th>承擔的問題</th>
          <th>起點書</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="design-and-practice/">設計判準與日常實踐</a></td>
          <td>怎麼寫出改得動的程式、日常工作該有哪些習慣</td>
          <td>The Pragmatic Programmer</td>
      </tr>
      <tr>
          <td><a href="changing-existing-code/">改既有的程式</a></td>
          <td>要動一段自己沒寫的、或沒有測試保護的程式碼</td>
          <td>Refactoring</td>
      </tr>
      <tr>
          <td><a href="system-architecture/">系統架構</a></td>
          <td>整個系統該長什麼形狀、拆分時每個選項的代價</td>
          <td>Fundamentals of Software Architecture</td>
      </tr>
      <tr>
          <td><a href="verification/">驗證自己寫對了</a></td>
          <td>該測到什麼程度、這裡到底該不該 mock</td>
          <td>Test-Driven Development: By Example</td>
      </tr>
  </tbody>
</table>
<h2 id="三個主題其實是同一組概念在三個尺度上運作">三個主題其實是同一組概念在三個尺度上運作</h2>
<p>這條線有四個主題，其中三個排在同一道刻度上。耦合與內聚這兩個概念貫穿它們，只是作用的範圍不同。Kent Beck 用它們算「這幾行現在要不要整理」，Ousterhout 用它們判斷「這個模組的介面該多深」，Richards 與 Ford 在元件層用同一組概念談切分與粒度。三個主題不是三種學問，是同一把尺在三個刻度上讀。這道刻度上的三本跟各篇的起點書只有一本重疊：架構那一層兩者都是 Richards 與 Ford，另外兩層不同——照起點書走的讀者在最小尺度落到的是 Fowler 而不是 Beck，在模組尺度落到的是 Pragmatic Programmer 而不是 Ousterhout。那兩本各自是所屬主題涵蓋面最廣的入口，而不是這把尺的刻度。要看這把尺，最小與模組兩層直接取 Beck 與 Ousterhout。</p>
<p>知道這件事有一個實用後果：<strong>換尺度是一種可以主動做的判斷</strong>。同一類問題反覆出現而每次都在原尺度處理，通常代表問題不在那一層——整理這段程式碼整理了五次而它還是難改，該往上看模組邊界；模組怎麼切都不對，該往上看系統的責任分配；而系統怎麼切都有人抱怨，那可能已經不是技術問題，走 <a href="../software-management/topics/team-design/">組織結構與團隊設計</a>。</p>
<p>反過來也成立。架構圖畫得再乾淨，落到每次修改仍然要有人決定先整理還是後整理，而那個決定沒有架構層的答案。</p>
<p><a href="verification/">驗證自己寫對了</a> 不在這道刻度上，它是橫跨三個尺度的另一軸——每個尺度都要回答「我怎麼知道自己沒弄壞」，而那個問題在一次修改、模組邊界與系統拆分上會得到不同的答案。</p>
<h2 id="這條線不做角色分眾">這條線不做角色分眾</h2>
<p>管理那條線按讀者對什麼負責分成五個位置，這條線刻意不做同樣的事，理由是技藝問題跟職涯位置的相關性遠低於管理問題。</p>
<p>資深工程師與剛入行的人在重構同一段程式碼時，需要的是同一本書；差別在讀得出多少，而那個差別已經寫在每本書的「讀得出價值的前提」裡，不需要再開一層路由承接。更根本的是這條線的主題本身就是分眾機制——讀者依當下在做什麼自己選尺度（我正在改這幾行、我在切模組、我在決定系統形狀），而那個選擇比職稱準確得多：同一個人在同一週可能三個尺度都碰到。</p>
<p>因此這條線的入口是主題表，不是位置表。要按職涯位置選書的讀者，那條路在 <a href="../software-management/roles/">依位置選書</a>，而那五篇也會在需要技藝內容時指過來。</p>
<h2 id="四個主題裡只有系統架構接得住公開課">四個主題裡只有系統架構接得住公開課</h2>
<p>讀不動長篇文字時，同一份知識的影音路徑由公開課承接，收錄門檻寫在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。這條線套用那兩條之後，接得住的只有 <a href="system-architecture/">系統架構</a>，另外三個主題都沒查到，而它們空著的理由各自不同，寫在各篇的「為什麼只收這幾本」段內。這條線與 <a href="../finance/">財務與投資</a> 的差別在沒查到的主題數：那條線四篇都有課，所以它不需要這樣一段線層說明，各篇自己交代就夠。</p>
<p>那三個主題的共同點只到觀察為止：跟它們最相關的學院課都只有文字材料。這裡不往下推論知識類型，因為最順的那個推論站不住。順的推論是「判準沒有可以對答案的形式，所以進不了以作業與考試為骨架的課程」，而 MIT 的 6.005 Software Construction 直接否證它——大綱涵蓋規格、測試、抽象資料型別、物件導向設計模式、並行與函數式程式設計，跟這條線的設計判準重疊得最多，而它在 OpenCourseWare 上放的資源是考題、考題解答、習題與程式作業，判準出得了題也評得了分。它缺的只有影片，成因與知識類型無關：課程的 FAQ 自陳刻意不把課堂時間花在講課上，改成課前讀、課堂做練習，於是沒有可錄的講課。</p>
<p>更廣的反例在同一所學校：Sloan 的 15.401 Finance Theory I（2008）與 15.S50 Poker Theory and Analytics（2015）都有完整的 lecture videos，可見同院同期的判斷型題材拍得出來。所以能說的只有結果——對讀不動文字的人，這三個主題目前沒有影音路徑——而成因逐篇不同，寫在各篇自己的收錄段。管理線那邊把同一件事分成三類成因（見 <a href="../software-management/topics/">主題書單</a> 的公開課段），這條線對得上其中兩類：設計判準是「學院有課、只是沒有影片」，驗證是「市場供給充足而形態不對」；改既有的程式對不上任何一類，那正是這裡不往下推論的部分。</p>
<p>市場那一側的供給充足而問的問題不同。以軟體測試或軟體工程為題的公開課數量不少，2026 年 8 月這一輪查到的多半是職涯訓練與面試準備，它們交付的是怎麼當一個測試工程師；驗證那一篇要交付的是三本書彼此不同意在哪。驗證那個主題因此不是被本質恆定那一條擋下來的——它是搜到的那些課與該主題不在同一層，逐篇的說明在各篇自己的收錄段。</p>
<p>中文側的落差落在更前面一段。台大開放式課程的 <a href="https://ocw.aca.ntu.edu.tw/courses/111S107">程式設計</a>（孔令傑，資訊管理學系，15 講，C++）教的是寫得出程式，課程頁自陳不預設任何程式背景，目標是讓學生之後能自學任何一種語言；這條線的四本起點書都預設讀者已經寫過一陣子程式，所以它落在這條線的入口之前而不在線上。程式經驗還沒建立起來的讀者從那裡開始，<a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpBuSFO8-TtF_q5QlBfeb6Q0">YouTube 播放清單</a> 有全部 15 講。</p>
<h2 id="跟教學系列的邊界">跟教學系列的邊界</h2>
<p>書單給選讀判斷，實作在教學系列：各語言的寫法與慣例看 <a href="/blog/python/" data-link-title="Python 維護工程師實戰指南" data-link-desc="以 Hook 系統為範例的 Python 開發教學">Python</a>、<a href="/blog/go/" data-link-title="Go 入門實戰指南" data-link-desc="理解 Go 語言精神與核心開發能力">Go</a>、<a href="/blog/flutter/" data-link-title="Flutter 實戰指南" data-link-desc="Flutter 與 Dart 的實作層教材：型別設計與語言機制、狀態與渲染、測試策略、工具鏈，從實際專案 case 抽出判準。">Flutter</a>，測試分層與 mock 判斷看 <a href="/blog/testing/" data-link-title="開發測試實務指南" data-link-desc="測試全過而實機全壞、或程式碼由 agent 產出而無法逐行讀時，用來決定驗證該掛在哪幾層、每一層各自守不住什麼">Testing 測試策略</a>，領域模型的切法看 <a href="/blog/ddd/" data-link-title="DDD 領域驅動設計指南" data-link-desc="領域模型的理論與判準層：一袋欄位還是領域模型、什麼時候值得建 entity、不變式該落在哪一層強制、狀態轉換怎麼留下稽核軌跡、建構路徑怎麼設計。語言無關，實作限制路由到各語言模組。">DDD 領域驅動設計指南</a>。</p>
<h2 id="backlog">Backlog</h2>
<table>
  <thead>
      <tr>
          <th>項目</th>
          <th>類型</th>
          <th>前置條件</th>
          <th>規模</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Open Yale Courses 四十門逐門判定</td>
          <td>案例</td>
          <td>該站規模可窮盡，這一輪只按主題名取用；逐門過完才能把「沒查到」升級成「枚舉後沒有」</td>
          <td>1 次</td>
      </tr>
      <tr>
          <td>沒查到課的三個主題重掃一次</td>
          <td>案例</td>
          <td>2027 年 8 月之後重跑，判準是本質恆定加實際有影音</td>
          <td>1 次</td>
      </tr>
      <tr>
          <td>設計判準這個主題改判</td>
          <td>主章</td>
          <td>MIT 6.005 補上影音，或找到另一門教設計判準而有影音的課；沒有人會主動去看，實際觸發點是 2027 年那次重掃</td>
          <td>1 段</td>
      </tr>
  </tbody>
</table>
]]></content:encoded></item><item><title>改既有的程式</title><link>https://tarrragon.github.io/blog/books/craft/changing-existing-code/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/craft/changing-existing-code/</guid><description>&lt;p>改既有的程式跟寫新的程式是兩種活。寫新的時候形狀由動手的人決定；改既有的時候形狀已經定了，動它的前提是不弄壞任何人依賴的行為。這件事的難度不由程式碼的複雜度決定，由&lt;strong>有沒有辦法知道自己弄壞了什麼&lt;/strong>決定——同一段程式，有測試時的改法跟沒測試時的改法完全不同。&lt;/p>
&lt;p>三本書按這條線分：有測試時怎麼做（Fowler 的《Refactoring》）、沒測試時怎麼先弄出測試（Feathers 的《Working Effectively with Legacy Code》）、以及改動小到不值得開專案時怎麼決定要不要現在做（Beck 的《Tidy First?》）。&lt;/p>
&lt;h2 id="起點是-refactoring">起點是 Refactoring&lt;/h2>
&lt;p>Martin Fowler 的《Refactoring》把這個主題編成一份目錄，第二版收了六十幾項具名重構，每一項都有動機、機制與範例——編成目錄這件事本身就是它涵蓋面最完整的原因，因為漏掉的手法在目錄裡是看得出來的。它同時定義了這個詞：重構是改變程式碼的內部結構而不改變其外部行為——這個定義比日常用法嚴格得多，而多數把「重構」用在大改寫上的溝通混亂都來自忽略後半句。&lt;/p>
&lt;p>&lt;strong>IDE 自動化之後這本書的價值在哪，是讀它之前最該想清楚的事。&lt;/strong> 目錄裡多數手法現在是一個快捷鍵：Extract Function、Rename、Move Method 都由工具代勞，而書裡那些「先做這步、再做這步、每步跑測試」的手動安全程序，實務上不會有人照著做。看到這裡就把整本書跳過是常見的誤判。&lt;/p>
&lt;p>被自動化的是機械步驟，沒有被自動化的是判斷：這段程式碼該不該提取、提取到哪一層、什麼訊號代表現在該動它。目錄的用途因此從「怎麼安全地手動做」轉成&lt;strong>一套共同詞彙&lt;/strong>——說得出「這裡要做的是 Replace Conditional with Polymorphism」的時候，審查討論的單位就從「我覺得這樣比較好」變成一個有明確前後狀態的動作。書中的程式碼異味清單（Code Smell）是這套詞彙的另一半，它命名的是動手的理由。&lt;/p>
&lt;p>版本要選：第二版（2018）把範例從 Java 換成 JavaScript，並補了不用 class 的函式式範例。這對讀者是真的取捨——寫 Java 的人第一版的範例反而貼近，而第二版的目錄本身有更新。時效上，被工具取代的是機械步驟而不是判斷——目錄裡多數手法現在是 IDE 的一個快捷鍵，那一層已經過時；命名這些動作的詞彙、以及判斷「現在該不該動它」的異味清單不依賴任何工具世代。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨客戶的顧問經驗（作者與貢獻者群的實務歸納），形式是目錄而非論證。&lt;/p>
&lt;p>這本要有一段程式碼在手上才讀得動——自己想改、但不確定怎麼下手的那種。沒有那段程式碼在手上，翻目錄的動作會停在「原來這叫 Extract Function」，而目錄真正的用法是反過來——手上有一個改不動的地方，去查它叫什麼。&lt;/p>
&lt;p>繁體中文版《重構（第二版）：改善既有程式的設計》，碁峰出版、賴屹民譯。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599">Amazon（Refactoring, 2nd Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010825896">博客來（重構（第二版）：改善既有程式的設計）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="手上沒有測試時讀-working-effectively-with-legacy-code">手上沒有測試時讀 Working Effectively with Legacy Code&lt;/h2>
&lt;p>Michael Feathers 這本補的是前一本假設已經存在、而現實中經常沒有的東西。它對遺留程式碼的定義是：&lt;strong>沒有測試的程式碼就是遺留程式碼&lt;/strong>，不論它上週才寫好。這個定義把問題從「這段程式碼有多老」換成「我改它的時候拿什麼確認自己沒弄壞」，而後者才是可以動手處理的。&lt;/p>
&lt;p>於是全書的主軸變成一個先有雞還是先有蛋的問題：要安全地改，得先有測試；要寫測試，得先把依賴切開；而切開依賴本身就是在改程式碼。Feathers 的解法是接縫（seam）——程式裡那些可以在不編輯該處的前提下改變行為的位置，找到它就有了掛測試的著力點。書末的二十四項解依賴技術是這套方法的目錄。&lt;/p>
&lt;p>它跟 Fowler 那本的關係是入場與正式作業：Feathers 負責把程式碼推到「已經進了測試控制」這個門檻，門檻之後 Fowler 的目錄才用得上。兩本沒有重疊。&lt;/p>
&lt;p>時效上，書中的範例語言（C++、Java、C）與那個年代的工具鏈已經隔了一段距離，測試框架的部分也是；接縫這個概念與二十四項技術處理的是靜態依賴怎麼被切開，那件事不依賴語言世代。證據來源是跨客戶的顧問經驗，來自作者在多個遺留系統上的現場工作。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，二十四項技術預設那份程式碼是動得了的——編譯、執行、加測試、改建置設定都做得到。系統只能透過廠商窗口改、或本機建不起來時，其中一半用不上，那種處境要先取得建置環境才談得上入場技術。&lt;/p>
&lt;p>這本要接手過一個沒有測試、而又被要求改動的系統才讀得出東西——沒有那個處境時，接縫會讀成一個過度講究的技巧。可以先知道它存在，接手那樣的系統時再拿出來。&lt;/p>
&lt;p>繁體中文版《Working Effectively with Legacy Code 中文版：管理、修改、重構遺留程式碼的藝術》，博碩出版。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052">Amazon（Working Effectively with Legacy Code）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010829482">博客來（Working Effectively with Legacy Code 中文版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要決定現在整理還是之後再說時讀-tidy-first">要決定「現在整理還是之後再說」時讀 Tidy First?&lt;/h2>
&lt;p>Kent Beck 的《Tidy First?》（2023）處理的是另外兩本沒有處理的那個決定：手上要改一個功能，而周圍的程式碼有點亂——先整理再改、改完再整理、還是不整理？這本書整本只回答這一個問題，很快就能讀完。它也是本篇門檻最低的一本，跟起點書不是同一本：起點取 Fowler 是因為涵蓋面，而 Fowler 那本要手上正有一段想改的程式碼才讀得出東西。要挑給一群程度不一的人共讀時取這本。&lt;/p>
&lt;p>它的做法是把整理當成一筆投資來算。整理現在要付成本、之後改動變便宜，而「之後」有多遠、會不會真的再改到這裡，決定了這筆投資划不划算。Beck 用耦合與內聚解釋成本從哪來，再用選擇權的概念解釋為什麼在不確定性高的時候保留彈性本身有價值。這是這個主題裡唯一把「要不要現在做」寫成可以推導的決定、而不是憑手感的一本。&lt;/p>
&lt;p>它跟另外兩本的分工是規模：Fowler 與 Feathers 處理的是動作本身怎麼做，這本處理的是動作要不要現在做、做多少。書中的整理項目刻意都很小（一次幾分鐘到一小時），因為它主張的正是小步——大改動需要批准、需要協調、會跟別人的工作衝突，而小到不需要開專案的改動可以隨時做。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗，加上他自己標明的經驗主義立場——書名的問號與副標的 personal exercise 都在說這是他的實踐而非通則，這個自我標定在技藝書裡少見。&lt;/p>
&lt;p>處境上，先整理再改這個取捨預設 commit 的節奏由動手的人自己控制。每個 commit 要對應一張工單、或整理型改動需要單獨送審的流程裡，整理的成本項要重算——書中算的是認知與風險成本，那些流程另外加上一筆固定的行政成本。時效上是這個主題最新的一本，尚無過時的部分。這本書幾乎不需要前置準備，但它預設讀者已經知道重構是什麼——完全沒有那個概念時，先讀 Fowler 的前幾章再回來。繁體中文版《先整理一下？｜個人層面的軟體設計考量》，歐萊禮出版。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Tidy-First-Personal-Exercise-Empirical/dp/1098151240">Amazon（Tidy First?: A Personal Exercise in Empirical Software Design）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0011008590">博客來（先整理一下？｜個人層面的軟體設計考量）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>手上有沒有測試，決定了哪一類技術用得上，所以這個主題的入口不只一個：有測試的走 Fowler 的目錄，沒有測試的走 Feathers 的入場技術，改動小到不值得開專案的走 Beck 的取捨算法。三本之間沒有重疊。&lt;/p>
&lt;p>重構主題的書市有一大類是特定語言的重構手冊，它們把 Fowler 的目錄翻譯成某個語言的慣用寫法。那類屬於教學系列而非書單的責任範圍，而且它們的時效跟語言版本綁在一起。看目錄裡的手法名稱就分得出來——手法名稱本身是某個語言的語法特徵時，那本書會隨那個語法的演進失效。&lt;/p>
&lt;p>Joshua Kerievsky 的《Refactoring to Patterns》把重構手法接到設計模式上，本書單未評估它。它的前提是讀者已經熟悉 GoF 設計模式，而那套模式在近年的適用性本身有討論——判斷這本書現在的價值要先處理那個前提，這裡沒有做。&lt;/p>
&lt;p>讀不動長篇文字的讀者在別的主題可以改走公開課，這個主題走不了。課堂教材要可控、可評分、每屆重複得了，而本篇三本書處理的&lt;strong>已經存在而且沒人想動的程式碼&lt;/strong>正好是這三項的反面——它的價值來自真實系統累積出來的歷史，那種材料課程取不到。所以這裡查不到課，而這是對缺席最合理的解釋、不是查證結果。整條線的供給狀況寫在 &lt;a href="../">工程技藝書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>改動的技術要用在對的地方，靠的是設計判準——什麼樣的結構值得改成、什麼樣的複雜度是根本問題。那條路徑走 &lt;a href="../design-and-practice/">設計判準與日常實踐&lt;/a>。&lt;/p>
&lt;p>要動的程式碼沒有測試而需要先補，測試該怎麼分層與設計看 &lt;a href="https://tarrragon.github.io/blog/testing/" data-link-title="開發測試實務指南" data-link-desc="測試全過而實機全壞、或程式碼由 agent 產出而無法逐行讀時，用來決定驗證該掛在哪幾層、每一層各自守不住什麼">Testing 測試策略&lt;/a>；大規模重構怎麼分階段推進、途中的常見失誤與作用域回歸風險，看 &lt;a href="https://tarrragon.github.io/blog/python/07-refactoring/" data-link-title="模組七：重構實戰" data-link-desc="基於 v0.28.0-v0.31.0 重構經驗的程式碼品質改善指南">Python 維護指南的重構章&lt;/a>，那裡有一個跨版本重構的完整實作案例。&lt;/p>
&lt;p>如果重構一直被排不進時程，那不是技藝問題——走 &lt;a href="../../software-management/topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a> 與 &lt;a href="../../software-management/topics/team-design/">組織結構與團隊設計&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>改既有的程式跟寫新的程式是兩種活。寫新的時候形狀由動手的人決定；改既有的時候形狀已經定了，動它的前提是不弄壞任何人依賴的行為。這件事的難度不由程式碼的複雜度決定，由<strong>有沒有辦法知道自己弄壞了什麼</strong>決定——同一段程式，有測試時的改法跟沒測試時的改法完全不同。</p>
<p>三本書按這條線分：有測試時怎麼做（Fowler 的《Refactoring》）、沒測試時怎麼先弄出測試（Feathers 的《Working Effectively with Legacy Code》）、以及改動小到不值得開專案時怎麼決定要不要現在做（Beck 的《Tidy First?》）。</p>
<h2 id="起點是-refactoring">起點是 Refactoring</h2>
<p>Martin Fowler 的《Refactoring》把這個主題編成一份目錄，第二版收了六十幾項具名重構，每一項都有動機、機制與範例——編成目錄這件事本身就是它涵蓋面最完整的原因，因為漏掉的手法在目錄裡是看得出來的。它同時定義了這個詞：重構是改變程式碼的內部結構而不改變其外部行為——這個定義比日常用法嚴格得多，而多數把「重構」用在大改寫上的溝通混亂都來自忽略後半句。</p>
<p><strong>IDE 自動化之後這本書的價值在哪，是讀它之前最該想清楚的事。</strong> 目錄裡多數手法現在是一個快捷鍵：Extract Function、Rename、Move Method 都由工具代勞，而書裡那些「先做這步、再做這步、每步跑測試」的手動安全程序，實務上不會有人照著做。看到這裡就把整本書跳過是常見的誤判。</p>
<p>被自動化的是機械步驟，沒有被自動化的是判斷：這段程式碼該不該提取、提取到哪一層、什麼訊號代表現在該動它。目錄的用途因此從「怎麼安全地手動做」轉成<strong>一套共同詞彙</strong>——說得出「這裡要做的是 Replace Conditional with Polymorphism」的時候，審查討論的單位就從「我覺得這樣比較好」變成一個有明確前後狀態的動作。書中的程式碼異味清單（Code Smell）是這套詞彙的另一半，它命名的是動手的理由。</p>
<p>版本要選：第二版（2018）把範例從 Java 換成 JavaScript，並補了不用 class 的函式式範例。這對讀者是真的取捨——寫 Java 的人第一版的範例反而貼近，而第二版的目錄本身有更新。時效上，被工具取代的是機械步驟而不是判斷——目錄裡多數手法現在是 IDE 的一個快捷鍵，那一層已經過時；命名這些動作的詞彙、以及判斷「現在該不該動它」的異味清單不依賴任何工具世代。<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨客戶的顧問經驗（作者與貢獻者群的實務歸納），形式是目錄而非論證。</p>
<p>這本要有一段程式碼在手上才讀得動——自己想改、但不確定怎麼下手的那種。沒有那段程式碼在手上，翻目錄的動作會停在「原來這叫 Extract Function」，而目錄真正的用法是反過來——手上有一個改不動的地方，去查它叫什麼。</p>
<p>繁體中文版《重構（第二版）：改善既有程式的設計》，碁峰出版、賴屹民譯。</p>
<ul>
<li><a href="https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599">Amazon（Refactoring, 2nd Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010825896">博客來（重構（第二版）：改善既有程式的設計）</a></li>
</ul>
<h2 id="手上沒有測試時讀-working-effectively-with-legacy-code">手上沒有測試時讀 Working Effectively with Legacy Code</h2>
<p>Michael Feathers 這本補的是前一本假設已經存在、而現實中經常沒有的東西。它對遺留程式碼的定義是：<strong>沒有測試的程式碼就是遺留程式碼</strong>，不論它上週才寫好。這個定義把問題從「這段程式碼有多老」換成「我改它的時候拿什麼確認自己沒弄壞」，而後者才是可以動手處理的。</p>
<p>於是全書的主軸變成一個先有雞還是先有蛋的問題：要安全地改，得先有測試；要寫測試，得先把依賴切開；而切開依賴本身就是在改程式碼。Feathers 的解法是接縫（seam）——程式裡那些可以在不編輯該處的前提下改變行為的位置，找到它就有了掛測試的著力點。書末的二十四項解依賴技術是這套方法的目錄。</p>
<p>它跟 Fowler 那本的關係是入場與正式作業：Feathers 負責把程式碼推到「已經進了測試控制」這個門檻，門檻之後 Fowler 的目錄才用得上。兩本沒有重疊。</p>
<p>時效上，書中的範例語言（C++、Java、C）與那個年代的工具鏈已經隔了一段距離，測試框架的部分也是；接縫這個概念與二十四項技術處理的是靜態依賴怎麼被切開，那件事不依賴語言世代。證據來源是跨客戶的顧問經驗，來自作者在多個遺留系統上的現場工作。</p>
<p><a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，二十四項技術預設那份程式碼是動得了的——編譯、執行、加測試、改建置設定都做得到。系統只能透過廠商窗口改、或本機建不起來時，其中一半用不上，那種處境要先取得建置環境才談得上入場技術。</p>
<p>這本要接手過一個沒有測試、而又被要求改動的系統才讀得出東西——沒有那個處境時，接縫會讀成一個過度講究的技巧。可以先知道它存在，接手那樣的系統時再拿出來。</p>
<p>繁體中文版《Working Effectively with Legacy Code 中文版：管理、修改、重構遺留程式碼的藝術》，博碩出版。</p>
<ul>
<li><a href="https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052">Amazon（Working Effectively with Legacy Code）</a></li>
<li><a href="https://www.books.com.tw/products/0010829482">博客來（Working Effectively with Legacy Code 中文版）</a></li>
</ul>
<h2 id="要決定現在整理還是之後再說時讀-tidy-first">要決定「現在整理還是之後再說」時讀 Tidy First?</h2>
<p>Kent Beck 的《Tidy First?》（2023）處理的是另外兩本沒有處理的那個決定：手上要改一個功能，而周圍的程式碼有點亂——先整理再改、改完再整理、還是不整理？這本書整本只回答這一個問題，很快就能讀完。它也是本篇門檻最低的一本，跟起點書不是同一本：起點取 Fowler 是因為涵蓋面，而 Fowler 那本要手上正有一段想改的程式碼才讀得出東西。要挑給一群程度不一的人共讀時取這本。</p>
<p>它的做法是把整理當成一筆投資來算。整理現在要付成本、之後改動變便宜，而「之後」有多遠、會不會真的再改到這裡，決定了這筆投資划不划算。Beck 用耦合與內聚解釋成本從哪來，再用選擇權的概念解釋為什麼在不確定性高的時候保留彈性本身有價值。這是這個主題裡唯一把「要不要現在做」寫成可以推導的決定、而不是憑手感的一本。</p>
<p>它跟另外兩本的分工是規模：Fowler 與 Feathers 處理的是動作本身怎麼做，這本處理的是動作要不要現在做、做多少。書中的整理項目刻意都很小（一次幾分鐘到一小時），因為它主張的正是小步——大改動需要批准、需要協調、會跟別人的工作衝突，而小到不需要開專案的改動可以隨時做。</p>
<p>證據來源是單一路徑的個人經驗，加上他自己標明的經驗主義立場——書名的問號與副標的 personal exercise 都在說這是他的實踐而非通則，這個自我標定在技藝書裡少見。</p>
<p>處境上，先整理再改這個取捨預設 commit 的節奏由動手的人自己控制。每個 commit 要對應一張工單、或整理型改動需要單獨送審的流程裡，整理的成本項要重算——書中算的是認知與風險成本，那些流程另外加上一筆固定的行政成本。時效上是這個主題最新的一本，尚無過時的部分。這本書幾乎不需要前置準備，但它預設讀者已經知道重構是什麼——完全沒有那個概念時，先讀 Fowler 的前幾章再回來。繁體中文版《先整理一下？｜個人層面的軟體設計考量》，歐萊禮出版。</p>
<ul>
<li><a href="https://www.amazon.com/Tidy-First-Personal-Exercise-Empirical/dp/1098151240">Amazon（Tidy First?: A Personal Exercise in Empirical Software Design）</a></li>
<li><a href="https://www.books.com.tw/products/0011008590">博客來（先整理一下？｜個人層面的軟體設計考量）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>手上有沒有測試，決定了哪一類技術用得上，所以這個主題的入口不只一個：有測試的走 Fowler 的目錄，沒有測試的走 Feathers 的入場技術，改動小到不值得開專案的走 Beck 的取捨算法。三本之間沒有重疊。</p>
<p>重構主題的書市有一大類是特定語言的重構手冊，它們把 Fowler 的目錄翻譯成某個語言的慣用寫法。那類屬於教學系列而非書單的責任範圍，而且它們的時效跟語言版本綁在一起。看目錄裡的手法名稱就分得出來——手法名稱本身是某個語言的語法特徵時，那本書會隨那個語法的演進失效。</p>
<p>Joshua Kerievsky 的《Refactoring to Patterns》把重構手法接到設計模式上，本書單未評估它。它的前提是讀者已經熟悉 GoF 設計模式，而那套模式在近年的適用性本身有討論——判斷這本書現在的價值要先處理那個前提，這裡沒有做。</p>
<p>讀不動長篇文字的讀者在別的主題可以改走公開課，這個主題走不了。課堂教材要可控、可評分、每屆重複得了，而本篇三本書處理的<strong>已經存在而且沒人想動的程式碼</strong>正好是這三項的反面——它的價值來自真實系統累積出來的歷史，那種材料課程取不到。所以這裡查不到課，而這是對缺席最合理的解釋、不是查證結果。整條線的供給狀況寫在 <a href="../">工程技藝書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>改動的技術要用在對的地方，靠的是設計判準——什麼樣的結構值得改成、什麼樣的複雜度是根本問題。那條路徑走 <a href="../design-and-practice/">設計判準與日常實踐</a>。</p>
<p>要動的程式碼沒有測試而需要先補，測試該怎麼分層與設計看 <a href="/blog/testing/" data-link-title="開發測試實務指南" data-link-desc="測試全過而實機全壞、或程式碼由 agent 產出而無法逐行讀時，用來決定驗證該掛在哪幾層、每一層各自守不住什麼">Testing 測試策略</a>；大規模重構怎麼分階段推進、途中的常見失誤與作用域回歸風險，看 <a href="/blog/python/07-refactoring/" data-link-title="模組七：重構實戰" data-link-desc="基於 v0.28.0-v0.31.0 重構經驗的程式碼品質改善指南">Python 維護指南的重構章</a>，那裡有一個跨版本重構的完整實作案例。</p>
<p>如果重構一直被排不進時程，那不是技藝問題——走 <a href="../../software-management/topics/estimation-decision/">估算、承諾與決策偏誤</a> 與 <a href="../../software-management/topics/team-design/">組織結構與團隊設計</a>。</p>
]]></content:encoded></item><item><title>處境相容性（context compatibility）</title><link>https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/</guid><description>&lt;p>處境相容性指一本書或一套做法預設的環境條件，在採用它的那個組織裡存不存在。它的失效長這樣：一本書的每一項建議都對，讀的人卻一項也動不了，因為那些建議預設的東西——一套職級表、一批待得夠久的成員、每天幾小時的重疊工時——這裡沒有。證據充分跟能不能落地是兩件事，前者由 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a> 判。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>它跟時效狀態的差別在軸的方向。時效問那個前提現在還在不在，是時間；處境相容性問它在這個組織裡在不在，是空間。一本 1987 年談中斷成本的書今天仍然成立，這是時效判定；同一本書預設團隊每天同處一室，而實際的八個人分在四個時區，這是處境判定。兩者會給出相反的結論，所以要分開問。這一組對照的第三邊是 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>：它問結論能推到多遠、時效問那個前提現在還在不在、處境問那個前提在這個組織裡在不在，三者互不替代，缺任何一項都會讓另外兩項的判定被誤用。&lt;/p>
&lt;h2 id="環境條件與它們缺席的樣子">環境條件與它們缺席的樣子&lt;/h2>
&lt;p>環境條件依領域實例化，這一項的判準不變而清單會換。下面四種是&lt;strong>組織與團隊題材&lt;/strong>的那一組，也是 &lt;a href="https://tarrragon.github.io/blog/books/software-management/" data-link-title="軟體管理與組織書單" data-link-desc="從只對自己的產出負責到對組織結構負責，各個位置當下該讀什麼、想換位置時該預習什麼">軟體管理與組織&lt;/a> 與 &lt;a href="https://tarrragon.github.io/blog/books/craft/" data-link-title="工程技藝書單" data-link-desc="想把軟體寫得更好、改得動、維持得住時該讀什麼——技藝層的判準，跟別人怎麼被組織無關">工程技藝&lt;/a> 兩條線在用的：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>組織形態&lt;/strong>：有沒有職級、績效與調薪制度可用。晉升、調薪、角色重新配置這類建議都預設有對應的流程可以走。缺席的典型是三十人以下、薪資由創辦人逐一談的公司，以及沒有職級表的接案團隊。&lt;/li>
&lt;li>&lt;strong>僱傭關係&lt;/strong>：成員是不是直屬部屬、待得夠不夠久、僱主是不是同一個。留任與凝聚類的建議預設投資關係划算，而那要成員待得夠久才成立。缺席的典型是成員來自外包商或人力派遣、以及專案結束就解散的編組——僱主不同一個，留任類的建議沒有對應的槓桿。&lt;/li>
&lt;li>&lt;strong>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>&lt;/strong>：每天重疊幾小時。這一項是連續量，不是同處一室與跨時區的二選一——中斷成本、凝聚、走廊上的一句話都建立在時間重疊上，而重疊多少決定那批論證失效多少。&lt;/li>
&lt;li>&lt;strong>法規環境&lt;/strong>：事故後有沒有法定的追責與報告義務。無指責檢討（事故調查只問系統怎麼允許這件事發生、不追究個人）這類主張在受監理的組織裡有法律邊界：金融、醫療、航空與上市公司的資安通報都有法定的追責與報告程序，那不是文化選擇。&lt;/li>
&lt;/ul>
&lt;p>換一個題材就換一組。&lt;a href="https://tarrragon.github.io/blog/books/finance/" data-link-title="財務與投資書單" data-link-desc="要決定錢往哪放、或要讀懂一份財報與一段總體環境時該讀什麼，以及哪些財務問題不該向書要答案">財務與投資&lt;/a> 那條線的環境是資本形態（會不會被生活需求打斷）、現金流的鬆緊與支出結構、幣別與匯率暴露、市場的資訊揭露程度、這個市場有沒有那類金融工具、以及所在經濟體的規模與資本開放程度——上面四項在那裡一項也對不上，照它逐項跑會全部落空。這六項裡後兩項是該線寫到第二、第四個主題時才補進去的，擴充的時機是既有項目對不上新收的書，判準寫在該線的入口頁。清單依線擴充，定義與判讀方式留在這張卡；各線用哪一組，寫在該線的入口頁。財務線另外把一類內容排除在這一項之外（稅制、退休金制度、投資額度這些每年變的），它們確實是環境，排除的理由在載體：書沒有更新路徑，承接不了要維持當期的內容——判別與處置見 &lt;a href="https://tarrragon.github.io/blog/report/current-content-needs-a-carrier-that-reaches-readers/" data-link-title="要維持當期的內容，只能放在更新到得了讀者的載體上" data-link-desc="某一類判定怎麼做都會過期、而直覺是把判定做得更細時，用來分辨該加深判定還是該換載體">#268&lt;/a> 與該線的「有些財務知識不該用書當載體」段。&lt;/p>
&lt;h2 id="缺席有兩種讀法要靠記錄分辨">缺席有兩種讀法，要靠記錄分辨&lt;/h2>
&lt;p>這一項有一個跟其他判定不同的性質：它的缺席有兩種讀法，而兩種讀法導出的動作相反。一本書沒有列出處境限制，可能是查過而沒有依賴，也可能是根本沒問過這個問題。前者是結論，後者是空白。&lt;/p>
&lt;p>分辨方式是看記錄有沒有把「查過」這件事本身寫下來。&lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>的做法是三分：寫出具體限制的、明說查過而沒有依賴的、以及尚未檢查的，三者分開計數。同一條推廣到任何判定框架的任何一維（空白與「查過而沒有依賴」長得一樣、而兩者導出的動作方向相反），寫在 &lt;a href="https://tarrragon.github.io/blog/report/current-content-needs-a-carrier-that-reaches-readers/" data-link-title="要維持當期的內容，只能放在更新到得了讀者的載體上" data-link-desc="某一類判定怎麼做都會過期、而直覺是把判定做得更細時，用來分辨該加深判定還是該換載體">#268&lt;/a> 的反模式段。&lt;/p>
&lt;p>讀者會在一個具體的時刻用到這個三分：看上一本書、那條書目沒有標任何處境限制，正要照它做。標成「查過而沒有依賴」時可以直接開始；標成「尚未檢查」時要自己先跑一次四種環境。少了這個區分，兩種狀態在頁面上長得一樣，而它們導出的動作相反。&lt;/p>
&lt;p>缺口的分布也帶訊息——同一個主題底下整批書都沒寫，表示那個主題沒問過這個問題；缺口按書散落，才代表逐本查過而只有部分有依賴。&lt;/p>
&lt;h2 id="判讀方式">判讀方式&lt;/h2>
&lt;p>這一項導出的是讀法而不是讀不讀。預設的環境不存在時，建立在那個環境上的那幾章自行折算或跳過，其餘照讀——一本十二章的書裡有三章預設了不存在的制度，剩下九章的價值不受影響。&lt;/p>
&lt;p>它可以獨立否決，條件很窄：整本書的推導都建立在同一個缺席的環境上時才成立。&lt;/p>
&lt;p>規模不在這張清單上，它由 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 列約束的那一段承接。這是編輯上的分工而不是概念上的界線：規模最常見的效果是把問題整個取消（一本教結構設計的書對三人公司，是那個問題還沒發生），而這裡幾項的效果多半是問題還在、建議動不了。兩者不是互斥的——僱傭關係缺席時，留任投資這個問題本身也不存在。規模放到約束那一段，是因為它同時牽動好幾個維度、放在單一維度底下會失真。這種情況下讀完得到的是一組動不了的處方，而且讀的過程不會給出任何訊號——書裡的每一步都合理，只是第一步的前提從一開始就不在。它長成這樣：一本從頭到尾在教怎麼設計職級階梯與調薪級距的書，對一個八個人、薪資由創辦人逐一談的團隊，每一章都建立在「有級距」這件事上；讀的時候不會卡，要動手時才發現第一步就沒有對象。&lt;/p>
&lt;p>否決之後要找的是另一個主題，不是同一個主題的第二本：預設有制度可用的書換不到「沒有制度時怎麼辦」，預設成員長期在職的書換不到交接與文件化的做法。有些約束連站外的替代方向都指不出來，那時停下來比繼續找書省時間。&lt;/p></description><content:encoded><![CDATA[<p>處境相容性指一本書或一套做法預設的環境條件，在採用它的那個組織裡存不存在。它的失效長這樣：一本書的每一項建議都對，讀的人卻一項也動不了，因為那些建議預設的東西——一套職級表、一批待得夠久的成員、每天幾小時的重疊工時——這裡沒有。證據充分跟能不能落地是兩件事，前者由 <a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a> 判。</p>
<h2 id="概念位置">概念位置</h2>
<p>它跟時效狀態的差別在軸的方向。時效問那個前提現在還在不在，是時間；處境相容性問它在這個組織裡在不在，是空間。一本 1987 年談中斷成本的書今天仍然成立，這是時效判定；同一本書預設團隊每天同處一室，而實際的八個人分在四個時區，這是處境判定。兩者會給出相反的結論，所以要分開問。這一組對照的第三邊是 <a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>：它問結論能推到多遠、時效問那個前提現在還在不在、處境問那個前提在這個組織裡在不在，三者互不替代，缺任何一項都會讓另外兩項的判定被誤用。</p>
<h2 id="環境條件與它們缺席的樣子">環境條件與它們缺席的樣子</h2>
<p>環境條件依領域實例化，這一項的判準不變而清單會換。下面四種是<strong>組織與團隊題材</strong>的那一組，也是 <a href="/blog/books/software-management/" data-link-title="軟體管理與組織書單" data-link-desc="從只對自己的產出負責到對組織結構負責，各個位置當下該讀什麼、想換位置時該預習什麼">軟體管理與組織</a> 與 <a href="/blog/books/craft/" data-link-title="工程技藝書單" data-link-desc="想把軟體寫得更好、改得動、維持得住時該讀什麼——技藝層的判準，跟別人怎麼被組織無關">工程技藝</a> 兩條線在用的：</p>
<ul>
<li><strong>組織形態</strong>：有沒有職級、績效與調薪制度可用。晉升、調薪、角色重新配置這類建議都預設有對應的流程可以走。缺席的典型是三十人以下、薪資由創辦人逐一談的公司，以及沒有職級表的接案團隊。</li>
<li><strong>僱傭關係</strong>：成員是不是直屬部屬、待得夠不夠久、僱主是不是同一個。留任與凝聚類的建議預設投資關係划算，而那要成員待得夠久才成立。缺席的典型是成員來自外包商或人力派遣、以及專案結束就解散的編組——僱主不同一個，留任類的建議沒有對應的槓桿。</li>
<li><strong><a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a></strong>：每天重疊幾小時。這一項是連續量，不是同處一室與跨時區的二選一——中斷成本、凝聚、走廊上的一句話都建立在時間重疊上，而重疊多少決定那批論證失效多少。</li>
<li><strong>法規環境</strong>：事故後有沒有法定的追責與報告義務。無指責檢討（事故調查只問系統怎麼允許這件事發生、不追究個人）這類主張在受監理的組織裡有法律邊界：金融、醫療、航空與上市公司的資安通報都有法定的追責與報告程序，那不是文化選擇。</li>
</ul>
<p>換一個題材就換一組。<a href="/blog/books/finance/" data-link-title="財務與投資書單" data-link-desc="要決定錢往哪放、或要讀懂一份財報與一段總體環境時該讀什麼，以及哪些財務問題不該向書要答案">財務與投資</a> 那條線的環境是資本形態（會不會被生活需求打斷）、現金流的鬆緊與支出結構、幣別與匯率暴露、市場的資訊揭露程度、這個市場有沒有那類金融工具、以及所在經濟體的規模與資本開放程度——上面四項在那裡一項也對不上，照它逐項跑會全部落空。這六項裡後兩項是該線寫到第二、第四個主題時才補進去的，擴充的時機是既有項目對不上新收的書，判準寫在該線的入口頁。清單依線擴充，定義與判讀方式留在這張卡；各線用哪一組，寫在該線的入口頁。財務線另外把一類內容排除在這一項之外（稅制、退休金制度、投資額度這些每年變的），它們確實是環境，排除的理由在載體：書沒有更新路徑，承接不了要維持當期的內容——判別與處置見 <a href="/blog/report/current-content-needs-a-carrier-that-reaches-readers/" data-link-title="要維持當期的內容，只能放在更新到得了讀者的載體上" data-link-desc="某一類判定怎麼做都會過期、而直覺是把判定做得更細時，用來分辨該加深判定還是該換載體">#268</a> 與該線的「有些財務知識不該用書當載體」段。</p>
<h2 id="缺席有兩種讀法要靠記錄分辨">缺席有兩種讀法，要靠記錄分辨</h2>
<p>這一項有一個跟其他判定不同的性質：它的缺席有兩種讀法，而兩種讀法導出的動作相反。一本書沒有列出處境限制，可能是查過而沒有依賴，也可能是根本沒問過這個問題。前者是結論，後者是空白。</p>
<p>分辨方式是看記錄有沒有把「查過」這件事本身寫下來。<a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>的做法是三分：寫出具體限制的、明說查過而沒有依賴的、以及尚未檢查的，三者分開計數。同一條推廣到任何判定框架的任何一維（空白與「查過而沒有依賴」長得一樣、而兩者導出的動作方向相反），寫在 <a href="/blog/report/current-content-needs-a-carrier-that-reaches-readers/" data-link-title="要維持當期的內容，只能放在更新到得了讀者的載體上" data-link-desc="某一類判定怎麼做都會過期、而直覺是把判定做得更細時，用來分辨該加深判定還是該換載體">#268</a> 的反模式段。</p>
<p>讀者會在一個具體的時刻用到這個三分：看上一本書、那條書目沒有標任何處境限制，正要照它做。標成「查過而沒有依賴」時可以直接開始；標成「尚未檢查」時要自己先跑一次四種環境。少了這個區分，兩種狀態在頁面上長得一樣，而它們導出的動作相反。</p>
<p>缺口的分布也帶訊息——同一個主題底下整批書都沒寫，表示那個主題沒問過這個問題；缺口按書散落，才代表逐本查過而只有部分有依賴。</p>
<h2 id="判讀方式">判讀方式</h2>
<p>這一項導出的是讀法而不是讀不讀。預設的環境不存在時，建立在那個環境上的那幾章自行折算或跳過，其餘照讀——一本十二章的書裡有三章預設了不存在的制度，剩下九章的價值不受影響。</p>
<p>它可以獨立否決，條件很窄：整本書的推導都建立在同一個缺席的環境上時才成立。</p>
<p>規模不在這張清單上，它由 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 列約束的那一段承接。這是編輯上的分工而不是概念上的界線：規模最常見的效果是把問題整個取消（一本教結構設計的書對三人公司，是那個問題還沒發生），而這裡幾項的效果多半是問題還在、建議動不了。兩者不是互斥的——僱傭關係缺席時，留任投資這個問題本身也不存在。規模放到約束那一段，是因為它同時牽動好幾個維度、放在單一維度底下會失真。這種情況下讀完得到的是一組動不了的處方，而且讀的過程不會給出任何訊號——書裡的每一步都合理，只是第一步的前提從一開始就不在。它長成這樣：一本從頭到尾在教怎麼設計職級階梯與調薪級距的書，對一個八個人、薪資由創辦人逐一談的團隊，每一章都建立在「有級距」這件事上；讀的時候不會卡，要動手時才發現第一步就沒有對象。</p>
<p>否決之後要找的是另一個主題，不是同一個主題的第二本：預設有制度可用的書換不到「沒有制度時怎麼辦」，預設成員長期在職的書換不到交接與文件化的做法。有些約束連站外的替代方向都指不出來，那時停下來比繼續找書省時間。</p>
]]></content:encoded></item><item><title>對技術品質負責、不帶人</title><link>https://tarrragon.github.io/blog/books/software-management/roles/technical-quality/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/technical-quality/</guid><description>&lt;p>這個位置的特徵是責任範圍超出自己動手的範圍，但權力沒有跟著擴大。技術決策錯了要被問，可是執行那些決策的人不歸這個位置管、排優先序時不必看它的意思、也沒有義務接受它的判斷。Staff 工程師、架構師、平台團隊的技術負責人、SRE 的技術主導都在這個位置。&lt;/p>
&lt;p>方案是對的但推不動，是這個位置的典型失敗；而它的形式通常是&lt;strong>被同意然後沒有發生&lt;/strong>，不是被否決。會議上大家點頭，回去照舊，因為那個方案沒有進到任何人的優先序裡。另一個高頻失敗是把標準寫成文件，就當作標準已經存在。文件不會約束任何人。約束來自 CI 擋不擋、review 過不過、以及不照做的時候會不會有人說話。&lt;/p>
&lt;h2 id="對技術品質負責時成文制度與否的差別">對技術品質負責時，成文制度與否的差別&lt;/h2>
&lt;p>有職級階梯的組織裡，這個位置通常有明確的頭銜（Staff、Principal），問題是&lt;strong>影響範圍與可見度的落差&lt;/strong>。做的事情橫跨多個團隊，每個團隊的主管卻只看得到自己那一段。切碎的形狀大致是這樣：花三個月讓四個團隊改用同一套部署流程，年度考評時主管收到的是四段各自兩三句的側面回饋，每一段聽起來都像「有幫忙」，沒有一段看得出那三個月。應對方式偏向留下跨團隊可見的產出（決策紀錄、遷移計畫、被引用的規範），而不是靠主管轉述。&lt;/p>
&lt;p>扁平的小公司通常沒有這個頭銜，這裡的人是「大家都會來問的那個人」。問題出在&lt;strong>邊界&lt;/strong>而非可見度：沒有頭銜也就沒有拒絕的依據，於是所有技術問題都流過來，把設定方向的時間吃成救火。這裡的關鍵能力是判斷什麼該接、什麼該退回。沒有職權時的「說不」通常是把成本攤開讓對方自己排序，而不是直接拒絕——「這件事我可以接，但它會讓遷移那條線延兩週，你要哪一個」比「我沒空」有用，因為前者把決定交回給有權決定的人，後者只是把問題推回去。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/role-transitions/">The Staff Engineer&amp;rsquo;s Path&lt;/a>&lt;/strong> 是這個位置的主要書。它把這個角色拆成三根支柱，其中一根正是上面說的「沒有職權的人如何設定標準」——那一塊在其他書裡少有處理，也是這個位置最難自己摸索出來的。三根支柱各是什麼在主題篇。想看這個位置在不同公司長什麼樣的人，Will Larson 的《Staff Engineer》收了多位 staff 工程師的訪談，兩本都在 &lt;a href="../../topics/role-transitions/">角色轉換與職涯路徑&lt;/a>。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/influence-conversation/">The Secrets of Consulting&lt;/a>&lt;/strong> 直接處理無職權推動改變。多數管理書預設讀者有直接權限，這本的處境設定是「被找來給建議、但決定權在別人手上」，跟這裡的處境幾乎一致——差別在它的作者退得掉，而站在這個位置的人退不掉，讀的時候要把那一段折算。書中處理的主題與證據判定在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/team-design/">Team Topologies&lt;/a>&lt;/strong> 在這個位置的用法是拿它當語言而不是拿它當方案。四種團隊型態與三種互動模式提供的是把「這兩個團隊該怎麼合作」講清楚的詞彙——站這個位置的人經常看得出問題出在交接面，卻只能說「他們配合度不好」——那句話推不動任何事。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/meeting-facilitation/">Facilitator&amp;rsquo;s Guide to Participatory Decision-Making&lt;/a>&lt;/strong> 對應的是上面那個「被同意然後沒有發生」。那個結果經常來自一場沒有真正收斂過的會議：意見攤開之後氣氛變難受，主持的人提早收攏，於是點頭的每個人各自帶著不同的理解離開。書中的鑽石模型把那段難受標成必經階段，用途是讓人在會議進行中就說得出「我們還沒收斂」，而不是散會兩週後才從執行狀況推回來。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/influence-conversation/">Difficult Conversations&lt;/a>&lt;/strong> 處理的是方案被反對時的那一場對話。三層對話的區分（事實、感受、身分認同）在技術爭論裡特別有用，因為技術爭論卡住的原因常常不在第一層——反對的人是在保護自己的判斷紀錄，而那件事在檯面上不會被說出來。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>進到這個位置的訊號通常是別人先開始把跨團隊的問題丟過來，職稱在那之後很久才追上。準備好的可觀察形式是這些事已經在做、而沒有人指派：主動去問隔壁團隊的計畫、在別人的設計討論裡被引用、寫的東西被當成別人的起點。這些累積夠了之後，要的是一個名分讓拒絕有依據，而不是一個新技能。&lt;/p>
&lt;p>&lt;strong>往更資深的技術路線&lt;/strong>：預習的是組織結構與系統架構這兩塊，而它們其實是同一件事的兩面——一個介面畫在哪裡，決定了哪兩個團隊要天天開會。組織那一面看 &lt;a href="../../topics/team-design/">組織結構與團隊設計&lt;/a> 的認知負荷段，系統那一面看 &lt;a href="../../../craft/system-architecture/">系統架構&lt;/a>：架構特性互相衝突、必須明確放棄一些，而那個取捨正是這個位置要能講清楚的東西。&lt;/p>
&lt;p>&lt;strong>往管理路線&lt;/strong>（&lt;a href="../people/">對人負責&lt;/a>）：預習的是人的問題，而這條路徑有一個具體的落差要注意——這裡練出來的是「不靠職權說服別人」，而管理位置需要的是「有職權時怎麼不濫用它」。這兩件事不是同一個技能的深淺，&lt;a href="../../topics/retention-motivation/">留任、動機與工作環境&lt;/a> 與 &lt;a href="../../topics/culture-safety/">組織文化與心理安全感&lt;/a> 是補這一塊的入口。&lt;/p>
&lt;p>&lt;strong>橫向移動回產品開發&lt;/strong>：這個方向不需要預習書單裡的東西，但值得先確認自己想離開的是這個位置還是這間公司的這個位置——兩者的解法不同。&lt;/p></description><content:encoded><![CDATA[<p>這個位置的特徵是責任範圍超出自己動手的範圍，但權力沒有跟著擴大。技術決策錯了要被問，可是執行那些決策的人不歸這個位置管、排優先序時不必看它的意思、也沒有義務接受它的判斷。Staff 工程師、架構師、平台團隊的技術負責人、SRE 的技術主導都在這個位置。</p>
<p>方案是對的但推不動，是這個位置的典型失敗；而它的形式通常是<strong>被同意然後沒有發生</strong>，不是被否決。會議上大家點頭，回去照舊，因為那個方案沒有進到任何人的優先序裡。另一個高頻失敗是把標準寫成文件，就當作標準已經存在。文件不會約束任何人。約束來自 CI 擋不擋、review 過不過、以及不照做的時候會不會有人說話。</p>
<h2 id="對技術品質負責時成文制度與否的差別">對技術品質負責時，成文制度與否的差別</h2>
<p>有職級階梯的組織裡，這個位置通常有明確的頭銜（Staff、Principal），問題是<strong>影響範圍與可見度的落差</strong>。做的事情橫跨多個團隊，每個團隊的主管卻只看得到自己那一段。切碎的形狀大致是這樣：花三個月讓四個團隊改用同一套部署流程，年度考評時主管收到的是四段各自兩三句的側面回饋，每一段聽起來都像「有幫忙」，沒有一段看得出那三個月。應對方式偏向留下跨團隊可見的產出（決策紀錄、遷移計畫、被引用的規範），而不是靠主管轉述。</p>
<p>扁平的小公司通常沒有這個頭銜，這裡的人是「大家都會來問的那個人」。問題出在<strong>邊界</strong>而非可見度：沒有頭銜也就沒有拒絕的依據，於是所有技術問題都流過來，把設定方向的時間吃成救火。這裡的關鍵能力是判斷什麼該接、什麼該退回。沒有職權時的「說不」通常是把成本攤開讓對方自己排序，而不是直接拒絕——「這件事我可以接，但它會讓遷移那條線延兩週，你要哪一個」比「我沒空」有用，因為前者把決定交回給有權決定的人，後者只是把問題推回去。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/role-transitions/">The Staff Engineer&rsquo;s Path</a></strong> 是這個位置的主要書。它把這個角色拆成三根支柱，其中一根正是上面說的「沒有職權的人如何設定標準」——那一塊在其他書裡少有處理，也是這個位置最難自己摸索出來的。三根支柱各是什麼在主題篇。想看這個位置在不同公司長什麼樣的人，Will Larson 的《Staff Engineer》收了多位 staff 工程師的訪談，兩本都在 <a href="../../topics/role-transitions/">角色轉換與職涯路徑</a>。</p>
<p><strong><a href="../../topics/influence-conversation/">The Secrets of Consulting</a></strong> 直接處理無職權推動改變。多數管理書預設讀者有直接權限，這本的處境設定是「被找來給建議、但決定權在別人手上」，跟這裡的處境幾乎一致——差別在它的作者退得掉，而站在這個位置的人退不掉，讀的時候要把那一段折算。書中處理的主題與證據判定在主題篇。</p>
<p><strong><a href="../../topics/team-design/">Team Topologies</a></strong> 在這個位置的用法是拿它當語言而不是拿它當方案。四種團隊型態與三種互動模式提供的是把「這兩個團隊該怎麼合作」講清楚的詞彙——站這個位置的人經常看得出問題出在交接面，卻只能說「他們配合度不好」——那句話推不動任何事。</p>
<p><strong><a href="../../topics/meeting-facilitation/">Facilitator&rsquo;s Guide to Participatory Decision-Making</a></strong> 對應的是上面那個「被同意然後沒有發生」。那個結果經常來自一場沒有真正收斂過的會議：意見攤開之後氣氛變難受，主持的人提早收攏，於是點頭的每個人各自帶著不同的理解離開。書中的鑽石模型把那段難受標成必經階段，用途是讓人在會議進行中就說得出「我們還沒收斂」，而不是散會兩週後才從執行狀況推回來。</p>
<p><strong><a href="../../topics/influence-conversation/">Difficult Conversations</a></strong> 處理的是方案被反對時的那一場對話。三層對話的區分（事實、感受、身分認同）在技術爭論裡特別有用，因為技術爭論卡住的原因常常不在第一層——反對的人是在保護自己的判斷紀錄，而那件事在檯面上不會被說出來。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>進到這個位置的訊號通常是別人先開始把跨團隊的問題丟過來，職稱在那之後很久才追上。準備好的可觀察形式是這些事已經在做、而沒有人指派：主動去問隔壁團隊的計畫、在別人的設計討論裡被引用、寫的東西被當成別人的起點。這些累積夠了之後，要的是一個名分讓拒絕有依據，而不是一個新技能。</p>
<p><strong>往更資深的技術路線</strong>：預習的是組織結構與系統架構這兩塊，而它們其實是同一件事的兩面——一個介面畫在哪裡，決定了哪兩個團隊要天天開會。組織那一面看 <a href="../../topics/team-design/">組織結構與團隊設計</a> 的認知負荷段，系統那一面看 <a href="../../../craft/system-architecture/">系統架構</a>：架構特性互相衝突、必須明確放棄一些，而那個取捨正是這個位置要能講清楚的東西。</p>
<p><strong>往管理路線</strong>（<a href="../people/">對人負責</a>）：預習的是人的問題，而這條路徑有一個具體的落差要注意——這裡練出來的是「不靠職權說服別人」，而管理位置需要的是「有職權時怎麼不濫用它」。這兩件事不是同一個技能的深淺，<a href="../../topics/retention-motivation/">留任、動機與工作環境</a> 與 <a href="../../topics/culture-safety/">組織文化與心理安全感</a> 是補這一塊的入口。</p>
<p><strong>橫向移動回產品開發</strong>：這個方向不需要預習書單裡的東西，但值得先確認自己想離開的是這個位置還是這間公司的這個位置——兩者的解法不同。</p>
]]></content:encoded></item><item><title>持續交付與交付效能</title><link>https://tarrragon.github.io/blog/books/software-management/topics/continuous-delivery/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/continuous-delivery/</guid><description>&lt;p>這個主題處理「怎麼知道一個做法真的有效」。軟體業長期靠資深者的經驗談傳遞判斷，而經驗談無法區分「這個做法有效」與「做這件事的那個人很強」。這個主題的書按證據強度分成三層——大規模實證、跨組織案例、單一組織的深度重建——三層各自可以支持的決定範圍不同，用錯層會在說服別人時失效。&lt;/p>
&lt;p>量測本身也在這個主題裡。選錯指標的組織會得到精確衡量的錯誤行為：以程式碼行數衡量產出、以工時衡量投入、以缺陷數衡量品質，每一個都會在幾個月內長出對應的規避行為。&lt;/p>
&lt;h2 id="起點是-accelerate">起點是 Accelerate&lt;/h2>
&lt;p>Nicole Forsgren、Jez Humble、Gene Kim 的《Accelerate》涵蓋了這個主題的完整座標，證據強度也是本篇最高的一本。它用心理計量與統計方法檢驗做法與績效的關係，產出四個指標：部署頻率、變更前置時間、變更失敗率、服務還原時間。這四項已經是業界共同語言，讀完之後其他書的討論才有對照基準。&lt;/p>
&lt;p>書裡最反直覺的結論是速度與穩定不是取捨關係。傳統假設認為部署越頻繁風險越高，因此要用審查與流程閘門把速度壓下來；資料顯示部署頻繁的組織同時擁有更低的變更失敗率與更快的還原時間。這個結論可以直接拿去回應「加閘門提升品質」這條管理直覺。&lt;/p>
&lt;p>書分三部分：研究發現與實踐、研究方法、組織轉型。研究方法那段常被跳過，但它才是這本書的結論可以支持實際決定的原因——它交代了怎麼設計問卷、怎麼處理自陳資料的偏誤、為什麼可以宣稱相關而非巧合。要引用書中結論說服別人的人，那段是前提。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是大規模實證，形式是跨組織調查與統計分析。時效上，資料採集期間持續交付與雲端部署已是主流，這是全書結論所依賴的前提，目前仍然成立。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，四項指標預設交付的兩端都在同一個組織裡——部署時機由團隊自己決定、部署目標是自己的生產環境。系統整合商與委外專案不是這樣：上線窗口由客戶排、生產環境是客戶的，變更前置時間與部署頻率有一半不由我方決定。這種處境要先把指標拆成我方可控與客戶決定兩組再看，否則會把客戶的排程記在團隊的帳上。讀得出價值的前提是：經歷過至少一次從提交到上線的完整交付流程。四項指標各自對應那段路上的一個位置，走過一次的人看得出它們量的是什麼。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339">Amazon（Accelerate: The Science of Lean Software and DevOps）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010913771">博客來（ACCELERATE：精益軟體與 DevOps 背後的科學）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要把結論落到操作時讀-the-devops-handbook">要把結論落到操作時讀 The DevOps Handbook&lt;/h2>
&lt;p>《The DevOps Handbook》與《Accelerate》分工明確：後者說什麼有效，前者說怎麼做。它把交付流程拆成建立快速流動、建立回饋迴路、建立持續學習文化三個層次，每層底下有技術實踐與組織實踐，並用案例說明導入時遇到什麼阻力。&lt;/p>
&lt;p>第二版的案例涵蓋 Adidas、美國航空、房利美、Target 與美國空軍，並由 Nicole Forsgren 補上研究面的洞察。這些案例多數不是網路原生公司，因此合規、既有系統、組織政治的阻力有比較誠實的記錄——這是它跟只寫成功故事的書的差別。&lt;/p>
&lt;p>證據來源是跨組織案例加上跨客戶的顧問經驗，強度低於大規模實證，高於單一路徑的個人經驗。時效上，第二版已把工具鏈章節更新到容器與雲原生環境，還沒有哪一段的前提被推翻。五百多頁，不是設計來一次讀完的；比較有效的用法是先讀三層框架，遇到具體問題再回頭查對應章節。這也表示它對經驗的要求分散在各章——手上有哪一段的問題就讀哪一段，不需要先具備整體經驗。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1950508404">Amazon（The DevOps Handbook, 2nd Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010962048">博客來（DevOps Handbook 中文版 第二版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="門檻最低的一本是鳳凰專案">門檻最低的一本是鳳凰專案&lt;/h2>
&lt;p>《The Phoenix Project》用小說形式講一個 IT 經理接手瀕臨崩潰的專案、被要求九十天內救回來的故事。它的功能是建立畫面感：工作在系統裡怎麼堆積、看不見的工作為什麼比看得見的危險、把 IT 工作類比成工廠產線之後哪些管理直覺可以搬過來。&lt;/p>
&lt;p>它的性質要說清楚：所有結論都由劇情推出來，沒有資料佐證。這使它適合拿給不讀技術書的主管或跨部門同事建立共同語言，不適合當作論證的依據。這也是它沒有被選為起點書的原因——涵蓋面排在 Accelerate 之後，而涵蓋面是&lt;a href="../">起點書判準&lt;/a>的第一順位，勝負在那裡就定了。讀得出價值的前提標不出條件——它是本篇唯一不需要任何前置經驗就讀得下去的一本。&lt;/p>
&lt;p>證據來源是虛構敘事，所有結論由劇情推出，另加作者的顧問觀察。時效上，書中的技術環境停在虛擬機與手動部署交界的年代，具體工具描述已經過時，而三步工作法與看不見的工作這兩個主軸不依賴那個前提。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290">Amazon（The Phoenix Project）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010765203">博客來（鳳凰專案：看 IT 部門如何讓公司從谷底翻身的傳奇故事）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="已經在跑生產環境時讀-google-sre">已經在跑生產環境時讀 Google SRE&lt;/h2>
&lt;p>Google 的《Site Reliability Engineering》是論文集，由 SRE 團隊成員各自撰寫章節。它的核心貢獻是把可靠性從「盡量不要出事」變成可以定價、可以編列預算的量。錯誤預算把可用性目標翻譯成「這一季還可以壞多久」，於是「要不要上這個功能」變成有數字可算的決定，而不是產品與維運的立場之爭。&lt;/p>
&lt;p>證據來源是單一組織的深度重建，形式是制度紀錄，這決定了它的用法：書中做法預設有專職團隊與內部工具鏈，直接照抄會做出過重的流程。讀它的價值在理解「為什麼在那個規模下這樣做合理」，然後判斷自己的規模需要哪一段。時效上，書出版於 2016 年，章節裡的內部工具與監控堆疊已與現況有距離，而錯誤預算、SLO/SLI 的定義方式與值班負載上限這幾條制度設計不依賴那些工具。這本要值過班才讀得動，或者處理過至少一次真實的生產事故。值班之前讀，錯誤預算是一個公式；值班之後讀，它是一個可以拿去跟產品談判的額度。&lt;/p>
&lt;p>書中的無指責檢討章節是另一條線的入口，完整的理論來源在 &lt;a href="../incident-blame/">事故、歸因與無指責檢討&lt;/a>。全文免費線上閱讀，包含原書、Workbook 與《Building Secure &amp;amp; Reliable Systems》。繁體中文版由歐萊禮出版、孫宇聰譯，譯名《網站可靠性工程｜Google 的系統管理之道》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://sre.google/books/">Google SRE 官方免費線上版&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Site-Reliability-Engineering-Production-Systems/dp/149192912X">Amazon（Site Reliability Engineering: How Google Runs Production Systems）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010770752">博客來（網站可靠性工程｜Google 的系統管理之道）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="量測的扭曲效應在溫伯格第-2-卷">量測的扭曲效應在溫伯格第 2 卷&lt;/h2>
&lt;p>Weinberg 的《Quality Software Management, Vol. 2: First-Order Measurement》處理的是量測這件事本身：怎麼知道專案的實際狀況、什麼該量、量測如何反過來扭曲被量測的行為。它主張多數組織的問題在於數據被用來評價人，於是數據開始服務評價而非服務判斷，缺乏數據反而很少是瓶頸。&lt;/p>
&lt;p>這一卷跟《Accelerate》的關係是互補而非替代。《Accelerate》回答該量什麼並提供統計佐證，這一卷回答量測制度在人身上會產生什麼副作用——後者沒有大規模實證，但這條線的其他書也沒有處理這個副作用。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗，書中自述取自他經手的案例。時效上，書中示範的量測技術（人工計數、抽樣觀察、紙本記錄）已被工具鏈取代，這部分讀起來像歷史；扭曲效應的論證建立在「被量測者知道自己被量測」這個前提上，那個前提沒有改變。讀得出價值的前提是一次親眼看過的變形：指標上線之後，行為跟著指標走。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Quality-Software-Management-First-Order-Measurement/dp/0932633242">Amazon（Quality Software Management: First-Order Measurement）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010411034">博客來（溫伯格的軟體管理學：第一級評量，第 2 卷）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>這個主題的書按證據強度分層，五本各承擔一層或一個獨立角色：統計實證（Accelerate）、跨組織案例（DevOps Handbook）、零門檻敘事（鳳凰專案）、單一組織的深度重建（Google SRE）、量測的副作用（溫伯格第 2 卷）。&lt;/p>
&lt;p>持續交付與 DevOps 的書在過去十年大量出版，多數重述四項指標或綁定特定工具鏈。前者與 Accelerate 承擔同一個角色，後者的內容會隨工具版本失效、且屬於教學系列而非書單的責任範圍。分辨方法是看它有沒有交代那四項指標的資料從哪來——只複述指標定義而不提資料來源的，承擔的是 Accelerate 已經承擔的角色。&lt;/p>
&lt;p>《Continuous Delivery》（Humble &amp;amp; Farley, 2010）是這個主題的奠基之作，本書單未評估它與《The DevOps Handbook》的內容重疊程度——判斷兩者是否可互相取代需要對讀，這裡沒有做。若已經讀過 Handbook 而想追溯部署管線設計原則的出處，那本仍然是原始來源。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而缺的不是數量：以它為名的課很多，內容集中在技巧演練與商業培訓，跨不過本質恆定那一條。它要的機制（研究設計與因果推論）在鄰近學科有課，只是這一輪沒有拿那組詞去搜。整條線的供給狀況與那個換法寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>指標定下來之後會立刻碰到組織問題：誰對指標負責、團隊怎麼切、交接面在哪。那些走 &lt;a href="../team-design/">組織結構與團隊設計&lt;/a>。&lt;/p>
&lt;p>指標回答的是「已經發生的事跑得多快」，而對外承諾的是還沒發生的事。要把實測分布用在承諾上，以及處理承諾失準的另外一半原因，走 &lt;a href="../estimation-decision/">估算、承諾與決策偏誤&lt;/a>。&lt;/p>
&lt;p>如果團隊已經在追指標、數字卻長期沒有改善，瓶頸通常在資料的可信度這一層而非指標選擇——沒有人願意回報壞消息時，所有指標都會漂亮。那條路徑走 &lt;a href="../culture-safety/">組織文化與心理安全感&lt;/a>。&lt;/p>
&lt;p>具體的管線設計、部署 gate 與環境分離看 &lt;a href="https://tarrragon.github.io/blog/ci/" data-link-title="CI/CD 教學" data-link-desc="整理 CI/CD 的驗證、建置、發布 gate 與不同部署場域的流程差異，讓每次變更都能被穩定驗證與交付">CI/CD 教學&lt;/a>，服務探活與容量規劃看 &lt;a href="https://tarrragon.github.io/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理「怎麼知道一個做法真的有效」。軟體業長期靠資深者的經驗談傳遞判斷，而經驗談無法區分「這個做法有效」與「做這件事的那個人很強」。這個主題的書按證據強度分成三層——大規模實證、跨組織案例、單一組織的深度重建——三層各自可以支持的決定範圍不同，用錯層會在說服別人時失效。</p>
<p>量測本身也在這個主題裡。選錯指標的組織會得到精確衡量的錯誤行為：以程式碼行數衡量產出、以工時衡量投入、以缺陷數衡量品質，每一個都會在幾個月內長出對應的規避行為。</p>
<h2 id="起點是-accelerate">起點是 Accelerate</h2>
<p>Nicole Forsgren、Jez Humble、Gene Kim 的《Accelerate》涵蓋了這個主題的完整座標，證據強度也是本篇最高的一本。它用心理計量與統計方法檢驗做法與績效的關係，產出四個指標：部署頻率、變更前置時間、變更失敗率、服務還原時間。這四項已經是業界共同語言，讀完之後其他書的討論才有對照基準。</p>
<p>書裡最反直覺的結論是速度與穩定不是取捨關係。傳統假設認為部署越頻繁風險越高，因此要用審查與流程閘門把速度壓下來；資料顯示部署頻繁的組織同時擁有更低的變更失敗率與更快的還原時間。這個結論可以直接拿去回應「加閘門提升品質」這條管理直覺。</p>
<p>書分三部分：研究發現與實踐、研究方法、組織轉型。研究方法那段常被跳過，但它才是這本書的結論可以支持實際決定的原因——它交代了怎麼設計問卷、怎麼處理自陳資料的偏誤、為什麼可以宣稱相關而非巧合。要引用書中結論說服別人的人，那段是前提。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是大規模實證，形式是跨組織調查與統計分析。時效上，資料採集期間持續交付與雲端部署已是主流，這是全書結論所依賴的前提，目前仍然成立。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，四項指標預設交付的兩端都在同一個組織裡——部署時機由團隊自己決定、部署目標是自己的生產環境。系統整合商與委外專案不是這樣：上線窗口由客戶排、生產環境是客戶的，變更前置時間與部署頻率有一半不由我方決定。這種處境要先把指標拆成我方可控與客戶決定兩組再看，否則會把客戶的排程記在團隊的帳上。讀得出價值的前提是：經歷過至少一次從提交到上線的完整交付流程。四項指標各自對應那段路上的一個位置，走過一次的人看得出它們量的是什麼。</p>
<ul>
<li><a href="https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339">Amazon（Accelerate: The Science of Lean Software and DevOps）</a></li>
<li><a href="https://www.books.com.tw/products/0010913771">博客來（ACCELERATE：精益軟體與 DevOps 背後的科學）</a></li>
</ul>
<h2 id="要把結論落到操作時讀-the-devops-handbook">要把結論落到操作時讀 The DevOps Handbook</h2>
<p>《The DevOps Handbook》與《Accelerate》分工明確：後者說什麼有效，前者說怎麼做。它把交付流程拆成建立快速流動、建立回饋迴路、建立持續學習文化三個層次，每層底下有技術實踐與組織實踐，並用案例說明導入時遇到什麼阻力。</p>
<p>第二版的案例涵蓋 Adidas、美國航空、房利美、Target 與美國空軍，並由 Nicole Forsgren 補上研究面的洞察。這些案例多數不是網路原生公司，因此合規、既有系統、組織政治的阻力有比較誠實的記錄——這是它跟只寫成功故事的書的差別。</p>
<p>證據來源是跨組織案例加上跨客戶的顧問經驗，強度低於大規模實證，高於單一路徑的個人經驗。時效上，第二版已把工具鏈章節更新到容器與雲原生環境，還沒有哪一段的前提被推翻。五百多頁，不是設計來一次讀完的；比較有效的用法是先讀三層框架，遇到具體問題再回頭查對應章節。這也表示它對經驗的要求分散在各章——手上有哪一段的問題就讀哪一段，不需要先具備整體經驗。</p>
<ul>
<li><a href="https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1950508404">Amazon（The DevOps Handbook, 2nd Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010962048">博客來（DevOps Handbook 中文版 第二版）</a></li>
</ul>
<h2 id="門檻最低的一本是鳳凰專案">門檻最低的一本是鳳凰專案</h2>
<p>《The Phoenix Project》用小說形式講一個 IT 經理接手瀕臨崩潰的專案、被要求九十天內救回來的故事。它的功能是建立畫面感：工作在系統裡怎麼堆積、看不見的工作為什麼比看得見的危險、把 IT 工作類比成工廠產線之後哪些管理直覺可以搬過來。</p>
<p>它的性質要說清楚：所有結論都由劇情推出來，沒有資料佐證。這使它適合拿給不讀技術書的主管或跨部門同事建立共同語言，不適合當作論證的依據。這也是它沒有被選為起點書的原因——涵蓋面排在 Accelerate 之後，而涵蓋面是<a href="../">起點書判準</a>的第一順位，勝負在那裡就定了。讀得出價值的前提標不出條件——它是本篇唯一不需要任何前置經驗就讀得下去的一本。</p>
<p>證據來源是虛構敘事，所有結論由劇情推出，另加作者的顧問觀察。時效上，書中的技術環境停在虛擬機與手動部署交界的年代，具體工具描述已經過時，而三步工作法與看不見的工作這兩個主軸不依賴那個前提。</p>
<ul>
<li><a href="https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290">Amazon（The Phoenix Project）</a></li>
<li><a href="https://www.books.com.tw/products/0010765203">博客來（鳳凰專案：看 IT 部門如何讓公司從谷底翻身的傳奇故事）</a></li>
</ul>
<h2 id="已經在跑生產環境時讀-google-sre">已經在跑生產環境時讀 Google SRE</h2>
<p>Google 的《Site Reliability Engineering》是論文集，由 SRE 團隊成員各自撰寫章節。它的核心貢獻是把可靠性從「盡量不要出事」變成可以定價、可以編列預算的量。錯誤預算把可用性目標翻譯成「這一季還可以壞多久」，於是「要不要上這個功能」變成有數字可算的決定，而不是產品與維運的立場之爭。</p>
<p>證據來源是單一組織的深度重建，形式是制度紀錄，這決定了它的用法：書中做法預設有專職團隊與內部工具鏈，直接照抄會做出過重的流程。讀它的價值在理解「為什麼在那個規模下這樣做合理」，然後判斷自己的規模需要哪一段。時效上，書出版於 2016 年，章節裡的內部工具與監控堆疊已與現況有距離，而錯誤預算、SLO/SLI 的定義方式與值班負載上限這幾條制度設計不依賴那些工具。這本要值過班才讀得動，或者處理過至少一次真實的生產事故。值班之前讀，錯誤預算是一個公式；值班之後讀，它是一個可以拿去跟產品談判的額度。</p>
<p>書中的無指責檢討章節是另一條線的入口，完整的理論來源在 <a href="../incident-blame/">事故、歸因與無指責檢討</a>。全文免費線上閱讀，包含原書、Workbook 與《Building Secure &amp; Reliable Systems》。繁體中文版由歐萊禮出版、孫宇聰譯，譯名《網站可靠性工程｜Google 的系統管理之道》。</p>
<ul>
<li><a href="https://sre.google/books/">Google SRE 官方免費線上版</a></li>
<li><a href="https://www.amazon.com/Site-Reliability-Engineering-Production-Systems/dp/149192912X">Amazon（Site Reliability Engineering: How Google Runs Production Systems）</a></li>
<li><a href="https://www.books.com.tw/products/0010770752">博客來（網站可靠性工程｜Google 的系統管理之道）</a></li>
</ul>
<h2 id="量測的扭曲效應在溫伯格第-2-卷">量測的扭曲效應在溫伯格第 2 卷</h2>
<p>Weinberg 的《Quality Software Management, Vol. 2: First-Order Measurement》處理的是量測這件事本身：怎麼知道專案的實際狀況、什麼該量、量測如何反過來扭曲被量測的行為。它主張多數組織的問題在於數據被用來評價人，於是數據開始服務評價而非服務判斷，缺乏數據反而很少是瓶頸。</p>
<p>這一卷跟《Accelerate》的關係是互補而非替代。《Accelerate》回答該量什麼並提供統計佐證，這一卷回答量測制度在人身上會產生什麼副作用——後者沒有大規模實證，但這條線的其他書也沒有處理這個副作用。</p>
<p>證據來源是跨客戶的顧問經驗，書中自述取自他經手的案例。時效上，書中示範的量測技術（人工計數、抽樣觀察、紙本記錄）已被工具鏈取代，這部分讀起來像歷史；扭曲效應的論證建立在「被量測者知道自己被量測」這個前提上，那個前提沒有改變。讀得出價值的前提是一次親眼看過的變形：指標上線之後，行為跟著指標走。</p>
<ul>
<li><a href="https://www.amazon.com/Quality-Software-Management-First-Order-Measurement/dp/0932633242">Amazon（Quality Software Management: First-Order Measurement）</a></li>
<li><a href="https://www.books.com.tw/products/0010411034">博客來（溫伯格的軟體管理學：第一級評量，第 2 卷）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>這個主題的書按證據強度分層，五本各承擔一層或一個獨立角色：統計實證（Accelerate）、跨組織案例（DevOps Handbook）、零門檻敘事（鳳凰專案）、單一組織的深度重建（Google SRE）、量測的副作用（溫伯格第 2 卷）。</p>
<p>持續交付與 DevOps 的書在過去十年大量出版，多數重述四項指標或綁定特定工具鏈。前者與 Accelerate 承擔同一個角色，後者的內容會隨工具版本失效、且屬於教學系列而非書單的責任範圍。分辨方法是看它有沒有交代那四項指標的資料從哪來——只複述指標定義而不提資料來源的，承擔的是 Accelerate 已經承擔的角色。</p>
<p>《Continuous Delivery》（Humble &amp; Farley, 2010）是這個主題的奠基之作，本書單未評估它與《The DevOps Handbook》的內容重疊程度——判斷兩者是否可互相取代需要對讀，這裡沒有做。若已經讀過 Handbook 而想追溯部署管線設計原則的出處，那本仍然是原始來源。</p>
<p>這個主題沒查到可以收的公開課，而缺的不是數量：以它為名的課很多，內容集中在技巧演練與商業培訓，跨不過本質恆定那一條。它要的機制（研究設計與因果推論）在鄰近學科有課，只是這一輪沒有拿那組詞去搜。整條線的供給狀況與那個換法寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>指標定下來之後會立刻碰到組織問題：誰對指標負責、團隊怎麼切、交接面在哪。那些走 <a href="../team-design/">組織結構與團隊設計</a>。</p>
<p>指標回答的是「已經發生的事跑得多快」，而對外承諾的是還沒發生的事。要把實測分布用在承諾上，以及處理承諾失準的另外一半原因，走 <a href="../estimation-decision/">估算、承諾與決策偏誤</a>。</p>
<p>如果團隊已經在追指標、數字卻長期沒有改善，瓶頸通常在資料的可信度這一層而非指標選擇——沒有人願意回報壞消息時，所有指標都會漂亮。那條路徑走 <a href="../culture-safety/">組織文化與心理安全感</a>。</p>
<p>具體的管線設計、部署 gate 與環境分離看 <a href="/blog/ci/" data-link-title="CI/CD 教學" data-link-desc="整理 CI/CD 的驗證、建置、發布 gate 與不同部署場域的流程差異，讓每次變更都能被穩定驗證與交付">CI/CD 教學</a>，服務探活與容量規劃看 <a href="/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運</a>。</p>
]]></content:encoded></item><item><title>會計與財報</title><link>https://tarrragon.github.io/blog/books/finance/accounting/</link><pubDate>Thu, 20 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/finance/accounting/</guid><description>&lt;p>會計是一組把交易轉換成三張報表的規則，而讀懂一份財報要的是反向的能力：從表上的數字回推當初發生過什麼，以及哪幾個數字的產生方式留有選擇空間。這條線把它放在讀懂層，因為它交付的是一種閱讀能力——這種能力本身不告訴讀者要買什麼或不買什麼，它讓後續的判斷有依據可用。&lt;/p>
&lt;p>這個主題分三個面。&lt;strong>結構&lt;/strong>是三張表怎麼接起來，以及為什麼一家公司可以帳上獲利而現金短缺。&lt;strong>選擇空間&lt;/strong>是同一筆交易在準則允許的範圍內有幾種認列方式（在哪一期、用多少金額入帳），以及管理層在什麼情況下有動機挑其中一種。&lt;strong>經營判讀&lt;/strong>是從表上的組合回推這門生意怎麼運作。三個面的先後不能換：認得出結構才看得出某個數字被挑過，看得出選擇空間才不會把修飾過的數字當成經營事實。&lt;/p>
&lt;p>本篇屬於 &lt;a href="../">財務與投資書單&lt;/a>，每本書都用同一組四項描述：&lt;strong>證據來源&lt;/strong>（它的結論建立在什麼材料上）、&lt;strong>時效狀態&lt;/strong>（哪些部分依賴已經改變的前提）、&lt;strong>處境相容性&lt;/strong>（讀者具不具備它預設的環境）、&lt;strong>讀得出價值的前提&lt;/strong>（要有什麼經驗才讀得出它的價值）。四項的完整定義與這些判定的可信度說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>。這四項描述的是書；讀不動長篇文字時，本篇文末另標出承接同一組內容的公開課，收錄門檻與已知限制見 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。&lt;/p>
&lt;h2 id="起點是財報就像一本故事書">起點是財報就像一本故事書&lt;/h2>
&lt;p>劉順仁的《財報就像一本故事書》三個面都碰，而它的涵蓋面優勢在第一個面：把五張報表之間的勾稽關係——同一筆交易在不同表上留下的數字必須互相對得起來——當成主線來寫，而不是把每張表分開介紹完就結束。這是這個主題的座標——讀者要先知道同一筆交易會在幾張表上各留下什麼痕跡，後面兩個面才有對照的基準。&lt;/p>
&lt;p>全書分心法、招式、進階三部分：報表的由來與功能、逐表的判讀方法與案例、以及經理人怎麼把報表用在自己的決定上。案例取自跨國與台灣的上市公司，作者是會計學者，敘述以解釋為主而非操作清單。&lt;/p>
&lt;p>起點書的選定在這一篇走到了第二層判準。它跟本篇第三本的涵蓋面差在一個面向以內——三個面兩本都碰得到，差別在重心落在哪一面——這時取證據來源足以支持「被拿去佐證實際決定」這個用途的那本（三層判準的完整說明在 &lt;a href="../../software-management/topics/">主題書單&lt;/a> 的判準段）。這一本的解讀建立在準則與報表定義上，引用出去之後對方追問依據時指得回公開的規則；第三本的門檻由作者從一批公司的分佈歸納，追問「這條線哪裡來的」時指回的是作者的執業經驗。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是理論建構加跨組織案例：把準則、報表結構與公司案例組織成一套解讀方式，不產生新證據，價值在串連。&lt;/p>
&lt;p>時效這一項在這本書上要分三段判，而它剛好示範了同一本書內部的衰減速度可以差好幾倍。三表之間的勾稽關係不隨準則改版而動。個別科目的認列方式會隨準則更新而變，判斷方式是看該節依據的是哪一版準則。第三段是增訂版加寫的兩塊——以生成式 AI 工具輔助財報分析的操作說明、以及永續資訊揭露的章節——這兩塊依賴當期的工具介面與當期的揭露規範，是全書衰減最快的部分。&lt;strong>這一項可以直接核對&lt;/strong>：翻到那幾節，看它點名的工具與規範現在還在不在。&lt;/p>
&lt;p>處境相容性上，案例以公開發行公司為主，那些判讀依賴一組只有公開發行才有的揭露——附註、分部資訊、關係人交易揭露。往來的對象是未上市中小企業時，手上拿得到的報表沒有那幾層，判讀方式要換，差別的形狀寫在 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/company-public-disclosure-levels/" data-link-title="公司公開程度：上市 / 上櫃 / 公開發行未上市 / 未公開發行" data-link-desc="判斷一間公司的財報查不查得到時，區分「股票有沒有在交易所交易」與「有沒有依法申報公開財報」——兩者是不同軸，公開發行未上市的公司沒有股價、卻有完整公開財報">公司公開程度&lt;/a>。&lt;/p>
&lt;p>讀得出價值的前提幾乎沒有，是本篇可以零基礎開始的一本。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/014916585">三民（財報就像一本故事書，20 週年與時俱進增訂版，時報文化，2025）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="數字被挑過的痕跡長什麼樣看財報詭計">數字被挑過的痕跡長什麼樣，看財報詭計&lt;/h2>
&lt;p>Howard Schilit、Jeremy Perler 與 Yoni Engelhart 的《財報詭計》處理第二個面：準則允許的範圍內，數字可以被挑成什麼樣子。它把手法分成四類——操弄盈餘、操弄現金流、操弄關鍵指標、以及併購會計，各類底下再拆成具體形態，每一種都附上實際發生過的公司案例。&lt;/p>
&lt;p>它在這個主題的位置是把「選擇空間」從一個抽象說法變成一份可以逐項比對的清單。認列時點提前、把融資性現金流入放進營業活動、換一個自訂的績效指標來報——這幾種在報表上留下的痕跡各不相同，而知道要找哪個痕跡以前，讀者看到的只是一組沒有異常感的數字。&lt;/p>
&lt;p>證據來源是跨組織案例，材料是數十家公司的實際申報，以及後續的財報重編（更正已經公告過的數字）或訴訟紀錄。這個類別支持得了「這條路別人走過」，支持不了「出現這個特徵就是舞弊」——每一種手法的合法版本與越線版本共用同一個報表外觀，書中給的是要追問什麼，不是判定規則。&lt;/p>
&lt;p>時效上有一個可以核對的過時前提：部分手法依賴特定期間的準則漏洞，而收入認列準則整併之後，某幾種提前認列的做法在新規範下難以維持原樣。另一邊不隨版本改變的是動機結構——管理層在什麼壓力下會想挑一個數字。判斷某一節屬於哪一邊，看它的論證依賴的是某條規則的寫法，還是某種壓力的存在。&lt;/p>
&lt;p>處境相容性上，案例以美國上市公司與該國證券主管機關的申報為主。手法的形態可以移植，查證的落點要換：台灣的公開資訊查詢入口、揭露格式與重編紀錄都在另一套系統上，而那套系統的名稱與介面歷來改過幾次，用之前確認當期入口。&lt;/p>
&lt;p>讀得出價值的前提是讀得懂三張報表，起點書提供的程度就夠。缺這個底子時，書中的手法讀起來是一串名詞。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/012945324">三民（財報詭計：識破財報三表中的會計舞弊與騙局，全新修訂版，感電，2024，譯自 Financial Shenanigans 第四版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="大會計師教你從財報數字看懂經營本質把表接回生意">大會計師教你從財報數字看懂經營本質把表接回生意&lt;/h2>
&lt;p>報表上的組合說明這門生意怎麼運作、以及它的體質落在哪裡，張明輝的這一本接的是這一面。作者的經歷是四大會計師事務所的實務端——曾任資誠聯合會計師事務所所長，執業三十餘年——所以書中的判讀多半從「這個數字為什麼會長成這樣」出發，而不是從準則條文出發。&lt;/p>
&lt;p>它在本篇的另一個作用是提供台灣的參照。案例與比率門檻取自台灣上市櫃公司的實際分佈，這讓讀者第一次把書上的判讀套到手邊查得到的財報時，中間少一層換算。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨客戶的顧問經驗加跨組織案例。這個類別提供別處拿不到的細節與語言，答不了「這條判準在我要看的那家公司也成立嗎」——書中的門檻是從一批公司的分佈歸納出來的，而分佈會隨產業與期間改變。&lt;/p>
&lt;p>這本書有一部分越過讀懂層的邊界，值得先標出來。它給出可以直接照抄的比率門檻，而 &lt;a href="../">財務與投資書單&lt;/a> 對讀懂層的起點書判準明說不把可操作性算進加分——理由是給一組可以照抄的比率屬於決定層的事。它仍然收在這一篇，因為那些門檻在書中的角色是解釋的結論而非判斷的入口：每個門檻後面接的是這個產業為什麼會落在這個帶。使用時把它們當成該產業在該期間的分佈，而非通用標準——直接拿來比對一家公司之前，先看 &lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/industry-benchmarking/" data-link-title="產業基準分析：怎麼判斷一間公司的數字是正常、優秀還是異常" data-link-desc="社群說「這個產業就是這樣」時，自己建立產業基準、構建比較組、判讀偏離方向的方法——從公開資料源到異常訊號的判讀">產業基準分析&lt;/a> 的比較組建構，以及那組基準的名冊有沒有被 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a> 篩過。&lt;/p>
&lt;p>時效上，增訂版以近年財報重寫案例，而比率門檻依賴當期的產業結構，這一項每隔幾年就要重看。作假特徵那幾節與前一本重疊，兩本的差別在視角：前一本從查核與申報紀錄看，這一本從經營現場看。&lt;/p>
&lt;p>處境相容性上，這是三本裡最貼近台灣讀者的一本，代價在同一處：它的門檻取自台灣的產業結構與稅制環境，換到另一個市場要重新取分佈。&lt;/p>
&lt;p>讀得出價值的前提是有過一次要判斷一家公司值不值得往來或投入的處境。缺這個處境時，書中的門檻讀起來是一組數字，而那些數字要回答的問題不在手上。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/012427000">三民（大會計師教你從財報數字看懂經營本質，增訂版．全新案例，商業周刊，2023）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>三本各接一個面：結構、選擇空間、經營判讀。角色不重疊的檢驗方式是看讀完之後多出什麼能力——第一本讓人看得懂表，第二本讓人看得出某個數字被挑過，第三本讓人從表回推生意。&lt;/p>
&lt;p>讀懂層不把可操作性算進加分，這條在本主題的具體形狀是：整本在給一組選股比率與買賣門檻的書不收，它們要回答的問題落在決定層，而它們預設讀者已經有這一篇要建立的能力。&lt;/p>
&lt;p>準則條文書與考試用書同樣不收，理由是載體。準則每年更新，條文書的正確性依賴當期版本，而書不隨版本重印到讀者手上；要查當期條文的落點是準則公報本身與主管機關的公告。它們的讀者也不同——編表的人與考照的人需要條文，讀表的人需要的是結構與選擇空間。&lt;/p>
&lt;p>跟教學系列的分工畫在產出上。&lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/sme-listed-company-financial-analysis/" data-link-title="企業財報判讀：中小企業經營評估與上市櫃公司供需及資金鏈分析" data-link-desc="評估中小企業的經營體質或判讀上市櫃公司的供需週轉與資金鏈健康度時，從三張報表的關係、營運週轉效率、負債結構、財報紅旗等維度做結構性分析的方法">企業財報判讀&lt;/a> 與那個模組的其他篇教的是一套可以直接執行的判讀流程，材料是站內的實際案例；這一篇回答的是要建立這種閱讀能力該讀哪一本、那本書的哪一部分會隨準則改版而失效。兩邊互相不依賴：教學系列不預設讀者讀過任何一本書，這一篇也不重述那套流程。&lt;/p>
&lt;h2 id="台大的三門初會把每個科目都做過一遍比本篇任何一本書細">台大的三門初會把每個科目都做過一遍，比本篇任何一本書細&lt;/h2>
&lt;p>台大開放式課程的初級會計學三門接&lt;strong>結構&lt;/strong>這一面，涵蓋的科目數比本篇任何一本書多——這一項從三門的單元標題就數得出來，不必看完課程。陳坤志（會計學系）主講，順序照會計本身推：初級會計學一從會計之所以為會計、記錄程序、帳戶調整走到買賣業的會計循環、收入認列、內部控制與現金，七講；初級會計學二逐一處理資產與負債的科目——應收帳款、存貨，不動產、廠房與設備，天然資源與無形資產，負債，五講；初級會計學三收在股東權益、投資、現金流量表與財務報表分析，四講。每講一到兩小時。三門合起來是一門完整的初會，而單元順序是照科目推進的，勾稽關係落在哪幾講由那個順序決定。&lt;/p>
&lt;p>跟起點書的分工落在深度與代價上。起點書用五張報表的勾稽當主線、四百多頁走完；課程要十六講的時間，換到的是每個科目的認列方式都被實際做過一遍。目標是看得懂表，起點書夠用；目標是自己判斷某個數字怎麼被算出來，課程給的底更厚。&lt;/p>
&lt;p>&lt;strong>經營判讀&lt;/strong>由台大的另一門課「財務報告分析」承接。陳明賢（財務金融學系）主講、十講，從財務報表分析的目的與使用者是誰開始，走到企業購併的評價方法。它跟本篇的《大會計師教你從財報數字看懂經營本質》都從經營現場看報表，差別在課程把評價那一段也納進來，而評價屬於這條線的決定層、本篇不收。&lt;/p>
&lt;p>&lt;strong>選擇空間&lt;/strong>這個問題，這一輪沒有查到對應的課。初會課教的是準則怎麼規定，選擇空間要問的是準則留下多少餘地，兩者用同一批科目而問題相反。只走課程路線的人讀得出報表怎麼組成，讀不出某個數字被挑過，那一半在本書單目前只有《財報詭計》承接得了。&lt;/p>
&lt;p>四門都是中文授課，這是這個主題跟 &lt;a href="../investing/">資本配置與投資&lt;/a> 最大的差別——那一篇的兩門是英語課堂實錄。門檻上初會三門不預設會計背景、財務報告分析預設讀得懂三張表；純靠聽的讀者要知道分錄與 T 帳戶那幾講高度依賴板書，離開畫面會聽不完整。時效上，會計循環與三表勾稽不隨準則改版而動，理由跟起點書那一項判定相同；會受影響的是個別科目的認列，而錄製年份寫在課程頁上，比書的版次好查。財務報告分析那一門另有一段依賴當期環境：企業購併的評價方法會隨市場的評價慣例走。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://ocw.aca.ntu.edu.tw/courses/mooc0066">台大開放式課程（mooc0066 初級會計學一：會計循環與收入認列，陳坤志，7 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpAAbR1Tp3Bw7Z6Qi9Bz4lfD">YouTube 播放清單（初會一）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://ocw.aca.ntu.edu.tw/courses/mooc0067">台大開放式課程（mooc0067 初級會計學二：資產與負債，陳坤志，5 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpC8yKP8v-1MDECH68Vw1wcK">YouTube 播放清單（初會二）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://ocw.aca.ntu.edu.tw/courses/mooc0068">台大開放式課程（mooc0068 初級會計學三：股東權益與現金流量，陳坤志，4 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpD6UjWEqXAYFsN-Csj4FJA7">YouTube 播放清單（初會三）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://ocw.aca.ntu.edu.tw/courses/113S103">台大開放式課程（113S103 財務報告分析，陳明賢，10 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpCqTgOXrL57c0OcBhMmPQ_-">YouTube 播放清單（財務報告分析）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>讀完之後要把能力用在具體公司上，走 &lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/" data-link-title="企業財務分析與投資評估" data-link-desc="從損益表識讀到產業供應鏈分析的系統性商業評估方法——涵蓋報表判讀、公司定位、產業基準、估值方法、外部衝擊判讀，以及真實上市公司的批判性案例分析">企業財務分析與投資評估&lt;/a>：報表識讀路線從損益表的四層分析開始，投資評估路線從企業評估定位開始。&lt;/p>
&lt;p>&lt;a href="../investing/">資本配置與投資&lt;/a> 收的《The Intelligent Investor》要求的財報底子，這一篇的起點書承接得了——那本書的篩選條件章節預設讀者讀得懂比率的組成。&lt;/p>
&lt;p>一家公司的報表落在什麼位置，要對照同業與產業結構，走 &lt;a href="https://tarrragon.github.io/blog/business/" data-link-title="商業概念與策略分析" data-link-desc="整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識，並提供閱讀商業分析的框架">商業概念與策略分析&lt;/a>。要判斷手上這組同業基準的名冊有沒有被篩過，走 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a>。&lt;/p>
&lt;p>利率與通膨在改變報表上的哪幾個科目——利息費用、存貨評價、匯兌損益——走 &lt;a href="../macroeconomics/">總體經濟&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>會計是一組把交易轉換成三張報表的規則，而讀懂一份財報要的是反向的能力：從表上的數字回推當初發生過什麼，以及哪幾個數字的產生方式留有選擇空間。這條線把它放在讀懂層，因為它交付的是一種閱讀能力——這種能力本身不告訴讀者要買什麼或不買什麼，它讓後續的判斷有依據可用。</p>
<p>這個主題分三個面。<strong>結構</strong>是三張表怎麼接起來，以及為什麼一家公司可以帳上獲利而現金短缺。<strong>選擇空間</strong>是同一筆交易在準則允許的範圍內有幾種認列方式（在哪一期、用多少金額入帳），以及管理層在什麼情況下有動機挑其中一種。<strong>經營判讀</strong>是從表上的組合回推這門生意怎麼運作。三個面的先後不能換：認得出結構才看得出某個數字被挑過，看得出選擇空間才不會把修飾過的數字當成經營事實。</p>
<p>本篇屬於 <a href="../">財務與投資書單</a>，每本書都用同一組四項描述：<strong>證據來源</strong>（它的結論建立在什麼材料上）、<strong>時效狀態</strong>（哪些部分依賴已經改變的前提）、<strong>處境相容性</strong>（讀者具不具備它預設的環境）、<strong>讀得出價值的前提</strong>（要有什麼經驗才讀得出它的價值）。四項的完整定義與這些判定的可信度說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>。這四項描述的是書；讀不動長篇文字時，本篇文末另標出承接同一組內容的公開課，收錄門檻與已知限制見 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。</p>
<h2 id="起點是財報就像一本故事書">起點是財報就像一本故事書</h2>
<p>劉順仁的《財報就像一本故事書》三個面都碰，而它的涵蓋面優勢在第一個面：把五張報表之間的勾稽關係——同一筆交易在不同表上留下的數字必須互相對得起來——當成主線來寫，而不是把每張表分開介紹完就結束。這是這個主題的座標——讀者要先知道同一筆交易會在幾張表上各留下什麼痕跡，後面兩個面才有對照的基準。</p>
<p>全書分心法、招式、進階三部分：報表的由來與功能、逐表的判讀方法與案例、以及經理人怎麼把報表用在自己的決定上。案例取自跨國與台灣的上市公司，作者是會計學者，敘述以解釋為主而非操作清單。</p>
<p>起點書的選定在這一篇走到了第二層判準。它跟本篇第三本的涵蓋面差在一個面向以內——三個面兩本都碰得到，差別在重心落在哪一面——這時取證據來源足以支持「被拿去佐證實際決定」這個用途的那本（三層判準的完整說明在 <a href="../../software-management/topics/">主題書單</a> 的判準段）。這一本的解讀建立在準則與報表定義上，引用出去之後對方追問依據時指得回公開的規則；第三本的門檻由作者從一批公司的分佈歸納，追問「這條線哪裡來的」時指回的是作者的執業經驗。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是理論建構加跨組織案例：把準則、報表結構與公司案例組織成一套解讀方式，不產生新證據，價值在串連。</p>
<p>時效這一項在這本書上要分三段判，而它剛好示範了同一本書內部的衰減速度可以差好幾倍。三表之間的勾稽關係不隨準則改版而動。個別科目的認列方式會隨準則更新而變，判斷方式是看該節依據的是哪一版準則。第三段是增訂版加寫的兩塊——以生成式 AI 工具輔助財報分析的操作說明、以及永續資訊揭露的章節——這兩塊依賴當期的工具介面與當期的揭露規範，是全書衰減最快的部分。<strong>這一項可以直接核對</strong>：翻到那幾節，看它點名的工具與規範現在還在不在。</p>
<p>處境相容性上，案例以公開發行公司為主，那些判讀依賴一組只有公開發行才有的揭露——附註、分部資訊、關係人交易揭露。往來的對象是未上市中小企業時，手上拿得到的報表沒有那幾層，判讀方式要換，差別的形狀寫在 <a href="/blog/business/knowledge-cards/company-public-disclosure-levels/" data-link-title="公司公開程度：上市 / 上櫃 / 公開發行未上市 / 未公開發行" data-link-desc="判斷一間公司的財報查不查得到時，區分「股票有沒有在交易所交易」與「有沒有依法申報公開財報」——兩者是不同軸，公開發行未上市的公司沒有股價、卻有完整公開財報">公司公開程度</a>。</p>
<p>讀得出價值的前提幾乎沒有，是本篇可以零基礎開始的一本。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/014916585">三民（財報就像一本故事書，20 週年與時俱進增訂版，時報文化，2025）</a></li>
</ul>
<h2 id="數字被挑過的痕跡長什麼樣看財報詭計">數字被挑過的痕跡長什麼樣，看財報詭計</h2>
<p>Howard Schilit、Jeremy Perler 與 Yoni Engelhart 的《財報詭計》處理第二個面：準則允許的範圍內，數字可以被挑成什麼樣子。它把手法分成四類——操弄盈餘、操弄現金流、操弄關鍵指標、以及併購會計，各類底下再拆成具體形態，每一種都附上實際發生過的公司案例。</p>
<p>它在這個主題的位置是把「選擇空間」從一個抽象說法變成一份可以逐項比對的清單。認列時點提前、把融資性現金流入放進營業活動、換一個自訂的績效指標來報——這幾種在報表上留下的痕跡各不相同，而知道要找哪個痕跡以前，讀者看到的只是一組沒有異常感的數字。</p>
<p>證據來源是跨組織案例，材料是數十家公司的實際申報，以及後續的財報重編（更正已經公告過的數字）或訴訟紀錄。這個類別支持得了「這條路別人走過」，支持不了「出現這個特徵就是舞弊」——每一種手法的合法版本與越線版本共用同一個報表外觀，書中給的是要追問什麼，不是判定規則。</p>
<p>時效上有一個可以核對的過時前提：部分手法依賴特定期間的準則漏洞，而收入認列準則整併之後，某幾種提前認列的做法在新規範下難以維持原樣。另一邊不隨版本改變的是動機結構——管理層在什麼壓力下會想挑一個數字。判斷某一節屬於哪一邊，看它的論證依賴的是某條規則的寫法，還是某種壓力的存在。</p>
<p>處境相容性上，案例以美國上市公司與該國證券主管機關的申報為主。手法的形態可以移植，查證的落點要換：台灣的公開資訊查詢入口、揭露格式與重編紀錄都在另一套系統上，而那套系統的名稱與介面歷來改過幾次，用之前確認當期入口。</p>
<p>讀得出價值的前提是讀得懂三張報表，起點書提供的程度就夠。缺這個底子時，書中的手法讀起來是一串名詞。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/012945324">三民（財報詭計：識破財報三表中的會計舞弊與騙局，全新修訂版，感電，2024，譯自 Financial Shenanigans 第四版）</a></li>
</ul>
<h2 id="大會計師教你從財報數字看懂經營本質把表接回生意">大會計師教你從財報數字看懂經營本質把表接回生意</h2>
<p>報表上的組合說明這門生意怎麼運作、以及它的體質落在哪裡，張明輝的這一本接的是這一面。作者的經歷是四大會計師事務所的實務端——曾任資誠聯合會計師事務所所長，執業三十餘年——所以書中的判讀多半從「這個數字為什麼會長成這樣」出發，而不是從準則條文出發。</p>
<p>它在本篇的另一個作用是提供台灣的參照。案例與比率門檻取自台灣上市櫃公司的實際分佈，這讓讀者第一次把書上的判讀套到手邊查得到的財報時，中間少一層換算。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨客戶的顧問經驗加跨組織案例。這個類別提供別處拿不到的細節與語言，答不了「這條判準在我要看的那家公司也成立嗎」——書中的門檻是從一批公司的分佈歸納出來的，而分佈會隨產業與期間改變。</p>
<p>這本書有一部分越過讀懂層的邊界，值得先標出來。它給出可以直接照抄的比率門檻，而 <a href="../">財務與投資書單</a> 對讀懂層的起點書判準明說不把可操作性算進加分——理由是給一組可以照抄的比率屬於決定層的事。它仍然收在這一篇，因為那些門檻在書中的角色是解釋的結論而非判斷的入口：每個門檻後面接的是這個產業為什麼會落在這個帶。使用時把它們當成該產業在該期間的分佈，而非通用標準——直接拿來比對一家公司之前，先看 <a href="/blog/business/financial-analysis/industry-benchmarking/" data-link-title="產業基準分析：怎麼判斷一間公司的數字是正常、優秀還是異常" data-link-desc="社群說「這個產業就是這樣」時，自己建立產業基準、構建比較組、判讀偏離方向的方法——從公開資料源到異常訊號的判讀">產業基準分析</a> 的比較組建構，以及那組基準的名冊有沒有被 <a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a> 篩過。</p>
<p>時效上，增訂版以近年財報重寫案例，而比率門檻依賴當期的產業結構，這一項每隔幾年就要重看。作假特徵那幾節與前一本重疊，兩本的差別在視角：前一本從查核與申報紀錄看，這一本從經營現場看。</p>
<p>處境相容性上，這是三本裡最貼近台灣讀者的一本，代價在同一處：它的門檻取自台灣的產業結構與稅制環境，換到另一個市場要重新取分佈。</p>
<p>讀得出價值的前提是有過一次要判斷一家公司值不值得往來或投入的處境。缺這個處境時，書中的門檻讀起來是一組數字，而那些數字要回答的問題不在手上。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/012427000">三民（大會計師教你從財報數字看懂經營本質，增訂版．全新案例，商業周刊，2023）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>三本各接一個面：結構、選擇空間、經營判讀。角色不重疊的檢驗方式是看讀完之後多出什麼能力——第一本讓人看得懂表，第二本讓人看得出某個數字被挑過，第三本讓人從表回推生意。</p>
<p>讀懂層不把可操作性算進加分，這條在本主題的具體形狀是：整本在給一組選股比率與買賣門檻的書不收，它們要回答的問題落在決定層，而它們預設讀者已經有這一篇要建立的能力。</p>
<p>準則條文書與考試用書同樣不收，理由是載體。準則每年更新，條文書的正確性依賴當期版本，而書不隨版本重印到讀者手上；要查當期條文的落點是準則公報本身與主管機關的公告。它們的讀者也不同——編表的人與考照的人需要條文，讀表的人需要的是結構與選擇空間。</p>
<p>跟教學系列的分工畫在產出上。<a href="/blog/business/financial-analysis/sme-listed-company-financial-analysis/" data-link-title="企業財報判讀：中小企業經營評估與上市櫃公司供需及資金鏈分析" data-link-desc="評估中小企業的經營體質或判讀上市櫃公司的供需週轉與資金鏈健康度時，從三張報表的關係、營運週轉效率、負債結構、財報紅旗等維度做結構性分析的方法">企業財報判讀</a> 與那個模組的其他篇教的是一套可以直接執行的判讀流程，材料是站內的實際案例；這一篇回答的是要建立這種閱讀能力該讀哪一本、那本書的哪一部分會隨準則改版而失效。兩邊互相不依賴：教學系列不預設讀者讀過任何一本書，這一篇也不重述那套流程。</p>
<h2 id="台大的三門初會把每個科目都做過一遍比本篇任何一本書細">台大的三門初會把每個科目都做過一遍，比本篇任何一本書細</h2>
<p>台大開放式課程的初級會計學三門接<strong>結構</strong>這一面，涵蓋的科目數比本篇任何一本書多——這一項從三門的單元標題就數得出來，不必看完課程。陳坤志（會計學系）主講，順序照會計本身推：初級會計學一從會計之所以為會計、記錄程序、帳戶調整走到買賣業的會計循環、收入認列、內部控制與現金，七講；初級會計學二逐一處理資產與負債的科目——應收帳款、存貨，不動產、廠房與設備，天然資源與無形資產，負債，五講；初級會計學三收在股東權益、投資、現金流量表與財務報表分析，四講。每講一到兩小時。三門合起來是一門完整的初會，而單元順序是照科目推進的，勾稽關係落在哪幾講由那個順序決定。</p>
<p>跟起點書的分工落在深度與代價上。起點書用五張報表的勾稽當主線、四百多頁走完；課程要十六講的時間，換到的是每個科目的認列方式都被實際做過一遍。目標是看得懂表，起點書夠用；目標是自己判斷某個數字怎麼被算出來，課程給的底更厚。</p>
<p><strong>經營判讀</strong>由台大的另一門課「財務報告分析」承接。陳明賢（財務金融學系）主講、十講，從財務報表分析的目的與使用者是誰開始，走到企業購併的評價方法。它跟本篇的《大會計師教你從財報數字看懂經營本質》都從經營現場看報表，差別在課程把評價那一段也納進來，而評價屬於這條線的決定層、本篇不收。</p>
<p><strong>選擇空間</strong>這個問題，這一輪沒有查到對應的課。初會課教的是準則怎麼規定，選擇空間要問的是準則留下多少餘地，兩者用同一批科目而問題相反。只走課程路線的人讀得出報表怎麼組成，讀不出某個數字被挑過，那一半在本書單目前只有《財報詭計》承接得了。</p>
<p>四門都是中文授課，這是這個主題跟 <a href="../investing/">資本配置與投資</a> 最大的差別——那一篇的兩門是英語課堂實錄。門檻上初會三門不預設會計背景、財務報告分析預設讀得懂三張表；純靠聽的讀者要知道分錄與 T 帳戶那幾講高度依賴板書，離開畫面會聽不完整。時效上，會計循環與三表勾稽不隨準則改版而動，理由跟起點書那一項判定相同；會受影響的是個別科目的認列，而錄製年份寫在課程頁上，比書的版次好查。財務報告分析那一門另有一段依賴當期環境：企業購併的評價方法會隨市場的評價慣例走。</p>
<ul>
<li><a href="https://ocw.aca.ntu.edu.tw/courses/mooc0066">台大開放式課程（mooc0066 初級會計學一：會計循環與收入認列，陳坤志，7 講）</a>、<a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpAAbR1Tp3Bw7Z6Qi9Bz4lfD">YouTube 播放清單（初會一）</a></li>
<li><a href="https://ocw.aca.ntu.edu.tw/courses/mooc0067">台大開放式課程（mooc0067 初級會計學二：資產與負債，陳坤志，5 講）</a>、<a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpC8yKP8v-1MDECH68Vw1wcK">YouTube 播放清單（初會二）</a></li>
<li><a href="https://ocw.aca.ntu.edu.tw/courses/mooc0068">台大開放式課程（mooc0068 初級會計學三：股東權益與現金流量，陳坤志，4 講）</a>、<a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpD6UjWEqXAYFsN-Csj4FJA7">YouTube 播放清單（初會三）</a></li>
<li><a href="https://ocw.aca.ntu.edu.tw/courses/113S103">台大開放式課程（113S103 財務報告分析，陳明賢，10 講）</a>、<a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpCqTgOXrL57c0OcBhMmPQ_-">YouTube 播放清單（財務報告分析）</a></li>
</ul>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>讀完之後要把能力用在具體公司上，走 <a href="/blog/business/financial-analysis/" data-link-title="企業財務分析與投資評估" data-link-desc="從損益表識讀到產業供應鏈分析的系統性商業評估方法——涵蓋報表判讀、公司定位、產業基準、估值方法、外部衝擊判讀，以及真實上市公司的批判性案例分析">企業財務分析與投資評估</a>：報表識讀路線從損益表的四層分析開始，投資評估路線從企業評估定位開始。</p>
<p><a href="../investing/">資本配置與投資</a> 收的《The Intelligent Investor》要求的財報底子，這一篇的起點書承接得了——那本書的篩選條件章節預設讀者讀得懂比率的組成。</p>
<p>一家公司的報表落在什麼位置，要對照同業與產業結構，走 <a href="/blog/business/" data-link-title="商業概念與策略分析" data-link-desc="整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識，並提供閱讀商業分析的框架">商業概念與策略分析</a>。要判斷手上這組同業基準的名冊有沒有被篩過，走 <a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a>。</p>
<p>利率與通膨在改變報表上的哪幾個科目——利息費用、存貨評價、匯兌損益——走 <a href="../macroeconomics/">總體經濟</a>。</p>
]]></content:encoded></item><item><title>系統架構</title><link>https://tarrragon.github.io/blog/books/craft/system-architecture/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/craft/system-architecture/</guid><description>&lt;p>架構決定跟 &lt;a href="../design-and-practice/">設計判準與日常實踐&lt;/a> 與 &lt;a href="../changing-existing-code/">改既有的程式&lt;/a> 的差別在&lt;strong>改錯的代價&lt;/strong>。程式碼寫得不好可以重構，模組切得不好可以搬；架構選錯之後，改動要跨越團隊、資料、部署與既有承諾，通常大到只能繞過而不能修正。這使得架構的核心能力是&lt;strong>在資訊不足的時候把取捨講清楚&lt;/strong>——包括講清楚自己選的那個爛在哪——而不是知道有哪些做法。&lt;/p>
&lt;p>這個主題只有兩本，按有沒有詞彙分：《Fundamentals of Software Architecture》先建立一整套可以用來討論的概念，《Software Architecture: The Hard Parts》再處理那些用了概念仍然沒有標準答案的決定。&lt;/p>
&lt;p>讀不動長篇文字時，本篇文末另標出承接這個主題機制層的公開課，收錄門檻與已知限制見 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。&lt;/p>
&lt;h2 id="起點是-fundamentals-of-software-architecture">起點是 Fundamentals of Software Architecture&lt;/h2>
&lt;p>Mark Richards 與 Neal Ford 這本的主要貢獻是一整套詞彙，而詞彙要鋪滿才有用——這也是它成為本篇涵蓋面最完整一本的原因。沒有那套詞彙的架構討論會停在「我覺得微服務比較好」，有了之後才問得出「我們要優化的是哪幾個架構特性、代價付在哪裡」。&lt;/p>
&lt;p>核心是架構特性（architecture characteristics）這個概念：可擴展性、彈性、可測試性、可部署性這些「性」不是越多越好，它們互相衝突，而架構的工作是選出這個系統真正需要的少數幾個、明確放棄其餘的。書中另一半是架構風格的目錄——分層、微核心、事件驅動、微服務、第二版新增的模組化單體——每個風格附上它在各項特性上的評分，於是「選哪個」變成一個有維度的比較而不是流行度投票。&lt;/p>
&lt;p>第二版（繁中版 2026 年出）跟第一版的差距大到需要挑版本：新增模組化單體、架構模式、圖示法、治理、資料架構與生成式 AI 幾章，並改寫了架構法則的部分。第一版繁中譯名是《軟體架構原理｜工程方法》，第二版是《軟體架構原理 第二版｜現代工程方法》，買新的。&lt;/p>
&lt;p>時效上，架構風格的清單與各風格的特性評分隨生態變動——第二版新增的模組化單體與生成式 AI 兩章就是這一層的更新；架構特性互相衝突、必須明確放棄一些，這條主軸不依賴任何一代的風格清單。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨客戶的顧問經驗與教學經驗，加上跨組織案例的整理，形式接近教科書——它整理已知的做法而非提出新主張，這也決定了它的用法：當參照系用，不是當論證用。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，架構特性的取捨預設有人為不同特性負責、而且那些人講得上話。決定由外部給定時——客戶指定、母公司統一、法規要求——這本書給的是理解那個決定的語言，不是做那個決定的方法。&lt;/p>
&lt;p>讀這本要參與過一個需要跨團隊協調的系統，架構特性的衝突才體會得到——衝突要在有人為不同特性負責時才顯現，只在單一服務裡工作時看不見它。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Fundamentals-Software-Architecture-Engineering-Approach/dp/1098175514">Amazon（Fundamentals of Software Architecture: A Modern Engineering Approach, 2nd Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0011045361">博客來（軟體架構原理 第二版｜現代工程方法）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="已經在拆分而每個選項都有代價時讀-software-architecture-the-hard-parts">已經在拆分而每個選項都有代價時讀 Software Architecture: The Hard Parts&lt;/h2>
&lt;p>同一組作者加上 Pramod Sadalage 與 Zhamak Dehghani 的這本，處理的是前一本建立詞彙之後才浮出來的問題：服務該切多細、工作流程要編排還是編舞、契約要嚴格還是寬鬆、分散式交易怎麼辦、資料該怎麼跟著服務拆。&lt;/p>
&lt;p>它的書名說明了立場——這些是&lt;strong>沒有最佳實踐的問題&lt;/strong>。書的結構因此給的是取捨分析的做法而非答案：把每個決定的可能選項列出來、標出各自在哪些架構特性上得分、明確寫出放棄了什麼。它反覆示範同一個動作，那個動作本身才是要學的東西。&lt;/p>
&lt;p>其中資料那部分特別值得注意，因為它是拆分服務時最常被低估的一段。服務可以切開，資料的一致性需求切不開；書中對於哪些資料該複製、哪些該共用、交易邊界該畫在哪，給的是可以逐項走的判斷，而不是「盡量避免分散式交易」這種沒有出口的建議。&lt;/p>
&lt;p>它跟前一本的關係是入場與深水：前一本讓人說得出這個系統要什麼，這本接手說得出之後仍然沒有標準答案的那些決定。順序不要顛倒——沒有架構特性的詞彙時，這本的取捨分析會讀成一堆並列的技術選項。&lt;/p>
&lt;p>證據來源同樣是跨客戶的顧問經驗加跨組織案例，而它比前一本更依賴一個貫穿全書的虛構案例。時效上，書出版於 2021 年，微服務相關的工具生態已有變化；取捨分析的做法與資料拆分的判斷不依賴那些工具。&lt;/p>
&lt;p>這本要有正在拆、或已經拆了一個系統的處境才讀得出東西——沒有那個處境時，八種粒度崩解訊號每一種都同樣有道理，而它們的用途是在其中認出正在發生的那一種。可以先知道它存在，開始拆的時候再拿出來。繁體中文版《軟體架構：困難部分》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Software-Architecture-Trade-Off-Distributed-Architectures/dp/1492086894">Amazon（Software Architecture: The Hard Parts）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010927173">博客來（軟體架構：困難部分）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這兩本">為什麼只收這兩本&lt;/h2>
&lt;p>兩本按「有沒有詞彙」分：建立整套概念與參照系（Fundamentals），以及用了概念之後仍然沒有標準答案的決定（The Hard Parts）。同一組作者，刻意寫成前後接續，中間沒有空隙也沒有重疊。&lt;/p>
&lt;p>架構的書市有一大類是特定架構風格的推廣書（微服務怎麼做、事件驅動怎麼做）。那類的問題是它們預設風格已經選定，而選擇本身才是架構工作最難的部分——分辨方式是看它有沒有寫「什麼情況下不要用這個風格」，而架構風格的邊界通常落在規模與團隊數上——同一個風格在三個團隊與三十個團隊下的代價差一個量級，不交代這一項的多半是在推銷而不是在分析。&lt;/p>
&lt;p>Robert Martin 的《Clean Architecture》常被列在這個位置，本書單未評估它，理由與 &lt;a href="../design-and-practice/">設計判準與日常實踐&lt;/a> 對《Clean Code》的處理相同。SEI 的《Software Architecture in Practice》是學術系統化的另一條路線（品質屬性、ATAM 評估法），繁中版也在，但它的讀者定位偏向需要正式架構評估流程的組織，本書單未評估那個情境。&lt;/p>
&lt;p>資料密集系統的設計（複製、分片、一致性模型）不在這個主題，那屬於 &lt;a href="https://tarrragon.github.io/blog/backend/" data-link-title="Backend 服務實務指南" data-link-desc="用跨語言教學路線整理資料庫、快取、訊息佇列、觀測、部署、可靠性、資安、事故與容量等後端服務能力">Backend 服務實務指南&lt;/a> 的責任範圍。&lt;/p>
&lt;h2 id="機制那一半有兩門完整的課取捨判斷那一半沒有">機制那一半有兩門完整的課，取捨判斷那一半沒有&lt;/h2>
&lt;p>這是技藝線唯一接得住公開課的主題，而它接住的只有一半。架構決定要用到機制知識與取捨判斷兩者：機制知識是複製怎麼做、一致性有幾種、共識協定在解什麼、分割之後交易怎麼辦；取捨判斷是在資訊不足時把每個選項的代價講清楚。機制教得了，判斷教不了——這跟本篇兩本書的分工同向，起點書先給詞彙、第二本才處理用了詞彙仍然沒有標準答案的決定。&lt;/p>
&lt;p>&lt;strong>MIT 6.824 Distributed Systems（Spring 2020）&lt;/strong> 由 Robert Morris 主講、20 講、每講約 80 分鐘，走的是讀論文加講解的形式。講次依序走過 GFS、主備複製、Raft（連三講）、ZooKeeper、CRAQ 的鏈式複製、Aurora、Frangipani 與 Memcached 的快取一致性、分散式交易、Spanner、樂觀並行控制、Spark、COPS 的因果一致性，最後兩講是 Bitcoin 與 Blockstack。它給的是本篇兩本書在談元件切分與資料所有權時預設讀者知道、而兩本書都不從頭建立的那些機制。這門課要寫 Go 的實驗作業（MapReduce 與 Raft 各一份），只看講課不做實驗仍然走得完，代價是共識協定那幾講會停在聽得懂而不是做得出來。&lt;/p>
&lt;p>&lt;strong>Martin Kleppmann 的 Distributed Systems lecture series&lt;/strong> 是劍橋的課，8 講切成 23 段影片、每段 10 到 20 分鐘，全長約七小時。同一位作者的《Designing Data-Intensive Applications》不在這一篇——資料密集系統的設計屬於 &lt;a href="https://tarrragon.github.io/blog/backend/" data-link-title="Backend 服務實務指南" data-link-desc="用跨語言教學路線整理資料庫、快取、訊息佇列、觀測、部署、可靠性、資安、事故與容量等後端服務能力">Backend 服務實務指南&lt;/a> 的範圍，這裡收的只有這門課。它跟前一門的差別在密度與門檻：Morris 那門一講一篇論文、每講約 80 分鐘、假設聽眾是研究生；Kleppmann 這門從電腦網路與時鐘開始建立，單段短、可以零碎聽完。兩門的「講」不是同一個單位——比長度要用總時數，6.824 二十講約二十六小時。想先建立整體地圖的從這一門開始，想追某個機制怎麼被證明的走前一門。&lt;/p>
&lt;p>兩門課的材料是已經發表的論文與已經定案的協定，時效因此不隨版本更新而動；會改變的是它們順帶提到的雲端服務與工具介面。兩門都是英語授課，而它們不像 Open Yale 的課附官方逐字稿——字幕狀態以 YouTube 當下提供的為準，本頁沒有確認過是人工還是自動。這個主題沒查到中文的對應課。&lt;/p>
&lt;p>取捨判斷那一半沒查到課，而缺口的成因就是這個主題的核心能力本身——在資訊不足的時候把取捨講清楚，包括講清楚自己選的那個爛在哪。這種能力的教材是別人做過的決定與它後來的代價，而那些代價要好幾年才顯現，一學期的課承載不了。整條線的供給狀況寫在 &lt;a href="../">工程技藝書單&lt;/a> 的公開課段。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.youtube.com/playlist?list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB">YouTube 播放清單（MIT 6.824 Distributed Systems，Robert Morris，Spring 2020，20 講）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB">YouTube 播放清單（Distributed Systems lecture series，Martin Kleppmann，8 講、23 段影片）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>架構決定的代價一半落在組織上——介面畫在哪裡，決定了哪兩個團隊要天天開會。那條路徑走 &lt;a href="../../software-management/topics/team-design/">組織結構與團隊設計&lt;/a>，Team Topologies 與這裡的架構風格處理的是同一件事的兩端。&lt;/p>
&lt;p>往下一個尺度走，模組與介面該怎麼切看 &lt;a href="../design-and-practice/">設計判準與日常實踐&lt;/a>；架構定了之後既有程式碼怎麼搬過去看 &lt;a href="../changing-existing-code/">改既有的程式&lt;/a>。&lt;/p>
&lt;p>具體的資料庫、快取、佇列與可觀測性選型看 &lt;a href="https://tarrragon.github.io/blog/backend/" data-link-title="Backend 服務實務指南" data-link-desc="用跨語言教學路線整理資料庫、快取、訊息佇列、觀測、部署、可靠性、資安、事故與容量等後端服務能力">Backend 服務實務指南&lt;/a>，部署與環境看 &lt;a href="https://tarrragon.github.io/blog/infra/" data-link-title="Infra 基礎設施建置指南" data-link-desc="從零循序漸進把雲端基礎設施做起來 — IaC、身分憑證、網路地基、環境分離、核心服務、可觀測性、自動化 review 與治理習慣，含怎麼在組織內推動">Infra 基礎設施建置指南&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>架構決定跟 <a href="../design-and-practice/">設計判準與日常實踐</a> 與 <a href="../changing-existing-code/">改既有的程式</a> 的差別在<strong>改錯的代價</strong>。程式碼寫得不好可以重構，模組切得不好可以搬；架構選錯之後，改動要跨越團隊、資料、部署與既有承諾，通常大到只能繞過而不能修正。這使得架構的核心能力是<strong>在資訊不足的時候把取捨講清楚</strong>——包括講清楚自己選的那個爛在哪——而不是知道有哪些做法。</p>
<p>這個主題只有兩本，按有沒有詞彙分：《Fundamentals of Software Architecture》先建立一整套可以用來討論的概念，《Software Architecture: The Hard Parts》再處理那些用了概念仍然沒有標準答案的決定。</p>
<p>讀不動長篇文字時，本篇文末另標出承接這個主題機制層的公開課，收錄門檻與已知限制見 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。</p>
<h2 id="起點是-fundamentals-of-software-architecture">起點是 Fundamentals of Software Architecture</h2>
<p>Mark Richards 與 Neal Ford 這本的主要貢獻是一整套詞彙，而詞彙要鋪滿才有用——這也是它成為本篇涵蓋面最完整一本的原因。沒有那套詞彙的架構討論會停在「我覺得微服務比較好」，有了之後才問得出「我們要優化的是哪幾個架構特性、代價付在哪裡」。</p>
<p>核心是架構特性（architecture characteristics）這個概念：可擴展性、彈性、可測試性、可部署性這些「性」不是越多越好，它們互相衝突，而架構的工作是選出這個系統真正需要的少數幾個、明確放棄其餘的。書中另一半是架構風格的目錄——分層、微核心、事件驅動、微服務、第二版新增的模組化單體——每個風格附上它在各項特性上的評分，於是「選哪個」變成一個有維度的比較而不是流行度投票。</p>
<p>第二版（繁中版 2026 年出）跟第一版的差距大到需要挑版本：新增模組化單體、架構模式、圖示法、治理、資料架構與生成式 AI 幾章，並改寫了架構法則的部分。第一版繁中譯名是《軟體架構原理｜工程方法》，第二版是《軟體架構原理 第二版｜現代工程方法》，買新的。</p>
<p>時效上，架構風格的清單與各風格的特性評分隨生態變動——第二版新增的模組化單體與生成式 AI 兩章就是這一層的更新；架構特性互相衝突、必須明確放棄一些，這條主軸不依賴任何一代的風格清單。<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨客戶的顧問經驗與教學經驗，加上跨組織案例的整理，形式接近教科書——它整理已知的做法而非提出新主張，這也決定了它的用法：當參照系用，不是當論證用。</p>
<p><a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，架構特性的取捨預設有人為不同特性負責、而且那些人講得上話。決定由外部給定時——客戶指定、母公司統一、法規要求——這本書給的是理解那個決定的語言，不是做那個決定的方法。</p>
<p>讀這本要參與過一個需要跨團隊協調的系統，架構特性的衝突才體會得到——衝突要在有人為不同特性負責時才顯現，只在單一服務裡工作時看不見它。</p>
<ul>
<li><a href="https://www.amazon.com/Fundamentals-Software-Architecture-Engineering-Approach/dp/1098175514">Amazon（Fundamentals of Software Architecture: A Modern Engineering Approach, 2nd Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0011045361">博客來（軟體架構原理 第二版｜現代工程方法）</a></li>
</ul>
<h2 id="已經在拆分而每個選項都有代價時讀-software-architecture-the-hard-parts">已經在拆分而每個選項都有代價時讀 Software Architecture: The Hard Parts</h2>
<p>同一組作者加上 Pramod Sadalage 與 Zhamak Dehghani 的這本，處理的是前一本建立詞彙之後才浮出來的問題：服務該切多細、工作流程要編排還是編舞、契約要嚴格還是寬鬆、分散式交易怎麼辦、資料該怎麼跟著服務拆。</p>
<p>它的書名說明了立場——這些是<strong>沒有最佳實踐的問題</strong>。書的結構因此給的是取捨分析的做法而非答案：把每個決定的可能選項列出來、標出各自在哪些架構特性上得分、明確寫出放棄了什麼。它反覆示範同一個動作，那個動作本身才是要學的東西。</p>
<p>其中資料那部分特別值得注意，因為它是拆分服務時最常被低估的一段。服務可以切開，資料的一致性需求切不開；書中對於哪些資料該複製、哪些該共用、交易邊界該畫在哪，給的是可以逐項走的判斷，而不是「盡量避免分散式交易」這種沒有出口的建議。</p>
<p>它跟前一本的關係是入場與深水：前一本讓人說得出這個系統要什麼，這本接手說得出之後仍然沒有標準答案的那些決定。順序不要顛倒——沒有架構特性的詞彙時，這本的取捨分析會讀成一堆並列的技術選項。</p>
<p>證據來源同樣是跨客戶的顧問經驗加跨組織案例，而它比前一本更依賴一個貫穿全書的虛構案例。時效上，書出版於 2021 年，微服務相關的工具生態已有變化；取捨分析的做法與資料拆分的判斷不依賴那些工具。</p>
<p>這本要有正在拆、或已經拆了一個系統的處境才讀得出東西——沒有那個處境時，八種粒度崩解訊號每一種都同樣有道理，而它們的用途是在其中認出正在發生的那一種。可以先知道它存在，開始拆的時候再拿出來。繁體中文版《軟體架構：困難部分》。</p>
<ul>
<li><a href="https://www.amazon.com/Software-Architecture-Trade-Off-Distributed-Architectures/dp/1492086894">Amazon（Software Architecture: The Hard Parts）</a></li>
<li><a href="https://www.books.com.tw/products/0010927173">博客來（軟體架構：困難部分）</a></li>
</ul>
<h2 id="為什麼只收這兩本">為什麼只收這兩本</h2>
<p>兩本按「有沒有詞彙」分：建立整套概念與參照系（Fundamentals），以及用了概念之後仍然沒有標準答案的決定（The Hard Parts）。同一組作者，刻意寫成前後接續，中間沒有空隙也沒有重疊。</p>
<p>架構的書市有一大類是特定架構風格的推廣書（微服務怎麼做、事件驅動怎麼做）。那類的問題是它們預設風格已經選定，而選擇本身才是架構工作最難的部分——分辨方式是看它有沒有寫「什麼情況下不要用這個風格」，而架構風格的邊界通常落在規模與團隊數上——同一個風格在三個團隊與三十個團隊下的代價差一個量級，不交代這一項的多半是在推銷而不是在分析。</p>
<p>Robert Martin 的《Clean Architecture》常被列在這個位置，本書單未評估它，理由與 <a href="../design-and-practice/">設計判準與日常實踐</a> 對《Clean Code》的處理相同。SEI 的《Software Architecture in Practice》是學術系統化的另一條路線（品質屬性、ATAM 評估法），繁中版也在，但它的讀者定位偏向需要正式架構評估流程的組織，本書單未評估那個情境。</p>
<p>資料密集系統的設計（複製、分片、一致性模型）不在這個主題，那屬於 <a href="/blog/backend/" data-link-title="Backend 服務實務指南" data-link-desc="用跨語言教學路線整理資料庫、快取、訊息佇列、觀測、部署、可靠性、資安、事故與容量等後端服務能力">Backend 服務實務指南</a> 的責任範圍。</p>
<h2 id="機制那一半有兩門完整的課取捨判斷那一半沒有">機制那一半有兩門完整的課，取捨判斷那一半沒有</h2>
<p>這是技藝線唯一接得住公開課的主題，而它接住的只有一半。架構決定要用到機制知識與取捨判斷兩者：機制知識是複製怎麼做、一致性有幾種、共識協定在解什麼、分割之後交易怎麼辦；取捨判斷是在資訊不足時把每個選項的代價講清楚。機制教得了，判斷教不了——這跟本篇兩本書的分工同向，起點書先給詞彙、第二本才處理用了詞彙仍然沒有標準答案的決定。</p>
<p><strong>MIT 6.824 Distributed Systems（Spring 2020）</strong> 由 Robert Morris 主講、20 講、每講約 80 分鐘，走的是讀論文加講解的形式。講次依序走過 GFS、主備複製、Raft（連三講）、ZooKeeper、CRAQ 的鏈式複製、Aurora、Frangipani 與 Memcached 的快取一致性、分散式交易、Spanner、樂觀並行控制、Spark、COPS 的因果一致性，最後兩講是 Bitcoin 與 Blockstack。它給的是本篇兩本書在談元件切分與資料所有權時預設讀者知道、而兩本書都不從頭建立的那些機制。這門課要寫 Go 的實驗作業（MapReduce 與 Raft 各一份），只看講課不做實驗仍然走得完，代價是共識協定那幾講會停在聽得懂而不是做得出來。</p>
<p><strong>Martin Kleppmann 的 Distributed Systems lecture series</strong> 是劍橋的課，8 講切成 23 段影片、每段 10 到 20 分鐘，全長約七小時。同一位作者的《Designing Data-Intensive Applications》不在這一篇——資料密集系統的設計屬於 <a href="/blog/backend/" data-link-title="Backend 服務實務指南" data-link-desc="用跨語言教學路線整理資料庫、快取、訊息佇列、觀測、部署、可靠性、資安、事故與容量等後端服務能力">Backend 服務實務指南</a> 的範圍，這裡收的只有這門課。它跟前一門的差別在密度與門檻：Morris 那門一講一篇論文、每講約 80 分鐘、假設聽眾是研究生；Kleppmann 這門從電腦網路與時鐘開始建立，單段短、可以零碎聽完。兩門的「講」不是同一個單位——比長度要用總時數，6.824 二十講約二十六小時。想先建立整體地圖的從這一門開始，想追某個機制怎麼被證明的走前一門。</p>
<p>兩門課的材料是已經發表的論文與已經定案的協定，時效因此不隨版本更新而動；會改變的是它們順帶提到的雲端服務與工具介面。兩門都是英語授課，而它們不像 Open Yale 的課附官方逐字稿——字幕狀態以 YouTube 當下提供的為準，本頁沒有確認過是人工還是自動。這個主題沒查到中文的對應課。</p>
<p>取捨判斷那一半沒查到課，而缺口的成因就是這個主題的核心能力本身——在資訊不足的時候把取捨講清楚，包括講清楚自己選的那個爛在哪。這種能力的教材是別人做過的決定與它後來的代價，而那些代價要好幾年才顯現，一學期的課承載不了。整條線的供給狀況寫在 <a href="../">工程技藝書單</a> 的公開課段。</p>
<ul>
<li><a href="https://www.youtube.com/playlist?list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB">YouTube 播放清單（MIT 6.824 Distributed Systems，Robert Morris，Spring 2020，20 講）</a></li>
<li><a href="https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB">YouTube 播放清單（Distributed Systems lecture series，Martin Kleppmann，8 講、23 段影片）</a></li>
</ul>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>架構決定的代價一半落在組織上——介面畫在哪裡，決定了哪兩個團隊要天天開會。那條路徑走 <a href="../../software-management/topics/team-design/">組織結構與團隊設計</a>，Team Topologies 與這裡的架構風格處理的是同一件事的兩端。</p>
<p>往下一個尺度走，模組與介面該怎麼切看 <a href="../design-and-practice/">設計判準與日常實踐</a>；架構定了之後既有程式碼怎麼搬過去看 <a href="../changing-existing-code/">改既有的程式</a>。</p>
<p>具體的資料庫、快取、佇列與可觀測性選型看 <a href="/blog/backend/" data-link-title="Backend 服務實務指南" data-link-desc="用跨語言教學路線整理資料庫、快取、訊息佇列、觀測、部署、可靠性、資安、事故與容量等後端服務能力">Backend 服務實務指南</a>，部署與環境看 <a href="/blog/infra/" data-link-title="Infra 基礎設施建置指南" data-link-desc="從零循序漸進把雲端基礎設施做起來 — IaC、身分憑證、網路地基、環境分離、核心服務、可觀測性、自動化 review 與治理習慣，含怎麼在組織內推動">Infra 基礎設施建置指南</a>。</p>
]]></content:encoded></item><item><title>協作形態（collaboration mode）</title><link>https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/</guid><description>&lt;p>協作形態指團隊成員在時間與空間上怎麼重疊，變數是每天的重疊工時而不是辦公室的位置。它是 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a> 那組環境條件裡最容易被略過的一個，因為其餘幾項（組織形態、僱傭關係、法規環境）逐條檢查都不踩時，選書或選做法會照一般路徑進行，而真正支配這個處境的變數根本不在被檢查的清單上。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>判讀落在兩格上——&lt;strong>重疊足夠&lt;/strong>與&lt;strong>重疊不足&lt;/strong>——中間有一條要分開處理的過渡帶。多數管理與團隊類的建議預設前者。重疊足夠時，共享物理空間主要改變的是成本——走過去問一句比發訊息快——所以「在不在同一個辦公室」不是第一個要問的，「每天重疊多久」才是。有一類例外：需要多人同時在場才成立的那些（當場示範坦承錯誤靠的是共同見證，逐一告知不等價；走廊上的相遇是外生事件，不需要有人決定要不要發起），空間對它們不只是單價。&lt;/p>
&lt;p>判讀要落在重疊工時上，「遠端」這個詞區分不出這一項：同一間公司全員在家但都在同一個時區，跟八個人分在四個時區，兩者都叫遠端，而前者幾乎不觸發這一項、後者觸發整批。&lt;/p>
&lt;p>它跟 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a> 那一項要分開問：一本大規模實證的書，它的樣本可能全部來自重疊充足的組織，於是證據強度很高而處境相容性為零——高強度的證據不會補上缺席的環境。&lt;/p>
&lt;h2 id="建立在時間重疊上的那一批論證會失效">建立在時間重疊上的那一批論證會失效&lt;/h2>
&lt;p>失效的不是整本書，是建立在「隨時問得到人」上的那一批。逐項對照比整本判斷有用，但那是排查的順序、不是可以逐項加總的模型——凝聚那一列失效之後，其餘幾列的換算成功率會跟著下降（沒有信任的人不會順口提一件小事）：&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>建立在時間重疊上的論證&lt;/th>
 &lt;th>非同步下發生什麼&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>中斷成本（被打斷、恢復專注）&lt;/td>
 &lt;td>中斷從同步事件變成回應期待，成本結構不同，書裡按分鐘算的那套換算不過去&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>團隊凝聚的形成條件&lt;/td>
 &lt;td>磨合所需的非正式接觸不會自然發生，要靠刻意設計的場合替代&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>走廊上的一句話解決一個誤會（依賴共同在場）&lt;/td>
 &lt;td>相遇不再是外生事件，誤會要累積到有人願意為它發一則訊息才被發現，發現時已經走了幾天&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>領導者當場示範坦承錯誤（依賴共同在場）&lt;/td>
 &lt;td>沒有同步場合承接即時反應，要換成公開的決策紀錄與對壞消息的第一則回覆&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>會議引導的收斂技巧&lt;/td>
 &lt;td>多數格式預設全員同時在場，逐時腳本類的方法整套需要重新設計&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>書裡通常不會標出哪些論證屬於這一批，因為原作者沒有理由把一個當時普遍成立的前提寫成假設。&lt;/p>
&lt;h2 id="判讀方式">判讀方式&lt;/h2>
&lt;p>先算重疊工時再判斷，因為其他判斷都建立在那個數字上。四小時以上的重疊，上表那批論證多半照原樣成立；兩小時以下，整批要逐列檢查。這兩個切點沒有研究背書，是照「一次同步問答加對方回覆需要多少共同時段」估出來的——四小時容得下幾輪來回加上各自的專注時間，兩小時只夠一次會議。團隊的往返節奏不同時，這兩個數字要跟著重設。&lt;/p>
&lt;p>過渡帶（兩到四小時）照上表逐列檢查——不是兩邊都準備：凡是&lt;strong>靠時間重疊才發生&lt;/strong>的功能（中斷成本的量化、凝聚的形成、走廊上那句話）一律另找發生的位置，其餘照重疊充足處理。這一格最容易被誤歸到兩端，而它要做的動作比兩端都多。&lt;/p>
&lt;p>換算的責任落在讀的人身上，而換算失敗多半走同一條路：把非同步當成「同步少了一點」來處理。加開視訊會議把重疊工時湊出來，是把非同步的成本轉嫁到某一邊的作息上。湊出來的那一小時通常落在其中一邊的晚上十點以後，而每週兩次不會有人反對——會議本身開得順，出席率與紀錄都正常。沒有被及時發現，是因為團隊看得到的訊號全部長在會議那一側，作息不對應任何一項團隊指標；等到有人離職，理由會被歸成個人生涯選擇。有效的換算方向相反——找出原本靠時間重疊才發生的功能，替它找一個不需要重疊的位置。&lt;/p>
&lt;p>這層換算目前得自己做。&lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 裡把非同步當成正面題目處理的只有&lt;a href="https://tarrragon.github.io/blog/books/software-management/topics/personal-workflow/" data-link-title="個人工作流與工作負荷" data-link-desc="事情永遠做不完、清單越來越長、換過幾套方法都維持不久時，用來判斷問題落在哪一層再決定投入哪本的選讀">個人工作流與工作負荷&lt;/a>收的 A World Without Email。&lt;a href="https://tarrragon.github.io/blog/books/software-management/topics/influence-conversation/" data-link-title="困難對話與無權限影響力" data-link-desc="該講的話講不出口、沒有職權卻要推動改變時，處理當下那幾十秒與長期影響力的選讀">困難對話與無權限影響力&lt;/a>收的 Humble Inquiry 第三版加了遠距工作專章，但那一章處理的是遠距而非重疊不足，而且繁體中文版譯自較早的版本、沒有那一章。其餘的書都要自己做這層換算。&lt;/p></description><content:encoded><![CDATA[<p>協作形態指團隊成員在時間與空間上怎麼重疊，變數是每天的重疊工時而不是辦公室的位置。它是 <a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a> 那組環境條件裡最容易被略過的一個，因為其餘幾項（組織形態、僱傭關係、法規環境）逐條檢查都不踩時，選書或選做法會照一般路徑進行，而真正支配這個處境的變數根本不在被檢查的清單上。</p>
<h2 id="概念位置">概念位置</h2>
<p>判讀落在兩格上——<strong>重疊足夠</strong>與<strong>重疊不足</strong>——中間有一條要分開處理的過渡帶。多數管理與團隊類的建議預設前者。重疊足夠時，共享物理空間主要改變的是成本——走過去問一句比發訊息快——所以「在不在同一個辦公室」不是第一個要問的，「每天重疊多久」才是。有一類例外：需要多人同時在場才成立的那些（當場示範坦承錯誤靠的是共同見證，逐一告知不等價；走廊上的相遇是外生事件，不需要有人決定要不要發起），空間對它們不只是單價。</p>
<p>判讀要落在重疊工時上，「遠端」這個詞區分不出這一項：同一間公司全員在家但都在同一個時區，跟八個人分在四個時區，兩者都叫遠端，而前者幾乎不觸發這一項、後者觸發整批。</p>
<p>它跟 <a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a> 那一項要分開問：一本大規模實證的書，它的樣本可能全部來自重疊充足的組織，於是證據強度很高而處境相容性為零——高強度的證據不會補上缺席的環境。</p>
<h2 id="建立在時間重疊上的那一批論證會失效">建立在時間重疊上的那一批論證會失效</h2>
<p>失效的不是整本書，是建立在「隨時問得到人」上的那一批。逐項對照比整本判斷有用，但那是排查的順序、不是可以逐項加總的模型——凝聚那一列失效之後，其餘幾列的換算成功率會跟著下降（沒有信任的人不會順口提一件小事）：</p>
<table>
  <thead>
      <tr>
          <th>建立在時間重疊上的論證</th>
          <th>非同步下發生什麼</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>中斷成本（被打斷、恢復專注）</td>
          <td>中斷從同步事件變成回應期待，成本結構不同，書裡按分鐘算的那套換算不過去</td>
      </tr>
      <tr>
          <td>團隊凝聚的形成條件</td>
          <td>磨合所需的非正式接觸不會自然發生，要靠刻意設計的場合替代</td>
      </tr>
      <tr>
          <td>走廊上的一句話解決一個誤會（依賴共同在場）</td>
          <td>相遇不再是外生事件，誤會要累積到有人願意為它發一則訊息才被發現，發現時已經走了幾天</td>
      </tr>
      <tr>
          <td>領導者當場示範坦承錯誤（依賴共同在場）</td>
          <td>沒有同步場合承接即時反應，要換成公開的決策紀錄與對壞消息的第一則回覆</td>
      </tr>
      <tr>
          <td>會議引導的收斂技巧</td>
          <td>多數格式預設全員同時在場，逐時腳本類的方法整套需要重新設計</td>
      </tr>
  </tbody>
</table>
<p>書裡通常不會標出哪些論證屬於這一批，因為原作者沒有理由把一個當時普遍成立的前提寫成假設。</p>
<h2 id="判讀方式">判讀方式</h2>
<p>先算重疊工時再判斷，因為其他判斷都建立在那個數字上。四小時以上的重疊，上表那批論證多半照原樣成立；兩小時以下，整批要逐列檢查。這兩個切點沒有研究背書，是照「一次同步問答加對方回覆需要多少共同時段」估出來的——四小時容得下幾輪來回加上各自的專注時間，兩小時只夠一次會議。團隊的往返節奏不同時，這兩個數字要跟著重設。</p>
<p>過渡帶（兩到四小時）照上表逐列檢查——不是兩邊都準備：凡是<strong>靠時間重疊才發生</strong>的功能（中斷成本的量化、凝聚的形成、走廊上那句話）一律另找發生的位置，其餘照重疊充足處理。這一格最容易被誤歸到兩端，而它要做的動作比兩端都多。</p>
<p>換算的責任落在讀的人身上，而換算失敗多半走同一條路：把非同步當成「同步少了一點」來處理。加開視訊會議把重疊工時湊出來，是把非同步的成本轉嫁到某一邊的作息上。湊出來的那一小時通常落在其中一邊的晚上十點以後，而每週兩次不會有人反對——會議本身開得順，出席率與紀錄都正常。沒有被及時發現，是因為團隊看得到的訊號全部長在會議那一側，作息不對應任何一項團隊指標；等到有人離職，理由會被歸成個人生涯選擇。有效的換算方向相反——找出原本靠時間重疊才發生的功能，替它找一個不需要重疊的位置。</p>
<p>這層換算目前得自己做。<a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 裡把非同步當成正面題目處理的只有<a href="/blog/books/software-management/topics/personal-workflow/" data-link-title="個人工作流與工作負荷" data-link-desc="事情永遠做不完、清單越來越長、換過幾套方法都維持不久時，用來判斷問題落在哪一層再決定投入哪本的選讀">個人工作流與工作負荷</a>收的 A World Without Email。<a href="/blog/books/software-management/topics/influence-conversation/" data-link-title="困難對話與無權限影響力" data-link-desc="該講的話講不出口、沒有職權卻要推動改變時，處理當下那幾十秒與長期影響力的選讀">困難對話與無權限影響力</a>收的 Humble Inquiry 第三版加了遠距工作專章，但那一章處理的是遠距而非重疊不足，而且繁體中文版譯自較早的版本、沒有那一章。其餘的書都要自己做這層換算。</p>
]]></content:encoded></item><item><title>財務與投資書單</title><link>https://tarrragon.github.io/blog/books/finance/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/finance/</guid><description>&lt;p>這條線處理的是&lt;strong>資本與現金流怎麼配置&lt;/strong>。它跟另外兩條線的分界在決定的對象：&lt;a href="../software-management/">軟體管理與組織&lt;/a> 的決定落在人與制度上，&lt;a href="../craft/">工程技藝&lt;/a> 的決定落在產物上，這條線的決定落在錢上。多數情況那是讀者自己的錢，而 &lt;a href="positions/">依資本責任選書&lt;/a> 列的四個位置裡有兩個不是（對他人的資產負責、對一門生意的損益負責），分界因此畫在決定的對象而不是它的所有權。三條線為什麼按這個軸分開，說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「書單線」段。&lt;/p>
&lt;p>書的描述沿用同一套維度（&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>、時效狀態、&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>、讀得出價值的前提），定義與這些判定的來源說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>。起點書判準的第一層跟另外兩條線相同（涵蓋面優先），完整的三層寫在 &lt;a href="../software-management/topics/">主題書單&lt;/a> 的「起點書怎麼選出來的」段。後兩層在這條線會隨主題調整，依據是下面那張表的最後一欄——這個主題要求讀者做什麼，決定「可操作性」算不算加分。&lt;/p>
&lt;h2 id="四個主題排在三層上">四個主題排在三層上&lt;/h2>
&lt;p>財務的問題落在不同的層級上，混在一起選書會讓一本解釋機制的書跟一本要求做決定的書被拿去比涵蓋面。分層的依據是這個主題有沒有要求讀者做決定：&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>層&lt;/th>
 &lt;th>主題&lt;/th>
 &lt;th>承擔的問題&lt;/th>
 &lt;th>對讀者要求什麼&lt;/th>
 &lt;th>起點書&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>決定層&lt;/td>
 &lt;td>&lt;a href="investing/">資本配置與投資&lt;/a>&lt;/td>
 &lt;td>錢放在哪些資產、放多久、能承受多深的回撤&lt;/td>
 &lt;td>做一個會有後果的決定&lt;/td>
 &lt;td>漫步華爾街&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>決定層&lt;/td>
 &lt;td>&lt;a href="personal-finance/">個人理財與風險保障&lt;/a>&lt;/td>
 &lt;td>現金流、緊急預備、保險、負債與退休的先後順序&lt;/td>
 &lt;td>做一個會有後果的決定&lt;/td>
 &lt;td>持續買進&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>讀懂層&lt;/td>
 &lt;td>&lt;a href="accounting/">會計與財報&lt;/a>&lt;/td>
 &lt;td>一份報表在說什麼、哪些數字可以被合法地修飾&lt;/td>
 &lt;td>具備一種閱讀能力&lt;/td>
 &lt;td>財報就像一本故事書&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>解釋層&lt;/td>
 &lt;td>&lt;a href="macroeconomics/">總體經濟&lt;/a>&lt;/td>
 &lt;td>利率、通膨與債務循環在改變什麼&lt;/td>
 &lt;td>理解一組機制&lt;/td>
 &lt;td>瘋狂、恐慌與崩盤&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>四個主題寫完之後留下兩個尚未承接的面，各自的說明寫在它所屬的位置：風險保障在 &lt;a href="personal-finance/">個人理財與風險保障&lt;/a> 的「為什麼只收這幾本」段，不由債務驅動的景氣波動在 &lt;a href="macroeconomics/">總體經濟&lt;/a> 的同名段，兩項都收在文末的 Backlog 段。第三個面本來也記在那裡——替別人做決定時的溝通與紀錄——判定之後沒有留在 Backlog 裡：溝通那一半的書在管理線，紀錄那一半不需要書，兩者的處置寫在 &lt;a href="positions/">依資本責任選書&lt;/a> 的最後一節。&lt;strong>書單線的缺口有兩種結局&lt;/strong>，這是第二種：一種是等一本書出現，一種是判定它本來就不該由書承接。&lt;/p>
&lt;p>分層有兩個操作後果。&lt;strong>起點書判準在解釋層要換一條&lt;/strong>：那一篇收的是寫得出自己失效條件的書。判準不寫成「解釋機制而不預測」，因為那兩者分不開——一套解釋利率怎麼傳導的機制本身就蘊含條件預測。真正可執行而且落在書自己交代得出來的那一面的，是它有沒有寫出在什麼條件下會失準；做預測的書同樣適用這一條，涵蓋面反而更大。預測準不準不參與判定，理由是判定它需要的材料不在這個書單的查證範圍內——要說一本總體經濟書預測得準不準，得追蹤它出版後那幾年的實際走勢並排除事後挑選，而本書單對每一本書做的是四項描述、不是績效追蹤。這是 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 那條「排除只給規則不給邊界的推廣書」判準在這個主題的形狀。&lt;strong>讀懂層不設起點書的可操作性要求&lt;/strong>：會計那一篇要選的是把報表結構講清楚的書，而不是給一組選股比率的書，後者屬於決定層。&lt;/p>
&lt;p>個體經濟在這條線沒有獨立主題。它對投資判斷真正有用的部分是產業結構、定價權與進入障礙，而那組問題已經是 &lt;a href="https://tarrragon.github.io/blog/business/" data-link-title="商業概念與策略分析" data-link-desc="整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識，並提供閱讀商業分析的框架">商業概念與策略分析&lt;/a> 在處理的——那裡的競爭護城河分類（轉換成本、鎖定、資料與技能厚度）承接的正是「為什麼別人打不進來」，案例拆解則把它套在具體市場事件上。用的名字跟個體經濟教科書不同，落點也還不完整（進入障礙與定價權目前沒有各自的術語卡）。這條線的做法是在需要那組概念的地方指過去，不在這裡再寫一套——同一組概念在兩處各寫一版，維護時只會改到其中一版。&lt;/p>
&lt;p>這條線四個主題都查得到可以收的公開課，各篇文末標出，收錄門檻在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。四門中文課來自台大開放式課程、兩門英語課來自 Open Yale Courses。&lt;/p>
&lt;h2 id="有些財務知識不該用書當載體">有些財務知識不該用書當載體&lt;/h2>
&lt;p>書單能回答的問題有一個上界，跟書寫得好不好無關。這條線收的書沒有更新路徑：讀者手上那一本印出來之後不會再變，出版社再版幾次都送不到他手上。所以任何「正確性依賴當期」的內容放進書裡都在發布當下就是待查狀態——稅制每年修正，而那一頁永遠停在付印那天，讀起來卻跟不會過期的段落完全一樣。&lt;/p>
&lt;p>這一條跟時效狀態的方向相反。時效問「這本書的某段論證依賴的前提現在還在不在」，判定的對象是內容的實例，做得越細越有用；這一條問「這類知識該不該放在書上」，判定的對象是內容與載體的配對，而做多細不改變結論。判別式是兩問：這段內容的正確性會不會隨時間失效（問它的主體是規則本身、還是讀規則的方法），以及這個載體能不能在失效之前把更新送到讀者手上。這條線收的書在第二問都答否（例外的形態與判準見那張卡），所以第一問是這裡唯一在做工的判準。兩問在有更新路徑的載體上長什麼樣、以及書為什麼會有例外，寫在 &lt;a href="https://tarrragon.github.io/blog/report/current-content-needs-a-carrier-that-reaches-readers/" data-link-title="要維持當期的內容，只能放在更新到得了讀者的載體上" data-link-desc="某一類判定怎麼做都會過期、而直覺是把判定做得更細時，用來分辨該加深判定還是該換載體">#268 要維持當期的內容只能放在更新到得了讀者的載體上&lt;/a>。&lt;/p>
&lt;p>處境軸因此在這條線切成兩層，切分的條件是一句話：&lt;strong>這一項改變時，書裡建立在它上面的推導要不要重做。&lt;/strong> 要重做的是判定的對象，不必重做的只是讀者查一次就換掉的數字。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>層&lt;/th>
 &lt;th>內容&lt;/th>
 &lt;th>這條線怎麼處理&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>結構性&lt;/td>
 &lt;td>資本形態（會不會被生活需求打斷）、現金流的鬆緊與支出結構、幣別與匯率暴露、市場的資訊揭露程度、這個市場有沒有可以買到全球股票這類工具、所在經濟體的規模與資本開放程度&lt;/td>
 &lt;td>進 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a> 判定&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>制度性&lt;/td>
 &lt;td>稅制、退休金與社會保險、投資額度與資格門檻、當期補助、某個工具的具體品項與費率&lt;/td>
 &lt;td>標示存在，不判定內容&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>這一組環境隨主題擴充過兩次，兩次都是既有的項目對不上新收的書。個人理財那一篇要判的是「留下緩衝」這個建議讀者執行得了多少，而決定它的是現金流扣掉固定支出之後的餘裕，資本形態問不到那一層；總體經濟那一篇的三本各自預設一種經濟體——有能力扮演最後貸款人的、債務以本國貨幣計價的、資本可以自由進出的——那些預設在原本四項裡也沒有位置。擴充的判準跟建表時同一條：這一項改變時，書裡建立在它上面的推導要不要重做。&lt;/p>
&lt;p>金融工具這一項橫跨兩層，切法照上面那句：這個市場有沒有可以買到全球股票的工具，是結構性的——沒有的話，一整章的資產配置推導在這裡都要重做；有哪幾檔、費率多少、稅務怎麼算，是制度性的，讀者查一次就換掉，書裡寫下來只會過期。&lt;/p>
&lt;p>制度性那一層的處理是明講不承接：主題篇只寫「這裡依賴一套每年會改的制度」並指向主管機關的公告，不寫制度的內容，也不判定它在讀者的法域裡成不成立。制度改了，那句話仍然成立。&lt;/p>
&lt;p>寫的當下怎麼認出自己正落在制度性那一層，有一個按鍵時就觀察得到的訊號：&lt;strong>打算把一個具體數字或門檻打進句子的那一刻&lt;/strong>——稅率、扣除額、費率、資格年齡、當期補助金額——就在制度性那一層。寫「這個市場有沒有這一類工具」「這一項改變時推導要不要重做」時在結構性那一層。這個訊號不必等出錯才出現。&lt;/p>
&lt;p>這條規則同時決定了這條線不收哪一類書：整本在講當期稅務規劃、當期補助方案或當期金融商品比較的書不進來。判準是載體、不是品質——那類內容要每年重印才維持得住正確，而書不重印。&lt;/p>
&lt;p>會計不受這一條影響，儘管準則也會改。差別在於會計書教的是報表的結構與各項目之間的關係，而不是當期準則的條文；準則更新會動到某幾個科目的認列方式，動不到「損益表與現金流量表為什麼會不一致」這一類的內容。判別式是問這本書的主體是規則本身、還是讀規則的方法。&lt;/p>
&lt;h2 id="這條線特別要注意證據來源">這條線特別要注意證據來源&lt;/h2>
&lt;p>技藝那條線最容易踩的是時效，這條線是證據來源，而且是它底下的一項特定失效：&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a>。&lt;/p>
&lt;p>原因在於報酬的變異幅度：同一套投資方法在不同人身上產出的結果差距極大，大到單一樣本分不出方法與運氣的比重，而寫書的機會落在分佈的上半部。&lt;/p>
&lt;p>它限定的是宣稱的範圍，而不是這本書讀不讀。落到選書的動作是&lt;strong>在同一本書裡分兩種句子讀&lt;/strong>：講機制怎麼運作的照讀，宣稱照做會有什麼結果的降級成一則觀察——後者需要失敗者的資料，而那正是缺席的那一半。這個機制與它在選書上的完整形態寫在 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源分類&lt;/a>，在資料上的其餘形態寫在 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a>。&lt;/p>
&lt;h2 id="依資本責任分成四個位置">依資本責任分成四個位置&lt;/h2>
&lt;p>管理那條線按讀者對什麼負責分成五個位置，這條線的等價軸是&lt;strong>對什麼資本負責&lt;/strong>——只有薪資現金流、有可投資的餘裕、對他人的資產負責、對一門生意的損益負責。這個軸改變答案的方式很具體：沒有可投資餘裕的人讀資產配置等於空轉，對他人資產負責的人讀個人理財不夠用。&lt;/p>
&lt;p>位置表在四個主題篇完成之後建立，判準、四格各自的主場與缺口都在 &lt;a href="positions/">依資本責任選書&lt;/a>。它跟技藝那條線的差別在相關性：那裡是位置與答案的相關性本來就低而刻意不建，這裡是相關性高，早先沒有建的理由只是承接的內容還沒長出來。&lt;/p>
&lt;p>不確定自己在哪一格時，也可以直接依當下手上的問題選主題：正在決定錢往哪放走決定層，看不懂手上那份報表走讀懂層，想知道環境在變什麼走解釋層。&lt;/p>
&lt;h2 id="跟教學系列的邊界">跟教學系列的邊界&lt;/h2>
&lt;p>書單給選讀判斷，實作與術語在教學系列：商業術語、單位經濟、護城河與估值語言看 &lt;a href="https://tarrragon.github.io/blog/business/" data-link-title="商業概念與策略分析" data-link-desc="整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識，並提供閱讀商業分析的框架">商業概念與策略分析&lt;/a>，報表判讀與企業體質分析看 &lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/sme-listed-company-financial-analysis/" data-link-title="企業財報判讀：中小企業經營評估與上市櫃公司供需及資金鏈分析" data-link-desc="評估中小企業的經營體質或判讀上市櫃公司的供需週轉與資金鏈健康度時，從三張報表的關係、營運週轉效率、負債結構、財報紅旗等維度做結構性分析的方法">企業財報判讀&lt;/a>，併購情境下的財務判斷看 &lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/ma-buyer-financial-assessment/" data-link-title="併購案的買方財務能力評估：交易金額只是進場門票" data-link-desc="評估一筆併購案的買方是否有能力消化交易時，從交易金額 vs 買方規模、隱性整合成本、資金來源結構做判讀的方法">買方財務能力評估&lt;/a> 與 &lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/acquisition-driven-integration/" data-link-title="併購引擎型公司的整合效果判讀" data-link-desc="評估一家靠連續併購擴張的公司時，判讀併購後整合有沒有成功、商譽累積風險有多大、以及整合效果跟收購溢價之間的消長關係">併購引擎型公司的整合效果判讀&lt;/a>。&lt;/p>
&lt;p>反向不成立：教學系列不引用這條線的選書判定，它們的關係是書單指出去、教學系列自己站得住。&lt;/p>
&lt;h2 id="backlog">Backlog&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>項目&lt;/th>
 &lt;th>類型&lt;/th>
 &lt;th>前置條件&lt;/th>
 &lt;th>規模&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>風險保障的條目&lt;/td>
 &lt;td>主章&lt;/td>
 &lt;td>先找到只講風險移轉機制、不寫當期商品與費率的書&lt;/td>
 &lt;td>1 節&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>不由債務驅動的景氣波動&lt;/td>
 &lt;td>主章&lt;/td>
 &lt;td>先判定它是總體經濟篇的第四本，還是一個獨立主題&lt;/td>
 &lt;td>1 節&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>提領期與長壽風險&lt;/td>
 &lt;td>主章&lt;/td>
 &lt;td>累積期的四個主題已完成，這個主題的讀者位置與那四個都不同&lt;/td>
 &lt;td>1 篇&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>把本篇的兩層切法（結構性 / 制度性）寫進處境相容性卡&lt;/td>
 &lt;td>知識卡&lt;/td>
 &lt;td>至少兩條線實跑過這個切法&lt;/td>
 &lt;td>1 張改寫&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>財務幸福自我養成計畫第五堂是否只講風險移轉機制&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>看過該堂內容&lt;/td>
 &lt;td>1 段判定&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>會計「選擇空間」那一面的公開課&lt;/td>
 &lt;td>主章&lt;/td>
 &lt;td>目前只有書承接，需確認有無對應課程&lt;/td>
 &lt;td>1 段&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>四格的課程供給重掃&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>2027 年 8 月之後重跑；這條線四個主題都有課，衰減風險在連結與平台政策而非缺口&lt;/td>
 &lt;td>1 次&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table></description><content:encoded><![CDATA[<p>這條線處理的是<strong>資本與現金流怎麼配置</strong>。它跟另外兩條線的分界在決定的對象：<a href="../software-management/">軟體管理與組織</a> 的決定落在人與制度上，<a href="../craft/">工程技藝</a> 的決定落在產物上，這條線的決定落在錢上。多數情況那是讀者自己的錢，而 <a href="positions/">依資本責任選書</a> 列的四個位置裡有兩個不是（對他人的資產負責、對一門生意的損益負責），分界因此畫在決定的對象而不是它的所有權。三條線為什麼按這個軸分開，說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「書單線」段。</p>
<p>書的描述沿用同一套維度（<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>、時效狀態、<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>、讀得出價值的前提），定義與這些判定的來源說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>。起點書判準的第一層跟另外兩條線相同（涵蓋面優先），完整的三層寫在 <a href="../software-management/topics/">主題書單</a> 的「起點書怎麼選出來的」段。後兩層在這條線會隨主題調整，依據是下面那張表的最後一欄——這個主題要求讀者做什麼，決定「可操作性」算不算加分。</p>
<h2 id="四個主題排在三層上">四個主題排在三層上</h2>
<p>財務的問題落在不同的層級上，混在一起選書會讓一本解釋機制的書跟一本要求做決定的書被拿去比涵蓋面。分層的依據是這個主題有沒有要求讀者做決定：</p>
<table>
  <thead>
      <tr>
          <th>層</th>
          <th>主題</th>
          <th>承擔的問題</th>
          <th>對讀者要求什麼</th>
          <th>起點書</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>決定層</td>
          <td><a href="investing/">資本配置與投資</a></td>
          <td>錢放在哪些資產、放多久、能承受多深的回撤</td>
          <td>做一個會有後果的決定</td>
          <td>漫步華爾街</td>
      </tr>
      <tr>
          <td>決定層</td>
          <td><a href="personal-finance/">個人理財與風險保障</a></td>
          <td>現金流、緊急預備、保險、負債與退休的先後順序</td>
          <td>做一個會有後果的決定</td>
          <td>持續買進</td>
      </tr>
      <tr>
          <td>讀懂層</td>
          <td><a href="accounting/">會計與財報</a></td>
          <td>一份報表在說什麼、哪些數字可以被合法地修飾</td>
          <td>具備一種閱讀能力</td>
          <td>財報就像一本故事書</td>
      </tr>
      <tr>
          <td>解釋層</td>
          <td><a href="macroeconomics/">總體經濟</a></td>
          <td>利率、通膨與債務循環在改變什麼</td>
          <td>理解一組機制</td>
          <td>瘋狂、恐慌與崩盤</td>
      </tr>
  </tbody>
</table>
<p>四個主題寫完之後留下兩個尚未承接的面，各自的說明寫在它所屬的位置：風險保障在 <a href="personal-finance/">個人理財與風險保障</a> 的「為什麼只收這幾本」段，不由債務驅動的景氣波動在 <a href="macroeconomics/">總體經濟</a> 的同名段，兩項都收在文末的 Backlog 段。第三個面本來也記在那裡——替別人做決定時的溝通與紀錄——判定之後沒有留在 Backlog 裡：溝通那一半的書在管理線，紀錄那一半不需要書，兩者的處置寫在 <a href="positions/">依資本責任選書</a> 的最後一節。<strong>書單線的缺口有兩種結局</strong>，這是第二種：一種是等一本書出現，一種是判定它本來就不該由書承接。</p>
<p>分層有兩個操作後果。<strong>起點書判準在解釋層要換一條</strong>：那一篇收的是寫得出自己失效條件的書。判準不寫成「解釋機制而不預測」，因為那兩者分不開——一套解釋利率怎麼傳導的機制本身就蘊含條件預測。真正可執行而且落在書自己交代得出來的那一面的，是它有沒有寫出在什麼條件下會失準；做預測的書同樣適用這一條，涵蓋面反而更大。預測準不準不參與判定，理由是判定它需要的材料不在這個書單的查證範圍內——要說一本總體經濟書預測得準不準，得追蹤它出版後那幾年的實際走勢並排除事後挑選，而本書單對每一本書做的是四項描述、不是績效追蹤。這是 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 那條「排除只給規則不給邊界的推廣書」判準在這個主題的形狀。<strong>讀懂層不設起點書的可操作性要求</strong>：會計那一篇要選的是把報表結構講清楚的書，而不是給一組選股比率的書，後者屬於決定層。</p>
<p>個體經濟在這條線沒有獨立主題。它對投資判斷真正有用的部分是產業結構、定價權與進入障礙，而那組問題已經是 <a href="/blog/business/" data-link-title="商業概念與策略分析" data-link-desc="整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識，並提供閱讀商業分析的框架">商業概念與策略分析</a> 在處理的——那裡的競爭護城河分類（轉換成本、鎖定、資料與技能厚度）承接的正是「為什麼別人打不進來」，案例拆解則把它套在具體市場事件上。用的名字跟個體經濟教科書不同，落點也還不完整（進入障礙與定價權目前沒有各自的術語卡）。這條線的做法是在需要那組概念的地方指過去，不在這裡再寫一套——同一組概念在兩處各寫一版，維護時只會改到其中一版。</p>
<p>這條線四個主題都查得到可以收的公開課，各篇文末標出，收錄門檻在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。四門中文課來自台大開放式課程、兩門英語課來自 Open Yale Courses。</p>
<h2 id="有些財務知識不該用書當載體">有些財務知識不該用書當載體</h2>
<p>書單能回答的問題有一個上界，跟書寫得好不好無關。這條線收的書沒有更新路徑：讀者手上那一本印出來之後不會再變，出版社再版幾次都送不到他手上。所以任何「正確性依賴當期」的內容放進書裡都在發布當下就是待查狀態——稅制每年修正，而那一頁永遠停在付印那天，讀起來卻跟不會過期的段落完全一樣。</p>
<p>這一條跟時效狀態的方向相反。時效問「這本書的某段論證依賴的前提現在還在不在」，判定的對象是內容的實例，做得越細越有用；這一條問「這類知識該不該放在書上」，判定的對象是內容與載體的配對，而做多細不改變結論。判別式是兩問：這段內容的正確性會不會隨時間失效（問它的主體是規則本身、還是讀規則的方法），以及這個載體能不能在失效之前把更新送到讀者手上。這條線收的書在第二問都答否（例外的形態與判準見那張卡），所以第一問是這裡唯一在做工的判準。兩問在有更新路徑的載體上長什麼樣、以及書為什麼會有例外，寫在 <a href="/blog/report/current-content-needs-a-carrier-that-reaches-readers/" data-link-title="要維持當期的內容，只能放在更新到得了讀者的載體上" data-link-desc="某一類判定怎麼做都會過期、而直覺是把判定做得更細時，用來分辨該加深判定還是該換載體">#268 要維持當期的內容只能放在更新到得了讀者的載體上</a>。</p>
<p>處境軸因此在這條線切成兩層，切分的條件是一句話：<strong>這一項改變時，書裡建立在它上面的推導要不要重做。</strong> 要重做的是判定的對象，不必重做的只是讀者查一次就換掉的數字。</p>
<table>
  <thead>
      <tr>
          <th>層</th>
          <th>內容</th>
          <th>這條線怎麼處理</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>結構性</td>
          <td>資本形態（會不會被生活需求打斷）、現金流的鬆緊與支出結構、幣別與匯率暴露、市場的資訊揭露程度、這個市場有沒有可以買到全球股票這類工具、所在經濟體的規模與資本開放程度</td>
          <td>進 <a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a> 判定</td>
      </tr>
      <tr>
          <td>制度性</td>
          <td>稅制、退休金與社會保險、投資額度與資格門檻、當期補助、某個工具的具體品項與費率</td>
          <td>標示存在，不判定內容</td>
      </tr>
  </tbody>
</table>
<p>這一組環境隨主題擴充過兩次，兩次都是既有的項目對不上新收的書。個人理財那一篇要判的是「留下緩衝」這個建議讀者執行得了多少，而決定它的是現金流扣掉固定支出之後的餘裕，資本形態問不到那一層；總體經濟那一篇的三本各自預設一種經濟體——有能力扮演最後貸款人的、債務以本國貨幣計價的、資本可以自由進出的——那些預設在原本四項裡也沒有位置。擴充的判準跟建表時同一條：這一項改變時，書裡建立在它上面的推導要不要重做。</p>
<p>金融工具這一項橫跨兩層，切法照上面那句：這個市場有沒有可以買到全球股票的工具，是結構性的——沒有的話，一整章的資產配置推導在這裡都要重做；有哪幾檔、費率多少、稅務怎麼算，是制度性的，讀者查一次就換掉，書裡寫下來只會過期。</p>
<p>制度性那一層的處理是明講不承接：主題篇只寫「這裡依賴一套每年會改的制度」並指向主管機關的公告，不寫制度的內容，也不判定它在讀者的法域裡成不成立。制度改了，那句話仍然成立。</p>
<p>寫的當下怎麼認出自己正落在制度性那一層，有一個按鍵時就觀察得到的訊號：<strong>打算把一個具體數字或門檻打進句子的那一刻</strong>——稅率、扣除額、費率、資格年齡、當期補助金額——就在制度性那一層。寫「這個市場有沒有這一類工具」「這一項改變時推導要不要重做」時在結構性那一層。這個訊號不必等出錯才出現。</p>
<p>這條規則同時決定了這條線不收哪一類書：整本在講當期稅務規劃、當期補助方案或當期金融商品比較的書不進來。判準是載體、不是品質——那類內容要每年重印才維持得住正確，而書不重印。</p>
<p>會計不受這一條影響，儘管準則也會改。差別在於會計書教的是報表的結構與各項目之間的關係，而不是當期準則的條文；準則更新會動到某幾個科目的認列方式，動不到「損益表與現金流量表為什麼會不一致」這一類的內容。判別式是問這本書的主體是規則本身、還是讀規則的方法。</p>
<h2 id="這條線特別要注意證據來源">這條線特別要注意證據來源</h2>
<p>技藝那條線最容易踩的是時效，這條線是證據來源，而且是它底下的一項特定失效：<a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a>。</p>
<p>原因在於報酬的變異幅度：同一套投資方法在不同人身上產出的結果差距極大，大到單一樣本分不出方法與運氣的比重，而寫書的機會落在分佈的上半部。</p>
<p>它限定的是宣稱的範圍，而不是這本書讀不讀。落到選書的動作是<strong>在同一本書裡分兩種句子讀</strong>：講機制怎麼運作的照讀，宣稱照做會有什麼結果的降級成一則觀察——後者需要失敗者的資料，而那正是缺席的那一半。這個機制與它在選書上的完整形態寫在 <a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源分類</a>，在資料上的其餘形態寫在 <a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a>。</p>
<h2 id="依資本責任分成四個位置">依資本責任分成四個位置</h2>
<p>管理那條線按讀者對什麼負責分成五個位置，這條線的等價軸是<strong>對什麼資本負責</strong>——只有薪資現金流、有可投資的餘裕、對他人的資產負責、對一門生意的損益負責。這個軸改變答案的方式很具體：沒有可投資餘裕的人讀資產配置等於空轉，對他人資產負責的人讀個人理財不夠用。</p>
<p>位置表在四個主題篇完成之後建立，判準、四格各自的主場與缺口都在 <a href="positions/">依資本責任選書</a>。它跟技藝那條線的差別在相關性：那裡是位置與答案的相關性本來就低而刻意不建，這裡是相關性高，早先沒有建的理由只是承接的內容還沒長出來。</p>
<p>不確定自己在哪一格時，也可以直接依當下手上的問題選主題：正在決定錢往哪放走決定層，看不懂手上那份報表走讀懂層，想知道環境在變什麼走解釋層。</p>
<h2 id="跟教學系列的邊界">跟教學系列的邊界</h2>
<p>書單給選讀判斷，實作與術語在教學系列：商業術語、單位經濟、護城河與估值語言看 <a href="/blog/business/" data-link-title="商業概念與策略分析" data-link-desc="整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識，並提供閱讀商業分析的框架">商業概念與策略分析</a>，報表判讀與企業體質分析看 <a href="/blog/business/financial-analysis/sme-listed-company-financial-analysis/" data-link-title="企業財報判讀：中小企業經營評估與上市櫃公司供需及資金鏈分析" data-link-desc="評估中小企業的經營體質或判讀上市櫃公司的供需週轉與資金鏈健康度時，從三張報表的關係、營運週轉效率、負債結構、財報紅旗等維度做結構性分析的方法">企業財報判讀</a>，併購情境下的財務判斷看 <a href="/blog/business/financial-analysis/ma-buyer-financial-assessment/" data-link-title="併購案的買方財務能力評估：交易金額只是進場門票" data-link-desc="評估一筆併購案的買方是否有能力消化交易時，從交易金額 vs 買方規模、隱性整合成本、資金來源結構做判讀的方法">買方財務能力評估</a> 與 <a href="/blog/business/financial-analysis/acquisition-driven-integration/" data-link-title="併購引擎型公司的整合效果判讀" data-link-desc="評估一家靠連續併購擴張的公司時，判讀併購後整合有沒有成功、商譽累積風險有多大、以及整合效果跟收購溢價之間的消長關係">併購引擎型公司的整合效果判讀</a>。</p>
<p>反向不成立：教學系列不引用這條線的選書判定，它們的關係是書單指出去、教學系列自己站得住。</p>
<h2 id="backlog">Backlog</h2>
<table>
  <thead>
      <tr>
          <th>項目</th>
          <th>類型</th>
          <th>前置條件</th>
          <th>規模</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>風險保障的條目</td>
          <td>主章</td>
          <td>先找到只講風險移轉機制、不寫當期商品與費率的書</td>
          <td>1 節</td>
      </tr>
      <tr>
          <td>不由債務驅動的景氣波動</td>
          <td>主章</td>
          <td>先判定它是總體經濟篇的第四本，還是一個獨立主題</td>
          <td>1 節</td>
      </tr>
      <tr>
          <td>提領期與長壽風險</td>
          <td>主章</td>
          <td>累積期的四個主題已完成，這個主題的讀者位置與那四個都不同</td>
          <td>1 篇</td>
      </tr>
      <tr>
          <td>把本篇的兩層切法（結構性 / 制度性）寫進處境相容性卡</td>
          <td>知識卡</td>
          <td>至少兩條線實跑過這個切法</td>
          <td>1 張改寫</td>
      </tr>
      <tr>
          <td>財務幸福自我養成計畫第五堂是否只講風險移轉機制</td>
          <td>案例</td>
          <td>看過該堂內容</td>
          <td>1 段判定</td>
      </tr>
      <tr>
          <td>會計「選擇空間」那一面的公開課</td>
          <td>主章</td>
          <td>目前只有書承接，需確認有無對應課程</td>
          <td>1 段</td>
      </tr>
      <tr>
          <td>四格的課程供給重掃</td>
          <td>案例</td>
          <td>2027 年 8 月之後重跑；這條線四個主題都有課，衰減風險在連結與平台政策而非缺口</td>
          <td>1 次</td>
      </tr>
  </tbody>
</table>
]]></content:encoded></item><item><title>對別人的產出負責</title><link>https://tarrragon.github.io/blog/books/software-management/roles/others-output/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/others-output/</guid><description>&lt;p>這個位置的定義是：團隊交不出來的時候被問的是帶團隊的那個人；薪水、績效評等與誰留下這三件事通常都不在這個位置的權限內。Tech Lead、技術負責人、專案的技術窗口都在這裡。責任跟權力的落差在這裡特別尷尬：只對技術品質負責的人至少可以不接一個案子，這個位置連不接都不行，因為交付本來就是它的責任。&lt;/p>
&lt;p>自己重寫是這個位置最常見的失敗，形成過程不經過任何決定點。團隊成員交出來的東西不夠好時，自己改掉最快、當下也最省事，於是變成常態；三個月後團隊沒有變強，而帶團隊的人變成瓶頸。另一個同樣不必決定就會發生的是把交付壓力轉成加班要求，因為在能動的槓桿裡它最不需要對話。&lt;/p>
&lt;h2 id="對別人產出負責時成文制度與否的差別">對別人產出負責時，成文制度與否的差別&lt;/h2>
&lt;p>有職級階梯的組織裡，Tech Lead 通常有對應的 EM 搭配，兩人分擔「事」與「人」。這裡的問題是&lt;strong>邊界模糊&lt;/strong>：績效面談時 EM 會問某個成員做得怎麼樣，於是 Tech Lead 實際上在影響考核，卻沒有處理後果的位置。這個處境要求把觀察講得具體到可以被複核。「他比較資淺」是印象評語，別人無從查證也無從反駁；「這三次 PR 他都漏了同一類邊界條件，第三次我指出來之後就沒再犯」是可複核的觀察，而且它同時說明了那個人在進步。兩句話花的時間差不多，能支持的結論差很多。&lt;/p>
&lt;p>扁平的小公司通常沒有這個分工，Tech Lead 同時是那個人的主管，這個位置與 &lt;a href="../people/">對人負責&lt;/a> 直接合併。這種情況下建議兩篇都讀——&lt;a href="../people/">對人負責&lt;/a> 那篇談分級、調薪與績效的段落預設組織已經有那些工具，沒有的話要讀的是它背後的判斷，不是照著把制度建起來。並且注意一個具體風險：交付壓力大時，人的問題會被無限期延後。它沒有截止日。所以它永遠排得進「下週再說」，而下週永遠有更急的事。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/role-transitions/">The Manager&amp;rsquo;s Path&lt;/a>&lt;/strong> 的 tech lead 那一章是這個位置最直接的對應。它是這條線上少數把「還要寫程式、同時要對別人的產出負責」這個雙重身分當成主題來處理的書。建議只讀那一章加上下一章，整本讀完的部分會記不住；全書的性質判定在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/continuous-delivery/">Accelerate&lt;/a>&lt;/strong> 在這個位置的價值是把「團隊做得好不好」從印象變成數字。這裡的人經常要向上回報進度、向下要求改變，兩邊都需要依據。那四項是部署頻率、變更前置時間、變更失敗率、服務還原時間；它們的好處是難以造假、且指向流程而非個人——用它們談問題，對話不會滑向「誰比較慢」。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/influence-conversation/">Difficult Conversations&lt;/a>&lt;/strong> 處理的是這個位置每週都會遇到的那場對話：某個人交出來的東西不夠好，而這件事得由這個位置去講。三層對話的區分在這裡的用途是辨認自己卡在哪一層——多數這類對話難開口，是因為講的人在第三層（怕自己顯得刻薄或外行），而不是第一層講不清楚。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/meeting-facilitation/">六頂思考帽&lt;/a>&lt;/strong> 在這個位置的用處是設計討論。方案一提出就被挑洞、提案的人轉入防守，是團隊討論的一種典型結束方式，消耗掉的是資淺成員下一次提案的意願。把找風險與找好處排成不同時段、規定同一時段全場只做一件事，這個做法不需要職權就能導入，是這個位置少數自己說了算的槓桿。這套方法背後沒有獨立驗證，完整的證據判定在 &lt;a href="../../topics/meeting-facilitation/">會議引導與群體決策&lt;/a>。它在這裡的位置因此是團隊內部的實驗協議：自己試、自己看收到什麼訊號，而不是拿去當推動更大範圍改變的依據。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">Peopleware&lt;/a>&lt;/strong> 在這個位置讀的是中斷成本與團隊凝聚那幾章。能實際動的槓桿有限，但保護團隊不被打斷是其中最有效也最在職權範圍內的一個。有兩種處境要先確認再投入：成員是約聘輪替或專案制編組時，凝聚那幾章的前提不成立；團隊跨時區而每天重疊不到兩小時（見[協作形態](/books/knowledge-cards/collaboration-mode/））時，中斷成本那幾章要自己換算成非同步的形式。兩者的完整說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的約束段。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>進到這個位置多半是被指派的，而指派的依據通常是「這個人交出來的東西最少讓人擔心」。準備好的訊號不是技術最強，是別人願意把有風險的部分交出來——那表示那個判斷已經被信任。剛被指派的人最該做的一件事是問清楚自己能決定什麼、不能決定什麼，因為責任與權力的落差正是這個位置的主要痛點，偏偏那個邊界通常沒有人主動說。&lt;/p>
&lt;p>&lt;strong>往管理路線&lt;/strong>（&lt;a href="../people/">對人負責&lt;/a>）：預習的是人的留任與動機，而不是更多的交付方法。這個位置處理的是「事」，&lt;a href="../people/">對人負責&lt;/a> 處理的是「人」，兩者的失敗模式不同——前者失敗是東西沒交出來，後者失敗是人走了而東西還在交。&lt;a href="../../topics/retention-motivation/">留任、動機與工作環境&lt;/a> 與 &lt;a href="../../topics/culture-safety/">組織文化與心理安全感&lt;/a> 是入口。&lt;/p>
&lt;p>&lt;strong>往技術路線&lt;/strong>（&lt;a href="../technical-quality/">對技術品質負責&lt;/a>）：這條路是橫向而非退回。這裡練出來的協調能力到那邊仍然有用，要補的是技術決策的廣度與無職權影響力，看 &lt;a href="../../topics/team-design/">組織結構與團隊設計&lt;/a>。&lt;/p>
&lt;p>&lt;strong>留在這個位置繼續深化&lt;/strong>：這是合理的選擇而非停滯。往深處走有兩個方向。一個是估算與承諾——這條路線對外承諾時程，而承諾失準有兩個不同來源需要分開處理，走 &lt;a href="../../topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a>。另一個是技藝本身：這個位置要判斷別人交出來的東西夠不夠好，而那需要自己的判準夠硬，走 &lt;a href="../../../craft/">工程技藝書單&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>這個位置的定義是：團隊交不出來的時候被問的是帶團隊的那個人；薪水、績效評等與誰留下這三件事通常都不在這個位置的權限內。Tech Lead、技術負責人、專案的技術窗口都在這裡。責任跟權力的落差在這裡特別尷尬：只對技術品質負責的人至少可以不接一個案子，這個位置連不接都不行，因為交付本來就是它的責任。</p>
<p>自己重寫是這個位置最常見的失敗，形成過程不經過任何決定點。團隊成員交出來的東西不夠好時，自己改掉最快、當下也最省事，於是變成常態；三個月後團隊沒有變強，而帶團隊的人變成瓶頸。另一個同樣不必決定就會發生的是把交付壓力轉成加班要求，因為在能動的槓桿裡它最不需要對話。</p>
<h2 id="對別人產出負責時成文制度與否的差別">對別人產出負責時，成文制度與否的差別</h2>
<p>有職級階梯的組織裡，Tech Lead 通常有對應的 EM 搭配，兩人分擔「事」與「人」。這裡的問題是<strong>邊界模糊</strong>：績效面談時 EM 會問某個成員做得怎麼樣，於是 Tech Lead 實際上在影響考核，卻沒有處理後果的位置。這個處境要求把觀察講得具體到可以被複核。「他比較資淺」是印象評語，別人無從查證也無從反駁；「這三次 PR 他都漏了同一類邊界條件，第三次我指出來之後就沒再犯」是可複核的觀察，而且它同時說明了那個人在進步。兩句話花的時間差不多，能支持的結論差很多。</p>
<p>扁平的小公司通常沒有這個分工，Tech Lead 同時是那個人的主管，這個位置與 <a href="../people/">對人負責</a> 直接合併。這種情況下建議兩篇都讀——<a href="../people/">對人負責</a> 那篇談分級、調薪與績效的段落預設組織已經有那些工具，沒有的話要讀的是它背後的判斷，不是照著把制度建起來。並且注意一個具體風險：交付壓力大時，人的問題會被無限期延後。它沒有截止日。所以它永遠排得進「下週再說」，而下週永遠有更急的事。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/role-transitions/">The Manager&rsquo;s Path</a></strong> 的 tech lead 那一章是這個位置最直接的對應。它是這條線上少數把「還要寫程式、同時要對別人的產出負責」這個雙重身分當成主題來處理的書。建議只讀那一章加上下一章，整本讀完的部分會記不住；全書的性質判定在主題篇。</p>
<p><strong><a href="../../topics/continuous-delivery/">Accelerate</a></strong> 在這個位置的價值是把「團隊做得好不好」從印象變成數字。這裡的人經常要向上回報進度、向下要求改變，兩邊都需要依據。那四項是部署頻率、變更前置時間、變更失敗率、服務還原時間；它們的好處是難以造假、且指向流程而非個人——用它們談問題，對話不會滑向「誰比較慢」。</p>
<p><strong><a href="../../topics/influence-conversation/">Difficult Conversations</a></strong> 處理的是這個位置每週都會遇到的那場對話：某個人交出來的東西不夠好，而這件事得由這個位置去講。三層對話的區分在這裡的用途是辨認自己卡在哪一層——多數這類對話難開口，是因為講的人在第三層（怕自己顯得刻薄或外行），而不是第一層講不清楚。</p>
<p><strong><a href="../../topics/meeting-facilitation/">六頂思考帽</a></strong> 在這個位置的用處是設計討論。方案一提出就被挑洞、提案的人轉入防守，是團隊討論的一種典型結束方式，消耗掉的是資淺成員下一次提案的意願。把找風險與找好處排成不同時段、規定同一時段全場只做一件事，這個做法不需要職權就能導入，是這個位置少數自己說了算的槓桿。這套方法背後沒有獨立驗證，完整的證據判定在 <a href="../../topics/meeting-facilitation/">會議引導與群體決策</a>。它在這裡的位置因此是團隊內部的實驗協議：自己試、自己看收到什麼訊號，而不是拿去當推動更大範圍改變的依據。</p>
<p><strong><a href="../../topics/retention-motivation/">Peopleware</a></strong> 在這個位置讀的是中斷成本與團隊凝聚那幾章。能實際動的槓桿有限，但保護團隊不被打斷是其中最有效也最在職權範圍內的一個。有兩種處境要先確認再投入：成員是約聘輪替或專案制編組時，凝聚那幾章的前提不成立；團隊跨時區而每天重疊不到兩小時（見[協作形態](/books/knowledge-cards/collaboration-mode/））時，中斷成本那幾章要自己換算成非同步的形式。兩者的完整說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的約束段。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>進到這個位置多半是被指派的，而指派的依據通常是「這個人交出來的東西最少讓人擔心」。準備好的訊號不是技術最強，是別人願意把有風險的部分交出來——那表示那個判斷已經被信任。剛被指派的人最該做的一件事是問清楚自己能決定什麼、不能決定什麼，因為責任與權力的落差正是這個位置的主要痛點，偏偏那個邊界通常沒有人主動說。</p>
<p><strong>往管理路線</strong>（<a href="../people/">對人負責</a>）：預習的是人的留任與動機，而不是更多的交付方法。這個位置處理的是「事」，<a href="../people/">對人負責</a> 處理的是「人」，兩者的失敗模式不同——前者失敗是東西沒交出來，後者失敗是人走了而東西還在交。<a href="../../topics/retention-motivation/">留任、動機與工作環境</a> 與 <a href="../../topics/culture-safety/">組織文化與心理安全感</a> 是入口。</p>
<p><strong>往技術路線</strong>（<a href="../technical-quality/">對技術品質負責</a>）：這條路是橫向而非退回。這裡練出來的協調能力到那邊仍然有用，要補的是技術決策的廣度與無職權影響力，看 <a href="../../topics/team-design/">組織結構與團隊設計</a>。</p>
<p><strong>留在這個位置繼續深化</strong>：這是合理的選擇而非停滯。往深處走有兩個方向。一個是估算與承諾——這條路線對外承諾時程，而承諾失準有兩個不同來源需要分開處理，走 <a href="../../topics/estimation-decision/">估算、承諾與決策偏誤</a>。另一個是技藝本身：這個位置要判斷別人交出來的東西夠不夠好，而那需要自己的判準夠硬，走 <a href="../../../craft/">工程技藝書單</a>。</p>
]]></content:encoded></item><item><title>組織結構與團隊設計</title><link>https://tarrragon.github.io/blog/books/software-management/topics/team-design/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/team-design/</guid><description>&lt;p>這個主題處理組織的形狀怎麼決定系統的形狀。團隊邊界一旦畫下去，溝通成本、交接延遲與架構耦合就跟著定下來，而這些代價通常在幾個月後才顯現、要改又得付重組成本。這使得團隊設計成為少數「事前多想一個月很划算」的決定。&lt;/p>
&lt;p>這個主題的書對組織規模特別敏感。同一套結構模板，在三十人的公司是過度設計，在三百人的公司是必要基礎設施。選書時先確認自己的規模，否則讀到的會是一整套用不上的框架，並且開始為不存在的問題做設計。&lt;/p>
&lt;h2 id="起點是-team-topologies">起點是 Team Topologies&lt;/h2>
&lt;p>Matthew Skelton 與 Manuel Pais 的《Team Topologies》涵蓋了從團隊型態到互動模式的完整設計語彙，套用成本也是本篇最低的一本：它把團隊互動收斂成三個具名選項，讀完就能拿去對照自己的組織。它從 Conway&amp;rsquo;s Law 出發——系統架構會反映組織的溝通結構——並把這條規律當設計工具用：既然結構會互相映射，就先設計組織來得到想要的架構。&lt;/p>
&lt;p>核心是四種團隊型態（stream-aligned、enabling、complicated-subsystem、platform）與三種互動模式（collaboration、X-as-a-Service、facilitating）。這套詞彙讓「這兩個團隊該怎麼合作」變成有限選項的決定：長期高頻協作是 collaboration，穩定介面是 X-as-a-Service，短期能力移轉是 facilitating。沒有這套詞彙時這個決定通常沒有被明確做過，於是預設落在成本最高的長期協作。&lt;/p>
&lt;p>另一條主線是團隊認知負荷。書中主張團隊能承擔的領域範圍由認知負荷上限決定而非人數決定，這直接影響「這個團隊還能不能再接一個服務」的判斷。這條主線把團隊邊界從官僚產物改判成承重結構——上限是實的，超過之後會有東西塌下來，而塌的形式是交付變慢與交接出錯。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨組織案例（作者的顧問現場）加上既有理論（Conway&amp;rsquo;s Law、Dunbar number）的整合，不是統計。時效上，第二版於 2025 年出版並補上更多實作案例；Conway&amp;rsquo;s Law 這個地基比書本身老得多，也還沒有被推翻的跡象。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，四種團隊型態與三種互動模式要有三個以上的團隊才對映得上。團隊數更少時它的價值落在詞彙而不在配置——只有一個交接面的組織不需要設計交接面，那件事兩個人講一次話就解決。讀得出價值的前提是：經歷過一次跨團隊交接摩擦。三種互動模式的差別是成本差別，而成本要付過才有感。繁體中文版目前未見，簡體中文版譯名《高效能團隊模式》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Team-Topologies-2nd-Organizing-Technology/dp/1966280009">Amazon（Team Topologies, 2nd Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Team-Topologies-Organizing-Business-Technology/dp/1942788819">Amazon（第一版）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.tenlong.com.tw/products/9787121410826">天瓏（高效能團隊模式：支持軟件快速交付的組織架構，簡體中文版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="已經在調度多個團隊時讀-an-elegant-puzzle">已經在調度多個團隊時讀 An Elegant Puzzle&lt;/h2>
&lt;p>Will Larson 的《An Elegant Puzzle》預設讀者越過了「怎麼帶三個人」的階段，關心的是團隊規模怎麼定、技術債怎麼排進計畫、接班怎麼安排、組織成長時哪些結構會先斷。書名的 puzzle 指的是這類問題的性質：沒有唯一解，但有明顯較好與較差的解，而各個約束彼此牽動。&lt;/p>
&lt;p>書中的團隊狀態模型把團隊分成落後、追平、還債、創新四種狀態，並主張每種狀態該用不同的介入方式——落後的團隊要減負載而不是加人，追平的團隊要保護不被打斷。這個模型讓「這個團隊需要什麼」變成可以問出答案的問題，而不是憑感覺調度資源。&lt;/p>
&lt;p>這本要有標的才讀得動：手上同時有兩個以上團隊在搶同一批資源。只帶一個團隊的人讀它，四種狀態是四個形容詞；要在兩個團隊之間分配同一批人的時候，它們才變成可以吵的依據。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗（作者在 Digg、Uber、Stripe 的任職），細節具體但樣本是一；素材來自長期經營的部落格，章節之間偏獨立、不是線性論述。時效上，書中的規模假設是快速成長的矽谷公司，招募與晉升制度那幾章綁定那個環境，團隊狀態模型與負載判斷不依賴它。目前沒有中譯本。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186">Amazon（An Elegant Puzzle: Systems of Engineering Management）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要理解規模與時間怎麼改變決策時讀-software-engineering-at-google">要理解規模與時間怎麼改變決策時讀 Software Engineering at Google&lt;/h2>
&lt;p>《Software Engineering at Google》處理的問題是：當程式碼要活二十年、當有數萬名工程師在同一個 repo 上工作時，哪些工程判斷會反過來。它把軟體工程定義成「隨時間推移的程式設計」，然後逐項檢視這個定義如何改變測試策略、程式碼審查、依賴管理、棄用流程與工具投資。&lt;/p>
&lt;p>書中的 Hyrum&amp;rsquo;s Law 及其衍生的設計態度可遷移到任何規模：介面的所有可觀察行為終將被某人依賴，因此棄用是需要制度而非公告的過程。這個洞察與組織規模無關，小團隊維護長壽專案時同樣成立。&lt;/p>
&lt;p>證據來源是單一組織的深度重建，形式是制度紀錄，且大量做法依賴 Google 的內部基礎設施，直接套用的成本很高。時效上，書出版於 2020 年，工具鏈章節描述的內部系統外部無法取得也無從更新；時間與規模如何改變工程決策這個論證軸不依賴特定工具。這本要先當過一次接手的人才讀得出價值：維護一個自己沒有參與初版開發的系統。繁體中文版由歐萊禮出版，譯名《Google 的軟體工程之道》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Software-Engineering-Google-Lessons-Programming/dp/1492082791">Amazon（Software Engineering at Google）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://abseil.io/resources/swe-book">官方免費線上版（HTML 全文，CC BY-NC-ND 授權）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010938794">博客來（Google 的軟體工程之道：從程式設計經驗中吸取教訓）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想把零散做法串成一套解釋時讀-wiring-the-winning-organization">想把零散做法串成一套解釋時讀 Wiring the Winning Organization&lt;/h2>
&lt;p>Gene Kim 與 Steven Spear 的《Wiring the Winning Organization》（2023）處理的問題是：為什麼同樣的工作在某些組織裡很難、在另一些組織裡很簡單。答案由三個機制構成——slowification（把問題移到壓力較低的場合先解決）、simplification（把大問題切成可獨立處理的小問題）、amplification（讓問題訊號快速被聽見並回應）。&lt;/p>
&lt;p>它與這個主題其他書的差別在抽象層級。Skelton 與 Pais 給結構模板，Larson 給調度模型，Kim 與 Spear 想給的是解釋那些做法為何有效的底層理論。Spear 的背景是豐田生產系統與醫療安全研究，案例因此跨產業。&lt;/p>
&lt;p>證據來源是理論建構加上跨組織案例，而三個機制的解釋力在不同案例上並不平均——這是它適合當第四本而非第一本的原因。時效上是本篇最新的一本，眼下沒有過期的部分。它的前提是閱讀量而非經驗：先讀過這個主題的另外兩三本，手上有一批彼此不相干的做法想找共同解釋。三個機制是收攏用的，要先有東西可收。目前沒有中譯本。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Wiring-Winning-Organization-Slowification-Simplification/dp/1950508420">Amazon（Wiring the Winning Organization）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="這些問題的源頭在人月神話">這些問題的源頭在人月神話&lt;/h2>
&lt;p>Frederick Brooks 的《The Mythical Man-Month》1975 年出版，取材自他在 IBM 帶 System/360 與 OS/360 的經驗。這個主題的多數討論可以追到它——加人為什麼不能壓縮時程、溝通成本為什麼隨人數超線性成長、設計為什麼要出自少數人。&lt;/p>
&lt;p>最廣為人知的是 Brooks&amp;rsquo;s Law：&lt;strong>對一個已經落後的軟體專案加人，只會讓它更落後&lt;/strong>。理由是新人要人帶，帶人的是最有產能的老手；而溝通路徑隨人數以平方成長，所以每加一個人的邊際貢獻遞減、邊際溝通成本遞增。這條定律是 &lt;a href="../problem-definition/">問題定義與系統思考&lt;/a> 那則效應圖的原始素材——效應圖是把它畫出來的工具，定律本身出自這裡。&lt;/p>
&lt;p>另一條沒有後繼的主線是概念完整性（conceptual integrity）：一個系統的設計要出自少數幾個人，否則會長成一堆各自合理而互不相容的決定。這條主張跟現在強調自主團隊的方向有張力，而張力本身值得讀——它逼人回答「哪些決定必須集中、哪些可以分散」，而那正是團隊切分的核心問題。&lt;/p>
&lt;p>20 週年版收錄了 1986 年的〈No Silver Bullet〉全文與作者事後的自我檢討，那篇提出的區分至今沒有更好的替代：軟體的困難分成&lt;strong>本質的&lt;/strong>（把需求想清楚、把概念結構建立起來，這件事無法被工具消除）與&lt;strong>偶然的&lt;/strong>（語言、環境、工具帶進來的負擔，這些可以被改善）。任何宣稱大幅提升生產力的工具，都可以拿這條線去問它改善的是哪一側——偶然側的改善有上限，因為本質側的比重會隨偶然側被清掉而上升。&lt;/p>
&lt;p>時效要分章看，這本書是分章判斷的好例子。外科手術團隊那套編制（一位主刀加一組支援）綁在當年的分工與工具上，已經不適用；溝通成本的部分被 Team Topologies 用認知負荷取代，而那個取代是升級——負荷上限比溝通路徑數更貼近「這個團隊還能不能再接一件事」。Brooks&amp;rsquo;s Law、概念完整性與本質／偶然的區分不依賴任何時代條件，那三塊是現在讀它的理由。&lt;/p>
&lt;p>證據來源是單一組織的深度重建（一個大型專案的完整反省）加上作者後續二十年的修正，不是統計——但它是被後續研究反覆檢驗的個人經驗，Brooks&amp;rsquo;s Law 在多份實證裡都成立。加了人卻沒有變快的專案參與過一次，這本才有對象；沒有的話，那條定律讀起來像一句俏皮話。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959">Amazon（The Mythical Man-Month, Anniversary Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010254508">博客來（人月神話：軟體專案管理之道，20 週年紀念版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="推動重組時的人的阻力在溫伯格第-4-卷">推動重組時的人的阻力在溫伯格第 4 卷&lt;/h2>
&lt;p>Weinberg 的《Quality Software Management, Vol. 4: Anticipating Change》處理組織轉變的推動過程。前面幾本給出目標結構長什麼樣，這一卷處理從現狀走到目標的路上會遇到什麼——誰會抗拒、抗拒的形式有哪些、哪些抗拒其實是有效資訊。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗。時效上，書中預設的組織轉型節奏是以年為單位的變革專案，與現在的做法不同；抗拒的形式與應對方式處理的是人對不確定的反應，不依賴那個節奏。事前讀跟事後讀是兩本不同的書，分界線是有沒有推動過一次失敗或半途而廢的組織改變。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Quality-Software-Management-Anticipating-Change/dp/0932633323">Amazon（Quality Software Management: Anticipating Change）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010545251">博客來（溫伯格的軟體管理學：擁抱變革，第 4 卷）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>這個主題的六本按抽象層級排：設計語彙（Team Topologies）、調度模型（An Elegant Puzzle）、規模與時間的約束（Software Engineering at Google）、底層理論（Wiring）、問題的來歷（人月神話）、推動過程（溫伯格第 4 卷）。前四本回答結構該長什麼樣，人月神話回答這些問題從哪來，最後一本回答怎麼走過去。&lt;/p>
&lt;p>組織設計的書大量來自一般管理領域（矩陣式組織、事業部制），它們不處理軟體特有的約束——程式碼的耦合會把組織的溝通成本固定下來，這件事在非軟體組織裡沒有對應物。要分辨，翻目錄找「架構與組織互相映射」這件事有沒有被當成前提；沒有的話，那本處理的是另一個問題。&lt;/p>
&lt;p>規模化敏捷框架（SAFe、LeSS 之類）本書單未評估。它們提供的是流程模板而非結構判準，適用性高度依賴組織既有的成熟度，要給出可靠的選讀建議需要在不同成熟度的組織各導入一次，這裡沒有這個基礎。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>團隊切好之後，交接面上的溝通品質決定結構有沒有真的生效——結構對但沒人講真話時，X-as-a-Service 的介面會變成互相推責的邊界。那條路徑走 &lt;a href="../culture-safety/">組織文化與心理安全感&lt;/a>。&lt;/p>
&lt;p>要判斷重組後的交付效能有沒有改善，走 &lt;a href="../continuous-delivery/">持續交付與交付效能&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理組織的形狀怎麼決定系統的形狀。團隊邊界一旦畫下去，溝通成本、交接延遲與架構耦合就跟著定下來，而這些代價通常在幾個月後才顯現、要改又得付重組成本。這使得團隊設計成為少數「事前多想一個月很划算」的決定。</p>
<p>這個主題的書對組織規模特別敏感。同一套結構模板，在三十人的公司是過度設計，在三百人的公司是必要基礎設施。選書時先確認自己的規模，否則讀到的會是一整套用不上的框架，並且開始為不存在的問題做設計。</p>
<h2 id="起點是-team-topologies">起點是 Team Topologies</h2>
<p>Matthew Skelton 與 Manuel Pais 的《Team Topologies》涵蓋了從團隊型態到互動模式的完整設計語彙，套用成本也是本篇最低的一本：它把團隊互動收斂成三個具名選項，讀完就能拿去對照自己的組織。它從 Conway&rsquo;s Law 出發——系統架構會反映組織的溝通結構——並把這條規律當設計工具用：既然結構會互相映射，就先設計組織來得到想要的架構。</p>
<p>核心是四種團隊型態（stream-aligned、enabling、complicated-subsystem、platform）與三種互動模式（collaboration、X-as-a-Service、facilitating）。這套詞彙讓「這兩個團隊該怎麼合作」變成有限選項的決定：長期高頻協作是 collaboration，穩定介面是 X-as-a-Service，短期能力移轉是 facilitating。沒有這套詞彙時這個決定通常沒有被明確做過，於是預設落在成本最高的長期協作。</p>
<p>另一條主線是團隊認知負荷。書中主張團隊能承擔的領域範圍由認知負荷上限決定而非人數決定，這直接影響「這個團隊還能不能再接一個服務」的判斷。這條主線把團隊邊界從官僚產物改判成承重結構——上限是實的，超過之後會有東西塌下來，而塌的形式是交付變慢與交接出錯。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨組織案例（作者的顧問現場）加上既有理論（Conway&rsquo;s Law、Dunbar number）的整合，不是統計。時效上，第二版於 2025 年出版並補上更多實作案例；Conway&rsquo;s Law 這個地基比書本身老得多，也還沒有被推翻的跡象。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，四種團隊型態與三種互動模式要有三個以上的團隊才對映得上。團隊數更少時它的價值落在詞彙而不在配置——只有一個交接面的組織不需要設計交接面，那件事兩個人講一次話就解決。讀得出價值的前提是：經歷過一次跨團隊交接摩擦。三種互動模式的差別是成本差別，而成本要付過才有感。繁體中文版目前未見，簡體中文版譯名《高效能團隊模式》。</p>
<ul>
<li><a href="https://www.amazon.com/Team-Topologies-2nd-Organizing-Technology/dp/1966280009">Amazon（Team Topologies, 2nd Edition）</a></li>
<li><a href="https://www.amazon.com/Team-Topologies-Organizing-Business-Technology/dp/1942788819">Amazon（第一版）</a></li>
<li><a href="https://www.tenlong.com.tw/products/9787121410826">天瓏（高效能團隊模式：支持軟件快速交付的組織架構，簡體中文版）</a></li>
</ul>
<h2 id="已經在調度多個團隊時讀-an-elegant-puzzle">已經在調度多個團隊時讀 An Elegant Puzzle</h2>
<p>Will Larson 的《An Elegant Puzzle》預設讀者越過了「怎麼帶三個人」的階段，關心的是團隊規模怎麼定、技術債怎麼排進計畫、接班怎麼安排、組織成長時哪些結構會先斷。書名的 puzzle 指的是這類問題的性質：沒有唯一解，但有明顯較好與較差的解，而各個約束彼此牽動。</p>
<p>書中的團隊狀態模型把團隊分成落後、追平、還債、創新四種狀態，並主張每種狀態該用不同的介入方式——落後的團隊要減負載而不是加人，追平的團隊要保護不被打斷。這個模型讓「這個團隊需要什麼」變成可以問出答案的問題，而不是憑感覺調度資源。</p>
<p>這本要有標的才讀得動：手上同時有兩個以上團隊在搶同一批資源。只帶一個團隊的人讀它，四種狀態是四個形容詞；要在兩個團隊之間分配同一批人的時候，它們才變成可以吵的依據。</p>
<p>證據來源是單一路徑的個人經驗（作者在 Digg、Uber、Stripe 的任職），細節具體但樣本是一；素材來自長期經營的部落格，章節之間偏獨立、不是線性論述。時效上，書中的規模假設是快速成長的矽谷公司，招募與晉升制度那幾章綁定那個環境，團隊狀態模型與負載判斷不依賴它。目前沒有中譯本。</p>
<ul>
<li><a href="https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186">Amazon（An Elegant Puzzle: Systems of Engineering Management）</a></li>
</ul>
<h2 id="要理解規模與時間怎麼改變決策時讀-software-engineering-at-google">要理解規模與時間怎麼改變決策時讀 Software Engineering at Google</h2>
<p>《Software Engineering at Google》處理的問題是：當程式碼要活二十年、當有數萬名工程師在同一個 repo 上工作時，哪些工程判斷會反過來。它把軟體工程定義成「隨時間推移的程式設計」，然後逐項檢視這個定義如何改變測試策略、程式碼審查、依賴管理、棄用流程與工具投資。</p>
<p>書中的 Hyrum&rsquo;s Law 及其衍生的設計態度可遷移到任何規模：介面的所有可觀察行為終將被某人依賴，因此棄用是需要制度而非公告的過程。這個洞察與組織規模無關，小團隊維護長壽專案時同樣成立。</p>
<p>證據來源是單一組織的深度重建，形式是制度紀錄，且大量做法依賴 Google 的內部基礎設施，直接套用的成本很高。時效上，書出版於 2020 年，工具鏈章節描述的內部系統外部無法取得也無從更新；時間與規模如何改變工程決策這個論證軸不依賴特定工具。這本要先當過一次接手的人才讀得出價值：維護一個自己沒有參與初版開發的系統。繁體中文版由歐萊禮出版，譯名《Google 的軟體工程之道》。</p>
<ul>
<li><a href="https://www.amazon.com/Software-Engineering-Google-Lessons-Programming/dp/1492082791">Amazon（Software Engineering at Google）</a></li>
<li><a href="https://abseil.io/resources/swe-book">官方免費線上版（HTML 全文，CC BY-NC-ND 授權）</a></li>
<li><a href="https://www.books.com.tw/products/0010938794">博客來（Google 的軟體工程之道：從程式設計經驗中吸取教訓）</a></li>
</ul>
<h2 id="想把零散做法串成一套解釋時讀-wiring-the-winning-organization">想把零散做法串成一套解釋時讀 Wiring the Winning Organization</h2>
<p>Gene Kim 與 Steven Spear 的《Wiring the Winning Organization》（2023）處理的問題是：為什麼同樣的工作在某些組織裡很難、在另一些組織裡很簡單。答案由三個機制構成——slowification（把問題移到壓力較低的場合先解決）、simplification（把大問題切成可獨立處理的小問題）、amplification（讓問題訊號快速被聽見並回應）。</p>
<p>它與這個主題其他書的差別在抽象層級。Skelton 與 Pais 給結構模板，Larson 給調度模型，Kim 與 Spear 想給的是解釋那些做法為何有效的底層理論。Spear 的背景是豐田生產系統與醫療安全研究，案例因此跨產業。</p>
<p>證據來源是理論建構加上跨組織案例，而三個機制的解釋力在不同案例上並不平均——這是它適合當第四本而非第一本的原因。時效上是本篇最新的一本，眼下沒有過期的部分。它的前提是閱讀量而非經驗：先讀過這個主題的另外兩三本，手上有一批彼此不相干的做法想找共同解釋。三個機制是收攏用的，要先有東西可收。目前沒有中譯本。</p>
<ul>
<li><a href="https://www.amazon.com/Wiring-Winning-Organization-Slowification-Simplification/dp/1950508420">Amazon（Wiring the Winning Organization）</a></li>
</ul>
<h2 id="這些問題的源頭在人月神話">這些問題的源頭在人月神話</h2>
<p>Frederick Brooks 的《The Mythical Man-Month》1975 年出版，取材自他在 IBM 帶 System/360 與 OS/360 的經驗。這個主題的多數討論可以追到它——加人為什麼不能壓縮時程、溝通成本為什麼隨人數超線性成長、設計為什麼要出自少數人。</p>
<p>最廣為人知的是 Brooks&rsquo;s Law：<strong>對一個已經落後的軟體專案加人，只會讓它更落後</strong>。理由是新人要人帶，帶人的是最有產能的老手；而溝通路徑隨人數以平方成長，所以每加一個人的邊際貢獻遞減、邊際溝通成本遞增。這條定律是 <a href="../problem-definition/">問題定義與系統思考</a> 那則效應圖的原始素材——效應圖是把它畫出來的工具，定律本身出自這裡。</p>
<p>另一條沒有後繼的主線是概念完整性（conceptual integrity）：一個系統的設計要出自少數幾個人，否則會長成一堆各自合理而互不相容的決定。這條主張跟現在強調自主團隊的方向有張力，而張力本身值得讀——它逼人回答「哪些決定必須集中、哪些可以分散」，而那正是團隊切分的核心問題。</p>
<p>20 週年版收錄了 1986 年的〈No Silver Bullet〉全文與作者事後的自我檢討，那篇提出的區分至今沒有更好的替代：軟體的困難分成<strong>本質的</strong>（把需求想清楚、把概念結構建立起來，這件事無法被工具消除）與<strong>偶然的</strong>（語言、環境、工具帶進來的負擔，這些可以被改善）。任何宣稱大幅提升生產力的工具，都可以拿這條線去問它改善的是哪一側——偶然側的改善有上限，因為本質側的比重會隨偶然側被清掉而上升。</p>
<p>時效要分章看，這本書是分章判斷的好例子。外科手術團隊那套編制（一位主刀加一組支援）綁在當年的分工與工具上，已經不適用；溝通成本的部分被 Team Topologies 用認知負荷取代，而那個取代是升級——負荷上限比溝通路徑數更貼近「這個團隊還能不能再接一件事」。Brooks&rsquo;s Law、概念完整性與本質／偶然的區分不依賴任何時代條件，那三塊是現在讀它的理由。</p>
<p>證據來源是單一組織的深度重建（一個大型專案的完整反省）加上作者後續二十年的修正，不是統計——但它是被後續研究反覆檢驗的個人經驗，Brooks&rsquo;s Law 在多份實證裡都成立。加了人卻沒有變快的專案參與過一次，這本才有對象；沒有的話，那條定律讀起來像一句俏皮話。</p>
<ul>
<li><a href="https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959">Amazon（The Mythical Man-Month, Anniversary Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010254508">博客來（人月神話：軟體專案管理之道，20 週年紀念版）</a></li>
</ul>
<h2 id="推動重組時的人的阻力在溫伯格第-4-卷">推動重組時的人的阻力在溫伯格第 4 卷</h2>
<p>Weinberg 的《Quality Software Management, Vol. 4: Anticipating Change》處理組織轉變的推動過程。前面幾本給出目標結構長什麼樣，這一卷處理從現狀走到目標的路上會遇到什麼——誰會抗拒、抗拒的形式有哪些、哪些抗拒其實是有效資訊。</p>
<p>證據來源是跨客戶的顧問經驗。時效上，書中預設的組織轉型節奏是以年為單位的變革專案，與現在的做法不同；抗拒的形式與應對方式處理的是人對不確定的反應，不依賴那個節奏。事前讀跟事後讀是兩本不同的書，分界線是有沒有推動過一次失敗或半途而廢的組織改變。</p>
<ul>
<li><a href="https://www.amazon.com/Quality-Software-Management-Anticipating-Change/dp/0932633323">Amazon（Quality Software Management: Anticipating Change）</a></li>
<li><a href="https://www.books.com.tw/products/0010545251">博客來（溫伯格的軟體管理學：擁抱變革，第 4 卷）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>這個主題的六本按抽象層級排：設計語彙（Team Topologies）、調度模型（An Elegant Puzzle）、規模與時間的約束（Software Engineering at Google）、底層理論（Wiring）、問題的來歷（人月神話）、推動過程（溫伯格第 4 卷）。前四本回答結構該長什麼樣，人月神話回答這些問題從哪來，最後一本回答怎麼走過去。</p>
<p>組織設計的書大量來自一般管理領域（矩陣式組織、事業部制），它們不處理軟體特有的約束——程式碼的耦合會把組織的溝通成本固定下來，這件事在非軟體組織裡沒有對應物。要分辨，翻目錄找「架構與組織互相映射」這件事有沒有被當成前提；沒有的話，那本處理的是另一個問題。</p>
<p>規模化敏捷框架（SAFe、LeSS 之類）本書單未評估。它們提供的是流程模板而非結構判準，適用性高度依賴組織既有的成熟度，要給出可靠的選讀建議需要在不同成熟度的組織各導入一次，這裡沒有這個基礎。</p>
<p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>團隊切好之後，交接面上的溝通品質決定結構有沒有真的生效——結構對但沒人講真話時，X-as-a-Service 的介面會變成互相推責的邊界。那條路徑走 <a href="../culture-safety/">組織文化與心理安全感</a>。</p>
<p>要判斷重組後的交付效能有沒有改善，走 <a href="../continuous-delivery/">持續交付與交付效能</a>。</p>
<p>邊界該畫在哪是這個主題的問題，它的上游有兩個：為什麼每次重組的效果都被抵銷，以及為什麼組織看不見自己的邊界已經切錯——繼承來的分類系統決定了哪些問題連被陳述的機會都沒有，而《穀倉效應》的八個個案演示的正是這件事。兩者都走 <a href="../problem-definition/">問題定義與系統思考</a>：那邊負責診斷，這裡的認知負荷上限負責回答邊界該畫在哪。</p>
<p>既有團隊的結構評估協議看 <a href="/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計</a>。</p>
]]></content:encoded></item><item><title>總體經濟</title><link>https://tarrragon.github.io/blog/books/finance/macroeconomics/</link><pubDate>Thu, 20 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/finance/macroeconomics/</guid><description>&lt;p>總體經濟在這條線承擔解釋：利率、通膨與債務水準的變動透過哪條路徑到達一家公司的損益與一個家庭的現金流。它落在解釋層，因為它交付的是一組機制而不是一個決定——同樣看懂了信用擴張的循環，該減碼還是該加碼仍然由決定層那兩個主題回答。&lt;/p>
&lt;p>這個主題有一個別的主題沒有的性質：同一組現象存在幾套互相競爭的解釋，而它們的分歧不會隨資料增加而消失。所以這一篇收的三本刻意落在三種不同的證據形態上——一套從跨事件敘事歸納出的機制、一套由作者自建並用自己的操作驗證的模板、一份可以公開覆核的長期資料庫。讀法是看它們在哪裡一致、在哪裡分開，那條分界線比任何一本的結論更接近這個主題能交付的判斷。&lt;/p>
&lt;p>本篇屬於 &lt;a href="../">財務與投資書單&lt;/a>，每本書都用同一組四項描述：&lt;strong>證據來源&lt;/strong>（它的結論建立在什麼材料上）、&lt;strong>時效狀態&lt;/strong>（哪些部分依賴已經改變的前提）、&lt;strong>處境相容性&lt;/strong>（讀者具不具備它預設的環境）、&lt;strong>讀得出價值的前提&lt;/strong>（要有什麼經驗才讀得出它的價值）。四項的完整定義與這些判定的可信度說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>。這四項描述的是書；讀不動長篇文字時，本篇文末另標出承接同一組內容的公開課，收錄門檻與已知限制見 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。&lt;/p>
&lt;h2 id="起點是瘋狂恐慌與崩盤">起點是瘋狂、恐慌與崩盤&lt;/h2>
&lt;p>Charles Kindleberger 與 Robert Aliber 的《瘋狂、恐慌與崩盤》給出這個主題的座標：一次投機循環從哪裡開始、經過哪幾個階段、在哪一步轉向恐慌。階段的順序是外生衝擊改變了某類資產的獲利預期、信用跟著擴張、參與者從獲利者擴大到旁觀者、槓桿累積到某個水準之後有人開始退出、退出變成集體。&lt;/p>
&lt;p>它的第二條主線是最後貸款人：崩盤發生時該不該救、誰有能力救、以及救援本身如何改變下一次循環的起點。這條線讓這本書不只解釋事件，也解釋政策——讀者在新聞上看到央行的動作時，對照得出那是循環的哪一步。&lt;/p>
&lt;p>起點書的選定在這一篇走到了第二層判準。它跟下一本的涵蓋面差在一個面向以內——兩本給的都是循環的機制，差別在一本用事件敘事、一本用模板與圖表，而政策那一面下一本展開得更完整——這時取證據來源足以支持「被拿去佐證實際決定」這個用途的那本（三層判準的完整說明在 &lt;a href="../../software-management/topics/">主題書單&lt;/a> 的判準段）。這本的材料是跨越四百年的實際事件與其他研究者的紀錄，引用出去之後對方追問依據時指得回可查證的來源；下一本的模板由作者自己建立，追問到底的時候指回的是作者自己的操作。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨組織案例加理論建構：材料是數十次投機事件的並列比較，而把它們組織起來的是 Hyman Minsky 的金融不穩定假說。這個組合支持得了「這條路走過很多次」，支持不了「下一次也會照這個順序走」——書中對「泡沫能不能在事前辨識」這個問題保留了爭議，沒有把它收成一條判準。&lt;/p>
&lt;p>時效上，循環的階段模型不依賴年代，而&lt;strong>這本書的時效判定要先確認版次&lt;/strong>：Kindleberger 之後由 Aliber 接手更新，每一版把涵蓋範圍往後延，手上這一本的最後一章寫到哪一次危機，決定了它涵蓋到哪裡。中譯本譯自 Aliber 參與後的版本，之後英文版另有更新。&lt;/p>
&lt;p>處境相容性上，全書預設一個有跨境資本流動與自由定價資產市場的環境，循環的形狀由資金能不能自由進出決定。資本管制嚴格或匯率由政策決定的市場，同一組壓力會走另一條路徑，兩者的差別在路徑本身，不在同一條路徑上的深淺。第二個預設是存在一個有能力扮演最後貸款人的機構，這一項在主權債務以外幣計價的經濟體裡不成立。&lt;/p>
&lt;p>讀得出價值的前提是對至少一次資產泡沫有過近距離的印象，親身參與或旁觀都算。缺這個印象時，書中的階段讀起來是一串發生在別人身上的事，而它要讓人認出來的是下一次。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/007742603">三民（瘋狂、恐慌與崩盤：一部投資人必讀的金融崩潰史，樂金文化，2020）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="循環的完整模板在大債危機">循環的完整模板在大債危機&lt;/h2>
&lt;p>Ray Dalio 的《大債危機》把上一本的階段模型往前推一步：不只描述循環的形狀，還把每一步的政策選項與各自的後果列出來，並且指出模板在什麼條件下走向兩條不同的路徑。&lt;/p>
&lt;p>分岔的條件是債務用什麼貨幣計價。債務主要以本國貨幣計價時，央行的工具足以把去槓桿（債務相對於所得降回來的過程）的痛苦分攤到較長的期間，路徑偏向通縮型；債務以外幣計價、或本國貨幣不被外部持有時，同一組工具會觸發資本外逃，路徑轉為通膨型。&lt;strong>這個分岔本身就是這本書寫出來的失效條件&lt;/strong>，也是解釋層對起點書的第三層判準要找的東西（那條判準為什麼取代可操作性，寫在 &lt;a href="../">財務與投資書單&lt;/a> 的分層段）。&lt;/p>
&lt;p>書分三部分：模板本身、三個詳細展開的案例、以及數十個案例的彙編。第三部分的用途是讓讀者拿模板去對照自己感興趣的那一次。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是作者自建的方法加跨組織案例，而這一項是本篇最需要標清楚的一則。模板由作者從案例歸納，而那批案例是公開的歷史，讀者可以自己回去對。沒有獨立驗證的是另一句：照這個模板判斷會做得比較好。它的依據是作者自己的操作紀錄，而那份紀錄被結果篩選過——&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a> 在這裡篩的是「誰有機會出版一套模板」，操作紀錄不好的那些不會走到出版這一步。用法因此是把模板當成一組可以拿去對照歷史的假說，對照的材料由下一本提供。&lt;/p>
&lt;p>時效上，模板不依賴年代，而書中的案例終點依賴出版時間：出版後的通膨與升息週期不在案例裡，而那正好是模板宣稱涵蓋的通膨型路徑的一次實際考驗。這一項可以直接核對——拿模板對照出版之後那一輪，看它預測的順序有沒有出現。&lt;/p>
&lt;p>處境相容性上，主要分析對象是有自己的貨幣、且相當部分債務以本國貨幣計價的大型經濟體。小型開放經濟體的約束不同：外部需求與匯率變動主導的幅度大過內部信用循環，而書裡沒有處理那一層。&lt;/p>
&lt;p>讀得出價值的前提是先讀過一次循環的敘事版本，起點書提供的程度就夠。直接從模板讀起時，那組圖表看起來像一套已經驗證的規律，而它的性質是假說。取得成本這一項有一個要注意的地方：作者的網站提供全書的免費電子檔，代價是留下電子郵件並訂閱後續內容。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/007228915">三民（大債危機：橋水基金應對債務危機的原則，商業周刊，2019）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="這次不一樣提供可以覆核的長期紀錄">這次不一樣提供可以覆核的長期紀錄&lt;/h2>
&lt;p>Carmen Reinhart 與 Kenneth Rogoff 的《這次不一樣》提供前兩本缺的那一半：一份可以公開覆核的長期紀錄。他們把主權對外違約、國內違約、銀行危機、貨幣崩潰與通膨爆發五類事件整理成跨越數百年、涵蓋數十國的資料集，然後問這些事件在發生前有沒有共同的前兆。&lt;/p>
&lt;p>書名指向的是它最常被引用的那個結論：每一次危機之前，都有一套解釋當時為什麼不同的說法。這個結論的用途在判讀上很具體——聽到「這次的結構跟以前不一樣」時，可以回頭問前兆指標現在的讀數。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是大規模實證，材料是作者自建的資料庫。這一類的硬度值得單獨說明：資料筆數多，而每一筆的口徑取決於各國各時期的紀錄方式，跨世紀比較需要一連串調整。作者把資料與定義公開，這讓結論可以被外部重做。&lt;/p>
&lt;p>同一組作者在本書之後另有一篇關於債務水準與經濟成長的論文，2013 年有研究者重做它的計算，指出試算表遺漏了部分數列以及加權方式的選擇會改變結論。這件事的對象是那篇論文而非本書，而它對讀本書的用法有直接影響：把結論從公開的資料回推一次是可行的，也是這一類材料應有的使用方式。&lt;/p>
&lt;p>時效上，資料集的終點落在 2008 年前後那一輪危機，之後的債務累積、負利率期間與再通膨都不在裡面；作者與後續研究者另有延續版本的資料集，要引用最新數字時查那些而非書中的表。不隨資料延長改變的是分類架構——五類危機的切法與前兆指標的定義。&lt;/p>
&lt;p>處境相容性上，樣本的單位是主權國家，而多數判讀建立在國家層級的總量上。要問的是單一產業或單一公司會受到什麼影響時，這本書給不出對應的粒度，那一段要換 &lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/industry-benchmarking/" data-link-title="產業基準分析：怎麼判斷一間公司的數字是正常、優秀還是異常" data-link-desc="社群說「這個產業就是這樣」時，自己建立產業基準、構建比較組、判讀偏離方向的方法——從公開資料源到異常訊號的判讀">產業基準分析&lt;/a> 這類以產業為單位的材料承接。&lt;/p>
&lt;p>讀得出價值的前提是帶著一個具體問題進來。全書的主體是圖表與附錄資料，沒有問題時讀到的是一疊數字；帶著「現在這個情況跟哪幾次像」進來時，附錄查得到對照。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.sanmin.com.tw/product/index/007763783">三民（這次不一樣：800 年金融危機史，大牌出版，2020）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>三本各接一個面：循環的機制與階段、政策選項與它們各自的後果、以及可覆核的長期紀錄。前兩本在第一個面上重疊，起點書另外碰到第二個面的最後貸款人那一角，第二本則把第二個面完整展開。它們的分歧同樣要讀——泡沫能不能在事前辨識、最後貸款人該救到什麼程度、以及模板的階段能不能對到實際事件，三本給的答案並不一致。這一篇的產出是那組分歧的位置，而非其中一個答案。&lt;/p>
&lt;p>&lt;strong>有一面這個主題目前沒有條目&lt;/strong>：不由債務驅動的一般景氣波動——技術擴散、人口結構、供給側衝擊——三本都不處理。這一面缺席的後果具體是這樣：一段成長趨緩若來自人口與生產力，用信用循環的模板去讀會找不到對得上的階段，而三本都不會提示這個落差。這一格待評估，記在 &lt;a href="../">財務與投資書單&lt;/a> 的 Backlog 段。&lt;/p>
&lt;p>不收教科書。學派之間對同一組現象的解釋差距大到選一本教科書本身是選一個立場，而這份書單的四項描述判不了學派之爭——判定它需要的材料不在本書單的查證範圍內，跟這條線不比較預測準不準是同一個理由（寫在 &lt;a href="../">財務與投資書單&lt;/a> 的分層段）。要建立完整的總體經濟學基礎時，這個判斷回到讀者所在的學術或訓練脈絡，而挑的時候有一項跟本書單同源的判準可以帶著走：看它把模型的假設與適用範圍寫在哪裡、以及寫得多明白。&lt;/p>
&lt;p>當期展望書與年度預測書不收，理由是載體：它們的正確性依賴撰寫當期的環境，而書不隨環境更新到讀者手上，這條寫在 &lt;a href="../">財務與投資書單&lt;/a> 的「有些財務知識不該用書當載體」段。只給一套解釋而不寫它在什麼條件下失準的立場書同樣不收，這是 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 那條排除判準在本主題的形狀。&lt;/p>
&lt;h2 id="經濟學原理的後半整段接得住這個主題而它接的是三本書共用的底">經濟學原理的後半整段接得住這個主題，而它接的是三本書共用的底&lt;/h2>
&lt;p>這個主題由一門經濟學原理整段承接。它接的是本篇三本書共用的底，不是其中任何一本。台大開放式課程的這一門由吳聰敏（經濟學系）主講、中文授課，30 章分成 53 講，第 1 到 15 章是個體、第 16 到 30 章是總體：國民所得、物價指數、經濟成長、儲蓄、固定投資與可貸資金市場、金融市場與風險、貨幣供給與需求、物價膨脹與貨幣政策、匯率、國際金融、薪資停滯、財政赤字，最後三章走景氣循環的現象與解釋、凱因斯總合供需模型，以及景氣循環理論之爭論。&lt;/p>
&lt;p>本篇的讀法是看三套解釋在哪裡一致、在哪裡分開，而那條分界線要讀得出來，前提是知道國民所得、貨幣供給、可貸資金這些量之間的標準關係長什麼樣——三本書都預設讀者有這個底，都不從頭建立它。缺這個底時，三本各自的論證讀起來一樣有說服力，分歧落在哪裡則看不見。這一項就是四項描述裡的「讀得出價值的前提」，而這個前提由課程承接比由書承接省事。&lt;/p>
&lt;p>最後三章值得單獨標出來：第 30 章的標題直接是「景氣循環理論之爭論」，也就是把分歧本身列成一章，而那正是本篇三本書分歧的那一點。課程實際怎麼處理那個爭論要看過講次才知道，這裡只從章名判定它有處理。&lt;/p>
&lt;p>授課日期是 2021 年 9 月，第 26 章的薪資停滯與第 27 章的財政赤字用的是當時的數字；那兩章的機制不隨數字更新而變。指定閱讀是講者自己的教科書（吳聰敏、樊家忠《經濟學原理》），課程不依賴讀它也走得完。&lt;/p>
&lt;p>台灣經濟四百年由同一位講者主講、28 講，提供的是本地脈絡：本篇三本書的案例集中在歐美與跨國危機史，而信用擴張與匯率制度在一個小型開放經濟體上留下的痕跡不同。它承擔的角色跟本篇任何一本都不重疊——本書單這個主題目前沒有收到承擔那個角色的書。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://ocw.aca.ntu.edu.tw/courses/110S112">台大開放式課程（110S112 經濟學原理，吳聰敏，53 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpBz8s_fZ0yU_zd0pCRok2qi">YouTube 播放清單&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://ocw.aca.ntu.edu.tw/courses/111S207">台大開放式課程（111S207 台灣經濟四百年，吳聰敏，28 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpC5YfqCNJNW0OKjZbrGX4zP">YouTube 播放清單&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>環境的判讀要落到配置決定上，走 &lt;a href="../investing/">資本配置與投資&lt;/a>——長期報酬的實際分佈在那一篇，而這一篇給的是那些數字產生時所處的環境。&lt;/p>
&lt;p>利率與通膨到達一家公司的位置是報表上的幾個科目：利息費用、存貨評價、匯兌損益、以及應收帳款的回收速度。從報表這一端讀它們，走 &lt;a href="../accounting/">會計與財報&lt;/a>。&lt;/p>
&lt;p>同一組壓力在不同產業的傳導路徑不同，成本衝擊要走 &lt;a href="https://tarrragon.github.io/blog/business/financial-analysis/external-shock-industry-transformation/" data-link-title="外部衝擊如何觸發產業策略轉型：從成本暴漲到競爭格局重塑" data-link-desc="當整個產業遇到原料暴漲、供給中斷或需求崩跌時，判斷哪些公司能撐過去、哪些會被淘汰、衝擊後的競爭格局如何重塑的分析框架">外部衝擊與產業轉型&lt;/a>。&lt;/p>
&lt;p>利率變動先到達的是自己的現金流——負債的利息、房貸、以及緊急預備的實質購買力，那些在 &lt;a href="../personal-finance/">個人理財與風險保障&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>總體經濟在這條線承擔解釋：利率、通膨與債務水準的變動透過哪條路徑到達一家公司的損益與一個家庭的現金流。它落在解釋層，因為它交付的是一組機制而不是一個決定——同樣看懂了信用擴張的循環，該減碼還是該加碼仍然由決定層那兩個主題回答。</p>
<p>這個主題有一個別的主題沒有的性質：同一組現象存在幾套互相競爭的解釋，而它們的分歧不會隨資料增加而消失。所以這一篇收的三本刻意落在三種不同的證據形態上——一套從跨事件敘事歸納出的機制、一套由作者自建並用自己的操作驗證的模板、一份可以公開覆核的長期資料庫。讀法是看它們在哪裡一致、在哪裡分開，那條分界線比任何一本的結論更接近這個主題能交付的判斷。</p>
<p>本篇屬於 <a href="../">財務與投資書單</a>，每本書都用同一組四項描述：<strong>證據來源</strong>（它的結論建立在什麼材料上）、<strong>時效狀態</strong>（哪些部分依賴已經改變的前提）、<strong>處境相容性</strong>（讀者具不具備它預設的環境）、<strong>讀得出價值的前提</strong>（要有什麼經驗才讀得出它的價值）。四項的完整定義與這些判定的可信度說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>。這四項描述的是書；讀不動長篇文字時，本篇文末另標出承接同一組內容的公開課，收錄門檻與已知限制見 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。</p>
<h2 id="起點是瘋狂恐慌與崩盤">起點是瘋狂、恐慌與崩盤</h2>
<p>Charles Kindleberger 與 Robert Aliber 的《瘋狂、恐慌與崩盤》給出這個主題的座標：一次投機循環從哪裡開始、經過哪幾個階段、在哪一步轉向恐慌。階段的順序是外生衝擊改變了某類資產的獲利預期、信用跟著擴張、參與者從獲利者擴大到旁觀者、槓桿累積到某個水準之後有人開始退出、退出變成集體。</p>
<p>它的第二條主線是最後貸款人：崩盤發生時該不該救、誰有能力救、以及救援本身如何改變下一次循環的起點。這條線讓這本書不只解釋事件，也解釋政策——讀者在新聞上看到央行的動作時，對照得出那是循環的哪一步。</p>
<p>起點書的選定在這一篇走到了第二層判準。它跟下一本的涵蓋面差在一個面向以內——兩本給的都是循環的機制，差別在一本用事件敘事、一本用模板與圖表，而政策那一面下一本展開得更完整——這時取證據來源足以支持「被拿去佐證實際決定」這個用途的那本（三層判準的完整說明在 <a href="../../software-management/topics/">主題書單</a> 的判準段）。這本的材料是跨越四百年的實際事件與其他研究者的紀錄，引用出去之後對方追問依據時指得回可查證的來源；下一本的模板由作者自己建立，追問到底的時候指回的是作者自己的操作。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨組織案例加理論建構：材料是數十次投機事件的並列比較，而把它們組織起來的是 Hyman Minsky 的金融不穩定假說。這個組合支持得了「這條路走過很多次」，支持不了「下一次也會照這個順序走」——書中對「泡沫能不能在事前辨識」這個問題保留了爭議，沒有把它收成一條判準。</p>
<p>時效上，循環的階段模型不依賴年代，而<strong>這本書的時效判定要先確認版次</strong>：Kindleberger 之後由 Aliber 接手更新，每一版把涵蓋範圍往後延，手上這一本的最後一章寫到哪一次危機，決定了它涵蓋到哪裡。中譯本譯自 Aliber 參與後的版本，之後英文版另有更新。</p>
<p>處境相容性上，全書預設一個有跨境資本流動與自由定價資產市場的環境，循環的形狀由資金能不能自由進出決定。資本管制嚴格或匯率由政策決定的市場，同一組壓力會走另一條路徑，兩者的差別在路徑本身，不在同一條路徑上的深淺。第二個預設是存在一個有能力扮演最後貸款人的機構，這一項在主權債務以外幣計價的經濟體裡不成立。</p>
<p>讀得出價值的前提是對至少一次資產泡沫有過近距離的印象，親身參與或旁觀都算。缺這個印象時，書中的階段讀起來是一串發生在別人身上的事，而它要讓人認出來的是下一次。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/007742603">三民（瘋狂、恐慌與崩盤：一部投資人必讀的金融崩潰史，樂金文化，2020）</a></li>
</ul>
<h2 id="循環的完整模板在大債危機">循環的完整模板在大債危機</h2>
<p>Ray Dalio 的《大債危機》把上一本的階段模型往前推一步：不只描述循環的形狀，還把每一步的政策選項與各自的後果列出來，並且指出模板在什麼條件下走向兩條不同的路徑。</p>
<p>分岔的條件是債務用什麼貨幣計價。債務主要以本國貨幣計價時，央行的工具足以把去槓桿（債務相對於所得降回來的過程）的痛苦分攤到較長的期間，路徑偏向通縮型；債務以外幣計價、或本國貨幣不被外部持有時，同一組工具會觸發資本外逃，路徑轉為通膨型。<strong>這個分岔本身就是這本書寫出來的失效條件</strong>，也是解釋層對起點書的第三層判準要找的東西（那條判準為什麼取代可操作性，寫在 <a href="../">財務與投資書單</a> 的分層段）。</p>
<p>書分三部分：模板本身、三個詳細展開的案例、以及數十個案例的彙編。第三部分的用途是讓讀者拿模板去對照自己感興趣的那一次。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是作者自建的方法加跨組織案例，而這一項是本篇最需要標清楚的一則。模板由作者從案例歸納，而那批案例是公開的歷史，讀者可以自己回去對。沒有獨立驗證的是另一句：照這個模板判斷會做得比較好。它的依據是作者自己的操作紀錄，而那份紀錄被結果篩選過——<a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a> 在這裡篩的是「誰有機會出版一套模板」，操作紀錄不好的那些不會走到出版這一步。用法因此是把模板當成一組可以拿去對照歷史的假說，對照的材料由下一本提供。</p>
<p>時效上，模板不依賴年代，而書中的案例終點依賴出版時間：出版後的通膨與升息週期不在案例裡，而那正好是模板宣稱涵蓋的通膨型路徑的一次實際考驗。這一項可以直接核對——拿模板對照出版之後那一輪，看它預測的順序有沒有出現。</p>
<p>處境相容性上，主要分析對象是有自己的貨幣、且相當部分債務以本國貨幣計價的大型經濟體。小型開放經濟體的約束不同：外部需求與匯率變動主導的幅度大過內部信用循環，而書裡沒有處理那一層。</p>
<p>讀得出價值的前提是先讀過一次循環的敘事版本，起點書提供的程度就夠。直接從模板讀起時，那組圖表看起來像一套已經驗證的規律，而它的性質是假說。取得成本這一項有一個要注意的地方：作者的網站提供全書的免費電子檔，代價是留下電子郵件並訂閱後續內容。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/007228915">三民（大債危機：橋水基金應對債務危機的原則，商業周刊，2019）</a></li>
</ul>
<h2 id="這次不一樣提供可以覆核的長期紀錄">這次不一樣提供可以覆核的長期紀錄</h2>
<p>Carmen Reinhart 與 Kenneth Rogoff 的《這次不一樣》提供前兩本缺的那一半：一份可以公開覆核的長期紀錄。他們把主權對外違約、國內違約、銀行危機、貨幣崩潰與通膨爆發五類事件整理成跨越數百年、涵蓋數十國的資料集，然後問這些事件在發生前有沒有共同的前兆。</p>
<p>書名指向的是它最常被引用的那個結論：每一次危機之前，都有一套解釋當時為什麼不同的說法。這個結論的用途在判讀上很具體——聽到「這次的結構跟以前不一樣」時，可以回頭問前兆指標現在的讀數。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是大規模實證，材料是作者自建的資料庫。這一類的硬度值得單獨說明：資料筆數多，而每一筆的口徑取決於各國各時期的紀錄方式，跨世紀比較需要一連串調整。作者把資料與定義公開，這讓結論可以被外部重做。</p>
<p>同一組作者在本書之後另有一篇關於債務水準與經濟成長的論文，2013 年有研究者重做它的計算，指出試算表遺漏了部分數列以及加權方式的選擇會改變結論。這件事的對象是那篇論文而非本書，而它對讀本書的用法有直接影響：把結論從公開的資料回推一次是可行的，也是這一類材料應有的使用方式。</p>
<p>時效上，資料集的終點落在 2008 年前後那一輪危機，之後的債務累積、負利率期間與再通膨都不在裡面；作者與後續研究者另有延續版本的資料集，要引用最新數字時查那些而非書中的表。不隨資料延長改變的是分類架構——五類危機的切法與前兆指標的定義。</p>
<p>處境相容性上，樣本的單位是主權國家，而多數判讀建立在國家層級的總量上。要問的是單一產業或單一公司會受到什麼影響時，這本書給不出對應的粒度，那一段要換 <a href="/blog/business/financial-analysis/industry-benchmarking/" data-link-title="產業基準分析：怎麼判斷一間公司的數字是正常、優秀還是異常" data-link-desc="社群說「這個產業就是這樣」時，自己建立產業基準、構建比較組、判讀偏離方向的方法——從公開資料源到異常訊號的判讀">產業基準分析</a> 這類以產業為單位的材料承接。</p>
<p>讀得出價值的前提是帶著一個具體問題進來。全書的主體是圖表與附錄資料，沒有問題時讀到的是一疊數字；帶著「現在這個情況跟哪幾次像」進來時，附錄查得到對照。</p>
<ul>
<li><a href="https://www.sanmin.com.tw/product/index/007763783">三民（這次不一樣：800 年金融危機史，大牌出版，2020）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>三本各接一個面：循環的機制與階段、政策選項與它們各自的後果、以及可覆核的長期紀錄。前兩本在第一個面上重疊，起點書另外碰到第二個面的最後貸款人那一角，第二本則把第二個面完整展開。它們的分歧同樣要讀——泡沫能不能在事前辨識、最後貸款人該救到什麼程度、以及模板的階段能不能對到實際事件，三本給的答案並不一致。這一篇的產出是那組分歧的位置，而非其中一個答案。</p>
<p><strong>有一面這個主題目前沒有條目</strong>：不由債務驅動的一般景氣波動——技術擴散、人口結構、供給側衝擊——三本都不處理。這一面缺席的後果具體是這樣：一段成長趨緩若來自人口與生產力，用信用循環的模板去讀會找不到對得上的階段，而三本都不會提示這個落差。這一格待評估，記在 <a href="../">財務與投資書單</a> 的 Backlog 段。</p>
<p>不收教科書。學派之間對同一組現象的解釋差距大到選一本教科書本身是選一個立場，而這份書單的四項描述判不了學派之爭——判定它需要的材料不在本書單的查證範圍內，跟這條線不比較預測準不準是同一個理由（寫在 <a href="../">財務與投資書單</a> 的分層段）。要建立完整的總體經濟學基礎時，這個判斷回到讀者所在的學術或訓練脈絡，而挑的時候有一項跟本書單同源的判準可以帶著走：看它把模型的假設與適用範圍寫在哪裡、以及寫得多明白。</p>
<p>當期展望書與年度預測書不收，理由是載體：它們的正確性依賴撰寫當期的環境，而書不隨環境更新到讀者手上，這條寫在 <a href="../">財務與投資書單</a> 的「有些財務知識不該用書當載體」段。只給一套解釋而不寫它在什麼條件下失準的立場書同樣不收，這是 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 那條排除判準在本主題的形狀。</p>
<h2 id="經濟學原理的後半整段接得住這個主題而它接的是三本書共用的底">經濟學原理的後半整段接得住這個主題，而它接的是三本書共用的底</h2>
<p>這個主題由一門經濟學原理整段承接。它接的是本篇三本書共用的底，不是其中任何一本。台大開放式課程的這一門由吳聰敏（經濟學系）主講、中文授課，30 章分成 53 講，第 1 到 15 章是個體、第 16 到 30 章是總體：國民所得、物價指數、經濟成長、儲蓄、固定投資與可貸資金市場、金融市場與風險、貨幣供給與需求、物價膨脹與貨幣政策、匯率、國際金融、薪資停滯、財政赤字，最後三章走景氣循環的現象與解釋、凱因斯總合供需模型，以及景氣循環理論之爭論。</p>
<p>本篇的讀法是看三套解釋在哪裡一致、在哪裡分開，而那條分界線要讀得出來，前提是知道國民所得、貨幣供給、可貸資金這些量之間的標準關係長什麼樣——三本書都預設讀者有這個底，都不從頭建立它。缺這個底時，三本各自的論證讀起來一樣有說服力，分歧落在哪裡則看不見。這一項就是四項描述裡的「讀得出價值的前提」，而這個前提由課程承接比由書承接省事。</p>
<p>最後三章值得單獨標出來：第 30 章的標題直接是「景氣循環理論之爭論」，也就是把分歧本身列成一章，而那正是本篇三本書分歧的那一點。課程實際怎麼處理那個爭論要看過講次才知道，這裡只從章名判定它有處理。</p>
<p>授課日期是 2021 年 9 月，第 26 章的薪資停滯與第 27 章的財政赤字用的是當時的數字；那兩章的機制不隨數字更新而變。指定閱讀是講者自己的教科書（吳聰敏、樊家忠《經濟學原理》），課程不依賴讀它也走得完。</p>
<p>台灣經濟四百年由同一位講者主講、28 講，提供的是本地脈絡：本篇三本書的案例集中在歐美與跨國危機史，而信用擴張與匯率制度在一個小型開放經濟體上留下的痕跡不同。它承擔的角色跟本篇任何一本都不重疊——本書單這個主題目前沒有收到承擔那個角色的書。</p>
<ul>
<li><a href="https://ocw.aca.ntu.edu.tw/courses/110S112">台大開放式課程（110S112 經濟學原理，吳聰敏，53 講）</a>、<a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpBz8s_fZ0yU_zd0pCRok2qi">YouTube 播放清單</a></li>
<li><a href="https://ocw.aca.ntu.edu.tw/courses/111S207">台大開放式課程（111S207 台灣經濟四百年，吳聰敏，28 講）</a>、<a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpC5YfqCNJNW0OKjZbrGX4zP">YouTube 播放清單</a></li>
</ul>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>環境的判讀要落到配置決定上，走 <a href="../investing/">資本配置與投資</a>——長期報酬的實際分佈在那一篇，而這一篇給的是那些數字產生時所處的環境。</p>
<p>利率與通膨到達一家公司的位置是報表上的幾個科目：利息費用、存貨評價、匯兌損益、以及應收帳款的回收速度。從報表這一端讀它們，走 <a href="../accounting/">會計與財報</a>。</p>
<p>同一組壓力在不同產業的傳導路徑不同，成本衝擊要走 <a href="/blog/business/financial-analysis/external-shock-industry-transformation/" data-link-title="外部衝擊如何觸發產業策略轉型：從成本暴漲到競爭格局重塑" data-link-desc="當整個產業遇到原料暴漲、供給中斷或需求崩跌時，判斷哪些公司能撐過去、哪些會被淘汰、衝擊後的競爭格局如何重塑的分析框架">外部衝擊與產業轉型</a>。</p>
<p>利率變動先到達的是自己的現金流——負債的利息、房貸、以及緊急預備的實質購買力，那些在 <a href="../personal-finance/">個人理財與風險保障</a>。</p>
]]></content:encoded></item><item><title>書單知識卡片</title><link>https://tarrragon.github.io/blog/books/knowledge-cards/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/knowledge-cards/</guid><description>&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>描述一本書用一組維度——&lt;strong>證據來源、時效狀態、處境相容性、讀得出價值的前提&lt;/strong>——各主題篇（一個主題一篇、逐本套用那組維度的文章）逐本套用的就是這一組。分工是這樣：名字與一句效力範圍住在母頁，因為主題篇要對齊的就是那組名字；怎麼判、判錯會怎樣、兩本衝突時怎麼辦住在這裡的卡。主題篇只寫某一本書落在哪一格，判讀規則不重述。&lt;/p>
&lt;h2 id="卡片索引">卡片索引&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>卡片&lt;/th>
 &lt;th>核心問題&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源分類&lt;/a>&lt;/td>
 &lt;td>這本書的結論建立在什麼材料上——決定它支持得了多大範圍的決定&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>&lt;/td>
 &lt;td>它預設的環境在這裡存不存在——缺席時是折算、還是整本動不了&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>&lt;/td>
 &lt;td>團隊每天重疊多少工時——決定哪一批論證要自己重新換算&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>協作形態不是新的維度，它是處境相容性底下的一項環境條件；單獨開一張是因為它在四種環境裡最容易被略過，而失效的形態又最具體。&lt;/p>
&lt;p>證據來源底下也有一項同型的檢查——樣本的進入條件——而它的卡不在這個目錄：&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤&lt;/a> 住在 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/" data-link-title="商業概念知識卡片" data-link-desc="用原子化卡片整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識的術語">商業概念知識卡片&lt;/a>。那個概念的用途比選書廣得多（產業基準、比較組建構、回測都要用它），而商業卡片系統本來就是站內處理這類分析術語的地方。它在選書上的形態寫在 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源分類&lt;/a> 的「判完類別之後還有一項檢查」段——那一段只寫書的應用，定義指過去。&lt;/p>
&lt;p>時效狀態與讀得出價值的前提兩項的定義寫在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的維度段，這裡沒有獨立卡片，而兩者的理由不同。時效那一項的定義只有一句（論證依賴的前提現在還在不在），展開之後沒有要讀者回頭查的分類。讀得出價值的前提有分類——那一段列了六種形狀（過去的經歷、當下的處境、當下握有的權限、即將進入的位置、投入的形態、同主題的前置閱讀）——但目前只有一個消費點，也就是主題篇裡的前提句；第二個消費點出現時就該拆卡。缺卡的判定看的是有沒有一組讀者要反覆回來查的內容，不是維度之間要對稱。&lt;/p>
&lt;p>母頁還有一個名詞在這裡沒有卡：&lt;strong>角色歸屬&lt;/strong>（一本書在某主題裡承擔什麼位置）。它的理由跟上面兩項都不同——角色由各主題自己界定，持續交付那篇按證據強度分、事故檢討那篇按操作指南與深度個案分，兩者的切法不同而且都對。建卡等於替它們發明一套共用的切法，而那套切法不存在。&lt;/p>
&lt;p>這三張卡的標題以中文為主、英文附在括號裡，跟站內其他卡片目錄的慣例相反。那是刻意的：這三個維度名由本書單自訂，英文沒有可查證的社群語料，給一個英文主標會讓它看起來有外部權威。同一條判準也解釋了倖存者偏誤為什麼不住這裡——survivorship bias 查得到外部語料、用英文主標，也因此不屬於本書單自訂的那一組。&lt;/p></description><content:encoded><![CDATA[<p><a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>描述一本書用一組維度——<strong>證據來源、時效狀態、處境相容性、讀得出價值的前提</strong>——各主題篇（一個主題一篇、逐本套用那組維度的文章）逐本套用的就是這一組。分工是這樣：名字與一句效力範圍住在母頁，因為主題篇要對齊的就是那組名字；怎麼判、判錯會怎樣、兩本衝突時怎麼辦住在這裡的卡。主題篇只寫某一本書落在哪一格，判讀規則不重述。</p>
<h2 id="卡片索引">卡片索引</h2>
<table>
  <thead>
      <tr>
          <th>卡片</th>
          <th>核心問題</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源分類</a></td>
          <td>這本書的結論建立在什麼材料上——決定它支持得了多大範圍的決定</td>
      </tr>
      <tr>
          <td><a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a></td>
          <td>它預設的環境在這裡存不存在——缺席時是折算、還是整本動不了</td>
      </tr>
      <tr>
          <td><a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a></td>
          <td>團隊每天重疊多少工時——決定哪一批論證要自己重新換算</td>
      </tr>
  </tbody>
</table>
<p>協作形態不是新的維度，它是處境相容性底下的一項環境條件；單獨開一張是因為它在四種環境裡最容易被略過，而失效的形態又最具體。</p>
<p>證據來源底下也有一項同型的檢查——樣本的進入條件——而它的卡不在這個目錄：<a href="/blog/business/knowledge-cards/survivorship-bias/" data-link-title="Survivorship Bias（倖存者偏誤）" data-link-desc="拿到一組產業基準、同業比較或成功案例時，用來判斷那批樣本是不是先被結果篩過、數字該往哪個方向修正">倖存者偏誤</a> 住在 <a href="/blog/business/knowledge-cards/" data-link-title="商業概念知識卡片" data-link-desc="用原子化卡片整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識的術語">商業概念知識卡片</a>。那個概念的用途比選書廣得多（產業基準、比較組建構、回測都要用它），而商業卡片系統本來就是站內處理這類分析術語的地方。它在選書上的形態寫在 <a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源分類</a> 的「判完類別之後還有一項檢查」段——那一段只寫書的應用，定義指過去。</p>
<p>時效狀態與讀得出價值的前提兩項的定義寫在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的維度段，這裡沒有獨立卡片，而兩者的理由不同。時效那一項的定義只有一句（論證依賴的前提現在還在不在），展開之後沒有要讀者回頭查的分類。讀得出價值的前提有分類——那一段列了六種形狀（過去的經歷、當下的處境、當下握有的權限、即將進入的位置、投入的形態、同主題的前置閱讀）——但目前只有一個消費點，也就是主題篇裡的前提句；第二個消費點出現時就該拆卡。缺卡的判定看的是有沒有一組讀者要反覆回來查的內容，不是維度之間要對稱。</p>
<p>母頁還有一個名詞在這裡沒有卡：<strong>角色歸屬</strong>（一本書在某主題裡承擔什麼位置）。它的理由跟上面兩項都不同——角色由各主題自己界定，持續交付那篇按證據強度分、事故檢討那篇按操作指南與深度個案分，兩者的切法不同而且都對。建卡等於替它們發明一套共用的切法，而那套切法不存在。</p>
<p>這三張卡的標題以中文為主、英文附在括號裡，跟站內其他卡片目錄的慣例相反。那是刻意的：這三個維度名由本書單自訂，英文沒有可查證的社群語料，給一個英文主標會讓它看起來有外部權威。同一條判準也解釋了倖存者偏誤為什麼不住這裡——survivorship bias 查得到外部語料、用英文主標，也因此不屬於本書單自訂的那一組。</p>
]]></content:encoded></item><item><title>對人負責</title><link>https://tarrragon.github.io/blog/books/software-management/roles/people/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/people/</guid><description>&lt;p>交付出問題可以調度資源，人走了不能。這個不對稱決定了這一格的優先序，而它管的正是那件不可調度的事：人留不留得住、成不成長、講不講真話。多數新任管理者把時間花在交付上，因為交付有截止日而人沒有，等到人真的走了才發現那件事的處理時間早就過了。&lt;/p>
&lt;p>把管理做成更大範圍的自己動手，是這裡的主要失敗形式：接手最難的任務、審查每一個 PR、開會時給答案。這些動作短期看起來是負責，累積起來卻把團隊的成長機會收走，並且製造一個離不開的自己。&lt;/p>
&lt;h2 id="對人負責時成文制度與否的差別">對人負責時，成文制度與否的差別&lt;/h2>
&lt;p>有職級階梯的組織裡，這個位置的多數工具已經存在——晉升制度、績效流程、薪資帶、調動管道。問題是&lt;strong>在制度裡替人爭取&lt;/strong>：同樣一位工程師，寫得出具體證據的主管能幫他升上去，寫不出來的不能；制度不會告訴主管證據要長什麼樣。它通常要的是三件事——做過什麼、影響到誰、沒有他會怎樣——而日常累積的觀察多半停在「做得不錯」，那三件事要平時就記，年度評等前一週補寫不出來。這裡的技能偏向把日常觀察轉成制度看得懂的語言，以及知道哪些戰場值得打。&lt;/p>
&lt;p>扁平的小公司沒有這些工具。沒有職級就沒有晉升，沒有薪資帶就每次調薪都是個案談判，沒有調動管道就「這個人不適合這個位置」只有離職一個出口。這裡的問題是&lt;strong>要自己造工具，同時還要用它&lt;/strong>——而自己造的制度沒有外部公信力：公布一套三級的工程師分級，隔週就有人問「這個級距是不是為了讓某某升上去才這樣切」——問的人不一定是在質疑動機，而是無從判斷這套標準是不是先射箭再畫靶，而定標準的一方也提不出制定過程以外的依據。應對方式是把外部標準引進來當錨（公開的職級框架、產業薪資調查），而不是自己定義一套。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">Peopleware&lt;/a>&lt;/strong>（DeMarco &amp;amp; Lister）是這個位置的主要書。在這個位置讀它的理由是槓桿：環境是這一格能動的東西裡最少人動、而效果最直接的一個，也是少數不必先取得別人同意的。它涵蓋哪些主題、證據有多硬，在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/role-transitions/">The Making of a Manager&lt;/a>&lt;/strong>（Julie Zhuo）聚焦第一年，剛進這條路線的人讀它的可執行性高於讀鋪完整條階梯的書——它給的是這個位置頭幾個月會實際遇到的場合該說什麼。涵蓋哪些場合在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">First, Break All the Rules&lt;/a>&lt;/strong> 在這個位置的用處有兩層：一是知道自己這一格的份量有多重，二是要在制度裡替人爭取時，它的調查規模足以支持拿去當依據——那是這條路線上少數可以引用數字的場合。核心發現與證據規模在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/culture-safety/">The Fearless Organization&lt;/a>&lt;/strong>（Amy Edmondson）處理的是這裡最難自我診斷的問題（概念本身見 &lt;a href="https://tarrragon.github.io/blog/til/organization/psychological-safety/" data-link-title="心理安全感：群體裡的人願不願意講壞消息" data-link-desc="看到某個團隊的回報一切正常卻結果不對時，用來理解沉默的機制：它衡量的是說出問題會不會被懲罰，而不是氣氛好不好">心理安全感&lt;/a>）——團隊不講壞消息時，所有回報看起來都正常。它給的介入手段都落在這一格能做的範圍內，不需要制度配合。書中失敗案例裡「領導者宣稱歡迎壞消息、實際反應卻相反」那一段值得特別對照，那是這個位置最常見的自我誤判。框架本身與證據在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/retention-motivation/">Radical Candor&lt;/a>&lt;/strong>（Kim Scott）處理回饋這一個動作。新任管理者最常卡在「只關心不挑戰」那一格，卡住的代價要幾個月後才結算。這本的用途是讓那個狀態在當下被自己認出來，而不是事後回想。四個象限的定義在主題篇。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>進到這個位置幾乎都是被指派的，而多數人接下來之後才發現它跟原本想像的不同——原本以為是「範圍更大的技術工作」，實際上一天裡技術佔的比例會掉到很低。轉換前值得先確認的是自己對「幫別人做成事」有沒有實際的興趣，而不只是對「不想被別人管」有興趣；後者會在半年內把人推回技術路線，而那個來回對團隊的代價比一開始就不接更高。&lt;/p>
&lt;p>&lt;strong>往管理更大的範圍&lt;/strong>（&lt;a href="../org-structure/">對組織結構負責&lt;/a>）：預習的是結構與承諾。這個位置的判斷單位是人，&lt;a href="../org-structure/">對組織結構負責&lt;/a> 的判斷單位是團隊之間的介面；那裡會遇到一個這裡完全碰不到的問題——組織的承諾為什麼系統性失準。&lt;a href="../../topics/team-design/">組織結構與團隊設計&lt;/a> 與 &lt;a href="../../topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a> 是入口。&lt;/p>
&lt;p>&lt;strong>留在這個位置&lt;/strong>也是完整的路線，而且是這五格裡最容易被誤讀成停滯的一格——把一組人帶到他們自己會處理問題，本身就是產出。往深處走要補的是結構與制度的視角：同樣的管理動作在不同的團隊規模與組成下效果差很多，&lt;a href="../../topics/team-design/">組織結構與團隊設計&lt;/a> 的認知負荷段是這個方向的入口。&lt;/p>
&lt;p>&lt;strong>轉回技術路線&lt;/strong>（&lt;a href="../technical-quality/">對技術品質負責&lt;/a>）：這條路走得通，而且這條路線練出來的判斷不會浪費——處理過人的問題之後再回去做技術決策，對「這個方案要靠誰執行、他們願不願意」的判斷會比沒帶過人的時候準。要補的是技術廣度與無職權影響力，看 &lt;a href="../../topics/influence-conversation/">困難對話與無權限影響力&lt;/a>。轉回去之前值得確認自己想離開的是管理工作本身，還是這個組織裡的管理工作。&lt;/p></description><content:encoded><![CDATA[<p>交付出問題可以調度資源，人走了不能。這個不對稱決定了這一格的優先序，而它管的正是那件不可調度的事：人留不留得住、成不成長、講不講真話。多數新任管理者把時間花在交付上，因為交付有截止日而人沒有，等到人真的走了才發現那件事的處理時間早就過了。</p>
<p>把管理做成更大範圍的自己動手，是這裡的主要失敗形式：接手最難的任務、審查每一個 PR、開會時給答案。這些動作短期看起來是負責，累積起來卻把團隊的成長機會收走，並且製造一個離不開的自己。</p>
<h2 id="對人負責時成文制度與否的差別">對人負責時，成文制度與否的差別</h2>
<p>有職級階梯的組織裡，這個位置的多數工具已經存在——晉升制度、績效流程、薪資帶、調動管道。問題是<strong>在制度裡替人爭取</strong>：同樣一位工程師，寫得出具體證據的主管能幫他升上去，寫不出來的不能；制度不會告訴主管證據要長什麼樣。它通常要的是三件事——做過什麼、影響到誰、沒有他會怎樣——而日常累積的觀察多半停在「做得不錯」，那三件事要平時就記，年度評等前一週補寫不出來。這裡的技能偏向把日常觀察轉成制度看得懂的語言，以及知道哪些戰場值得打。</p>
<p>扁平的小公司沒有這些工具。沒有職級就沒有晉升，沒有薪資帶就每次調薪都是個案談判，沒有調動管道就「這個人不適合這個位置」只有離職一個出口。這裡的問題是<strong>要自己造工具，同時還要用它</strong>——而自己造的制度沒有外部公信力：公布一套三級的工程師分級，隔週就有人問「這個級距是不是為了讓某某升上去才這樣切」——問的人不一定是在質疑動機，而是無從判斷這套標準是不是先射箭再畫靶，而定標準的一方也提不出制定過程以外的依據。應對方式是把外部標準引進來當錨（公開的職級框架、產業薪資調查），而不是自己定義一套。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/retention-motivation/">Peopleware</a></strong>（DeMarco &amp; Lister）是這個位置的主要書。在這個位置讀它的理由是槓桿：環境是這一格能動的東西裡最少人動、而效果最直接的一個，也是少數不必先取得別人同意的。它涵蓋哪些主題、證據有多硬，在主題篇。</p>
<p><strong><a href="../../topics/role-transitions/">The Making of a Manager</a></strong>（Julie Zhuo）聚焦第一年，剛進這條路線的人讀它的可執行性高於讀鋪完整條階梯的書——它給的是這個位置頭幾個月會實際遇到的場合該說什麼。涵蓋哪些場合在主題篇。</p>
<p><strong><a href="../../topics/retention-motivation/">First, Break All the Rules</a></strong> 在這個位置的用處有兩層：一是知道自己這一格的份量有多重，二是要在制度裡替人爭取時，它的調查規模足以支持拿去當依據——那是這條路線上少數可以引用數字的場合。核心發現與證據規模在主題篇。</p>
<p><strong><a href="../../topics/culture-safety/">The Fearless Organization</a></strong>（Amy Edmondson）處理的是這裡最難自我診斷的問題（概念本身見 <a href="/blog/til/organization/psychological-safety/" data-link-title="心理安全感：群體裡的人願不願意講壞消息" data-link-desc="看到某個團隊的回報一切正常卻結果不對時，用來理解沉默的機制：它衡量的是說出問題會不會被懲罰，而不是氣氛好不好">心理安全感</a>）——團隊不講壞消息時，所有回報看起來都正常。它給的介入手段都落在這一格能做的範圍內，不需要制度配合。書中失敗案例裡「領導者宣稱歡迎壞消息、實際反應卻相反」那一段值得特別對照，那是這個位置最常見的自我誤判。框架本身與證據在主題篇。</p>
<p><strong><a href="../../topics/retention-motivation/">Radical Candor</a></strong>（Kim Scott）處理回饋這一個動作。新任管理者最常卡在「只關心不挑戰」那一格，卡住的代價要幾個月後才結算。這本的用途是讓那個狀態在當下被自己認出來，而不是事後回想。四個象限的定義在主題篇。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>進到這個位置幾乎都是被指派的，而多數人接下來之後才發現它跟原本想像的不同——原本以為是「範圍更大的技術工作」，實際上一天裡技術佔的比例會掉到很低。轉換前值得先確認的是自己對「幫別人做成事」有沒有實際的興趣，而不只是對「不想被別人管」有興趣；後者會在半年內把人推回技術路線，而那個來回對團隊的代價比一開始就不接更高。</p>
<p><strong>往管理更大的範圍</strong>（<a href="../org-structure/">對組織結構負責</a>）：預習的是結構與承諾。這個位置的判斷單位是人，<a href="../org-structure/">對組織結構負責</a> 的判斷單位是團隊之間的介面；那裡會遇到一個這裡完全碰不到的問題——組織的承諾為什麼系統性失準。<a href="../../topics/team-design/">組織結構與團隊設計</a> 與 <a href="../../topics/estimation-decision/">估算、承諾與決策偏誤</a> 是入口。</p>
<p><strong>留在這個位置</strong>也是完整的路線，而且是這五格裡最容易被誤讀成停滯的一格——把一組人帶到他們自己會處理問題，本身就是產出。往深處走要補的是結構與制度的視角：同樣的管理動作在不同的團隊規模與組成下效果差很多，<a href="../../topics/team-design/">組織結構與團隊設計</a> 的認知負荷段是這個方向的入口。</p>
<p><strong>轉回技術路線</strong>（<a href="../technical-quality/">對技術品質負責</a>）：這條路走得通，而且這條路線練出來的判斷不會浪費——處理過人的問題之後再回去做技術決策，對「這個方案要靠誰執行、他們願不願意」的判斷會比沒帶過人的時候準。要補的是技術廣度與無職權影響力，看 <a href="../../topics/influence-conversation/">困難對話與無權限影響力</a>。轉回去之前值得確認自己想離開的是管理工作本身，還是這個組織裡的管理工作。</p>
]]></content:encoded></item><item><title>驗證自己寫對了</title><link>https://tarrragon.github.io/blog/books/craft/verification/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/craft/verification/</guid><description>&lt;p>這個主題有一個技藝線其他三篇——設計判準、系統架構、改既有的程式——都沒有的特徵：&lt;strong>收錄的書彼此不同意&lt;/strong>。測試該寫到什麼粒度、協作對象該不該用 mock 替換、測試該綁在行為上還是結構上——這些問題有兩個互相對立的傳統，而多數讀者是在讀到第二本、發現它跟第一本說法相反的時候，才知道自己一直在照著其中一派做而不知道有另一派。&lt;/p>
&lt;p>所以這篇的選讀判斷跟那三篇不同：不是「先讀哪本再讀哪本」，是&lt;strong>先知道分歧在哪，再決定要站哪邊&lt;/strong>。&lt;/p>
&lt;p>收的書分成兩組。第一組四本各自站在一個位置上：Kent Beck 的《Test-Driven Development: By Example》給出原始定義，Freeman 與 Pryce 的《Growing Object-Oriented Software, Guided by Tests》把其中一派的主張寫到最完整，Khorikov 的《Unit Testing Principles, Practices, and Patterns》是後來對那一派的系統性批評——&lt;strong>這三本不同意的是同一個問題的答案&lt;/strong>，那個問題是「測試的單元是什麼」。Bach 與 Bolton 的《Taking Testing Seriously》站在第四個位置上，&lt;strong>它不同意的是問題本身&lt;/strong>：它主張要先分開的是兩種活動——「執行事先寫好的判準」與「設計判準、發現沒人想到要問的問題」——而不是單元的大小。&lt;/p>
&lt;p>第二組一本，Aniche 的《Effective Software Testing》，處理的是立場確定之後仍然要回答的操作問題——這些測試案例是怎麼推出來的。前四本沒有一本給這個程序。&lt;/p>
&lt;p>站內對這個分歧的立場與推導在 &lt;a href="https://tarrragon.github.io/blog/record/behavior-first-tdd-methodology/" data-link-title="行為優先的 TDD：測試耦合行為、不耦合結構" data-link-desc="重構時測試大量壞掉、或在「該不該 mock 這個協作者」上需要一個可執行的立場時，本站對兩派 TDD 分歧的選擇與推導">行為優先的 TDD 方法論&lt;/a>，那篇處理的是「所以我們怎麼做」；這裡處理的是「該讀哪本、每本代表什麼位置」。&lt;/p>
&lt;h2 id="起點是-kent-beck-的-test-driven-development-by-example">起點是 Kent Beck 的 Test-Driven Development: By Example&lt;/h2>
&lt;p>這本是 TDD 的原始定義，2003 年出版，做的事情很單純：從頭到尾走完兩個小專案，把紅燈、綠燈、重構這個循環示範幾十次。讀它的價值不在學到技巧，在於看清楚那個循環的節奏究竟有多小——書中的步伐比多數人想像的細，細到會讓第一次讀的人覺得沒必要。&lt;/p>
&lt;p>它是起點的理由是 Freeman 與 Pryce 那本、Khorikov 那本都在跟它對話。分歧從一個定義開始：&lt;strong>測試的單元是什麼&lt;/strong>。Beck 的用法把單元當成一組協同工作的類別，測試對外的行為；後來的另一派——書市慣稱倫敦學派——把單元縮到單一類別，把所有協作者換成 mock。兩派的所有差異都從這個定義分岔出去。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是單一路徑的個人經驗，形式是作者逐步演練自己的實踐而非論證。時效上，範例是 Java 與 Python 的舊版本，測試框架也隔了兩個世代；紅綠重構的節奏與「讓測試驅動設計」這個主張不依賴那些。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，這套節奏預設提交的粒度由寫的人自己決定。流程若要求每個提交對應一張工單、或測試必須跟功能在同一個 PR 送審，書中那個細到讓人覺得沒必要的步伐就落不了地，要先改流程、或改用較粗的循環。&lt;/p>
&lt;p>這本書幾乎不需要前置作業，但它預設讀者寫過測試——完全沒寫過的人會看不出那些步驟在避免什麼；先在自己的專案寫過幾個測試再來讀，那些步驟的用意才看得出來。繁體中文版《Kent Beck 的測試驅動開發：案例導向的逐步解決之道》，博碩出版、陳仕傑譯。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530">Amazon（Test Driven Development: By Example）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010883019">博客來（Kent Beck 的測試驅動開發：案例導向的逐步解決之道）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想看-mock-那一派的完整主張時讀-growing-object-oriented-software-guided-by-tests">想看 mock 那一派的完整主張時讀 Growing Object-Oriented Software, Guided by Tests&lt;/h2>
&lt;p>Steve Freeman 與 Nat Pryce 這本是倫敦學派的代表作，也是它最完整的一次陳述。主張是由外而內開發：從最外層的驗收測試開始，往內每遇到一個還不存在的協作對象就先用 mock 頂替，於是 mock 不只是測試工具，而是&lt;strong>用來發現物件之間該有什麼關係的設計手段&lt;/strong>。&lt;/p>
&lt;p>這個定位常被誤解。多數人把 mock 當成「真實依賴太慢所以換掉」，而這本書的主張是相反的——mock 是在那個依賴還不知道長什麼樣的時候，用寫測試的方式把它的介面逼出來。書中貫穿全書的那個範例完整走過一次這個流程，是它跟只講技巧的測試書的差別。&lt;/p>
&lt;p>它也是這個主題裡爭議最集中的一本。批評集中在同一點：這種寫法讓測試綁在物件的協作結構上，於是重構內部結構時測試會大量壞掉，而重構本來不該破壞測試。這個批評成不成立，取決於單元怎麼定義——那正是 Khorikov 那本要處理的問題。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗（兩位作者十年的系統開發），形式是主張加上一個長篇範例。時效上，範例是 Java 與 JMock，那部分已經很遠；由外而內的流程與 mock 當設計手段這個主張不依賴語言。&lt;/p>
&lt;p>讀這本要先有一次自己造成的後果：寫過一套後來覺得難維護的測試。還沒有那個經驗時，這本的主張跟批評它的主張聽起來都有道理，讀的人沒有判斷的依據——它因此適合排在自己的測試開始出現維護負擔之後，而不是照出版順序讀。查不到中譯本（2026 年 8 月查）。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627">Amazon（Growing Object-Oriented Software, Guided by Tests）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要一組可以拿來評分的判準時讀-unit-testing-principles-practices-and-patterns">要一組可以拿來評分的判準時讀 Unit Testing Principles, Practices, and Patterns&lt;/h2>
&lt;p>Vladimir Khorikov 這本（2020）是單元定義這條線上最後出版的一本，也是唯一給出&lt;strong>一套可以拿來評測試的通用判準&lt;/strong>的一本。四支柱是防止回歸、抵抗重構、快速回饋、易於維護，而書中的核心論證是前三者互相衝突、不可能同時最大化，所以測試設計是取捨而非最佳實踐。這套判準有一類測試評不了：為了替沒有測試的程式碼建立行為快照而寫、用完就丟的那種（&lt;a href="../changing-existing-code/">改既有的程式&lt;/a> 收的 Feathers 那本教的手法），它在抵抗重構與易於維護上必然低分，而那正是它該有的樣子。四支柱預設被評的測試要長期留著。&lt;/p>
&lt;p>它對倫敦學派的批評就建立在這組判準上：把所有協作者 mock 掉會讓測試耦合到實作結構，因而在「抵抗重構」這一項上得分很低——而那一項是四支柱裡唯一不能用其他項補償的，因為一個會誤報的測試套件最終會被團隊忽略。作者主張的是古典學派：單元是行為而非類別，只有跨越應用邊界的協作對象（資料庫、外部服務）才該替換。&lt;/p>
&lt;p>這本的用法跟前兩本不同：它不是拿來讀完的，是拿來當量尺的。手上有一套自己覺得不對勁的測試時，逐項打分數比讀任何主張都快看出問題在哪。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗加上理論建構，形式是原則加判準——這是本篇收錄的書裡唯一嘗試把測試設計寫成可推導體系的。範例是 C#，但判準本身與語言無關。時效上沒有明顯過時的部分——四支柱的取捨與工具世代無關。&lt;/p>
&lt;p>這本要有量測的對象：手上一套實際在跑、而且開始造成負擔的測試。沒有那套測試，四支柱之間的取捨不會浮現——它們互相衝突，而衝突要有一套實際的測試當標的才看得見。還沒有這樣一套測試的話，可以先知道這本存在，等負擔出現再拿出來用。查不到繁體中文版，簡體中文版《單元測試：原則、實踐與模式》（2026 年 8 月查）。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Unit-Testing-Principles-Practices-Patterns/dp/1617296279">Amazon（Unit Testing Principles, Practices, and Patterns）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.tenlong.com.tw/products/9781617296277">天瓏（Unit Testing Principles, Practices, and Patterns，原文版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想知道機器接手判準之後人還做什麼時讀-taking-testing-seriously">想知道機器接手判準之後人還做什麼時讀 Taking Testing Seriously&lt;/h2>
&lt;p>James Bach 與 Michael Bolton 這本（Wiley，2025 年 11 月）是 Rapid Software Testing 這一派的完整陳述。它跟前三本不在同一個座標系裡：前三本爭的是單元的邊界該畫在哪，這本主張要先分開的是兩種活動——&lt;strong>checking&lt;/strong>（對一個已經被決定的事實做二元評估，判準事先寫下、原則上可以交給機器）與 &lt;strong>testing&lt;/strong>（設計判準本身、發現沒有人想到要問的問題、判斷觀察到的現象算不算問題）。作者的立場是自動化能接手的只有前者，而前者的品質完全取決於當初設計它的那次後者。&lt;/p>
&lt;p>這個分界是這一派的起點，理由是自動化的邊界由判準寫不寫得下來決定，與工具能力無關。作者同期公開談論過 AI 與這個分界的關係；書的目次未能取得，這裡不指涉它在書中的位置與篇幅。&lt;/p>
&lt;p>證據來源是兩位作者長期的教學與顧問實踐加上一套自建的術語體系，形式是主張與啟發式的目錄而不是逐步演練——它不像 Freeman 與 Pryce 那本有一個貫穿全書的範例可以跟著做。時效上是本篇最新的一本，術語體系本身不依賴任何工具世代。&lt;/p>
&lt;p>處境相容性上要先知道一件事：這一派的語彙（checking、oracle、heuristic、探索式測試的活動記錄）與多數團隊日常使用的詞彙不重疊，讀的時候要一邊做術語對照。它也預設讀者有機會親自操作產品——判準要在觀察當下才成形是這套主張的核心，而完全只寫單元測試、不碰成品的人拿不到那個觀察位置。查不到中譯本（2026 年 8 月查）。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.wiley.com/en-us/Taking&amp;#43;Testing&amp;#43;Seriously:&amp;#43;The&amp;#43;Rapid&amp;#43;Software&amp;#43;Testing&amp;#43;Approach-p-00416398">Wiley（Taking Testing Seriously: The Rapid Software Testing Approach）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.tenlong.com.tw/products/9781394253197">天瓏（Taking Testing Seriously，原文版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要一套推出測試案例的程序時讀-effective-software-testing">要一套推出測試案例的程序時讀 Effective Software Testing&lt;/h2>
&lt;p>Maurício Aniche 這本（Manning，2022）處理的是前四本都沒有給的一項：&lt;strong>這些測試案例是怎麼被推出來的&lt;/strong>。Khorikov 給的是評分用的量尺，Beck 給的是循環的節奏，這本給的是從需求推導案例的步驟——先從規格切出等價類與邊界，再用覆蓋準則檢查有沒有漏掉分支，接著設計方法與類別的契約（前置條件、後置條件、不變量），最後回頭問這段程式碼的可測試性是不是設計本身的問題。&lt;/p></description><content:encoded><![CDATA[<p>這個主題有一個技藝線其他三篇——設計判準、系統架構、改既有的程式——都沒有的特徵：<strong>收錄的書彼此不同意</strong>。測試該寫到什麼粒度、協作對象該不該用 mock 替換、測試該綁在行為上還是結構上——這些問題有兩個互相對立的傳統，而多數讀者是在讀到第二本、發現它跟第一本說法相反的時候，才知道自己一直在照著其中一派做而不知道有另一派。</p>
<p>所以這篇的選讀判斷跟那三篇不同：不是「先讀哪本再讀哪本」，是<strong>先知道分歧在哪，再決定要站哪邊</strong>。</p>
<p>收的書分成兩組。第一組四本各自站在一個位置上：Kent Beck 的《Test-Driven Development: By Example》給出原始定義，Freeman 與 Pryce 的《Growing Object-Oriented Software, Guided by Tests》把其中一派的主張寫到最完整，Khorikov 的《Unit Testing Principles, Practices, and Patterns》是後來對那一派的系統性批評——<strong>這三本不同意的是同一個問題的答案</strong>，那個問題是「測試的單元是什麼」。Bach 與 Bolton 的《Taking Testing Seriously》站在第四個位置上，<strong>它不同意的是問題本身</strong>：它主張要先分開的是兩種活動——「執行事先寫好的判準」與「設計判準、發現沒人想到要問的問題」——而不是單元的大小。</p>
<p>第二組一本，Aniche 的《Effective Software Testing》，處理的是立場確定之後仍然要回答的操作問題——這些測試案例是怎麼推出來的。前四本沒有一本給這個程序。</p>
<p>站內對這個分歧的立場與推導在 <a href="/blog/record/behavior-first-tdd-methodology/" data-link-title="行為優先的 TDD：測試耦合行為、不耦合結構" data-link-desc="重構時測試大量壞掉、或在「該不該 mock 這個協作者」上需要一個可執行的立場時，本站對兩派 TDD 分歧的選擇與推導">行為優先的 TDD 方法論</a>，那篇處理的是「所以我們怎麼做」；這裡處理的是「該讀哪本、每本代表什麼位置」。</p>
<h2 id="起點是-kent-beck-的-test-driven-development-by-example">起點是 Kent Beck 的 Test-Driven Development: By Example</h2>
<p>這本是 TDD 的原始定義，2003 年出版，做的事情很單純：從頭到尾走完兩個小專案，把紅燈、綠燈、重構這個循環示範幾十次。讀它的價值不在學到技巧，在於看清楚那個循環的節奏究竟有多小——書中的步伐比多數人想像的細，細到會讓第一次讀的人覺得沒必要。</p>
<p>它是起點的理由是 Freeman 與 Pryce 那本、Khorikov 那本都在跟它對話。分歧從一個定義開始：<strong>測試的單元是什麼</strong>。Beck 的用法把單元當成一組協同工作的類別，測試對外的行為；後來的另一派——書市慣稱倫敦學派——把單元縮到單一類別，把所有協作者換成 mock。兩派的所有差異都從這個定義分岔出去。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是單一路徑的個人經驗，形式是作者逐步演練自己的實踐而非論證。時效上，範例是 Java 與 Python 的舊版本，測試框架也隔了兩個世代；紅綠重構的節奏與「讓測試驅動設計」這個主張不依賴那些。</p>
<p><a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，這套節奏預設提交的粒度由寫的人自己決定。流程若要求每個提交對應一張工單、或測試必須跟功能在同一個 PR 送審，書中那個細到讓人覺得沒必要的步伐就落不了地，要先改流程、或改用較粗的循環。</p>
<p>這本書幾乎不需要前置作業，但它預設讀者寫過測試——完全沒寫過的人會看不出那些步驟在避免什麼；先在自己的專案寫過幾個測試再來讀，那些步驟的用意才看得出來。繁體中文版《Kent Beck 的測試驅動開發：案例導向的逐步解決之道》，博碩出版、陳仕傑譯。</p>
<ul>
<li><a href="https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530">Amazon（Test Driven Development: By Example）</a></li>
<li><a href="https://www.books.com.tw/products/0010883019">博客來（Kent Beck 的測試驅動開發：案例導向的逐步解決之道）</a></li>
</ul>
<h2 id="想看-mock-那一派的完整主張時讀-growing-object-oriented-software-guided-by-tests">想看 mock 那一派的完整主張時讀 Growing Object-Oriented Software, Guided by Tests</h2>
<p>Steve Freeman 與 Nat Pryce 這本是倫敦學派的代表作，也是它最完整的一次陳述。主張是由外而內開發：從最外層的驗收測試開始，往內每遇到一個還不存在的協作對象就先用 mock 頂替，於是 mock 不只是測試工具，而是<strong>用來發現物件之間該有什麼關係的設計手段</strong>。</p>
<p>這個定位常被誤解。多數人把 mock 當成「真實依賴太慢所以換掉」，而這本書的主張是相反的——mock 是在那個依賴還不知道長什麼樣的時候，用寫測試的方式把它的介面逼出來。書中貫穿全書的那個範例完整走過一次這個流程，是它跟只講技巧的測試書的差別。</p>
<p>它也是這個主題裡爭議最集中的一本。批評集中在同一點：這種寫法讓測試綁在物件的協作結構上，於是重構內部結構時測試會大量壞掉，而重構本來不該破壞測試。這個批評成不成立，取決於單元怎麼定義——那正是 Khorikov 那本要處理的問題。</p>
<p>證據來源是單一路徑的個人經驗（兩位作者十年的系統開發），形式是主張加上一個長篇範例。時效上，範例是 Java 與 JMock，那部分已經很遠；由外而內的流程與 mock 當設計手段這個主張不依賴語言。</p>
<p>讀這本要先有一次自己造成的後果：寫過一套後來覺得難維護的測試。還沒有那個經驗時，這本的主張跟批評它的主張聽起來都有道理，讀的人沒有判斷的依據——它因此適合排在自己的測試開始出現維護負擔之後，而不是照出版順序讀。查不到中譯本（2026 年 8 月查）。</p>
<ul>
<li><a href="https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627">Amazon（Growing Object-Oriented Software, Guided by Tests）</a></li>
</ul>
<h2 id="要一組可以拿來評分的判準時讀-unit-testing-principles-practices-and-patterns">要一組可以拿來評分的判準時讀 Unit Testing Principles, Practices, and Patterns</h2>
<p>Vladimir Khorikov 這本（2020）是單元定義這條線上最後出版的一本，也是唯一給出<strong>一套可以拿來評測試的通用判準</strong>的一本。四支柱是防止回歸、抵抗重構、快速回饋、易於維護，而書中的核心論證是前三者互相衝突、不可能同時最大化，所以測試設計是取捨而非最佳實踐。這套判準有一類測試評不了：為了替沒有測試的程式碼建立行為快照而寫、用完就丟的那種（<a href="../changing-existing-code/">改既有的程式</a> 收的 Feathers 那本教的手法），它在抵抗重構與易於維護上必然低分，而那正是它該有的樣子。四支柱預設被評的測試要長期留著。</p>
<p>它對倫敦學派的批評就建立在這組判準上：把所有協作者 mock 掉會讓測試耦合到實作結構，因而在「抵抗重構」這一項上得分很低——而那一項是四支柱裡唯一不能用其他項補償的，因為一個會誤報的測試套件最終會被團隊忽略。作者主張的是古典學派：單元是行為而非類別，只有跨越應用邊界的協作對象（資料庫、外部服務）才該替換。</p>
<p>這本的用法跟前兩本不同：它不是拿來讀完的，是拿來當量尺的。手上有一套自己覺得不對勁的測試時，逐項打分數比讀任何主張都快看出問題在哪。</p>
<p>證據來源是單一路徑的個人經驗加上理論建構，形式是原則加判準——這是本篇收錄的書裡唯一嘗試把測試設計寫成可推導體系的。範例是 C#，但判準本身與語言無關。時效上沒有明顯過時的部分——四支柱的取捨與工具世代無關。</p>
<p>這本要有量測的對象：手上一套實際在跑、而且開始造成負擔的測試。沒有那套測試，四支柱之間的取捨不會浮現——它們互相衝突，而衝突要有一套實際的測試當標的才看得見。還沒有這樣一套測試的話，可以先知道這本存在，等負擔出現再拿出來用。查不到繁體中文版，簡體中文版《單元測試：原則、實踐與模式》（2026 年 8 月查）。</p>
<ul>
<li><a href="https://www.amazon.com/Unit-Testing-Principles-Practices-Patterns/dp/1617296279">Amazon（Unit Testing Principles, Practices, and Patterns）</a></li>
<li><a href="https://www.tenlong.com.tw/products/9781617296277">天瓏（Unit Testing Principles, Practices, and Patterns，原文版）</a></li>
</ul>
<h2 id="想知道機器接手判準之後人還做什麼時讀-taking-testing-seriously">想知道機器接手判準之後人還做什麼時讀 Taking Testing Seriously</h2>
<p>James Bach 與 Michael Bolton 這本（Wiley，2025 年 11 月）是 Rapid Software Testing 這一派的完整陳述。它跟前三本不在同一個座標系裡：前三本爭的是單元的邊界該畫在哪，這本主張要先分開的是兩種活動——<strong>checking</strong>（對一個已經被決定的事實做二元評估，判準事先寫下、原則上可以交給機器）與 <strong>testing</strong>（設計判準本身、發現沒有人想到要問的問題、判斷觀察到的現象算不算問題）。作者的立場是自動化能接手的只有前者，而前者的品質完全取決於當初設計它的那次後者。</p>
<p>這個分界是這一派的起點，理由是自動化的邊界由判準寫不寫得下來決定，與工具能力無關。作者同期公開談論過 AI 與這個分界的關係；書的目次未能取得，這裡不指涉它在書中的位置與篇幅。</p>
<p>證據來源是兩位作者長期的教學與顧問實踐加上一套自建的術語體系，形式是主張與啟發式的目錄而不是逐步演練——它不像 Freeman 與 Pryce 那本有一個貫穿全書的範例可以跟著做。時效上是本篇最新的一本，術語體系本身不依賴任何工具世代。</p>
<p>處境相容性上要先知道一件事：這一派的語彙（checking、oracle、heuristic、探索式測試的活動記錄）與多數團隊日常使用的詞彙不重疊，讀的時候要一邊做術語對照。它也預設讀者有機會親自操作產品——判準要在觀察當下才成形是這套主張的核心，而完全只寫單元測試、不碰成品的人拿不到那個觀察位置。查不到中譯本（2026 年 8 月查）。</p>
<ul>
<li><a href="https://www.wiley.com/en-us/Taking&#43;Testing&#43;Seriously:&#43;The&#43;Rapid&#43;Software&#43;Testing&#43;Approach-p-00416398">Wiley（Taking Testing Seriously: The Rapid Software Testing Approach）</a></li>
<li><a href="https://www.tenlong.com.tw/products/9781394253197">天瓏（Taking Testing Seriously，原文版）</a></li>
</ul>
<h2 id="要一套推出測試案例的程序時讀-effective-software-testing">要一套推出測試案例的程序時讀 Effective Software Testing</h2>
<p>Maurício Aniche 這本（Manning，2022）處理的是前四本都沒有給的一項：<strong>這些測試案例是怎麼被推出來的</strong>。Khorikov 給的是評分用的量尺，Beck 給的是循環的節奏，這本給的是從需求推導案例的步驟——先從規格切出等價類與邊界，再用覆蓋準則檢查有沒有漏掉分支，接著設計方法與類別的契約（前置條件、後置條件、不變量），最後回頭問這段程式碼的可測試性是不是設計本身的問題。</p>
<p>它跟量尺型的書搭配起來沒有重疊：量尺回答「手上這套測試好不好」，這本回答「還缺哪幾個案例」。手上一套測試被評為分數低而不知道要補什麼時，缺的通常是這本教的推導程序。</p>
<p>證據來源是學術訓練加業界實踐（作者當時同時任教於 Delft 理工大學並在業界帶技術培訓），形式是步驟加練習，每章有可自己動手的題目。範例是 Java 與 JUnit，推導程序本身與語言無關。時效上沒有明顯過時的部分。</p>
<p>前置經驗要求比前四本低——它不預設讀者已經寫過一套難維護的測試，也不預設讀者對兩派分歧有立場。缺點的另一面是它不處理立場問題：讀完之後仍然要自己決定單元畫在哪，那要回到前面四本。作者另有一套與本書同主題的免費線上課（見下方公開課段），內容重疊但形式互補。查不到繁體中文版，另有簡體中文譯本（2026 年 8 月查）。</p>
<ul>
<li><a href="https://www.manning.com/books/effective-software-testing">Manning（Effective Software Testing: A Developer&rsquo;s Guide）</a></li>
<li><a href="https://www.tenlong.com.tw/products/9781633439931">天瓏（Effective Software Testing: A Developer&rsquo;s Guide，原文版）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>立場那四本彼此不同意，而它們的分歧點正是這個主題最難自己判斷的那一個。讀完會發現自己原本以為的「測試最佳實踐」是某一派的立場，而那個發現比任何單一技巧有用。Aniche 那本收在旁邊，因為立場選定之後「案例怎麼推出來」仍然沒有答案。</p>
<p>測試的書市有兩大類不在這裡。一類是特定框架的操作手冊，那類的時效跟框架版本綁死，且屬於教學系列的範圍。另一類是把測試金字塔或某個覆蓋率目標推銷成普適規則的書——它們的問題是規則脫離了推導它的取捨，而本篇收的書恰好證明那些取捨還在爭論中。</p>
<p>Mark Winteringham 的《Software Testing with Generative AI》（Manning，2024）是 2026 年 8 月這一輪查到唯一整本處理「用生成式工具做測試」的書，本書單評估後不收。內容是工具操作層——用編碼助理引導 TDD、向對話模型取回饋、呼叫 API 生測試資料——落在上一段第一類的排除範圍裡，時效跟工具版本綁死。這個判定只針對本篇的收錄軸（立場分歧），要找那類操作內容的人它是現成的入口。</p>
<p>Roy Osherove 的《單元測試的藝術》繁中版流通度高，本書單未評估它。它的定位偏向操作手冊而非立場陳述，跟本篇要回答的問題（分歧在哪）不同軸；要判斷它現在的價值需要對照第三版的改寫幅度，這裡沒有做。</p>
<p>Gerard Meszaros 的《xUnit Test Patterns》是測試異味與模式的完整目錄，本書單未評估——它的體量與參考書性質接近 Code Complete，而這個主題目前沒有那個生態位的需求。</p>
<h2 id="影音路徑在別的關鍵字底下">影音路徑在別的關鍵字底下</h2>
<p>以「軟體測試」為關鍵字找到的公開課，2026 年 8 月這一輪查到的集中在怎麼當一個測試工程師——測試種類的名詞、工具操作、面試會問什麼，那類內容預設有標準答案可以教。本篇要交付的是幾本書彼此不同意在哪，是一組還在爭論中的立場，兩者不在同一層。</p>
<p>但這不表示這個主題沒有影音路徑，<strong>它出現在別的關鍵字底下</strong>。問「分歧在哪」的影音內容出現在 TDD、software engineering、craftsmanship 這幾個關鍵字下，而不在 software testing 下——後者的檢索結果被測試工程師的職涯內容佔滿。讀不動長篇文字的讀者要換的是關鍵字，不是放棄。</p>
<p>供給的形態依製作者的商業模式分成三種，判斷免費內容拿得到多少要先看這個：</p>
<table>
  <thead>
      <tr>
          <th>形態</th>
          <th>免費內容的位置</th>
          <th>這個主題拿得到什麼</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>內容型（付費課程靠免費內容引流）</td>
          <td>影音平台頻道，量大且完整</td>
          <td>Dave Farley 的 Continuous Delivery 與 Modern Software Engineering 頻道、Emily Bache 的頻道（approval testing 與重構的逐步演練）、Khorikov 的 Enterprise Craftsmanship 部落格</td>
      </tr>
      <tr>
          <td>顧問型（課程面向企業、不靠影音引流）</td>
          <td>長篇文字，不是影音</td>
          <td>Bach 與 Bolton 的 developsense.com 與 satisfice.com；想走影音繞過長文的人在這一派上沒有路徑</td>
      </tr>
      <tr>
          <td>平台型（全免費、靠上游產品變現）</td>
          <td>課程平台本身</td>
          <td>工具操作為主（Selenium、Cypress、Playwright、Appium），填不了立場分歧那個缺口</td>
      </tr>
  </tbody>
</table>
<p>學術機構開的免費課是這一輪查到最貼近本篇主題的影音資源：Delft 理工大學在 edX 上的 Automated Software Testing 系列由 Aniche 與 Arie van Deursen 開設，內容是單元測試、覆蓋準則與可測試性設計，與上面收錄的《Effective Software Testing》同源而形式互補。</p>
<p>整條線的供給狀況寫在 <a href="../">工程技藝書單</a> 的公開課段。</p>
<p>本篇的「最新」「唯一」「查不到中譯」這幾類宣稱都是相對於查證時點的。下次新增或替換任何一本書時，整篇重掃一次這三類句子——它們不會自己跟著新書更新。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>測試寫不出來常常是設計的訊號而非測試技巧的問題——難測的程式碼通常是耦合太緊。那條路徑走 <a href="../design-and-practice/">設計判準與日常實踐</a>。既有程式碼沒有測試而必須先補，那是 <a href="../changing-existing-code/">改既有的程式</a> 裡 Feathers 那本處理的問題。</p>
<p>站內自己的測試分層策略、協議整合驗證與實機教訓看 <a href="/blog/testing/" data-link-title="開發測試實務指南" data-link-desc="測試全過而實機全壞、或程式碼由 agent 產出而無法逐行讀時，用來決定驗證該掛在哪幾層、每一層各自守不住什麼">Testing 測試策略</a>；本站在 mock 學派分歧上採取的立場與推導在 <a href="/blog/record/behavior-first-tdd-methodology/" data-link-title="行為優先的 TDD：測試耦合行為、不耦合結構" data-link-desc="重構時測試大量壞掉、或在「該不該 mock 這個協作者」上需要一個可執行的立場時，本站對兩派 TDD 分歧的選擇與推導">行為優先的 TDD 方法論</a>。</p>
<p>程式碼由 agent 產出、而人不打算逐行讀時，判準該落在哪走 <a href="/blog/testing/06-agent-authored-code/" data-link-title="模組六：Agent 產出程式碼的驗證" data-link-desc="程式碼由 agent 寫、人不再逐行讀時，用來決定驗證該落在哪些位置，以及每個位置的射程到哪裡">模組六：Agent 產出程式碼的驗證</a>——那裡處理的是本篇四本立場書共同預設而在那個情境下失效的前提：測試由懂需求的人寫，而那個人會讀自己的程式碼。Bach 與 Bolton 那本的 checking 與 testing 分界是這條路線的上游概念。</p>
]]></content:encoded></item><item><title>組織文化與心理安全感</title><link>https://tarrragon.github.io/blog/books/software-management/topics/culture-safety/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/culture-safety/</guid><description>&lt;p>這個主題處理一件其他主題都預設成立的前提：組織回報的資訊大致反映實情。當這個前提失效，指標會漂亮、檢討會順利、承諾會準時給出——所有訊號都正常，只有結果不對。這使得它同時是其他主題的地基與失效模式，也使得它的問題最難自我診斷：沉默的組織裡沒有人會回報「我們正在沉默」。&lt;/p>
&lt;p>這個主題的書大多來自軟體業以外——組織行為學、教育學、管理心理學。這反映的是軟體業自己的書幾乎不處理恐懼與防衛，而這些領域已經累積了三十年以上的實證研究，並非刻意的取材偏好。&lt;/p>
&lt;h2 id="起點是-the-fearless-organization">起點是 The Fearless Organization&lt;/h2>
&lt;p>Amy Edmondson 的《The Fearless Organization》從現象一路寫到操作框架，中間解釋機制的那一段沒有跳過，證據規模也是本篇最大的一本。概念本身的整理在 &lt;a href="https://tarrragon.github.io/blog/til/organization/psychological-safety/" data-link-title="心理安全感：群體裡的人願不願意講壞消息" data-link-desc="看到某個團隊的回報一切正常卻結果不對時，用來理解沉默的機制：它衡量的是說出問題會不會被懲罰，而不是氣氛好不好">心理安全感&lt;/a>，這裡處理的是要不要讀這本書。起點是一個反直覺的研究結果：她研究醫院團隊時預期表現好的團隊犯錯較少，資料卻顯示表現好的團隊回報的錯誤更多。追下去才發現差別出在回報率這一層，犯錯率其實相當——好團隊敢講。心理安全感這個概念與後續三十年的研究從這裡長出來。&lt;/p>
&lt;p>書的操作價值在於把心理安全感從一種氛圍變成可以做的事。框架有三步：把工作定調成學習問題而非執行問題、承認自己會犯錯、主動示範提問。每一步都有語言範例與失敗案例，包括領導者宣稱歡迎壞消息但實際反應相反時會發生什麼。&lt;/p>
&lt;p>需要先知道的邊界是心理安全感並非降低標準。書中把心理安全感與績效標準當成兩個獨立的軸，並指出兩者都高才是學習區、安全感高而標準低是舒適區。這個區分在導入時最容易被誤讀成「對人要溫和」。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是大規模實證加上跨組織案例，強度足以支持組織層級的改變。時效上，書中案例的產業背景橫跨醫療、航空、製造與科技業；心理安全感與績效標準兩軸的論證建立在人際風險的感知上，不依賴工作場所的形式。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，書中的介入手段——把工作定調成學習問題、當場承認自己會犯錯、主動示範提問——多數發生在同步的面對面場合，靠的是別人看得見領導者的即時反應。非同步為主的團隊要先找到對應的載體（公開的決策紀錄、留在文件上的提問、對壞消息的第一則回覆），那個轉換書裡沒有給，換算的方向見 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>。讀得出價值的前提幾乎沒有，任何位置都讀得出東西——只對自己產出負責的人讀它，讀出來的是「原來我不敢講不是我的問題」；帶人的人讀它，學到的是自己做了哪些動作，團隊才不再把壞消息講上來。&lt;/p>
&lt;p>同作者的另外兩本各補一個面向，與這本承擔同一個角色而非獨立選項。《Teaming》處理跨團隊、跨專業的臨時協作怎麼學習，適合矩陣式組織或跨部門專案多的環境，目前無中譯本。《Right Kind of Wrong》把失敗分成簡單失敗、複雜失敗、智慧型失敗三類，並主張只有第三類值得鼓勵——這對把「快速失敗」當成免責聲明的團隊是直接的校正。兩本的證據來源與起點書同一組（大規模實證加跨組織案例），因此不另外判定；處境上，《Teaming》預設協作對象會換人，《Right Kind of Wrong》不預設任何組織形態。讀得出價值的前提是先讀過起點書那本——它們補的是面向，不是入口。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Fearless-Organization-Psychological-Workplace-Innovation/dp/1119477247">Amazon（The Fearless Organization）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010952358">博客來（心理安全感的力量：別讓沉默扼殺了你和團隊的未來）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Teaming-Organizations-Innovate-Compete-Knowledge/dp/078797093X">Amazon（Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Right-Kind-Wrong-Science-Failing/dp/1982195061">Amazon（Right Kind of Wrong: The Science of Failing Well）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010985600">博客來（正確犯錯：哈佛學者揭開成長心態的關鍵）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想知道為什麼改善措施總是失效時讀-argyris">想知道為什麼改善措施總是失效時讀 Argyris&lt;/h2>
&lt;p>Chris Argyris 的研究方法是逐字記錄組織裡的真實對話再逐句分析，因此是這個主題裡證據粒度最細的一位。貢獻集中在兩組概念。第一組是信奉理論與使用理論的落差：一個人宣稱相信的原則，與他的行為顯示他實際依循的原則經常不同，而本人通常看不見這個落差。第二組是組織防衛慣例：組織會發展出一套機制迴避尷尬與威脅，接著把「這套機制存在」本身也變成不可討論的話題，於是防衛無法被檢討。&lt;/p>
&lt;p>這組概念解釋了為什麼許多文化改善措施會失效——措施本身成為新的表演場合，而指出「這是表演」變成新的不可討論話題。Edmondson 描述現象並給出做法，Argyris 解釋做法為什麼會被組織消化掉。&lt;/p>
&lt;p>那篇 HBR 文章〈Teaching Smart People How to Learn〉是最經濟的入口，十幾頁，主張聰明人特別不擅長學習——因為他們很少失敗、沒有練習過面對失敗，一旦失敗就把責任外推。這個論點描述的處境在高學歷、高能力的工程團隊上有明確對應。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗，形式特別的地方在方法：長期的組織介入研究加上逐字對話分析，因此細節極具體，但樣本集中在少數顧問公司與大型企業。時效上，案例場景是 1980 年代的管理顧問與董事會，職稱與會議形式已經不同；信奉理論與使用理論的落差建立在人對自我形象的維護上，不依賴那個場景。文字的概念密度高、案例冗長，《Overcoming Organizational Defenses》是書的形式，但多數人從那篇文章得到的已經接近全書。兩者目前都沒有中譯本。讀得出價值的前提是：親身推動過一次無疾而終的改善——沒有這個對照時，防衛慣例會讀成對組織的譏諷。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://hbr.org/1991/05/teaching-smart-people-how-to-learn">HBR（Teaching Smart People How to Learn）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Overcoming-Organizational-Defenses-Facilitating-Learning/dp/0205123384">Amazon（Overcoming Organizational Defenses: Facilitating Organizational Learning）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="程式碼審查滑向人身攻擊的起源在溫伯格-1971-年的the-psychology-of-computer-programming">程式碼審查滑向人身攻擊的起源在溫伯格 1971 年的《The Psychology of Computer Programming》&lt;/h2>
&lt;p>這本書是最早把寫程式當成人類行為來研究的著作。書中的無私程式設計（egoless programming）——把程式碼與自我認同分開，才能坦然接受別人檢視——是今天 code review 文化的思想源頭。&lt;/p>
&lt;p>現在讀它的價值集中在觀念層。25 週年紀念版的做法是保留原文不動、只在旁邊加註解評論自己當年錯在哪——作者認為自己的錯誤是讀者最能學到東西的部分。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗（作者在 IBM 與 NASA 水星計畫的現場觀察）加上早期的受控實驗，樣本小、方法以現在的標準看相當鬆散。時效上，技術背景（主機、打卡、批次作業）已經完全不同，涉及工作流程的章節無法直接套用；程式設計師如何看待自己的產出、審查為什麼會滑向人身攻擊這兩條論證建立在自我認同與產出的連結上，不依賴技術形式。收過一次讓自己不舒服的 code review，是讀它的前提。繁體中文版目前未見，簡體中文版有《程序开发心理学》等譯名。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Psychology-Computer-Programming-Silver-Anniversary/dp/0932633420">Amazon（The Psychology of Computer Programming: Silver Anniversary Edition）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>這個主題的三本按解釋深度排：現象與操作框架（Edmondson）、機制解釋（Argyris）、軟體業內部的起源（溫伯格 1971）。三者處理沉默的不同層次，任何一本都不能替代另外兩本。&lt;/p>
&lt;p>企業文化的書是商管書市最擁擠的區塊，多數落在兩個位置：宣稱某家公司文化很成功的個案敘事，以及把文化拆成價值觀清單的操作手冊。前者無法回答「這在我的組織也成立嗎」，後者跳過了價值觀為什麼會被組織消化掉這一層——要區分，看它處不處理「宣告的價值觀與實際行為不同」這個落差，沒處理的停在第一層。&lt;/p>
&lt;p>Google 的 Project Aristotle 常被拿來當心理安全感的佐證，它的一手資料是公開文件而非書籍，因此不列進書單。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>理解機制之後，落到單次對話的執行走 &lt;a href="../influence-conversation/">困難對話與無權限影響力&lt;/a>——那裡處理的是主管盯著人問「到底行不行」的那三十秒。&lt;/p>
&lt;p>沉默在事故現場的具體形式（明知有異狀卻沒有升級）走 &lt;a href="../incident-blame/">事故、歸因與無指責檢討&lt;/a>。沉默在承諾現場的具體形式（明知做不完還是點頭）走 &lt;a href="../estimation-decision/">估算、承諾與決策偏誤&lt;/a>。&lt;/p>
&lt;p>人留不留得住是另一組問題，走 &lt;a href="../retention-motivation/">留任、動機與工作環境&lt;/a>。&lt;/p>
&lt;p>安全感夠了而討論仍然收斂不了，缺的是流程而非氣氛，走 &lt;a href="../meeting-facilitation/">會議引導與群體決策&lt;/a>。兩者的先後不能顛倒——講真話會被記上一筆時，再好的會議格式也只會收到安全的答案。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理一件其他主題都預設成立的前提：組織回報的資訊大致反映實情。當這個前提失效，指標會漂亮、檢討會順利、承諾會準時給出——所有訊號都正常，只有結果不對。這使得它同時是其他主題的地基與失效模式，也使得它的問題最難自我診斷：沉默的組織裡沒有人會回報「我們正在沉默」。</p>
<p>這個主題的書大多來自軟體業以外——組織行為學、教育學、管理心理學。這反映的是軟體業自己的書幾乎不處理恐懼與防衛，而這些領域已經累積了三十年以上的實證研究，並非刻意的取材偏好。</p>
<h2 id="起點是-the-fearless-organization">起點是 The Fearless Organization</h2>
<p>Amy Edmondson 的《The Fearless Organization》從現象一路寫到操作框架，中間解釋機制的那一段沒有跳過，證據規模也是本篇最大的一本。概念本身的整理在 <a href="/blog/til/organization/psychological-safety/" data-link-title="心理安全感：群體裡的人願不願意講壞消息" data-link-desc="看到某個團隊的回報一切正常卻結果不對時，用來理解沉默的機制：它衡量的是說出問題會不會被懲罰，而不是氣氛好不好">心理安全感</a>，這裡處理的是要不要讀這本書。起點是一個反直覺的研究結果：她研究醫院團隊時預期表現好的團隊犯錯較少，資料卻顯示表現好的團隊回報的錯誤更多。追下去才發現差別出在回報率這一層，犯錯率其實相當——好團隊敢講。心理安全感這個概念與後續三十年的研究從這裡長出來。</p>
<p>書的操作價值在於把心理安全感從一種氛圍變成可以做的事。框架有三步：把工作定調成學習問題而非執行問題、承認自己會犯錯、主動示範提問。每一步都有語言範例與失敗案例，包括領導者宣稱歡迎壞消息但實際反應相反時會發生什麼。</p>
<p>需要先知道的邊界是心理安全感並非降低標準。書中把心理安全感與績效標準當成兩個獨立的軸，並指出兩者都高才是學習區、安全感高而標準低是舒適區。這個區分在導入時最容易被誤讀成「對人要溫和」。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是大規模實證加上跨組織案例，強度足以支持組織層級的改變。時效上，書中案例的產業背景橫跨醫療、航空、製造與科技業；心理安全感與績效標準兩軸的論證建立在人際風險的感知上，不依賴工作場所的形式。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，書中的介入手段——把工作定調成學習問題、當場承認自己會犯錯、主動示範提問——多數發生在同步的面對面場合，靠的是別人看得見領導者的即時反應。非同步為主的團隊要先找到對應的載體（公開的決策紀錄、留在文件上的提問、對壞消息的第一則回覆），那個轉換書裡沒有給，換算的方向見 <a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a>。讀得出價值的前提幾乎沒有，任何位置都讀得出東西——只對自己產出負責的人讀它，讀出來的是「原來我不敢講不是我的問題」；帶人的人讀它，學到的是自己做了哪些動作，團隊才不再把壞消息講上來。</p>
<p>同作者的另外兩本各補一個面向，與這本承擔同一個角色而非獨立選項。《Teaming》處理跨團隊、跨專業的臨時協作怎麼學習，適合矩陣式組織或跨部門專案多的環境，目前無中譯本。《Right Kind of Wrong》把失敗分成簡單失敗、複雜失敗、智慧型失敗三類，並主張只有第三類值得鼓勵——這對把「快速失敗」當成免責聲明的團隊是直接的校正。兩本的證據來源與起點書同一組（大規模實證加跨組織案例），因此不另外判定；處境上，《Teaming》預設協作對象會換人，《Right Kind of Wrong》不預設任何組織形態。讀得出價值的前提是先讀過起點書那本——它們補的是面向，不是入口。</p>
<ul>
<li><a href="https://www.amazon.com/Fearless-Organization-Psychological-Workplace-Innovation/dp/1119477247">Amazon（The Fearless Organization）</a></li>
<li><a href="https://www.books.com.tw/products/0010952358">博客來（心理安全感的力量：別讓沉默扼殺了你和團隊的未來）</a></li>
<li><a href="https://www.amazon.com/Teaming-Organizations-Innovate-Compete-Knowledge/dp/078797093X">Amazon（Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy）</a></li>
<li><a href="https://www.amazon.com/Right-Kind-Wrong-Science-Failing/dp/1982195061">Amazon（Right Kind of Wrong: The Science of Failing Well）</a></li>
<li><a href="https://www.books.com.tw/products/0010985600">博客來（正確犯錯：哈佛學者揭開成長心態的關鍵）</a></li>
</ul>
<h2 id="想知道為什麼改善措施總是失效時讀-argyris">想知道為什麼改善措施總是失效時讀 Argyris</h2>
<p>Chris Argyris 的研究方法是逐字記錄組織裡的真實對話再逐句分析，因此是這個主題裡證據粒度最細的一位。貢獻集中在兩組概念。第一組是信奉理論與使用理論的落差：一個人宣稱相信的原則，與他的行為顯示他實際依循的原則經常不同，而本人通常看不見這個落差。第二組是組織防衛慣例：組織會發展出一套機制迴避尷尬與威脅，接著把「這套機制存在」本身也變成不可討論的話題，於是防衛無法被檢討。</p>
<p>這組概念解釋了為什麼許多文化改善措施會失效——措施本身成為新的表演場合，而指出「這是表演」變成新的不可討論話題。Edmondson 描述現象並給出做法，Argyris 解釋做法為什麼會被組織消化掉。</p>
<p>那篇 HBR 文章〈Teaching Smart People How to Learn〉是最經濟的入口，十幾頁，主張聰明人特別不擅長學習——因為他們很少失敗、沒有練習過面對失敗，一旦失敗就把責任外推。這個論點描述的處境在高學歷、高能力的工程團隊上有明確對應。</p>
<p>證據來源是跨客戶的顧問經驗，形式特別的地方在方法：長期的組織介入研究加上逐字對話分析，因此細節極具體，但樣本集中在少數顧問公司與大型企業。時效上，案例場景是 1980 年代的管理顧問與董事會，職稱與會議形式已經不同；信奉理論與使用理論的落差建立在人對自我形象的維護上，不依賴那個場景。文字的概念密度高、案例冗長，《Overcoming Organizational Defenses》是書的形式，但多數人從那篇文章得到的已經接近全書。兩者目前都沒有中譯本。讀得出價值的前提是：親身推動過一次無疾而終的改善——沒有這個對照時，防衛慣例會讀成對組織的譏諷。</p>
<ul>
<li><a href="https://hbr.org/1991/05/teaching-smart-people-how-to-learn">HBR（Teaching Smart People How to Learn）</a></li>
<li><a href="https://www.amazon.com/Overcoming-Organizational-Defenses-Facilitating-Learning/dp/0205123384">Amazon（Overcoming Organizational Defenses: Facilitating Organizational Learning）</a></li>
</ul>
<h2 id="程式碼審查滑向人身攻擊的起源在溫伯格-1971-年的the-psychology-of-computer-programming">程式碼審查滑向人身攻擊的起源在溫伯格 1971 年的《The Psychology of Computer Programming》</h2>
<p>這本書是最早把寫程式當成人類行為來研究的著作。書中的無私程式設計（egoless programming）——把程式碼與自我認同分開，才能坦然接受別人檢視——是今天 code review 文化的思想源頭。</p>
<p>現在讀它的價值集中在觀念層。25 週年紀念版的做法是保留原文不動、只在旁邊加註解評論自己當年錯在哪——作者認為自己的錯誤是讀者最能學到東西的部分。</p>
<p>證據來源是單一路徑的個人經驗（作者在 IBM 與 NASA 水星計畫的現場觀察）加上早期的受控實驗，樣本小、方法以現在的標準看相當鬆散。時效上，技術背景（主機、打卡、批次作業）已經完全不同，涉及工作流程的章節無法直接套用；程式設計師如何看待自己的產出、審查為什麼會滑向人身攻擊這兩條論證建立在自我認同與產出的連結上，不依賴技術形式。收過一次讓自己不舒服的 code review，是讀它的前提。繁體中文版目前未見，簡體中文版有《程序开发心理学》等譯名。</p>
<ul>
<li><a href="https://www.amazon.com/Psychology-Computer-Programming-Silver-Anniversary/dp/0932633420">Amazon（The Psychology of Computer Programming: Silver Anniversary Edition）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>這個主題的三本按解釋深度排：現象與操作框架（Edmondson）、機制解釋（Argyris）、軟體業內部的起源（溫伯格 1971）。三者處理沉默的不同層次，任何一本都不能替代另外兩本。</p>
<p>企業文化的書是商管書市最擁擠的區塊，多數落在兩個位置：宣稱某家公司文化很成功的個案敘事，以及把文化拆成價值觀清單的操作手冊。前者無法回答「這在我的組織也成立嗎」，後者跳過了價值觀為什麼會被組織消化掉這一層——要區分，看它處不處理「宣告的價值觀與實際行為不同」這個落差，沒處理的停在第一層。</p>
<p>Google 的 Project Aristotle 常被拿來當心理安全感的佐證，它的一手資料是公開文件而非書籍，因此不列進書單。</p>
<p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>理解機制之後，落到單次對話的執行走 <a href="../influence-conversation/">困難對話與無權限影響力</a>——那裡處理的是主管盯著人問「到底行不行」的那三十秒。</p>
<p>沉默在事故現場的具體形式（明知有異狀卻沒有升級）走 <a href="../incident-blame/">事故、歸因與無指責檢討</a>。沉默在承諾現場的具體形式（明知做不完還是點頭）走 <a href="../estimation-decision/">估算、承諾與決策偏誤</a>。</p>
<p>人留不留得住是另一組問題，走 <a href="../retention-motivation/">留任、動機與工作環境</a>。</p>
<p>安全感夠了而討論仍然收斂不了，缺的是流程而非氣氛，走 <a href="../meeting-facilitation/">會議引導與群體決策</a>。兩者的先後不能顛倒——講真話會被記上一筆時，再好的會議格式也只會收到安全的答案。</p>
]]></content:encoded></item><item><title>書單推薦</title><link>https://tarrragon.github.io/blog/books/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/</guid><description>&lt;p>書單分類回答兩個問題：站在一個特定的職涯位置上，這個主題該先讀哪一本；以及要往別的位置移動時，該預習什麼。工具書的選擇跟當下承擔的責任綁在一起——同一本書給只對自己產出負責的人讀，跟給要對整個組織結構負責的人讀，能讀出來的東西完全不同，而且不是深淺差別，是關注點根本不在同一處。&lt;/p>
&lt;p>要直接找書的，三條書線與各自涵蓋的問題在下面的「書單線」段。要的是同一份知識換成用聽的，直接走「公開課怎麼收」段，那裡有收錄門檻、盤點到什麼程度、以及它服務得了哪些處境。中間三段說明的是這裡怎麼描述一本書、那些描述有多可靠、以及哪些約束會讓答案改變——各主題篇逐本套用的就是那組描述，要拿它們做判斷之前值得先讀。&lt;/p>
&lt;p>這裡不做脫離用途的品質評價。書之間確實會被排出先後——每篇選一本起點書就是排序，怎麼排寫在 &lt;a href="software-management/topics/">主題書單&lt;/a> 的判準段。差別在於排的是「它的結論夠不夠支持手上要拿它去做的那件事」而不是「這本書好不好」，換一個用途順序就換一次。取代通用品質評分的是四項可以各自核對的描述：它的結論從哪來、它的哪些部分依賴已經改變的條件、它預設的環境在讀它的那個組織裡存不存在、以及要有什麼經驗才讀得出它的價值。四項各自導出什麼決定、哪幾項可以否決，寫在四項定義之後。&lt;/p>
&lt;h2 id="描述一本書的四個維度">描述一本書的四個維度&lt;/h2>
&lt;p>四個維度裡有三項的定義、分類與判讀方式住在 &lt;a href="knowledge-cards/">書單知識卡片&lt;/a>，下面各段只說明它在這套描述裡承擔什麼、以及怎麼跟其他維度分工。&lt;/p>
&lt;p>**&lt;a href="knowledge-cards/evidence-provenance/">證據來源&lt;/a>**決定這本書的結論可以支持多大範圍的決定。主題篇裡每本書的證據來源句都會用下面這組名字開頭，這樣兩本候選才對得齊：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>大規模實證&lt;/strong>（數萬份調查、跨組織統計）可以拿來支持組織層級的改變。&lt;/li>
&lt;li>&lt;strong>跨組織案例&lt;/strong>（多個組織並列比較，形式是敘述而非統計）可以支持「這條路別人走過」，不足以支持「所以在我們這裡也會成立」。&lt;/li>
&lt;li>&lt;strong>單一組織的深度重建&lt;/strong>（一個組織或一次事件被完整記錄，包括制度紀錄）給的是機制的完整樣子，代價是那些機制常常依賴該組織特有的條件。&lt;/li>
&lt;li>&lt;strong>跨客戶的顧問經驗&lt;/strong>（作者數十年在多個組織的現場觀察）提供別處拿不到的細節與語言，但無法回答「這在我的組織也成立嗎」。&lt;/li>
&lt;li>&lt;strong>單一路徑的個人經驗&lt;/strong>（作者自己走過的那一條路，含在少數幾家公司的任職）適合用來對照自己的處境，樣本是一。&lt;/li>
&lt;li>&lt;strong>受控實驗&lt;/strong>（心理學或行為科學的實驗研究）對它測的那個機制很硬，代價是實驗室情境與工作現場之間的那一段要自己接。&lt;/li>
&lt;li>&lt;strong>理論建構&lt;/strong>（把零散的做法、或既有的研究，組織成一套解釋）的價值在於串連已知的事。它自己不產生新證據，而整合研究的那一種會繼承被它整合的研究的一部分效力。&lt;/li>
&lt;li>&lt;strong>作者自建的方法&lt;/strong>（方法由作者提出，效果宣稱來自訓練現場的自陳而沒有獨立驗證）適合當自己團隊的實驗協議，拿去支持組織層級的改變要另外找依據。&lt;/li>
&lt;li>&lt;strong>虛構敘事&lt;/strong>（結論由劇情推出，沒有資料佐證）的用途是建立共同語言，不是當論證的依據。&lt;/li>
&lt;/ul>
&lt;p>一本書可以同時落在兩類（顧問經驗加理論建構是常見的組合），主題篇會兩類都標。多數書會在前言或方法章節自述資料從哪來，這一項的判定多半就取自那裡；取自第三方評述或體裁推斷的，主題篇會寫出是從哪裡看出來的。判錯的後果要到出示依據的時候才現形：拿一本靠劇情推出結論的書去支持部署流程的改動，提案在會議上被問資料在哪，而書裡沒有數字可以指。敘事型的書讀起來說服力不低於統計型的，差別在讀的當下沒有任何訊號，代價是那個提案被歸成個人偏好，下次帶著統計資料來還得先洗掉這個印象。這一項怎麼導出一個具體的閱讀決定，&lt;a href="software-management/topics/meeting-facilitation/">會議引導與群體決策&lt;/a> 的六頂思考帽那一段有完整示範。&lt;/p>
&lt;p>&lt;strong>時效狀態&lt;/strong>要分開看，因為一本書很少整本過時。技術細節、工具選擇、交付節奏的假設會過時；人在壓力下的行為、組織的溝通結構、恐懼與防衛的機制不會。1987 年的書談辦公室隔間可能無效，談中斷成本仍然成立。判斷方式是問這一段的論證依賴什麼前提，那個前提現在還在不在。主題篇裡每本書都會給時效判定，包含新書——&lt;strong>沒有寫出具體過時前提的，表示尚未發現它的論證依賴已經改變的條件&lt;/strong>，而不是沒查。&lt;/p>
&lt;p>**&lt;a href="knowledge-cards/context-compatibility/">處境相容性&lt;/a>**問讀它的那一方具不具備這本書預設的環境。環境清單依題材實例化，判準不變而項目會換。組織與團隊題材（管理線與技藝線）的那一組有四項：組織形態（有沒有職級、績效與調薪制度可用）、僱傭關係（成員是不是直屬部屬、待得夠不夠久、僱主是不是同一個）、&lt;a href="knowledge-cards/collaboration-mode/">協作形態&lt;/a>（每天重疊幾小時——這是連續量，不是同處一室與跨時區的二選一）、法規環境（事故後有沒有法定的追責與報告義務）。財務題材換成另一組（資本形態、幣別暴露、資訊揭露程度、市場上有沒有那類工具），寫在該線的入口頁；各組的定義與判讀方式都住在那張卡。&lt;/p>
&lt;p>它跟時效狀態的差別在軸的方向。時效問那個前提現在還在不在，是時間；處境相容性問它在這個組織裡在不在，是空間。1987 年那本談中斷成本的書今天仍然成立，這是時效判定；同一本書預設團隊每天同處一室，而實際的八個人分在四個時區，這是處境判定。兩者會給出相反的結論，所以要分開問。&lt;/p>
&lt;p>這一項跟時效一樣導出讀法而非讀不讀：預設的環境不存在時，建立在那個環境上的那幾章自行折算或跳過，其餘照讀。但它可以獨立否決——整本書的推導都依賴一個缺席的環境時，讀完得到的是一組動不了的處方。&lt;/p>
&lt;p>這一項的覆蓋是不完整的，而且缺口的形狀值得先知道。以書目小節為單位計數，六十七個小節裡三十六個寫出了具體的處境限制，六個明說查過而沒有依賴——這六個小節的判定由篇首的整篇宣告承接（問題定義那篇的三本概念書、設計判準那篇的三本），逐節掃不到，要看那兩篇的前置段——其餘二十五個&lt;strong>尚未檢查&lt;/strong>——沒寫不表示相容。這跟時效那一項的「沒寫表示尚未發現」不同：時效判定每個小節都做過，處境判定沒有。缺口現在散落在各篇的個別書上，不再整篇整篇缺——每個主題篇至少對一本書問過這個問題，剩下的是那一篇裡還沒逐本問完。目前唯一逐本問完的是 &lt;a href="finance/">財務與投資&lt;/a>，那條線的每一本都寫出了具體限制，理由是它的題材本來就跨法域與跨幣別，缺席的環境比別的題材容易被看見。下面那段列的幾種約束，是這個維度在讀者側最常被踩到的實例。&lt;/p>
&lt;p>&lt;strong>讀得出價值的前提&lt;/strong>決定閱讀時機。有些書的內容在沒有對應經驗時讀起來像常識，有了經驗才變成判準；提早讀的成本在於留下「這本我讀過」的錯誤印象，之後真的需要時不會回頭，而不只是當下多花的時間。這個代價的形狀具體是這樣：帶三個人的時候有人推薦了一本談團隊切分的書，讀完覺得講的都是常識，於是歸檔成讀過。兩年後團隊變成三個、交接面天天卡住，翻書單看到這本標著自己讀過，就往下一本找。中間沒有任何一步會提醒這件事——被記下來的只有讀沒讀，而讀得出什麼會隨經驗改變、不留痕跡。&lt;/p>
&lt;p>這一項寫成可以拿自己的處境核對的條件句。最常見的形狀是過去的經歷（「前提是曾經 X」），另外幾種是當下的處境、當下握有的權限（Sprint 那本要的是能清空一組人一週行事曆，不是經驗）、即將進入的位置、投入的形態（Code Complete 要的是耐心，九百多頁不適合通讀）、以及同主題的前置閱讀（Edmondson 另外兩本要先讀過起點書，Wiring the Winning Organization 要先讀過這個主題的兩三本才有東西可對照）；還有一類書標不出條件，那就不標。點不出具體的 X 也不標——寫「難度高」這種評分等於回頭做品質評價，正是這套描述要避免的東西。拿條件句去對而不確定自己那次算不算時，兩種對不上的處理方式相反：條件寫的是某種經驗（待過兩間文化不同的公司，而兩間同產業），判準是問那次有沒有製造過意外，沒有意外就表示還沒有第二個對照組；條件寫的是某個處境而人正要進去（下個月開始帶人），那是提早讀唯一划算的情況，因為書這時要給的是預期而不是判準。&lt;/p>
&lt;h3 id="四項怎麼合成一個決定">四項怎麼合成一個決定&lt;/h3>
&lt;p>四項各自導出不同的閱讀決定：仰賴個人經驗的書適合用來對照自己的處境，大規模實證的書適合用來說服別人，需要特定經驗當底的書提早讀會空轉。&lt;/p>
&lt;p>時效狀態與處境相容性導出的是讀法而不是讀不讀——過時或對不上的若是工具、交付節奏、辦公形態，照讀但要自行折算；若是某一段論證依賴的前提，那一段換別的材料。&lt;/p>
&lt;p>否決權只有三項有，而且強度不同：證據來源與讀得出價值的前提是無條件否決，處境相容性只在整本書的推導都建立在同一個缺席的環境上時才否決。三者都不做補償式加權——任一項成立就先不投入時間，不能靠另一項的分數高把它補回來。&lt;/p>
&lt;p>這四項共同預設了一件事：這個主題適合用書承接。變動速率快過書的改版週期的主題——稅制、當期補助方案、當期商品條款——不滿足那個前提，而四項判定在那裡會全部通過：一本當期稅務書的證據來源、處境相容性與讀者前提都可以無可挑剔，它只是在印出來的時候就開始過期。這個上界由各線自己標出來，&lt;a href="finance/">財務與投資&lt;/a> 是目前唯一踩到的一條，處理方式寫在該線的「有些財務知識不該用書當載體」段。&lt;/p>
&lt;h2 id="這些判定從哪來">這些判定從哪來&lt;/h2>
&lt;p>書目資訊（書名、作者、出版年、版次、中譯本與譯名、購書頁面）逐筆查證過，並在頁面上留連結供覆核。四個維度的判定來源不同，混合了書本身的方法章節與前言自述、書的公開內容摘要，以及該領域的公開討論；&lt;strong>並非每一本都經過通讀&lt;/strong>。因此這四項的性質是「有依據的判斷」而不是「代為驗證的結論」——它們的用途是幫忙決定要不要投入時間，決定投入之後，書裡的說法以原書為準。&lt;/p>
&lt;p>這個限制有具體後果：越是需要密讀才能下的判定（章節層級的時效切分、某一章的論證依賴哪個前提），可信度越低。看到這類判定時，把它當成一條待驗證的線索，而不是結論。分辨方法在判定本身的措辭：出現章節名、或指出某一段論證的前提落在哪裡的，屬於需要密讀才下得了的那一類；只描述全書的資料來源與出版年代的，密讀與否不改變結論。頁面上找不到出處的形容（某某「公認」如何、某書「最常被引用」的是什麼）已經盡量清掉；還留著的話，那是疏漏，不是有把握的斷言。&lt;/p>
&lt;p>中譯本狀態以撰稿時查證為準。這一項最容易靜默過期——新譯本會出現，而「目前沒有中譯本」這種否定命題無法窮盡驗證，只能說查不到。它記錄的是有沒有中文版可讀，對台灣讀者是實際資訊，但&lt;strong>不參與選書判定&lt;/strong>——沒有中譯本不會讓一本書掉出書單，有中譯本也不會讓它進來。書目連結一律指向可查證的商品頁或官方免費線上版。用哪個通路看撰稿時抓得到哪個：早期幾篇的英文版用 Amazon、中文版用博客來，財務線那幾筆改用三民與天瓏，因為撰稿時前兩站擋抓、無法逐筆核對頁面內容。改用替代站時就記下這個降級，不假裝兩者可信度相同。這些連結不含任何聯盟或推廣關係。&lt;/p>
&lt;h2 id="哪些約束會改變答案">哪些約束會改變答案&lt;/h2>
&lt;p>四個維度描述的是書，位置表描述的是誰負責什麼，兩者都沒有問讀的人受什麼約束。下面幾項會讓同一個位置的正確答案不同，而書單對它們的處理程度不一樣：有的給得出調整方式，有的只標得出邊界。這份清單不窮盡——它是目前踩到過的那些，處境相容性那一項的環境清單是它的上游，遇到清單以外的約束時回去對該題材那一組環境。選書前先確認自己有沒有踩到：&lt;/p>
&lt;p>&lt;strong>組織規模&lt;/strong>：結構設計類的書預設的最小規模大約是三個團隊。三人公司的技術負責人照位置表會走到組織結構那一格，但那一格的書對他是過度設計——那個階段的瓶頸是把事做完，不是把介面畫對。三個團隊這個數字可以自己重算：結構問題出在團隊之間的交接面上，n 個團隊有 n(n-1)/2 個介面，兩個團隊只有一個介面、協調靠兩個人講一次話就解決，要到三個團隊、三個介面之後，介面本身才變成需要設計的東西。踩到這一項之後往哪走，寫在 &lt;a href="software-management/roles/">依位置選書&lt;/a> 的規模下限那一段。&lt;/p>
&lt;p>&lt;strong>人員流動率&lt;/strong>：留任與團隊凝聚類的書預設成員會待夠久，久到值得投資關係與環境。約聘輪替、外包接案、專案制編組這些情境裡，那個前提不成立，而書裡的建議（保護團隊不被打斷、培養凝聚）換算不到可執行的動作。這種處境需要的是交接與文件化，那不在這條書線的範圍內——這是清單裡唯一連站外替代方向都給不出來的一項，其餘幾項至少標得出往哪走。&lt;a href="software-management/topics/retention-motivation/">留任、動機與工作環境&lt;/a> 的前置段是同一條約束在該主題的落點。&lt;/p>
&lt;p>&lt;strong>&lt;a href="knowledge-cards/collaboration-mode/">協作形態&lt;/a>&lt;/strong>：多數管理與團隊類的書預設成員每天有大量重疊工時，凝聚、中斷成本、走廊上的一句話都建立在共處上。重疊工時每天不到兩小時的團隊，那批論證的前提有一半不存在，而書裡通常不會標出哪一半；兩到四小時這一段要逐項換算，做法在那張卡。這一項最容易假性通過——前面三項約束逐條檢查都不踩，於是照一般路徑選書，而真正支配這個處境的變數根本不在清單上。目前正向處理非同步的只有 &lt;a href="software-management/topics/personal-workflow/">個人工作流與工作負荷&lt;/a> 收的 A World Without Email。&lt;/p>
&lt;p>&lt;strong>法規與稽核義務&lt;/strong>：無指責檢討這類主張有法律邊界。受金融、醫療、航空等主管機關監理的組織，事故後有法定的追責與報告義務，而「不追究個人」在那個脈絡下不是文化選擇。這類組織要讀的是懲戒界線怎麼畫，而不是怎麼取消懲戒——&lt;a href="software-management/topics/incident-blame/">事故、歸因與無指責檢討&lt;/a> 的「為什麼只收這幾本」段有標出對應的書，但本書單沒有評估過法遵環境的適用方式。&lt;/p>
&lt;p>&lt;strong>閱讀本身的成本&lt;/strong>：這份書單預設讀者能靠長篇文字取得知識。那個前提對一部分人不成立——閱讀障礙、以及英文長文的閱讀速度慢到一本四百頁的原文書落在可行範圍之外，都讓「讀哪一本」這個問題失去意義，因為卡住的是載體而不是選擇。這種處境要的是同一份知識的另一種形式，而它有自己的一組收錄門檻與已知限制，寫在下面的「公開課怎麼收」段；有課程的主題篇會在文末標出它。&lt;/p>
&lt;p>&lt;strong>取得成本&lt;/strong>：書單不以價格篩選，也沒有把它列進描述維度，因此對預算受限的讀者不提供任何幫助。目前標出官方免費線上版的是 Google SRE 系列與《Software Engineering at Google》；Argyris 那篇給的是 HBR 的文章頁，讀不讀得完取決於該站當下的計次規則。這份清單只反映已經查過的那些，沒標不表示沒有。中譯本狀態會標，但那記錄的是有沒有中文版，不是負不負擔得起。&lt;/p>
&lt;h2 id="書單線">書單線&lt;/h2>
&lt;p>三條線按決定的對象分開：一條的決定落在人與制度上，一條落在產物上，一條落在自己的錢上。前兩條值得分開，是因為兩邊的失敗互相看不見——程式寫得好而團隊切錯，交付一樣卡；團隊結構完美而每個模組都難改，速度一樣起不來。第三條分開的理由不同：它的決定不在工作場域裡發生，讀者的位置從「在一個組織裡負責某件事」換成「配置自己的資本」，而前兩條線用來調整答案的那組約束（組織規模、人員流動率、協作形態）在那個位置上一條也對不上。&lt;/p>
&lt;p>這三條線是涵蓋決定，不是問題空間的三分。它說的是目前這裡收了哪三類，不是問題只有這三類：落在交界的主題會自己說明白（&lt;a href="software-management/topics/personal-workflow/">個人工作流與工作負荷&lt;/a> 目前是唯一一個），而學習與技能取得、產品判斷、倦怠、以及責任來源在組織外的處境（獨立接案、開源維護、對社群負責）三條線都不收。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>書單線&lt;/th>
 &lt;th>涵蓋的問題&lt;/th>
 &lt;th>讀者的處境&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="software-management/">軟體管理與組織&lt;/a>&lt;/td>
 &lt;td>問題定義、交付與結構、文化與留任、估算與事故、對話與會議、個人負荷與角色轉換&lt;/td>
 &lt;td>與別人和制度之間發生的事&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="craft/">工程技藝&lt;/a>&lt;/td>
 &lt;td>設計判準與日常實踐、改既有程式、系統架構、驗證&lt;/td>
 &lt;td>打開編輯器之後的判斷&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="finance/">財務與投資&lt;/a>&lt;/td>
 &lt;td>資本配置與投資、個人理財、財報閱讀、總體環境&lt;/td>
 &lt;td>自己的錢往哪裡放&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>技藝的問題在職涯早期最密集，管理的問題要有人可帶才會出現，所以多數人是先走技藝線、之後才需要第二條。財務那條線的觸發跟職涯階段無關，由手上有沒有需要配置的餘裕決定，因此它可以在任何時間點插進來，也可以一直不需要。&lt;/p>
&lt;h2 id="收錄與排除的規則">收錄與排除的規則&lt;/h2>
&lt;p>每個主題只收在該主題裡承擔不同角色的書，承擔同一個角色的不各佔一個獨立條目——可以並收，但要合寫成一條並說明為什麼需要不只一本（Edmondson 的三本與 Staff 那兩本都是這種形態）。角色由各主題自己界定——持續交付那篇分的是證據強度的層級，事故檢討那篇分的是操作指南與深度個案，兩者的切法不同，因為那兩個主題的讀者要區分的東西不同。各篇的「為什麼只收這幾本」段會說明該篇怎麼分。&lt;/p>
&lt;p>這條規則存在的理由是任何主題的相關書籍都遠多於一個人讀得完的量，而列滿一頁書名等於把篩選工作退回給讀者。書單的價值在篩選本身，不在覆蓋率。被排除的書不代表它不值得讀，只代表這個主題裡已經有書承擔同一個角色。這條規則對讀者的用途是判斷要不要再讀第二本：同主題的第二本若跟第一本承擔同一個角色，讀完等於把同一組結論再聽一次別的說法；承擔不同角色的那幾本，各篇的「為什麼只收這幾本」段有寫出誰承擔什麼。排除理由能給具體依據的會給，給不出的會直接寫成「本書單未評估」，而不是包裝成看起來有依據的判斷。「未評估」是誠實的欄位，不是委婉的否決，因此它保留給真的沒做過判斷的那些：給得出確定排除理由的（角色與既有的某本重疊、要回答的問題不同軸）寫成排除並說明依據，不掛這個標籤。掛上它的時候要一併寫出未評估的是哪一項——角色歸屬、內容重疊、適用邊界、還是時效——否則同一句話會同時宣稱「不知道」與「知道它適用什麼」。&lt;/p>
&lt;p>被排除的最大一類不是具名的那幾本，是推廣書：整本推一個格式、一套流程或一組規則，而不寫它在什麼條件下失效。判準因此是&lt;strong>看它有沒有交代自己的適用邊界&lt;/strong>——寫得出「什麼情況下不要用這個」的是分析，只給規則不給邊界的把判斷收走了。各篇「為什麼只收這幾本」段會說這條判準在該主題具體長什麼樣，因為邊界的形狀隨主題不同：架構風格的邊界是規模與團隊數，會議格式的邊界是參與者的權力落差，生產力方法的邊界是讀者能不能決定自己的排程。這一類排除是&lt;strong>類別級的、未逐本核對&lt;/strong>——那條判準是給讀者拿去用的操作，不是書單對每一本推廣書實際執行過的檢查。因此它排除的是一個類別的預設值，遇到具體某本書時仍要自己翻一次目錄。&lt;/p>
&lt;p>書單會隨時間失準，而失準的兩類東西需要不同的觸發點。判定類的（時效切分、角色歸屬、處境相容性）跟著新增書走：往某個主題新增一本時，順帶重看同篇既有書的判定。這個觸發對不再新增書的主題不會發生，因此判定類另外需要一個作者以外可以核對的錨。判定、判定的記錄、判定的觸發若全部出自同一個位置，「認真做過」與「完全沒做」在頁面上長得一樣。&lt;/p>
&lt;p>三維目前的錨強度不同。&lt;strong>處境相容性&lt;/strong>有現成的一個：上面那組三十六／六／二十五的分佈可數，數字掉出來就知道有沒有人在維護這一維，不必靠自陳。計數單位是書目小節，不是「處境上」這三個字出現幾次——那三個字在全站出現的次數不到寫出處境限制的小節數的一半（而且其中一次就在這句話自己裡面），關鍵詞抓不到的比抓得到的多——多數判定用的是「預設」「假設」「這本書要的環境」這類說法，理由見 &lt;a href="https://tarrragon.github.io/blog/report/keyword-list-needs-dominant-violating-sense/" data-link-title="入口由違規形態寫不寫得成 pattern 決定，佔比只決定能不能原樣進清單" data-link-desc="某個用詞規則已經有 grep 清單、而漏抓的實例一直從外部指正進來時，用來判斷該擴充清單還是該換偵測方式">#267 入口由違規形態寫不寫得成 pattern 決定，佔比只決定能不能原樣進清單&lt;/a>。&lt;strong>時效&lt;/strong>的覆蓋率是滿的：以書目小節為單位（三條線各主題篇的 H2，扣掉每篇末尾的「為什麼只收這幾本」與「這個主題接到哪裡」兩節——技藝線的系統架構那篇用的是「為什麼只收這兩本」，同樣扣掉——再扣掉公開課段，那一節描述的是課不是書，不計入書目小節），六十七個小節裡六十六個做過，剩下那一個是指回別篇主場的引用小節（Google SRE 的判定住在持續交付那篇），本來就不重複。滿的覆蓋率只偵測得到新增書漏寫、偵測不到既有判定隨時間變質，偏偏時效正是最會變質的一維。補的辦法是讓每一則時效判定都點名一個具體的過時前提——辦公室隔間、以年為單位的瀑布式階段劃分、Java 與 JMock 的範例版本——那個前提現在成不成立，不必信任這個頁面就查得到；只寫「有些部分過時」而點不出前提的，等於這一項還沒做。這一維也不用關鍵詞計數：六十七節裡有兩節（Peopleware 與 High Output Management）直接從出版年切入而沒有用「時效」這個詞，掃字會把全批最老、判定寫得最完整的兩本判成缺口，理由見 &lt;a href="https://tarrragon.github.io/blog/report/keyword-list-needs-dominant-violating-sense/" data-link-title="入口由違規形態寫不寫得成 pattern 決定，佔比只決定能不能原樣進清單" data-link-desc="某個用詞規則已經有 grep 清單、而漏抓的實例一直從外部指正進來時，用來判斷該擴充清單還是該換偵測方式">#267 入口由違規形態寫不寫得成 pattern 決定，佔比只決定能不能原樣進清單&lt;/a>。&lt;strong>角色歸屬沒有錨&lt;/strong>，而且不像另外兩維有補的辦法：角色由各主題自己界定（持續交付那篇按證據強度分、事故檢討那篇按操作指南與深度個案分），不對應任何頁面外的事實，因此沒有可以拿去核對的對象。它能做到的上限是把界定寫進「為什麼只收這幾本」段，讓那個切法可以被反駁——可反駁不等於可核對，這一維的維護狀態目前確實看不出來。&lt;/p>
&lt;p>第三類是&lt;strong>結構計數&lt;/strong>（書線有幾條、主題篇有幾篇、書目小節總數與各維度的分佈），它的觸發點是新增或移除一條線、一篇主題，而不是新增一本書。這一類的住址散在幾處：本頁的書單線表與上面那組分佈、&lt;a href="software-management/topics/">主題書單&lt;/a> 的判準適用範圍句、以及各線入口頁提到彼此的地方。公開課那一組另有自己的計數住址——各線有幾個主題接得住、幾個沒查到，寫在 &lt;a href="craft/">工程技藝書單&lt;/a> 與 &lt;a href="software-management/topics/">主題書單&lt;/a> 的公開課段、三條線的 Backlog、本頁下方的 Backlog 總覽表，以及系統架構篇與估算篇各自的「唯一」宣稱。改動時這幾處要一次走完。改動線或篇的當下要一次走完這幾處——本頁第一次加線時就在同一段裡留下過兩個不同的分母，那是這條規則存在的理由。&lt;/p>
&lt;p>機械類的（購書連結、版次、中譯本狀態、通路可得性，以及課程的連結、講次與平台政策）跟新增書無關——它們在沒有人動這個主題的時候照樣衰減，而論證最完整、最不可能再新增書的那幾篇，衰減速度跟其他篇一樣。這一類只保證撰稿時查證過，連結失效與新譯本出現都靠讀者回報或下一次全站連結檢查，不由新增書觸發。&lt;/p>
&lt;h2 id="公開課怎麼收">公開課怎麼收&lt;/h2>
&lt;p>&lt;strong>課程&lt;/strong>收錄的門檻四條，跟上面「收錄與排除的規則」講的選書判準是兩套東西。前兩條是判準、後兩條是取得條件。&lt;strong>知識本質恆定&lt;/strong>問的跟書的時效狀態同一件事：這門課教的內容依賴什麼前提，那個前提會不會在幾年內改變——會計循環與三表勾稽不會，某個工具的操作會。逐年改版而教的是同一套（CS50 那種形態）是這一條的補充訊號而非定義，因為多數課程只錄過一次、跨版本比較無從做起。&lt;strong>實際有可聽的錄音或錄影&lt;/strong>要逐門開頁確認而不從課名或平台推斷：MIT 的 15.501 Introduction to Financial and Managerial Accounting 內容恆定這一條過，而它在 OpenCourseWare 上提供的是講義、習題與考古題，第二條沒過，對讀不動文字的人不構成選項。只有音訊沒有影像的算過——服務的目的是換成用聽的，影像在這一條上不是必要的。&lt;/p>
&lt;p>後兩條是&lt;strong>免費且內容不被鎖&lt;/strong>與&lt;strong>上傳者持有原始材料&lt;/strong>，它們決定的是連結指向哪裡。第一條的判準是不要錢、而且全部單元看得完；要註冊帳號本身不構成排除，Coursera 在 2025 年 8 月被改指開放式課程網站的實際理由是免費版只剩第一單元，不是它要登入。第二條寫成「持有原始材料」而不是「由學院或講者釋出」，是因為真正要的是來源穩定——會因為授權到期而下架的是轉錄的副本，而當年的助教把完整課堂實錄放在自己帳號上、學校那邊反而沒有留檔時，穩定的是助教那一份。判身分會把它刷掉，判來源不會。&lt;/p>
&lt;p>同一門課有多個版本時，先用後兩條選出取得得到的那一版，再拿第一條對那一版重判——舊版被選中時，「已經改版過」本身就是一個具體的過時前提，要寫進該課的時效判定。被後兩條擋下來的課要在該主題的課程段留一句，寫明是存在而取得條件不過，別讓它跟「沒查到」混在一起：這兩種狀態對讀者的下一步不同，前者可以自己去找，後者不行。&lt;/p>
&lt;p>這四條跟書的四維度不是兩套互不相干的描述，而目前只對得上一半，值得先講清楚哪一半。&lt;strong>時效&lt;/strong>兩邊沿用同一條約定。&lt;strong>讀得出價值的前提&lt;/strong>在課上的形狀是門檻——ECON 251 要解聯立方程式、ECON 159 要修過個體經濟學導論、台大的財務幸福課自陳不預設商學背景，那一項問的跟書那一維是同一件事。&lt;strong>處境相容性&lt;/strong>在課上分成語言與取得條件兩塊。剩下兩維的狀況不同。&lt;strong>證據來源&lt;/strong>課程條目不標，而這是還沒做、不是判定不需要。&lt;strong>角色歸屬&lt;/strong>有些主題篇做了——&lt;a href="finance/accounting/">會計與財報&lt;/a> 把三門初會對到「結構」、財報分析對到「經營判讀」，跟該篇分書的三個面同一組名字——但沒有跨篇約定，所以它目前是各篇自己的做法而非這一組的規格。讀者要在同一個主題上決定讀起點書還是走那門課時，缺的是證據來源那一維。&lt;/p>
&lt;p>盤點的範圍要寫出來，否則各篇「這個主題沒有課」的可信度無從判斷。2026 年 8 月這一輪查的是 MIT OpenCourseWare、Open Yale Courses、台大開放式課程與 YouTube 上的課堂實錄，逐門開課程頁確認影音與講次；單場演講、研討會錄影與付費平台的課程不在範圍內。站內另有一份課程清單（&lt;a href="https://tarrragon.github.io/blog/llm/02-math-foundations/going-deeper-math/" data-link-title="2.4 想學更深：推薦公開課程" data-link-desc="MIT、Stanford、Harvard 等公開課程：數學基礎跟 LLM 預備知識的完整學習路線">想學更深：推薦公開課程&lt;/a>），它的收錄目的是排一條學習路線而不是替代載體，因此不在這一輪的盤點範圍內。台大以外的中文來源尚未盤點。實際收錄的是中文九門、英語六門，中文全數來自台大開放式課程，英語來自 Yale、MIT 與劍橋。&lt;/p>
&lt;p>這一輪的搜尋方式有一個已知弱點，寫出來是為了讓「沒查到」有正確的權重：查法是拿主題名去找同名的課，而不是拿該主題底下的機制去找鄰近學科。這兩種查法會給出不同的結果——管理線唯一接得住的那個主題，正是靠後者才找到的。Open Yale Courses 全站只有四十門，屬於可以窮盡逐門判定的來源，而這一輪沒有那樣做。所以各篇的措辭是查不到而不是沒有：它跟中譯本那一項一樣是無法窮盡驗證的否定命題，而這裡連可窮盡的那一部分都還沒窮盡。&lt;/p>
&lt;p>上面那一節說過，判定、判定的記錄與判定的觸發若全部出自同一個位置，認真做過與完全沒做在頁面上長得一樣。那條在書那一側逐維套用過，這一組目前還沒有，下面四樣是它現在拿得出來的全部，寫出來讓它可以被核對：&lt;strong>查詢詞&lt;/strong>是各主題篇的標題加「課程」「公開課」「open course」，估算那個主題另外用了「誘因結構」與「賽局理論」；&lt;strong>來源集合&lt;/strong>是上一段列的四處，沒有第五處；&lt;strong>可窮盡的分母&lt;/strong>只有 Open Yale Courses 的四十門，MIT OpenCourseWare 與 YouTube 沒有分母；&lt;strong>查證年月&lt;/strong>全批是 2026 年 8 月，逐筆沒有各自的日期。這四樣裡前三樣可以被第三方重跑，第四樣只是宣告——它跟書那邊的機械類一樣，時間一長就要靠下一次全站檢查而不是靠這一頁。&lt;/p></description><content:encoded><![CDATA[<p>書單分類回答兩個問題：站在一個特定的職涯位置上，這個主題該先讀哪一本；以及要往別的位置移動時，該預習什麼。工具書的選擇跟當下承擔的責任綁在一起——同一本書給只對自己產出負責的人讀，跟給要對整個組織結構負責的人讀，能讀出來的東西完全不同，而且不是深淺差別，是關注點根本不在同一處。</p>
<p>要直接找書的，三條書線與各自涵蓋的問題在下面的「書單線」段。要的是同一份知識換成用聽的，直接走「公開課怎麼收」段，那裡有收錄門檻、盤點到什麼程度、以及它服務得了哪些處境。中間三段說明的是這裡怎麼描述一本書、那些描述有多可靠、以及哪些約束會讓答案改變——各主題篇逐本套用的就是那組描述，要拿它們做判斷之前值得先讀。</p>
<p>這裡不做脫離用途的品質評價。書之間確實會被排出先後——每篇選一本起點書就是排序，怎麼排寫在 <a href="software-management/topics/">主題書單</a> 的判準段。差別在於排的是「它的結論夠不夠支持手上要拿它去做的那件事」而不是「這本書好不好」，換一個用途順序就換一次。取代通用品質評分的是四項可以各自核對的描述：它的結論從哪來、它的哪些部分依賴已經改變的條件、它預設的環境在讀它的那個組織裡存不存在、以及要有什麼經驗才讀得出它的價值。四項各自導出什麼決定、哪幾項可以否決，寫在四項定義之後。</p>
<h2 id="描述一本書的四個維度">描述一本書的四個維度</h2>
<p>四個維度裡有三項的定義、分類與判讀方式住在 <a href="knowledge-cards/">書單知識卡片</a>，下面各段只說明它在這套描述裡承擔什麼、以及怎麼跟其他維度分工。</p>
<p>**<a href="knowledge-cards/evidence-provenance/">證據來源</a>**決定這本書的結論可以支持多大範圍的決定。主題篇裡每本書的證據來源句都會用下面這組名字開頭，這樣兩本候選才對得齊：</p>
<ul>
<li><strong>大規模實證</strong>（數萬份調查、跨組織統計）可以拿來支持組織層級的改變。</li>
<li><strong>跨組織案例</strong>（多個組織並列比較，形式是敘述而非統計）可以支持「這條路別人走過」，不足以支持「所以在我們這裡也會成立」。</li>
<li><strong>單一組織的深度重建</strong>（一個組織或一次事件被完整記錄，包括制度紀錄）給的是機制的完整樣子，代價是那些機制常常依賴該組織特有的條件。</li>
<li><strong>跨客戶的顧問經驗</strong>（作者數十年在多個組織的現場觀察）提供別處拿不到的細節與語言，但無法回答「這在我的組織也成立嗎」。</li>
<li><strong>單一路徑的個人經驗</strong>（作者自己走過的那一條路，含在少數幾家公司的任職）適合用來對照自己的處境，樣本是一。</li>
<li><strong>受控實驗</strong>（心理學或行為科學的實驗研究）對它測的那個機制很硬，代價是實驗室情境與工作現場之間的那一段要自己接。</li>
<li><strong>理論建構</strong>（把零散的做法、或既有的研究，組織成一套解釋）的價值在於串連已知的事。它自己不產生新證據，而整合研究的那一種會繼承被它整合的研究的一部分效力。</li>
<li><strong>作者自建的方法</strong>（方法由作者提出，效果宣稱來自訓練現場的自陳而沒有獨立驗證）適合當自己團隊的實驗協議，拿去支持組織層級的改變要另外找依據。</li>
<li><strong>虛構敘事</strong>（結論由劇情推出，沒有資料佐證）的用途是建立共同語言，不是當論證的依據。</li>
</ul>
<p>一本書可以同時落在兩類（顧問經驗加理論建構是常見的組合），主題篇會兩類都標。多數書會在前言或方法章節自述資料從哪來，這一項的判定多半就取自那裡；取自第三方評述或體裁推斷的，主題篇會寫出是從哪裡看出來的。判錯的後果要到出示依據的時候才現形：拿一本靠劇情推出結論的書去支持部署流程的改動，提案在會議上被問資料在哪，而書裡沒有數字可以指。敘事型的書讀起來說服力不低於統計型的，差別在讀的當下沒有任何訊號，代價是那個提案被歸成個人偏好，下次帶著統計資料來還得先洗掉這個印象。這一項怎麼導出一個具體的閱讀決定，<a href="software-management/topics/meeting-facilitation/">會議引導與群體決策</a> 的六頂思考帽那一段有完整示範。</p>
<p><strong>時效狀態</strong>要分開看，因為一本書很少整本過時。技術細節、工具選擇、交付節奏的假設會過時；人在壓力下的行為、組織的溝通結構、恐懼與防衛的機制不會。1987 年的書談辦公室隔間可能無效，談中斷成本仍然成立。判斷方式是問這一段的論證依賴什麼前提，那個前提現在還在不在。主題篇裡每本書都會給時效判定，包含新書——<strong>沒有寫出具體過時前提的，表示尚未發現它的論證依賴已經改變的條件</strong>，而不是沒查。</p>
<p>**<a href="knowledge-cards/context-compatibility/">處境相容性</a>**問讀它的那一方具不具備這本書預設的環境。環境清單依題材實例化，判準不變而項目會換。組織與團隊題材（管理線與技藝線）的那一組有四項：組織形態（有沒有職級、績效與調薪制度可用）、僱傭關係（成員是不是直屬部屬、待得夠不夠久、僱主是不是同一個）、<a href="knowledge-cards/collaboration-mode/">協作形態</a>（每天重疊幾小時——這是連續量，不是同處一室與跨時區的二選一）、法規環境（事故後有沒有法定的追責與報告義務）。財務題材換成另一組（資本形態、幣別暴露、資訊揭露程度、市場上有沒有那類工具），寫在該線的入口頁；各組的定義與判讀方式都住在那張卡。</p>
<p>它跟時效狀態的差別在軸的方向。時效問那個前提現在還在不在，是時間；處境相容性問它在這個組織裡在不在，是空間。1987 年那本談中斷成本的書今天仍然成立，這是時效判定；同一本書預設團隊每天同處一室，而實際的八個人分在四個時區，這是處境判定。兩者會給出相反的結論，所以要分開問。</p>
<p>這一項跟時效一樣導出讀法而非讀不讀：預設的環境不存在時，建立在那個環境上的那幾章自行折算或跳過，其餘照讀。但它可以獨立否決——整本書的推導都依賴一個缺席的環境時，讀完得到的是一組動不了的處方。</p>
<p>這一項的覆蓋是不完整的，而且缺口的形狀值得先知道。以書目小節為單位計數，六十七個小節裡三十六個寫出了具體的處境限制，六個明說查過而沒有依賴——這六個小節的判定由篇首的整篇宣告承接（問題定義那篇的三本概念書、設計判準那篇的三本），逐節掃不到，要看那兩篇的前置段——其餘二十五個<strong>尚未檢查</strong>——沒寫不表示相容。這跟時效那一項的「沒寫表示尚未發現」不同：時效判定每個小節都做過，處境判定沒有。缺口現在散落在各篇的個別書上，不再整篇整篇缺——每個主題篇至少對一本書問過這個問題，剩下的是那一篇裡還沒逐本問完。目前唯一逐本問完的是 <a href="finance/">財務與投資</a>，那條線的每一本都寫出了具體限制，理由是它的題材本來就跨法域與跨幣別，缺席的環境比別的題材容易被看見。下面那段列的幾種約束，是這個維度在讀者側最常被踩到的實例。</p>
<p><strong>讀得出價值的前提</strong>決定閱讀時機。有些書的內容在沒有對應經驗時讀起來像常識，有了經驗才變成判準；提早讀的成本在於留下「這本我讀過」的錯誤印象，之後真的需要時不會回頭，而不只是當下多花的時間。這個代價的形狀具體是這樣：帶三個人的時候有人推薦了一本談團隊切分的書，讀完覺得講的都是常識，於是歸檔成讀過。兩年後團隊變成三個、交接面天天卡住，翻書單看到這本標著自己讀過，就往下一本找。中間沒有任何一步會提醒這件事——被記下來的只有讀沒讀，而讀得出什麼會隨經驗改變、不留痕跡。</p>
<p>這一項寫成可以拿自己的處境核對的條件句。最常見的形狀是過去的經歷（「前提是曾經 X」），另外幾種是當下的處境、當下握有的權限（Sprint 那本要的是能清空一組人一週行事曆，不是經驗）、即將進入的位置、投入的形態（Code Complete 要的是耐心，九百多頁不適合通讀）、以及同主題的前置閱讀（Edmondson 另外兩本要先讀過起點書，Wiring the Winning Organization 要先讀過這個主題的兩三本才有東西可對照）；還有一類書標不出條件，那就不標。點不出具體的 X 也不標——寫「難度高」這種評分等於回頭做品質評價，正是這套描述要避免的東西。拿條件句去對而不確定自己那次算不算時，兩種對不上的處理方式相反：條件寫的是某種經驗（待過兩間文化不同的公司，而兩間同產業），判準是問那次有沒有製造過意外，沒有意外就表示還沒有第二個對照組；條件寫的是某個處境而人正要進去（下個月開始帶人），那是提早讀唯一划算的情況，因為書這時要給的是預期而不是判準。</p>
<h3 id="四項怎麼合成一個決定">四項怎麼合成一個決定</h3>
<p>四項各自導出不同的閱讀決定：仰賴個人經驗的書適合用來對照自己的處境，大規模實證的書適合用來說服別人，需要特定經驗當底的書提早讀會空轉。</p>
<p>時效狀態與處境相容性導出的是讀法而不是讀不讀——過時或對不上的若是工具、交付節奏、辦公形態，照讀但要自行折算；若是某一段論證依賴的前提，那一段換別的材料。</p>
<p>否決權只有三項有，而且強度不同：證據來源與讀得出價值的前提是無條件否決，處境相容性只在整本書的推導都建立在同一個缺席的環境上時才否決。三者都不做補償式加權——任一項成立就先不投入時間，不能靠另一項的分數高把它補回來。</p>
<p>這四項共同預設了一件事：這個主題適合用書承接。變動速率快過書的改版週期的主題——稅制、當期補助方案、當期商品條款——不滿足那個前提，而四項判定在那裡會全部通過：一本當期稅務書的證據來源、處境相容性與讀者前提都可以無可挑剔，它只是在印出來的時候就開始過期。這個上界由各線自己標出來，<a href="finance/">財務與投資</a> 是目前唯一踩到的一條，處理方式寫在該線的「有些財務知識不該用書當載體」段。</p>
<h2 id="這些判定從哪來">這些判定從哪來</h2>
<p>書目資訊（書名、作者、出版年、版次、中譯本與譯名、購書頁面）逐筆查證過，並在頁面上留連結供覆核。四個維度的判定來源不同，混合了書本身的方法章節與前言自述、書的公開內容摘要，以及該領域的公開討論；<strong>並非每一本都經過通讀</strong>。因此這四項的性質是「有依據的判斷」而不是「代為驗證的結論」——它們的用途是幫忙決定要不要投入時間，決定投入之後，書裡的說法以原書為準。</p>
<p>這個限制有具體後果：越是需要密讀才能下的判定（章節層級的時效切分、某一章的論證依賴哪個前提），可信度越低。看到這類判定時，把它當成一條待驗證的線索，而不是結論。分辨方法在判定本身的措辭：出現章節名、或指出某一段論證的前提落在哪裡的，屬於需要密讀才下得了的那一類；只描述全書的資料來源與出版年代的，密讀與否不改變結論。頁面上找不到出處的形容（某某「公認」如何、某書「最常被引用」的是什麼）已經盡量清掉；還留著的話，那是疏漏，不是有把握的斷言。</p>
<p>中譯本狀態以撰稿時查證為準。這一項最容易靜默過期——新譯本會出現，而「目前沒有中譯本」這種否定命題無法窮盡驗證，只能說查不到。它記錄的是有沒有中文版可讀，對台灣讀者是實際資訊，但<strong>不參與選書判定</strong>——沒有中譯本不會讓一本書掉出書單，有中譯本也不會讓它進來。書目連結一律指向可查證的商品頁或官方免費線上版。用哪個通路看撰稿時抓得到哪個：早期幾篇的英文版用 Amazon、中文版用博客來，財務線那幾筆改用三民與天瓏，因為撰稿時前兩站擋抓、無法逐筆核對頁面內容。改用替代站時就記下這個降級，不假裝兩者可信度相同。這些連結不含任何聯盟或推廣關係。</p>
<h2 id="哪些約束會改變答案">哪些約束會改變答案</h2>
<p>四個維度描述的是書，位置表描述的是誰負責什麼，兩者都沒有問讀的人受什麼約束。下面幾項會讓同一個位置的正確答案不同，而書單對它們的處理程度不一樣：有的給得出調整方式，有的只標得出邊界。這份清單不窮盡——它是目前踩到過的那些，處境相容性那一項的環境清單是它的上游，遇到清單以外的約束時回去對該題材那一組環境。選書前先確認自己有沒有踩到：</p>
<p><strong>組織規模</strong>：結構設計類的書預設的最小規模大約是三個團隊。三人公司的技術負責人照位置表會走到組織結構那一格，但那一格的書對他是過度設計——那個階段的瓶頸是把事做完，不是把介面畫對。三個團隊這個數字可以自己重算：結構問題出在團隊之間的交接面上，n 個團隊有 n(n-1)/2 個介面，兩個團隊只有一個介面、協調靠兩個人講一次話就解決，要到三個團隊、三個介面之後，介面本身才變成需要設計的東西。踩到這一項之後往哪走，寫在 <a href="software-management/roles/">依位置選書</a> 的規模下限那一段。</p>
<p><strong>人員流動率</strong>：留任與團隊凝聚類的書預設成員會待夠久，久到值得投資關係與環境。約聘輪替、外包接案、專案制編組這些情境裡，那個前提不成立，而書裡的建議（保護團隊不被打斷、培養凝聚）換算不到可執行的動作。這種處境需要的是交接與文件化，那不在這條書線的範圍內——這是清單裡唯一連站外替代方向都給不出來的一項，其餘幾項至少標得出往哪走。<a href="software-management/topics/retention-motivation/">留任、動機與工作環境</a> 的前置段是同一條約束在該主題的落點。</p>
<p><strong><a href="knowledge-cards/collaboration-mode/">協作形態</a></strong>：多數管理與團隊類的書預設成員每天有大量重疊工時，凝聚、中斷成本、走廊上的一句話都建立在共處上。重疊工時每天不到兩小時的團隊，那批論證的前提有一半不存在，而書裡通常不會標出哪一半；兩到四小時這一段要逐項換算，做法在那張卡。這一項最容易假性通過——前面三項約束逐條檢查都不踩，於是照一般路徑選書，而真正支配這個處境的變數根本不在清單上。目前正向處理非同步的只有 <a href="software-management/topics/personal-workflow/">個人工作流與工作負荷</a> 收的 A World Without Email。</p>
<p><strong>法規與稽核義務</strong>：無指責檢討這類主張有法律邊界。受金融、醫療、航空等主管機關監理的組織，事故後有法定的追責與報告義務，而「不追究個人」在那個脈絡下不是文化選擇。這類組織要讀的是懲戒界線怎麼畫，而不是怎麼取消懲戒——<a href="software-management/topics/incident-blame/">事故、歸因與無指責檢討</a> 的「為什麼只收這幾本」段有標出對應的書，但本書單沒有評估過法遵環境的適用方式。</p>
<p><strong>閱讀本身的成本</strong>：這份書單預設讀者能靠長篇文字取得知識。那個前提對一部分人不成立——閱讀障礙、以及英文長文的閱讀速度慢到一本四百頁的原文書落在可行範圍之外，都讓「讀哪一本」這個問題失去意義，因為卡住的是載體而不是選擇。這種處境要的是同一份知識的另一種形式，而它有自己的一組收錄門檻與已知限制，寫在下面的「公開課怎麼收」段；有課程的主題篇會在文末標出它。</p>
<p><strong>取得成本</strong>：書單不以價格篩選，也沒有把它列進描述維度，因此對預算受限的讀者不提供任何幫助。目前標出官方免費線上版的是 Google SRE 系列與《Software Engineering at Google》；Argyris 那篇給的是 HBR 的文章頁，讀不讀得完取決於該站當下的計次規則。這份清單只反映已經查過的那些，沒標不表示沒有。中譯本狀態會標，但那記錄的是有沒有中文版，不是負不負擔得起。</p>
<h2 id="書單線">書單線</h2>
<p>三條線按決定的對象分開：一條的決定落在人與制度上，一條落在產物上，一條落在自己的錢上。前兩條值得分開，是因為兩邊的失敗互相看不見——程式寫得好而團隊切錯，交付一樣卡；團隊結構完美而每個模組都難改，速度一樣起不來。第三條分開的理由不同：它的決定不在工作場域裡發生，讀者的位置從「在一個組織裡負責某件事」換成「配置自己的資本」，而前兩條線用來調整答案的那組約束（組織規模、人員流動率、協作形態）在那個位置上一條也對不上。</p>
<p>這三條線是涵蓋決定，不是問題空間的三分。它說的是目前這裡收了哪三類，不是問題只有這三類：落在交界的主題會自己說明白（<a href="software-management/topics/personal-workflow/">個人工作流與工作負荷</a> 目前是唯一一個），而學習與技能取得、產品判斷、倦怠、以及責任來源在組織外的處境（獨立接案、開源維護、對社群負責）三條線都不收。</p>
<table>
  <thead>
      <tr>
          <th>書單線</th>
          <th>涵蓋的問題</th>
          <th>讀者的處境</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="software-management/">軟體管理與組織</a></td>
          <td>問題定義、交付與結構、文化與留任、估算與事故、對話與會議、個人負荷與角色轉換</td>
          <td>與別人和制度之間發生的事</td>
      </tr>
      <tr>
          <td><a href="craft/">工程技藝</a></td>
          <td>設計判準與日常實踐、改既有程式、系統架構、驗證</td>
          <td>打開編輯器之後的判斷</td>
      </tr>
      <tr>
          <td><a href="finance/">財務與投資</a></td>
          <td>資本配置與投資、個人理財、財報閱讀、總體環境</td>
          <td>自己的錢往哪裡放</td>
      </tr>
  </tbody>
</table>
<p>技藝的問題在職涯早期最密集，管理的問題要有人可帶才會出現，所以多數人是先走技藝線、之後才需要第二條。財務那條線的觸發跟職涯階段無關，由手上有沒有需要配置的餘裕決定，因此它可以在任何時間點插進來，也可以一直不需要。</p>
<h2 id="收錄與排除的規則">收錄與排除的規則</h2>
<p>每個主題只收在該主題裡承擔不同角色的書，承擔同一個角色的不各佔一個獨立條目——可以並收，但要合寫成一條並說明為什麼需要不只一本（Edmondson 的三本與 Staff 那兩本都是這種形態）。角色由各主題自己界定——持續交付那篇分的是證據強度的層級，事故檢討那篇分的是操作指南與深度個案，兩者的切法不同，因為那兩個主題的讀者要區分的東西不同。各篇的「為什麼只收這幾本」段會說明該篇怎麼分。</p>
<p>這條規則存在的理由是任何主題的相關書籍都遠多於一個人讀得完的量，而列滿一頁書名等於把篩選工作退回給讀者。書單的價值在篩選本身，不在覆蓋率。被排除的書不代表它不值得讀，只代表這個主題裡已經有書承擔同一個角色。這條規則對讀者的用途是判斷要不要再讀第二本：同主題的第二本若跟第一本承擔同一個角色，讀完等於把同一組結論再聽一次別的說法；承擔不同角色的那幾本，各篇的「為什麼只收這幾本」段有寫出誰承擔什麼。排除理由能給具體依據的會給，給不出的會直接寫成「本書單未評估」，而不是包裝成看起來有依據的判斷。「未評估」是誠實的欄位，不是委婉的否決，因此它保留給真的沒做過判斷的那些：給得出確定排除理由的（角色與既有的某本重疊、要回答的問題不同軸）寫成排除並說明依據，不掛這個標籤。掛上它的時候要一併寫出未評估的是哪一項——角色歸屬、內容重疊、適用邊界、還是時效——否則同一句話會同時宣稱「不知道」與「知道它適用什麼」。</p>
<p>被排除的最大一類不是具名的那幾本，是推廣書：整本推一個格式、一套流程或一組規則，而不寫它在什麼條件下失效。判準因此是<strong>看它有沒有交代自己的適用邊界</strong>——寫得出「什麼情況下不要用這個」的是分析，只給規則不給邊界的把判斷收走了。各篇「為什麼只收這幾本」段會說這條判準在該主題具體長什麼樣，因為邊界的形狀隨主題不同：架構風格的邊界是規模與團隊數，會議格式的邊界是參與者的權力落差，生產力方法的邊界是讀者能不能決定自己的排程。這一類排除是<strong>類別級的、未逐本核對</strong>——那條判準是給讀者拿去用的操作，不是書單對每一本推廣書實際執行過的檢查。因此它排除的是一個類別的預設值，遇到具體某本書時仍要自己翻一次目錄。</p>
<p>書單會隨時間失準，而失準的兩類東西需要不同的觸發點。判定類的（時效切分、角色歸屬、處境相容性）跟著新增書走：往某個主題新增一本時，順帶重看同篇既有書的判定。這個觸發對不再新增書的主題不會發生，因此判定類另外需要一個作者以外可以核對的錨。判定、判定的記錄、判定的觸發若全部出自同一個位置，「認真做過」與「完全沒做」在頁面上長得一樣。</p>
<p>三維目前的錨強度不同。<strong>處境相容性</strong>有現成的一個：上面那組三十六／六／二十五的分佈可數，數字掉出來就知道有沒有人在維護這一維，不必靠自陳。計數單位是書目小節，不是「處境上」這三個字出現幾次——那三個字在全站出現的次數不到寫出處境限制的小節數的一半（而且其中一次就在這句話自己裡面），關鍵詞抓不到的比抓得到的多——多數判定用的是「預設」「假設」「這本書要的環境」這類說法，理由見 <a href="/blog/report/keyword-list-needs-dominant-violating-sense/" data-link-title="入口由違規形態寫不寫得成 pattern 決定，佔比只決定能不能原樣進清單" data-link-desc="某個用詞規則已經有 grep 清單、而漏抓的實例一直從外部指正進來時，用來判斷該擴充清單還是該換偵測方式">#267 入口由違規形態寫不寫得成 pattern 決定，佔比只決定能不能原樣進清單</a>。<strong>時效</strong>的覆蓋率是滿的：以書目小節為單位（三條線各主題篇的 H2，扣掉每篇末尾的「為什麼只收這幾本」與「這個主題接到哪裡」兩節——技藝線的系統架構那篇用的是「為什麼只收這兩本」，同樣扣掉——再扣掉公開課段，那一節描述的是課不是書，不計入書目小節），六十七個小節裡六十六個做過，剩下那一個是指回別篇主場的引用小節（Google SRE 的判定住在持續交付那篇），本來就不重複。滿的覆蓋率只偵測得到新增書漏寫、偵測不到既有判定隨時間變質，偏偏時效正是最會變質的一維。補的辦法是讓每一則時效判定都點名一個具體的過時前提——辦公室隔間、以年為單位的瀑布式階段劃分、Java 與 JMock 的範例版本——那個前提現在成不成立，不必信任這個頁面就查得到；只寫「有些部分過時」而點不出前提的，等於這一項還沒做。這一維也不用關鍵詞計數：六十七節裡有兩節（Peopleware 與 High Output Management）直接從出版年切入而沒有用「時效」這個詞，掃字會把全批最老、判定寫得最完整的兩本判成缺口，理由見 <a href="/blog/report/keyword-list-needs-dominant-violating-sense/" data-link-title="入口由違規形態寫不寫得成 pattern 決定，佔比只決定能不能原樣進清單" data-link-desc="某個用詞規則已經有 grep 清單、而漏抓的實例一直從外部指正進來時，用來判斷該擴充清單還是該換偵測方式">#267 入口由違規形態寫不寫得成 pattern 決定，佔比只決定能不能原樣進清單</a>。<strong>角色歸屬沒有錨</strong>，而且不像另外兩維有補的辦法：角色由各主題自己界定（持續交付那篇按證據強度分、事故檢討那篇按操作指南與深度個案分），不對應任何頁面外的事實，因此沒有可以拿去核對的對象。它能做到的上限是把界定寫進「為什麼只收這幾本」段，讓那個切法可以被反駁——可反駁不等於可核對，這一維的維護狀態目前確實看不出來。</p>
<p>第三類是<strong>結構計數</strong>（書線有幾條、主題篇有幾篇、書目小節總數與各維度的分佈），它的觸發點是新增或移除一條線、一篇主題，而不是新增一本書。這一類的住址散在幾處：本頁的書單線表與上面那組分佈、<a href="software-management/topics/">主題書單</a> 的判準適用範圍句、以及各線入口頁提到彼此的地方。公開課那一組另有自己的計數住址——各線有幾個主題接得住、幾個沒查到，寫在 <a href="craft/">工程技藝書單</a> 與 <a href="software-management/topics/">主題書單</a> 的公開課段、三條線的 Backlog、本頁下方的 Backlog 總覽表，以及系統架構篇與估算篇各自的「唯一」宣稱。改動時這幾處要一次走完。改動線或篇的當下要一次走完這幾處——本頁第一次加線時就在同一段裡留下過兩個不同的分母，那是這條規則存在的理由。</p>
<p>機械類的（購書連結、版次、中譯本狀態、通路可得性，以及課程的連結、講次與平台政策）跟新增書無關——它們在沒有人動這個主題的時候照樣衰減，而論證最完整、最不可能再新增書的那幾篇，衰減速度跟其他篇一樣。這一類只保證撰稿時查證過，連結失效與新譯本出現都靠讀者回報或下一次全站連結檢查，不由新增書觸發。</p>
<h2 id="公開課怎麼收">公開課怎麼收</h2>
<p><strong>課程</strong>收錄的門檻四條，跟上面「收錄與排除的規則」講的選書判準是兩套東西。前兩條是判準、後兩條是取得條件。<strong>知識本質恆定</strong>問的跟書的時效狀態同一件事：這門課教的內容依賴什麼前提，那個前提會不會在幾年內改變——會計循環與三表勾稽不會，某個工具的操作會。逐年改版而教的是同一套（CS50 那種形態）是這一條的補充訊號而非定義，因為多數課程只錄過一次、跨版本比較無從做起。<strong>實際有可聽的錄音或錄影</strong>要逐門開頁確認而不從課名或平台推斷：MIT 的 15.501 Introduction to Financial and Managerial Accounting 內容恆定這一條過，而它在 OpenCourseWare 上提供的是講義、習題與考古題，第二條沒過，對讀不動文字的人不構成選項。只有音訊沒有影像的算過——服務的目的是換成用聽的，影像在這一條上不是必要的。</p>
<p>後兩條是<strong>免費且內容不被鎖</strong>與<strong>上傳者持有原始材料</strong>，它們決定的是連結指向哪裡。第一條的判準是不要錢、而且全部單元看得完；要註冊帳號本身不構成排除，Coursera 在 2025 年 8 月被改指開放式課程網站的實際理由是免費版只剩第一單元，不是它要登入。第二條寫成「持有原始材料」而不是「由學院或講者釋出」，是因為真正要的是來源穩定——會因為授權到期而下架的是轉錄的副本，而當年的助教把完整課堂實錄放在自己帳號上、學校那邊反而沒有留檔時，穩定的是助教那一份。判身分會把它刷掉，判來源不會。</p>
<p>同一門課有多個版本時，先用後兩條選出取得得到的那一版，再拿第一條對那一版重判——舊版被選中時，「已經改版過」本身就是一個具體的過時前提，要寫進該課的時效判定。被後兩條擋下來的課要在該主題的課程段留一句，寫明是存在而取得條件不過，別讓它跟「沒查到」混在一起：這兩種狀態對讀者的下一步不同，前者可以自己去找，後者不行。</p>
<p>這四條跟書的四維度不是兩套互不相干的描述，而目前只對得上一半，值得先講清楚哪一半。<strong>時效</strong>兩邊沿用同一條約定。<strong>讀得出價值的前提</strong>在課上的形狀是門檻——ECON 251 要解聯立方程式、ECON 159 要修過個體經濟學導論、台大的財務幸福課自陳不預設商學背景，那一項問的跟書那一維是同一件事。<strong>處境相容性</strong>在課上分成語言與取得條件兩塊。剩下兩維的狀況不同。<strong>證據來源</strong>課程條目不標，而這是還沒做、不是判定不需要。<strong>角色歸屬</strong>有些主題篇做了——<a href="finance/accounting/">會計與財報</a> 把三門初會對到「結構」、財報分析對到「經營判讀」，跟該篇分書的三個面同一組名字——但沒有跨篇約定，所以它目前是各篇自己的做法而非這一組的規格。讀者要在同一個主題上決定讀起點書還是走那門課時，缺的是證據來源那一維。</p>
<p>盤點的範圍要寫出來，否則各篇「這個主題沒有課」的可信度無從判斷。2026 年 8 月這一輪查的是 MIT OpenCourseWare、Open Yale Courses、台大開放式課程與 YouTube 上的課堂實錄，逐門開課程頁確認影音與講次；單場演講、研討會錄影與付費平台的課程不在範圍內。站內另有一份課程清單（<a href="/blog/llm/02-math-foundations/going-deeper-math/" data-link-title="2.4 想學更深：推薦公開課程" data-link-desc="MIT、Stanford、Harvard 等公開課程：數學基礎跟 LLM 預備知識的完整學習路線">想學更深：推薦公開課程</a>），它的收錄目的是排一條學習路線而不是替代載體，因此不在這一輪的盤點範圍內。台大以外的中文來源尚未盤點。實際收錄的是中文九門、英語六門，中文全數來自台大開放式課程，英語來自 Yale、MIT 與劍橋。</p>
<p>這一輪的搜尋方式有一個已知弱點，寫出來是為了讓「沒查到」有正確的權重：查法是拿主題名去找同名的課，而不是拿該主題底下的機制去找鄰近學科。這兩種查法會給出不同的結果——管理線唯一接得住的那個主題，正是靠後者才找到的。Open Yale Courses 全站只有四十門，屬於可以窮盡逐門判定的來源，而這一輪沒有那樣做。所以各篇的措辭是查不到而不是沒有：它跟中譯本那一項一樣是無法窮盡驗證的否定命題，而這裡連可窮盡的那一部分都還沒窮盡。</p>
<p>上面那一節說過，判定、判定的記錄與判定的觸發若全部出自同一個位置，認真做過與完全沒做在頁面上長得一樣。那條在書那一側逐維套用過，這一組目前還沒有，下面四樣是它現在拿得出來的全部，寫出來讓它可以被核對：<strong>查詢詞</strong>是各主題篇的標題加「課程」「公開課」「open course」，估算那個主題另外用了「誘因結構」與「賽局理論」；<strong>來源集合</strong>是上一段列的四處，沒有第五處；<strong>可窮盡的分母</strong>只有 Open Yale Courses 的四十門，MIT OpenCourseWare 與 YouTube 沒有分母；<strong>查證年月</strong>全批是 2026 年 8 月，逐筆沒有各自的日期。這四樣裡前三樣可以被第三方重跑，第四樣只是宣告——它跟書那邊的機械類一樣，時間一長就要靠下一次全站檢查而不是靠這一頁。</p>
<p><strong>這一組服務的處境要圈出來，因為它比「讀不動長篇文字」窄。</strong> 適用的是閱讀障礙、以及外語<strong>讀</strong>得慢而<strong>聽</strong>得動的那一種——第二種要分清楚，因為英語課堂實錄是連續八十分鐘的英語口說，對讀得慢也聽不動的人比讀英文書更難，那時搭起橋的是字幕與逐字稿而不是影音本身。各篇會在英語課的條目標出有沒有官方字幕或逐字稿。<strong>不適用的是注意力與時間受限</strong>：這批課動輒二十到五十講、單門總時數以十小時計，對時間受限的讀者比一本書更差而不是更好。那是選課的另一條軸（單元短不短、能不能零碎聽完），這一輪的四條門檻沒有問它。目前站內唯一做過這個判斷的是系統架構那篇對 Kleppmann 那門的評語，而它是個案不是規則。</p>
<p>同一個保留也適用在「實際有影音」這一條上：<strong>它是二元的，而讀者實際能不能用是連續的。</strong> 有影音只是必要條件，語言、有沒有字幕與逐字稿、要不要先修微積分或會寫某個語言，還有它對畫面的依賴程度，這些決定的是同一門課對某個讀者可不可用。最後一項對這一組的服務對象特別要緊：會計的分錄與 T 帳戶、架構的拓樸圖、賽局的賽局樹，離開畫面就聽不完整，而那正是純靠聽的讀者拿不到的部分。各篇會在課程段標出語言與門檻，但那些沒有寫進四條門檻，所以線層那幾個「幾個主題有課」的計數對真正讀不動文字的讀者是高估。計數單位本身也有同樣的鬆動：台大的初級會計學三門合起來是一門初會、Kleppmann 那門是八講切成二十三段影片，「門」與「講」在不同來源不是同一個單位。</p>
<p>課程的時效比書更需要標，理由在載體本身：書會改版重印，讀者拿到的是當期版本，而錄影不會，畫面上也沒有訊號提示已經過了幾年。各課程條目因此沿用書的同一條約定——<strong>沒有寫出具體過時前提的，表示尚未發現它依賴已經改變的條件</strong>，而不是沒查。課程的機械類資訊（連結、講次、播放清單、平台政策）與書的購書連結同屬「這些判定從哪來」段末說的機械類：只保證撰稿時查證過，且它衰減得比書更快。</p>
<p>課程這個載體接不住某些東西，而各篇是分頭發現的，這裡把發現並排起來讓它們可以互相對照——<strong>並排不等於歸納出一條規律</strong>，目前的證據支持不了那一步（理由在 <a href="craft/">工程技藝書單</a> 的公開課段，那裡寫出了一個試過而失敗的歸納）。<a href="craft/changing-existing-code/">改既有的程式</a> 說材料要來自真實系統累積出來的歷史，課堂取不到；<a href="craft/verification/">驗證自己寫對了</a> 說本篇要交付的是三本書彼此不同意在哪，而查到的課預設有標準答案可以教；<a href="craft/system-architecture/">系統架構</a> 說取捨的代價要好幾年才顯現，一學期的課承載不了；<a href="software-management/topics/estimation-decision/">估算、承諾與決策偏誤</a> 說當長期參考的偏誤目錄那個功能課程沒有。<a href="finance/personal-finance/">個人理財與風險保障</a> 那一則的形狀不同：課程講得了制度，但錄影不改版，所以同樣的內容在課上衰減得比在書上快。五則之間看得出家族相似，五則不足以支持一條通則。</p>
<h2 id="backlog-總覽">Backlog 總覽</h2>
<p>三條線各自維護待辦，這裡只放索引，細節在各線的 Backlog 段。新增或移除一條線時要同步補這張表，理由跟上一段的結構計數相同。</p>
<table>
  <thead>
      <tr>
          <th>書單線</th>
          <th>項數</th>
          <th>缺口</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="finance/">財務與投資</a></td>
          <td>7</td>
          <td>書：風險保障這個主題沒有書、提領期尚未成篇。課：待重掃（四篇現況皆有）</td>
      </tr>
      <tr>
          <td><a href="craft/">工程技藝</a></td>
          <td>3</td>
          <td>課：四個主題裡三個沒查到，等重掃與 MIT 6.005 改判</td>
      </tr>
      <tr>
          <td><a href="software-management/">軟體管理與組織</a></td>
          <td>3</td>
          <td>課：十一個主題裡十個沒查到，等重掃與 MIT 15.871 改判</td>
      </tr>
  </tbody>
</table>
<h2 id="跟其他分類的邊界">跟其他分類的邊界</h2>
<p>書單只放外部書籍與選讀判斷。書中概念怎麼在自己的專案落地，回到教學系列：交付管線與部署 gate 看 <a href="/blog/ci/" data-link-title="CI/CD 教學" data-link-desc="整理 CI/CD 的驗證、建置、發布 gate 與不同部署場域的流程差異，讓每次變更都能被穩定驗證與交付">CI/CD 教學</a>，服務探活與容量規劃看 <a href="/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運</a>，事故分級、指揮角色與復盤制度看 <a href="/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤</a>，客戶端遙測的收集鏈路看 <a href="/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系</a>，交付生命週期的全景看 <a href="/blog/devops/" data-link-title="DevOps 全景：軟體交付生命週期" data-link-desc="想釐清 infra、CI/CD、運行期維運怎麼串成一條軟體交付生命週期、或不確定手上的問題該進哪個系列時回來讀">DevOps 全景</a>，商業術語看 <a href="/blog/business/" data-link-title="商業概念與策略分析" data-link-desc="整理商業模式、單位經濟、進入市場、競爭護城河、市場動態、資本估值與執行知識，並提供閱讀商業分析的框架">商業概念與策略分析</a>。</p>
]]></content:encoded></item><item><title>對組織結構負責</title><link>https://tarrragon.github.io/blog/books/software-management/roles/org-structure/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/org-structure/</guid><description>&lt;p>管的是管人的人，不再是人本身。因此動作與結果之間隔著至少兩層，回饋延遲以季為單位——這一格的判斷幾乎都要在確認得到結果之前就下。要判斷的東西落在團隊與團隊之間：邊界畫在哪、交接面誰負責、哪些事情沒有人特別該負責但一定會出問題。&lt;/p>
&lt;p>改組織圖而沒有改任何人的實際約束，是這個位置代價最高的失敗。畫新的框、宣布新的分工，隔天每個人面對的優先序、被誰打斷、被誰評分都沒有變。三個月後一切照舊，信任被消耗掉一次。與它相鄰的是把每一個跨團隊問題都當成溝通問題處理——那個解釋的吸引力在於它不必動結構。&lt;/p>
&lt;h2 id="對組織結構負責時成文制度與否的差別">對組織結構負責時，成文制度與否的差別&lt;/h2>
&lt;p>制度成文的大組織裡，這個位置的動作要穿過既有制度，於是&lt;strong>變更成本高到讓錯誤結構被保留&lt;/strong>。具體長這樣：某個服務跨在兩個團隊的邊界上，每改一次都要兩邊各自排期，通常差兩到三週；提議把它併進其中一邊，就要動另一邊的 headcount，而 headcount 綁在年度預算裡、還要說服兩位主管跟他們共同的上級；於是這件事每季被提一次，每次都合理地被延後。這裡需要的是判斷哪些結構債值得付這個代價去修，哪些改用介面設計繞過——把跨團隊的協作改成一方提供穩定介面、另一方自助使用，不動組織圖也能減少排期依賴。&lt;/p>
&lt;p>制度還沒定型、但層級已經出現的公司（人數常落在五十到兩百之間，但決定性的是制度而非人數）問題相反：改組織幾乎沒有成本，於是改得太頻繁。每次重組都重置一次團隊的默契與領域知識；那個成本不會出現在任何報表上。這裡需要的是知道重組的代價在哪裡、以及什麼訊號才真的構成重組的理由。&lt;/p>
&lt;h2 id="這個位置該讀什麼">這個位置該讀什麼&lt;/h2>
&lt;p>&lt;strong>&lt;a href="../../topics/team-design/">Team Topologies&lt;/a>&lt;/strong>（Skelton &amp;amp; Pais）是這個位置的主要書。它在這個位置的用途是把切分決定寫成別人可以反駁的形式——這條路線的決定會被上下兩層檢視，而「我覺得這樣切比較好」擋不住任何一次質疑。書的完整描述在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/team-design/">An Elegant Puzzle&lt;/a>&lt;/strong>（Will Larson）處理的是這裡的日常：團隊規模怎麼定、技術債怎麼排進計畫、接班怎麼安排、組織成長時哪些結構會先斷。它的團隊狀態模型在這個位置的用途是分配資源時的共同語言：這裡的判斷單位是團隊之間的介面，而爭資源的場合需要一個雙方都認的分類，否則討論會退回誰的嗓門大。模型本身的四種狀態與各自的介入方式在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/estimation-decision/">How Big Things Get Done&lt;/a>&lt;/strong>（Flyvbjerg &amp;amp; Gardner）處理的是這個位置躲不掉的承諾問題。它區分的兩個失準來源對這條路線特別重要，因為到這裡的所有估算都經過至少兩層轉述，每一層都有調整它的誘因——分不出手上這個數字失真在哪一層，加再多緩衝也押錯地方。兩個來源各是什麼、為什麼其中一個靠方法修不了，在主題篇。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/culture-safety/">The Fearless Organization&lt;/a>&lt;/strong> 在這個位置讀出來的東西，跟直接帶人的人讀到的不同。這裡的問題是&lt;strong>壞消息在兩層轉述中會不會被磨平&lt;/strong>——每一層都做了合理的摘要，而合理的摘要累積起來就是失真；自己的團隊敢不敢講是 &lt;a href="../people/">對人負責&lt;/a> 那一篇的題目。&lt;/p>
&lt;p>&lt;strong>&lt;a href="../../topics/team-design/">Quality Software Management, Vol. 4&lt;/a>&lt;/strong>（Gerald Weinberg，繁中譯名《溫伯格的軟體管理學：擁抱變革》，四卷各自獨立、不必從第 1 卷讀起）處理推動組織轉變時的人的阻力，是這條路線上唯一一本把抗拒當資訊而不是當障礙的書。完整的性質判定與讀的時機在主題篇。&lt;/p>
&lt;h2 id="想往哪裡走">想往哪裡走&lt;/h2>
&lt;p>進到這個位置的方式通常是組織長大，而不是換了工作內容——原本帶的一個團隊裂成兩個，人就在這裡了。準備好的訊號是兩個團隊之間的事已經在處理：協調誰做哪一段、決定介面長什麼樣、被找去仲裁優先序。沒有這些累積就直接接下多團隊，最常見的結果是把時間全部花在其中一個團隊上，因為那是唯一熟悉的工作。&lt;/p>
&lt;p>這個位置往上走，書能提供的比重快速下降。位置越高，同一個職稱在不同公司對應的實際工作差異越大，決定成敗的是這個組織的規模、產業與治理結構，而那些沒有通用解。&lt;/p>
&lt;p>比較有用的方向是往深處而非往上：&lt;strong>&lt;a href="../../topics/team-design/">Wiring the Winning Organization&lt;/a>&lt;/strong> 嘗試解釋為什麼同樣的工作在某些組織裡很難、在另一些組織裡很簡單，適合手上已經有一批彼此不相干的做法、想找共同解釋的人。&lt;strong>&lt;a href="../../topics/team-design/">Software Engineering at Google&lt;/a>&lt;/strong> 提供的是規模與時間如何反轉工程判斷的具體案例，可以拿來校準自己組織的規模對應到哪些問題。&lt;/p>
&lt;p>要把結構決定落到實際的評估動作，&lt;a href="https://tarrragon.github.io/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計&lt;/a> 提供的是把這類框架用在既有團隊上的判讀步驟。&lt;/p></description><content:encoded><![CDATA[<p>管的是管人的人，不再是人本身。因此動作與結果之間隔著至少兩層，回饋延遲以季為單位——這一格的判斷幾乎都要在確認得到結果之前就下。要判斷的東西落在團隊與團隊之間：邊界畫在哪、交接面誰負責、哪些事情沒有人特別該負責但一定會出問題。</p>
<p>改組織圖而沒有改任何人的實際約束，是這個位置代價最高的失敗。畫新的框、宣布新的分工，隔天每個人面對的優先序、被誰打斷、被誰評分都沒有變。三個月後一切照舊，信任被消耗掉一次。與它相鄰的是把每一個跨團隊問題都當成溝通問題處理——那個解釋的吸引力在於它不必動結構。</p>
<h2 id="對組織結構負責時成文制度與否的差別">對組織結構負責時，成文制度與否的差別</h2>
<p>制度成文的大組織裡，這個位置的動作要穿過既有制度，於是<strong>變更成本高到讓錯誤結構被保留</strong>。具體長這樣：某個服務跨在兩個團隊的邊界上，每改一次都要兩邊各自排期，通常差兩到三週；提議把它併進其中一邊，就要動另一邊的 headcount，而 headcount 綁在年度預算裡、還要說服兩位主管跟他們共同的上級；於是這件事每季被提一次，每次都合理地被延後。這裡需要的是判斷哪些結構債值得付這個代價去修，哪些改用介面設計繞過——把跨團隊的協作改成一方提供穩定介面、另一方自助使用，不動組織圖也能減少排期依賴。</p>
<p>制度還沒定型、但層級已經出現的公司（人數常落在五十到兩百之間，但決定性的是制度而非人數）問題相反：改組織幾乎沒有成本，於是改得太頻繁。每次重組都重置一次團隊的默契與領域知識；那個成本不會出現在任何報表上。這裡需要的是知道重組的代價在哪裡、以及什麼訊號才真的構成重組的理由。</p>
<h2 id="這個位置該讀什麼">這個位置該讀什麼</h2>
<p><strong><a href="../../topics/team-design/">Team Topologies</a></strong>（Skelton &amp; Pais）是這個位置的主要書。它在這個位置的用途是把切分決定寫成別人可以反駁的形式——這條路線的決定會被上下兩層檢視，而「我覺得這樣切比較好」擋不住任何一次質疑。書的完整描述在主題篇。</p>
<p><strong><a href="../../topics/team-design/">An Elegant Puzzle</a></strong>（Will Larson）處理的是這裡的日常：團隊規模怎麼定、技術債怎麼排進計畫、接班怎麼安排、組織成長時哪些結構會先斷。它的團隊狀態模型在這個位置的用途是分配資源時的共同語言：這裡的判斷單位是團隊之間的介面，而爭資源的場合需要一個雙方都認的分類，否則討論會退回誰的嗓門大。模型本身的四種狀態與各自的介入方式在主題篇。</p>
<p><strong><a href="../../topics/estimation-decision/">How Big Things Get Done</a></strong>（Flyvbjerg &amp; Gardner）處理的是這個位置躲不掉的承諾問題。它區分的兩個失準來源對這條路線特別重要，因為到這裡的所有估算都經過至少兩層轉述，每一層都有調整它的誘因——分不出手上這個數字失真在哪一層，加再多緩衝也押錯地方。兩個來源各是什麼、為什麼其中一個靠方法修不了，在主題篇。</p>
<p><strong><a href="../../topics/culture-safety/">The Fearless Organization</a></strong> 在這個位置讀出來的東西，跟直接帶人的人讀到的不同。這裡的問題是<strong>壞消息在兩層轉述中會不會被磨平</strong>——每一層都做了合理的摘要，而合理的摘要累積起來就是失真；自己的團隊敢不敢講是 <a href="../people/">對人負責</a> 那一篇的題目。</p>
<p><strong><a href="../../topics/team-design/">Quality Software Management, Vol. 4</a></strong>（Gerald Weinberg，繁中譯名《溫伯格的軟體管理學：擁抱變革》，四卷各自獨立、不必從第 1 卷讀起）處理推動組織轉變時的人的阻力，是這條路線上唯一一本把抗拒當資訊而不是當障礙的書。完整的性質判定與讀的時機在主題篇。</p>
<h2 id="想往哪裡走">想往哪裡走</h2>
<p>進到這個位置的方式通常是組織長大，而不是換了工作內容——原本帶的一個團隊裂成兩個，人就在這裡了。準備好的訊號是兩個團隊之間的事已經在處理：協調誰做哪一段、決定介面長什麼樣、被找去仲裁優先序。沒有這些累積就直接接下多團隊，最常見的結果是把時間全部花在其中一個團隊上，因為那是唯一熟悉的工作。</p>
<p>這個位置往上走，書能提供的比重快速下降。位置越高，同一個職稱在不同公司對應的實際工作差異越大，決定成敗的是這個組織的規模、產業與治理結構，而那些沒有通用解。</p>
<p>比較有用的方向是往深處而非往上：<strong><a href="../../topics/team-design/">Wiring the Winning Organization</a></strong> 嘗試解釋為什麼同樣的工作在某些組織裡很難、在另一些組織裡很簡單，適合手上已經有一批彼此不相干的做法、想找共同解釋的人。<strong><a href="../../topics/team-design/">Software Engineering at Google</a></strong> 提供的是規模與時間如何反轉工程判斷的具體案例，可以拿來校準自己組織的規模對應到哪些問題。</p>
<p>要把結構決定落到實際的評估動作，<a href="/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計</a> 提供的是把這類框架用在既有團隊上的判讀步驟。</p>
]]></content:encoded></item><item><title>留任、動機與工作環境</title><link>https://tarrragon.github.io/blog/books/software-management/topics/retention-motivation/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/retention-motivation/</guid><description>&lt;p>這個主題處理人留下來的條件。離職的原因通常被歸給薪資或機會，但研究一致指向另外兩層：工作環境是否讓人能專心把事做完，以及與直屬主管的關係是否讓人覺得自己被看見。這兩層都在管理者的控制範圍內，而且代價不對稱——環境與關係的損壞需要幾個月累積，修復需要更久，而一次資深工程師離職的成本遠高於任何環境投資。&lt;/p>
&lt;p>這個主題整批有一個共同前提：成員會待夠久，久到值得投資關係與環境。這條約束的完整說明（哪些情境會讓它不成立、不成立之後往哪走）在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的人員流動率那一項，選書前先確認自己踩不踩得到。&lt;/p>
&lt;p>前提成立的話，這個主題的書分成兩支，選書時先確認自己面對的是哪一支。環境支處理的是物理與制度條件：中斷、噪音、加班、流程負擔。關係支處理的是主管與部屬之間發生什麼：回饋怎麼給、才能怎麼配置、期望怎麼對齊。兩支的書幾乎不重疊。&lt;/p>
&lt;h2 id="起點是-peopleware">起點是 Peopleware&lt;/h2>
&lt;p>Tom DeMarco 與 Timothy Lister 的《Peopleware》一本收齊環境支的全部主題，後面兩本都只處理其中一支的一部分，因此起點是它。它 1987 年出版時的主張是軟體專案的主要問題是社會性的而非技術性的；這個立場現在聽起來像常識，但書中對中斷成本、辦公環境、團隊凝聚、離職代價的具體論證，後續的書多半引用它而少有更完整的處理。&lt;/p>
&lt;p>最可直接使用的是中斷成本的量化與 jelled team 的形成條件。前者把「開放式辦公室很吵」從抱怨變成可以算成本的事；後者（書中稱 jelled team，指一群人已經磨合到把團隊目標當成自己的目標、彼此的工作方式互相熟悉）說明凝聚的團隊有哪些可觀察特徵，以及哪些管理動作會把凝聚拆掉——包括加班、頻繁重組、以及用個人績效評比取代團隊成果。&lt;/p>
&lt;p>一本 1987 年的書會讓人先問哪些部分還算數。談實體辦公室隔間、電話中斷、通勤的段落，預設的工作型態已經改變，第三版新增的領導病理、會議文化與跨世代混合團隊章節補上了一部分；中斷成本、凝聚條件、離職代價這三條論證建立在注意力恢復與人際信任的累積上，不依賴辦公形式，因此仍然成立。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨客戶的顧問經驗加上他們自辦的編碼競賽資料，強度介於單一路徑的個人經驗與大規模實證之間——競賽樣本數以百計，不是大規模調查。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，環境那一半的論證以共處一個實體空間為單位：隔間、噪音、走過來打斷手上工作的那個人。分散在多個時區的團隊要自己把「中斷」重新定義成非同步訊息的回應期待（哪些論證會在這個換算裡失效，見 &lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>），而書裡沒有做這個轉換；凝聚那一半同樣預設每天有大量重疊時間。讀得出價值的前提標不出具體條件——待過任何一個辦公環境就讀得動，不需要先帶過人。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113">Amazon（Peopleware: Productive Projects and Teams, 3rd Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010872982">博客來（Peopleware：腦力密集產業的人才管理之道，經典紀念版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要用資料說服別人時讀-first-break-all-the-rules">要用資料說服別人時讀 First, Break All the Rules&lt;/h2>
&lt;p>Marcus Buckingham 與 Curt Coffman 的《First, Break All the Rules》建立在 Gallup 二十五年間、超過八萬名經理人的訪談與百萬名員工的調查上，證據規模是本篇最大的一本。核心發現是員工留任與績效的差異，主要由與直屬主管的關係決定，而非由公司整體政策決定。&lt;/p>
&lt;p>書中最反直覺的幾條主張都與傳統管理智慧相反：把時間花在表現最好的人身上而非最弱的人身上、依才能而非經驗聘用、定義正確的結果而非正確的步驟、以及不要試圖修補人的弱項而要重新配置角色。這些主張各自附有調查資料佐證，因此可以拿去支持實際的制度改變。&lt;/p>
&lt;p>沒有被選為起點的原因是涵蓋面：它集中在關係支，環境條件幾乎不談，讀完只有半張地圖。證據來源是大規模實證，形式是訪談與員工調查。時效上，資料採集期集中在 1990 年代；核心發現後續被 Gallup 的持續調查重複驗證。處境上，它的建議預設有制度可動——調薪、升遷、角色重新配置都要有對應的流程才執行得了，也預設每個人有一個穩定的直屬主管。約聘輪替、矩陣式雙線匯報與共同創辦人之間的關係都不在樣本裡，那些情境要讀的是它的核心發現而不是它的制度建議。繁體中文版是 2001 年的舊譯本。這本要帶過人才讀得出來，而且要處理過一次「這個人放在這個位置不對」。才能配置與訓練補強的差別，要有人選錯過位置才看得出來不是同一件事。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/First-Break-All-Rules-Differently/dp/0684852861">Amazon（First, Break All the Rules: What the World&amp;rsquo;s Greatest Managers Do Differently）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010120349">博客來（首先，打破成規：八萬名傑出經理人的共通特質）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="回饋給不出口時讀-radical-candor">回饋給不出口時讀 Radical Candor&lt;/h2>
&lt;p>Kim Scott 的《Radical Candor》處理關係支裡最具體的一環：怎麼在不傷害關係的前提下把難聽的話講出來。它的框架是兩個軸——個人關心與直接挑戰——兩軸交叉出四個象限，其中三個是失敗模式：只挑戰不關心是討人厭的侵略，只關心不挑戰是毀滅性同理，兩者皆無是操弄式虛偽。兩者兼具的那一格就是書名所指的徹底坦率。&lt;/p>
&lt;p>這個框架的作用是命名了最常見的那個失敗：多數管理者卡在毀滅性同理，因為不想破壞關係而讓問題累積，最後一次爆發時關係反而受更大傷害。有了名字之後，這個狀態才可以在當下被自己認出來。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗（作者在 Google 與 Apple 的任職）加上顧問案例，不是統計。範圍也窄——它處理回饋這一件事，不處理環境、才能配置或制度設計。時效上，修訂版補充了偏誤與權力差距的討論；它依賴的前提是主管與部屬會反覆互動，這件事沒有變。這本的時間窗窄，落在第一次負面回饋的前後：事前讀補的是語言，事後讀補的是診斷。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Radical-Candor-Revised-Kick-Ass-Humanity/dp/1250235375">Amazon（Radical Candor: Fully Revised &amp;amp; Updated Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010816772">博客來（徹底坦率：一種有溫度而真誠的領導）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>留任的解釋分成兩支，而這三本不是平均散在兩邊。環境支只有 Peopleware 一本，它是全面入門；關係支有兩本，First, Break All the Rules 給大規模實證，Radical Candor 只處理回饋這一個動作。後兩本層級不同：一個給制度依據，一個給當下的話術框架。&lt;/p>
&lt;p>動機與留任的書在商管書市數量龐大，多數建立在單一心理學理論的推廣上（自我決定論、心流、正向心理學）。它們共同的限制是把個人層級的心理機制直接放大到組織層級，而中間的推論步驟通常沒有被檢驗——翻參考文獻就分得出來：研究對象是個人任務的，跟研究對象是組織單位的，能支持的結論不同。&lt;/p>
&lt;p>Daniel Pink 的《Drive》常被列在這類書單，本書單未評估它對團隊層級制度設計的適用性。它整理的自主、精熟、目的三要素是清楚的框架，要的是理解動機的心理學基礎而非設計留任制度的話，那本是直接對應的書。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>人留下來的另一個條件是講真話不會受懲罰，那條路徑走 &lt;a href="../culture-safety/">組織文化與心理安全感&lt;/a>。回饋這件事的對話技術走 &lt;a href="../influence-conversation/">困難對話與無權限影響力&lt;/a>。&lt;/p>
&lt;p>如果離職集中在特定團隊、而那個團隊的工作範圍明顯超載，問題可能在結構而非管理，走 &lt;a href="../team-design/">組織結構與團隊設計&lt;/a>——認知負荷上限那一段直接處理這個情況。&lt;/p>
&lt;p>這個主題寫給動得了環境的人。身在環境裡、而環境短期不會改變時，要處理的是流進來的量怎麼被一個人接住，走 &lt;a href="../personal-workflow/">個人工作流與工作負荷&lt;/a>。&lt;/p>
&lt;p>第一次要對人負責、想知道這個位置整體要做什麼，走 &lt;a href="../role-transitions/">角色轉換與職涯路徑&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理人留下來的條件。離職的原因通常被歸給薪資或機會，但研究一致指向另外兩層：工作環境是否讓人能專心把事做完，以及與直屬主管的關係是否讓人覺得自己被看見。這兩層都在管理者的控制範圍內，而且代價不對稱——環境與關係的損壞需要幾個月累積，修復需要更久，而一次資深工程師離職的成本遠高於任何環境投資。</p>
<p>這個主題整批有一個共同前提：成員會待夠久，久到值得投資關係與環境。這條約束的完整說明（哪些情境會讓它不成立、不成立之後往哪走）在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的人員流動率那一項，選書前先確認自己踩不踩得到。</p>
<p>前提成立的話，這個主題的書分成兩支，選書時先確認自己面對的是哪一支。環境支處理的是物理與制度條件：中斷、噪音、加班、流程負擔。關係支處理的是主管與部屬之間發生什麼：回饋怎麼給、才能怎麼配置、期望怎麼對齊。兩支的書幾乎不重疊。</p>
<h2 id="起點是-peopleware">起點是 Peopleware</h2>
<p>Tom DeMarco 與 Timothy Lister 的《Peopleware》一本收齊環境支的全部主題，後面兩本都只處理其中一支的一部分，因此起點是它。它 1987 年出版時的主張是軟體專案的主要問題是社會性的而非技術性的；這個立場現在聽起來像常識，但書中對中斷成本、辦公環境、團隊凝聚、離職代價的具體論證，後續的書多半引用它而少有更完整的處理。</p>
<p>最可直接使用的是中斷成本的量化與 jelled team 的形成條件。前者把「開放式辦公室很吵」從抱怨變成可以算成本的事；後者（書中稱 jelled team，指一群人已經磨合到把團隊目標當成自己的目標、彼此的工作方式互相熟悉）說明凝聚的團隊有哪些可觀察特徵，以及哪些管理動作會把凝聚拆掉——包括加班、頻繁重組、以及用個人績效評比取代團隊成果。</p>
<p>一本 1987 年的書會讓人先問哪些部分還算數。談實體辦公室隔間、電話中斷、通勤的段落，預設的工作型態已經改變，第三版新增的領導病理、會議文化與跨世代混合團隊章節補上了一部分；中斷成本、凝聚條件、離職代價這三條論證建立在注意力恢復與人際信任的累積上，不依賴辦公形式，因此仍然成立。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨客戶的顧問經驗加上他們自辦的編碼競賽資料，強度介於單一路徑的個人經驗與大規模實證之間——競賽樣本數以百計，不是大規模調查。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，環境那一半的論證以共處一個實體空間為單位：隔間、噪音、走過來打斷手上工作的那個人。分散在多個時區的團隊要自己把「中斷」重新定義成非同步訊息的回應期待（哪些論證會在這個換算裡失效，見 <a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a>），而書裡沒有做這個轉換；凝聚那一半同樣預設每天有大量重疊時間。讀得出價值的前提標不出具體條件——待過任何一個辦公環境就讀得動，不需要先帶過人。</p>
<ul>
<li><a href="https://www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113">Amazon（Peopleware: Productive Projects and Teams, 3rd Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010872982">博客來（Peopleware：腦力密集產業的人才管理之道，經典紀念版）</a></li>
</ul>
<h2 id="要用資料說服別人時讀-first-break-all-the-rules">要用資料說服別人時讀 First, Break All the Rules</h2>
<p>Marcus Buckingham 與 Curt Coffman 的《First, Break All the Rules》建立在 Gallup 二十五年間、超過八萬名經理人的訪談與百萬名員工的調查上，證據規模是本篇最大的一本。核心發現是員工留任與績效的差異，主要由與直屬主管的關係決定，而非由公司整體政策決定。</p>
<p>書中最反直覺的幾條主張都與傳統管理智慧相反：把時間花在表現最好的人身上而非最弱的人身上、依才能而非經驗聘用、定義正確的結果而非正確的步驟、以及不要試圖修補人的弱項而要重新配置角色。這些主張各自附有調查資料佐證，因此可以拿去支持實際的制度改變。</p>
<p>沒有被選為起點的原因是涵蓋面：它集中在關係支，環境條件幾乎不談，讀完只有半張地圖。證據來源是大規模實證，形式是訪談與員工調查。時效上，資料採集期集中在 1990 年代；核心發現後續被 Gallup 的持續調查重複驗證。處境上，它的建議預設有制度可動——調薪、升遷、角色重新配置都要有對應的流程才執行得了，也預設每個人有一個穩定的直屬主管。約聘輪替、矩陣式雙線匯報與共同創辦人之間的關係都不在樣本裡，那些情境要讀的是它的核心發現而不是它的制度建議。繁體中文版是 2001 年的舊譯本。這本要帶過人才讀得出來，而且要處理過一次「這個人放在這個位置不對」。才能配置與訓練補強的差別，要有人選錯過位置才看得出來不是同一件事。</p>
<ul>
<li><a href="https://www.amazon.com/First-Break-All-Rules-Differently/dp/0684852861">Amazon（First, Break All the Rules: What the World&rsquo;s Greatest Managers Do Differently）</a></li>
<li><a href="https://www.books.com.tw/products/0010120349">博客來（首先，打破成規：八萬名傑出經理人的共通特質）</a></li>
</ul>
<h2 id="回饋給不出口時讀-radical-candor">回饋給不出口時讀 Radical Candor</h2>
<p>Kim Scott 的《Radical Candor》處理關係支裡最具體的一環：怎麼在不傷害關係的前提下把難聽的話講出來。它的框架是兩個軸——個人關心與直接挑戰——兩軸交叉出四個象限，其中三個是失敗模式：只挑戰不關心是討人厭的侵略，只關心不挑戰是毀滅性同理，兩者皆無是操弄式虛偽。兩者兼具的那一格就是書名所指的徹底坦率。</p>
<p>這個框架的作用是命名了最常見的那個失敗：多數管理者卡在毀滅性同理，因為不想破壞關係而讓問題累積，最後一次爆發時關係反而受更大傷害。有了名字之後，這個狀態才可以在當下被自己認出來。</p>
<p>證據來源是單一路徑的個人經驗（作者在 Google 與 Apple 的任職）加上顧問案例，不是統計。範圍也窄——它處理回饋這一件事，不處理環境、才能配置或制度設計。時效上，修訂版補充了偏誤與權力差距的討論；它依賴的前提是主管與部屬會反覆互動，這件事沒有變。這本的時間窗窄，落在第一次負面回饋的前後：事前讀補的是語言，事後讀補的是診斷。</p>
<ul>
<li><a href="https://www.amazon.com/Radical-Candor-Revised-Kick-Ass-Humanity/dp/1250235375">Amazon（Radical Candor: Fully Revised &amp; Updated Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010816772">博客來（徹底坦率：一種有溫度而真誠的領導）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>留任的解釋分成兩支，而這三本不是平均散在兩邊。環境支只有 Peopleware 一本，它是全面入門；關係支有兩本，First, Break All the Rules 給大規模實證，Radical Candor 只處理回饋這一個動作。後兩本層級不同：一個給制度依據，一個給當下的話術框架。</p>
<p>動機與留任的書在商管書市數量龐大，多數建立在單一心理學理論的推廣上（自我決定論、心流、正向心理學）。它們共同的限制是把個人層級的心理機制直接放大到組織層級，而中間的推論步驟通常沒有被檢驗——翻參考文獻就分得出來：研究對象是個人任務的，跟研究對象是組織單位的，能支持的結論不同。</p>
<p>Daniel Pink 的《Drive》常被列在這類書單，本書單未評估它對團隊層級制度設計的適用性。它整理的自主、精熟、目的三要素是清楚的框架，要的是理解動機的心理學基礎而非設計留任制度的話，那本是直接對應的書。</p>
<p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>人留下來的另一個條件是講真話不會受懲罰，那條路徑走 <a href="../culture-safety/">組織文化與心理安全感</a>。回饋這件事的對話技術走 <a href="../influence-conversation/">困難對話與無權限影響力</a>。</p>
<p>如果離職集中在特定團隊、而那個團隊的工作範圍明顯超載，問題可能在結構而非管理，走 <a href="../team-design/">組織結構與團隊設計</a>——認知負荷上限那一段直接處理這個情況。</p>
<p>這個主題寫給動得了環境的人。身在環境裡、而環境短期不會改變時，要處理的是流進來的量怎麼被一個人接住，走 <a href="../personal-workflow/">個人工作流與工作負荷</a>。</p>
<p>第一次要對人負責、想知道這個位置整體要做什麼，走 <a href="../role-transitions/">角色轉換與職涯路徑</a>。</p>
]]></content:encoded></item><item><title>個人工作流與工作負荷</title><link>https://tarrragon.github.io/blog/books/software-management/topics/personal-workflow/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/personal-workflow/</guid><description>&lt;p>這個主題處理流進來的工作怎麼被一個人接住：承諾記在哪裡、下一步是什麼、什麼時候該承認做不完。它落在 &lt;a href="../../../craft/">工程技藝&lt;/a> 與本線的交界：一個人獨自面對整個組織丟過來的量——決定的對象既不是產物，也不完全是人與制度。&lt;/p>
&lt;p>三本書對同一種體感給出三種診斷，而它們分歧的是&lt;strong>問題落在哪一層&lt;/strong>，不是做法。Allen 認為問題在個人層，把所有承諾外部化就能解決；Newport 認為層級錯了，決定工作量與節奏的協議在組織層，個人再怎麼優化都只是把自己處理得更快；Burkeman 認為目標錯了，「全部做完」這個狀態不存在，因為處理事情本身會製造更多事情。&lt;/p>
&lt;p>選書的第一個動作因此是判斷自己的處境屬於哪一層，而判斷的材料就在下面三節各自的「讀得出價值的前提」那一句：承諾量已經超過記得住的範圍、而且漏掉過其中一項，是個人層；能改變至少一個小組的協作方式，是組織層；試過至少一套系統、系統運作良好而清單仍然變長，是目標層。三個診斷可以同時成立，但投入的順序不同，花掉的時間差很多。&lt;/p>
&lt;h2 id="起點是-getting-things-done">起點是 Getting Things Done&lt;/h2>
&lt;p>David Allen 這本把一個人處理工作的整條管線都給了名字與步驟：收集、釐清、整理、回顧、執行。五個步驟從入口蓋到出口，中間沒有留白，本篇最完整的一本因此是它。另外兩本的批評需要這套座標才有對象——它們針對的正是這條管線被要求承擔的位置。&lt;/p>
&lt;p>書的核心診斷是壓力的來源。未完成的承諾佔用著大腦，而大腦是很差的儲存裝置：提醒隨機發生、不挑處理得了的時機，而且不附帶「現在做不做得了」這個資訊。解法是把每一項承諾移到一個自己信得過的外部系統。信得過是關鍵字——系統只要漏掉過一項，大腦就會恢復自己記，整套設計的效果隨之歸零。&lt;/p>
&lt;p>最可操作的是下一步行動這個定義：一項待辦要寫到「下一個實體動作是什麼」的粒度。「處理保險的事」不是行動，「打電話給某某問理賠文件要哪幾份」才是。這條規則把拖延從意志問題換成定義問題——Allen 的觀察是卡住的項目多半還沒被想清楚到可以動手，而不是難。&lt;/p>
&lt;p>這套系統的失效點集中在每週回顧。它是整套設計裡唯一讓清單與現實重新對齊的環節，斷掉之後清單開始靜默失真——上面的項目還在，但它們對應的狀況已經變了，沒有任何一步會把這件事指出來。清單失真到一定程度，人就不再相信它。判斷自己適不適合這套方法，看的是能不能穩定維持這一項，而不是能不能接受那五個步驟。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨客戶的顧問經驗，形式是三十多年的一對一教練，而這個形態值得單獨說明。Allen 從 1980 年代 Lockheed 的人資部門開始做顧問，長年替大型企業的主管做一對一教練，1996 年創立自己的顧問公司。他跟大組織的接觸全部是從外部進去、對著個人工作的，從沒在裡面當過那個要對交付結果負責的人。這解釋得了書的邊界：工作量從哪來、優先序誰決定、誰有權說不，這些不在書裡，因為在教練的觀察位置上看不見。&lt;/p>
&lt;p>另有一篇學術文獻常被當成這本書的背書，需要分清它證明了什麼。Heylighen 與 Vidal 2008 年在《Long Range Planning》用分散式認知與具身認知的研究論證 GTD 的做法與認知科學相容——那是機制上的相容，不是效果的量測。整套方法的效果目前找不到嚴謹的對照研究。&lt;/p>
&lt;p>時效上，2015 修訂版依作者自述更新的是工具舉例與術語，五個步驟的骨架沿用。處境上最需要知道的一項是它對自主權的假設：全套設計預設「收件匣是自己控制得了的」。2001 年的知識工作者大致成立，而現在有相當比例的工作是被指派進共用待辦、在群組頻道裡被喊住的，那些工作不經過任何一個屬於個人的入口。這是改版沒有處理的缺口。&lt;/p>
&lt;p>讀得出價值的前提是：手上同時有超過一個人記得住的承諾量，而且已經漏掉過其中一項。承諾量還在腦子裝得下的範圍時，維護這套系統的成本高於它省下的。繁體中文版《搞定！工作效率大師教你：事情再多照樣做好的搞定5步驟》，商業周刊出版、向名惠與林淑鈴譯，譯自 2015 修訂版。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0143126563">Amazon（Getting Things Done: The Art of Stress-Free Productivity, 2015 revised edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010731198">博客來（搞定！工作效率大師教你：事情再多照樣做好的搞定5步驟）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="系統做對了而事情還是做不完時讀-a-world-without-email">系統做對了而事情還是做不完時讀 A World Without Email&lt;/h2>
&lt;p>Cal Newport 這本處理的是前一本假設不存在的那一層：工作怎麼被指派、審查、排序。他的觀察是知識工作在這一層沒有協議——公司給目標、給文化，講到事情實際怎麼流動，做法是把所有人接上 email 與即時通訊，剩下自己想辦法。他給這個預設模式的名字是過動的蜂巢思維（hyperactive hive mind）：所有協調靠隨時發生、無結構的訊息往返完成。&lt;/p>
&lt;p>這本書跟 GTD 的關係要講清楚，因為它常被誤讀成攻擊。Newport 明確表示他欣賞 Allen 的系統，他要指出的是那套系統被要求承擔的位置不對。個人層的優化改變的是自己處理事情的速度；流進來的量與順序沒有動——跑得快的獎賞是分到更多。他在 2020 年《The New Yorker》那篇〈The Rise and Fall of Getting Things Done〉裡用 Merlin Mann 的軌跡說明這件事：GTD 最大的推廣者最後放棄了整套實踐，而那不是意志力的問題。&lt;/p>
&lt;p>建設性的那一半是把工作流當成可以設計的對象。注意力資本理論的主張是知識工作的產出取決於注意力怎麼被配置，多數組織卻從沒對這件事做過任何決定；工作流協議則是把「這類事情怎麼流動」明文化——誰在什麼條件下把什麼交給誰、用什麼形式、多久回應一次。這一層的每個決定都可以被討論與修改，而蜂巢思維的問題正在於它沒有被任何人決定過，它只是預設值。&lt;/p>
&lt;p>證據來源是跨組織案例加上理論建構（產業史類比與注意力研究的整合），形式是論證而非統計。時效上，2021 年出版，遠距與&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">非同步協作&lt;/a>普及之後它的問題描述更貼近而不是更遠。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，它預設讀的人至少改變得了一個小組的協作方式。讀得出價值的前提也建立在那件事上；純粹的個人貢獻者讀完得到的是一個準確的診斷跟一組動不了的處方，而那個診斷本身仍然有用——它讓人停止把結構問題當成自己的效率問題。繁體中文版《沒有Email的世界：過度溝通時代的深度工作法》，時報出版、蕭美惠譯。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/World-Without-Email-Reimagining-Communication/dp/0525536558">Amazon（A World Without Email: Reimagining Work in an Age of Communication Overload）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010905956">博客來（沒有Email的世界：過度溝通時代的深度工作法）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="對全部做完這個目標存疑時讀-four-thousand-weeks">對「全部做完」這個目標存疑時讀 Four Thousand Weeks&lt;/h2>
&lt;p>Oliver Burkeman 這本挑戰的是另外兩本共有的前提：存在一個「處理完了」的狀態，而方法的任務是把人帶到那裡。他的主張是那個狀態不存在，而理由在結構、不在效率——處理事情本身會製造更多事情，收件匣清空的獎賞是更多郵件被寄進來，而能力提升會讓自己與別人同步提高期望。&lt;/p>
&lt;p>書名來自一個算術：活到八十歲大約是四千個禮拜。這個數字的用途是把時間管理從最佳化問題換成取捨問題。若時間本來就裝不下所有值得做的事，那麼「怎麼塞得更多」是錯的問題，「決定放棄什麼」才是。&lt;/p>
&lt;p>它在本篇的位置是把前兩本的失敗解釋完。GTD 使用者的典型結局是系統維護得越好、進來的工作越多；Newport 說明了那為什麼不是個人的錯；Burkeman 說明了就算組織層的協議修好了，那個「終於處理完」的感覺仍然不會來。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗加上理論建構（哲學與歷史論述、心理學研究的整合），形式接近長篇隨筆——作者是《衛報》長年寫這個題目的專欄作者。這使它給不出可以照做的步驟，它改變的是判準而非流程。時效上，2021 年出版，論述沒有綁定任何工具或組織形式。讀得出價值的前提很具體：試過至少一套生產力系統，而且經歷過系統運作良好但清單仍然變長。沒有那段經歷時，這本書讀起來像在勸人放棄。繁體中文版《人生4千個禮拜：時間不是用來掌控的，直面「生命的有限」，打造游刃有餘的時間運用觀》，大塊文化出版、許恬寧譯。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Four-Thousand-Weeks-Management-Mortals/dp/0374159122">Amazon（Four Thousand Weeks: Time Management for Mortals）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010914255">博客來（人生4千個禮拜）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>三本按診斷的層級排：個人的系統（Allen）、組織的工作流協議（Newport）、目標本身的可達成性（Burkeman）。這三本是同一種體感在三個高度上的解釋，不是三種做法在競爭，因此疊著用比擇一有效。順序倒過來走有代價：先讀 Burkeman 的人容易把它讀成放棄的許可，那本要有前兩層的失敗經驗當底才讀得對。&lt;/p>
&lt;p>時間管理的書市極擁擠，多數集中在單一技巧的推廣（番茄鐘、時間箱、某某矩陣）。那類的共同限制是技巧脫離了它假設的處境——同一套方法給一個能決定自己排程的人是有效，給一個整天被會議切碎的人是製造新的挫折，差別不在程度。分辨方法是看它有沒有說這套做法需要什麼條件才成立。&lt;/p>
&lt;p>Cal Newport 的《Deep Work》常被列在這個位置，這裡按角色重疊排除。它跟這裡收的《A World Without Email》是同一位作者的兩個階段，而後者明確修正了前者留下的個人層樂觀，兩本並收會在同一個主題裡放兩份重疊的說明。要讀那一本的話值得知道它成書於作者把問題改判到組織層之前。&lt;/p>
&lt;p>Nir Eyal 的《Indistractable》與 James Clear 的《Atomic Habits》也常出現在這類清單，這裡按不同軸排除：它們處理的是習慣養成與衝動控制，而這個主題要回答的是流進來的工作怎麼被接住、那是誰的問題。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而缺的不是數量：以它為名的課很多，內容集中在技巧演練與商業培訓，跨不過本質恆定那一條。它要的機制（注意力與習慣形成）在鄰近學科有課，只是這一輪沒有拿那組詞去搜。整條線的供給狀況與那個換法寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>有多少負擔其實來自環境而不是自己的方法，Peopleware 那本有具體論證，走 &lt;a href="../retention-motivation/">留任、動機與工作環境&lt;/a>。那本跟這裡三本的差別在誰動得了：那本寫給能改變環境的人，這裡寫給身在環境裡的人。&lt;/p>
&lt;p>判斷結果若是問題確實在組織層，接下來要動的若是團隊之間怎麼交接、認知負荷到哪算滿，走 &lt;a href="../team-design/">組織結構與團隊設計&lt;/a>；要動的若是承諾怎麼被定下來，走 &lt;a href="../estimation-decision/">估算、承諾與決策偏誤&lt;/a>。要把工作流的改變推給一個自己管不到的團隊，走 &lt;a href="../influence-conversation/">困難對話與無權限影響力&lt;/a>。&lt;/p>
&lt;p>判定落在組織層、而自己連一個小組的協作方式都動不了時，這一篇的出口就到這裡為止：這三本沒有一本能讓沒有槓桿的人改變工作怎麼流進來。剩下的是那個診斷本身，而它改變兩件事——要不要繼續把時間投在優化個人系統上，以及換工作面談時該問對方哪些問題。&lt;/p>
&lt;p>工作流協議要改的常常是會議與訊息往返本身，那一組工具在 &lt;a href="../meeting-facilitation/">會議引導與群體決策&lt;/a>。如果卡住的地方是每次都在做別人切錯的需求，那不是工作量問題，走 &lt;a href="../problem-definition/">問題定義與系統思考&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理流進來的工作怎麼被一個人接住：承諾記在哪裡、下一步是什麼、什麼時候該承認做不完。它落在 <a href="../../../craft/">工程技藝</a> 與本線的交界：一個人獨自面對整個組織丟過來的量——決定的對象既不是產物，也不完全是人與制度。</p>
<p>三本書對同一種體感給出三種診斷，而它們分歧的是<strong>問題落在哪一層</strong>，不是做法。Allen 認為問題在個人層，把所有承諾外部化就能解決；Newport 認為層級錯了，決定工作量與節奏的協議在組織層，個人再怎麼優化都只是把自己處理得更快；Burkeman 認為目標錯了，「全部做完」這個狀態不存在，因為處理事情本身會製造更多事情。</p>
<p>選書的第一個動作因此是判斷自己的處境屬於哪一層，而判斷的材料就在下面三節各自的「讀得出價值的前提」那一句：承諾量已經超過記得住的範圍、而且漏掉過其中一項，是個人層；能改變至少一個小組的協作方式，是組織層；試過至少一套系統、系統運作良好而清單仍然變長，是目標層。三個診斷可以同時成立，但投入的順序不同，花掉的時間差很多。</p>
<h2 id="起點是-getting-things-done">起點是 Getting Things Done</h2>
<p>David Allen 這本把一個人處理工作的整條管線都給了名字與步驟：收集、釐清、整理、回顧、執行。五個步驟從入口蓋到出口，中間沒有留白，本篇最完整的一本因此是它。另外兩本的批評需要這套座標才有對象——它們針對的正是這條管線被要求承擔的位置。</p>
<p>書的核心診斷是壓力的來源。未完成的承諾佔用著大腦，而大腦是很差的儲存裝置：提醒隨機發生、不挑處理得了的時機，而且不附帶「現在做不做得了」這個資訊。解法是把每一項承諾移到一個自己信得過的外部系統。信得過是關鍵字——系統只要漏掉過一項，大腦就會恢復自己記，整套設計的效果隨之歸零。</p>
<p>最可操作的是下一步行動這個定義：一項待辦要寫到「下一個實體動作是什麼」的粒度。「處理保險的事」不是行動，「打電話給某某問理賠文件要哪幾份」才是。這條規則把拖延從意志問題換成定義問題——Allen 的觀察是卡住的項目多半還沒被想清楚到可以動手，而不是難。</p>
<p>這套系統的失效點集中在每週回顧。它是整套設計裡唯一讓清單與現實重新對齊的環節，斷掉之後清單開始靜默失真——上面的項目還在，但它們對應的狀況已經變了，沒有任何一步會把這件事指出來。清單失真到一定程度，人就不再相信它。判斷自己適不適合這套方法，看的是能不能穩定維持這一項，而不是能不能接受那五個步驟。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨客戶的顧問經驗，形式是三十多年的一對一教練，而這個形態值得單獨說明。Allen 從 1980 年代 Lockheed 的人資部門開始做顧問，長年替大型企業的主管做一對一教練，1996 年創立自己的顧問公司。他跟大組織的接觸全部是從外部進去、對著個人工作的，從沒在裡面當過那個要對交付結果負責的人。這解釋得了書的邊界：工作量從哪來、優先序誰決定、誰有權說不，這些不在書裡，因為在教練的觀察位置上看不見。</p>
<p>另有一篇學術文獻常被當成這本書的背書，需要分清它證明了什麼。Heylighen 與 Vidal 2008 年在《Long Range Planning》用分散式認知與具身認知的研究論證 GTD 的做法與認知科學相容——那是機制上的相容，不是效果的量測。整套方法的效果目前找不到嚴謹的對照研究。</p>
<p>時效上，2015 修訂版依作者自述更新的是工具舉例與術語，五個步驟的骨架沿用。處境上最需要知道的一項是它對自主權的假設：全套設計預設「收件匣是自己控制得了的」。2001 年的知識工作者大致成立，而現在有相當比例的工作是被指派進共用待辦、在群組頻道裡被喊住的，那些工作不經過任何一個屬於個人的入口。這是改版沒有處理的缺口。</p>
<p>讀得出價值的前提是：手上同時有超過一個人記得住的承諾量，而且已經漏掉過其中一項。承諾量還在腦子裝得下的範圍時，維護這套系統的成本高於它省下的。繁體中文版《搞定！工作效率大師教你：事情再多照樣做好的搞定5步驟》，商業周刊出版、向名惠與林淑鈴譯，譯自 2015 修訂版。</p>
<ul>
<li><a href="https://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0143126563">Amazon（Getting Things Done: The Art of Stress-Free Productivity, 2015 revised edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010731198">博客來（搞定！工作效率大師教你：事情再多照樣做好的搞定5步驟）</a></li>
</ul>
<h2 id="系統做對了而事情還是做不完時讀-a-world-without-email">系統做對了而事情還是做不完時讀 A World Without Email</h2>
<p>Cal Newport 這本處理的是前一本假設不存在的那一層：工作怎麼被指派、審查、排序。他的觀察是知識工作在這一層沒有協議——公司給目標、給文化，講到事情實際怎麼流動，做法是把所有人接上 email 與即時通訊，剩下自己想辦法。他給這個預設模式的名字是過動的蜂巢思維（hyperactive hive mind）：所有協調靠隨時發生、無結構的訊息往返完成。</p>
<p>這本書跟 GTD 的關係要講清楚，因為它常被誤讀成攻擊。Newport 明確表示他欣賞 Allen 的系統，他要指出的是那套系統被要求承擔的位置不對。個人層的優化改變的是自己處理事情的速度；流進來的量與順序沒有動——跑得快的獎賞是分到更多。他在 2020 年《The New Yorker》那篇〈The Rise and Fall of Getting Things Done〉裡用 Merlin Mann 的軌跡說明這件事：GTD 最大的推廣者最後放棄了整套實踐，而那不是意志力的問題。</p>
<p>建設性的那一半是把工作流當成可以設計的對象。注意力資本理論的主張是知識工作的產出取決於注意力怎麼被配置，多數組織卻從沒對這件事做過任何決定；工作流協議則是把「這類事情怎麼流動」明文化——誰在什麼條件下把什麼交給誰、用什麼形式、多久回應一次。這一層的每個決定都可以被討論與修改，而蜂巢思維的問題正在於它沒有被任何人決定過，它只是預設值。</p>
<p>證據來源是跨組織案例加上理論建構（產業史類比與注意力研究的整合），形式是論證而非統計。時效上，2021 年出版，遠距與<a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">非同步協作</a>普及之後它的問題描述更貼近而不是更遠。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，它預設讀的人至少改變得了一個小組的協作方式。讀得出價值的前提也建立在那件事上；純粹的個人貢獻者讀完得到的是一個準確的診斷跟一組動不了的處方，而那個診斷本身仍然有用——它讓人停止把結構問題當成自己的效率問題。繁體中文版《沒有Email的世界：過度溝通時代的深度工作法》，時報出版、蕭美惠譯。</p>
<ul>
<li><a href="https://www.amazon.com/World-Without-Email-Reimagining-Communication/dp/0525536558">Amazon（A World Without Email: Reimagining Work in an Age of Communication Overload）</a></li>
<li><a href="https://www.books.com.tw/products/0010905956">博客來（沒有Email的世界：過度溝通時代的深度工作法）</a></li>
</ul>
<h2 id="對全部做完這個目標存疑時讀-four-thousand-weeks">對「全部做完」這個目標存疑時讀 Four Thousand Weeks</h2>
<p>Oliver Burkeman 這本挑戰的是另外兩本共有的前提：存在一個「處理完了」的狀態，而方法的任務是把人帶到那裡。他的主張是那個狀態不存在，而理由在結構、不在效率——處理事情本身會製造更多事情，收件匣清空的獎賞是更多郵件被寄進來，而能力提升會讓自己與別人同步提高期望。</p>
<p>書名來自一個算術：活到八十歲大約是四千個禮拜。這個數字的用途是把時間管理從最佳化問題換成取捨問題。若時間本來就裝不下所有值得做的事，那麼「怎麼塞得更多」是錯的問題，「決定放棄什麼」才是。</p>
<p>它在本篇的位置是把前兩本的失敗解釋完。GTD 使用者的典型結局是系統維護得越好、進來的工作越多；Newport 說明了那為什麼不是個人的錯；Burkeman 說明了就算組織層的協議修好了，那個「終於處理完」的感覺仍然不會來。</p>
<p>證據來源是單一路徑的個人經驗加上理論建構（哲學與歷史論述、心理學研究的整合），形式接近長篇隨筆——作者是《衛報》長年寫這個題目的專欄作者。這使它給不出可以照做的步驟，它改變的是判準而非流程。時效上，2021 年出版，論述沒有綁定任何工具或組織形式。讀得出價值的前提很具體：試過至少一套生產力系統，而且經歷過系統運作良好但清單仍然變長。沒有那段經歷時，這本書讀起來像在勸人放棄。繁體中文版《人生4千個禮拜：時間不是用來掌控的，直面「生命的有限」，打造游刃有餘的時間運用觀》，大塊文化出版、許恬寧譯。</p>
<ul>
<li><a href="https://www.amazon.com/Four-Thousand-Weeks-Management-Mortals/dp/0374159122">Amazon（Four Thousand Weeks: Time Management for Mortals）</a></li>
<li><a href="https://www.books.com.tw/products/0010914255">博客來（人生4千個禮拜）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>三本按診斷的層級排：個人的系統（Allen）、組織的工作流協議（Newport）、目標本身的可達成性（Burkeman）。這三本是同一種體感在三個高度上的解釋，不是三種做法在競爭，因此疊著用比擇一有效。順序倒過來走有代價：先讀 Burkeman 的人容易把它讀成放棄的許可，那本要有前兩層的失敗經驗當底才讀得對。</p>
<p>時間管理的書市極擁擠，多數集中在單一技巧的推廣（番茄鐘、時間箱、某某矩陣）。那類的共同限制是技巧脫離了它假設的處境——同一套方法給一個能決定自己排程的人是有效，給一個整天被會議切碎的人是製造新的挫折，差別不在程度。分辨方法是看它有沒有說這套做法需要什麼條件才成立。</p>
<p>Cal Newport 的《Deep Work》常被列在這個位置，這裡按角色重疊排除。它跟這裡收的《A World Without Email》是同一位作者的兩個階段，而後者明確修正了前者留下的個人層樂觀，兩本並收會在同一個主題裡放兩份重疊的說明。要讀那一本的話值得知道它成書於作者把問題改判到組織層之前。</p>
<p>Nir Eyal 的《Indistractable》與 James Clear 的《Atomic Habits》也常出現在這類清單，這裡按不同軸排除：它們處理的是習慣養成與衝動控制，而這個主題要回答的是流進來的工作怎麼被接住、那是誰的問題。</p>
<p>這個主題沒查到可以收的公開課，而缺的不是數量：以它為名的課很多，內容集中在技巧演練與商業培訓，跨不過本質恆定那一條。它要的機制（注意力與習慣形成）在鄰近學科有課，只是這一輪沒有拿那組詞去搜。整條線的供給狀況與那個換法寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>有多少負擔其實來自環境而不是自己的方法，Peopleware 那本有具體論證，走 <a href="../retention-motivation/">留任、動機與工作環境</a>。那本跟這裡三本的差別在誰動得了：那本寫給能改變環境的人，這裡寫給身在環境裡的人。</p>
<p>判斷結果若是問題確實在組織層，接下來要動的若是團隊之間怎麼交接、認知負荷到哪算滿，走 <a href="../team-design/">組織結構與團隊設計</a>；要動的若是承諾怎麼被定下來，走 <a href="../estimation-decision/">估算、承諾與決策偏誤</a>。要把工作流的改變推給一個自己管不到的團隊，走 <a href="../influence-conversation/">困難對話與無權限影響力</a>。</p>
<p>判定落在組織層、而自己連一個小組的協作方式都動不了時，這一篇的出口就到這裡為止：這三本沒有一本能讓沒有槓桿的人改變工作怎麼流進來。剩下的是那個診斷本身，而它改變兩件事——要不要繼續把時間投在優化個人系統上，以及換工作面談時該問對方哪些問題。</p>
<p>工作流協議要改的常常是會議與訊息往返本身，那一組工具在 <a href="../meeting-facilitation/">會議引導與群體決策</a>。如果卡住的地方是每次都在做別人切錯的需求，那不是工作量問題，走 <a href="../problem-definition/">問題定義與系統思考</a>。</p>
]]></content:encoded></item><item><title>估算、承諾與決策偏誤</title><link>https://tarrragon.github.io/blog/books/software-management/topics/estimation-decision/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/estimation-decision/</guid><description>&lt;p>估算失準有兩個來源，需要用完全不同的方法處理。第一個是樂觀偏誤：估算的人真心低估，因為人傾向從內部細節推導，而細節推導系統性地漏掉未知項。第二個是策略性虛報：知道會超支，但講實話案子就過不了，因此低報是理性選擇。前者靠方法修正，後者靠方法修不了——它是誘因結構的產物，要改變它必須先改變「講實話會發生什麼事」。&lt;/p>
&lt;p>把這兩者分開是這個主題的核心價值。多數組織的估算改善措施只處理第一層，於是導入了更精細的估算流程、卻得到同樣失準的數字，因為真正在運作的是第二層。&lt;/p>
&lt;p>讀不動長篇文字時，本篇文末另標出承接第二層的公開課，收錄門檻與已知限制見 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。&lt;/p>
&lt;h2 id="起點是-how-big-things-get-done">起點是 How Big Things Get Done&lt;/h2>
&lt;p>Bent Flyvbjerg 與 Dan Gardner 的《How Big Things Get Done》同時涵蓋上述兩層來源並且明確區分兩者，證據規模也是本篇最大的一本，資料庫涵蓋上萬件大型專案的實際成本與時程。&lt;/p>
&lt;p>最可直接使用的是參考組預測法：不從內部細節推估，而是找同類專案的歷史實際數字，用分布而非單點來預測。這個方法之所以有效，是因為它繞過了細節推導這個偏誤來源本身，而不是試圖讓細節推導更準。&lt;/p>
&lt;p>另一條主線是「慢想快做」：規劃階段盡量長、盡量多次修改設計，執行階段盡量短。理由是規劃階段的修改幾乎免費、執行階段的修改極貴。這條原則與軟體業「盡早交付、快速迭代」的直覺表面衝突，實際處理的是不同性質的專案——可逆的實驗適合快速迭代，不可逆的大型投入適合慢想快做。判斷手上這件事屬於哪一類，是使用這條原則的前提。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是大規模實證，形式是跨產業的歷史成本資料庫，強度足以支持預算與時程的實際決定。時效上，資料庫的專案類型以基建、能源與 IT 大型導入為主，軟體團隊常見的小型迭代不在樣本裡；樂觀偏誤與策略性虛報的區分建立在決策者的資訊與誘因結構上，不依賴專案規模。讀得出價值的前提幾乎沒有，但案例以基建與大型工程為主，軟體的轉譯要自己做。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/How-Big-Things-Get-Done/dp/0593239512">Amazon（How Big Things Get Done）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010986409">博客來（超級專案管理：牛津大學教授揭示計畫成敗的法則）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要處理軟體專案的風險時讀-waltzing-with-bears">要處理軟體專案的風險時讀 Waltzing with Bears&lt;/h2>
&lt;p>Tom DeMarco 與 Timothy Lister 的《Waltzing with Bears》是這個主題唯一針對軟體專案寫的一本。核心主張分兩段：忽視風險在道德上站不住也危及成功，但單純迴避風險在商業上等於放棄競爭力，因此必須接受並管理風險。&lt;/p>
&lt;p>書中處理的五類常見風險——時程缺陷、需求膨脹、人員流失、規格崩潰、績效不足——各自附有辨識訊號與應對策略。最實用的是它把風險管理具體化成可執行的動作：把風險列出來、給機率與衝擊、留下對應的緩衝，並且讓緩衝是公開的而非藏在各項估算裡。藏起來的緩衝會在第一次壓力測試時被要求交出來，公開的緩衝才守得住。&lt;/p>
&lt;p>它也直接處理了策略性虛報那一層：書中指出組織若懲罰誠實的風險揭露，風險管理制度就只會產出安全的假風險清單。這個觀察把這個主題連回文化問題。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗加上蒙地卡羅模擬工具，樣本規模有限。時效上，範例的時程單位是多年期大型開發案，與現在的迭代週期不同；五類風險的分類與緩衝要公開這條論證不依賴那個節奏。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，緩衝公開化預設存在一個對外承諾的窗口、而且排程可以攤開討論。承諾由業務單獨對客戶做出、工程只收到日期的組織裡，公開的緩衝沒有地方可以放，那一段要換成對內的風險登記。那五類風險在紙上是一張清單，直到其中一類真的發生過——讀得出價值的前提因此是一次時程失控。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Waltzing-Bears-Managing-Software-Projects/dp/0932633609">Amazon（Waltzing With Bears: Managing Risk on Software Projects）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010888540">博客來（與熊共舞：軟體專案的風險管理，經典紀念版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想理解偏誤的來源時讀-thinking-fast-and-slow">想理解偏誤的來源時讀 Thinking, Fast and Slow&lt;/h2>
&lt;p>Daniel Kahneman 的《Thinking, Fast and Slow》提供的是規劃謬誤的心理學源頭，以及一整份認知偏誤地圖——系統一與系統二、錨定、可得性、框架效應。技術決策裡的許多爭論其實是這些偏誤在不同人身上的不同表現，有了名字之後才能在會議中被指認。&lt;/p>
&lt;p>它在這個主題的位置是背景而非操作。書中提供的是機制解釋，不提供估算流程；讀完不會讓估算變準，但會解釋為什麼加上緩衝之後還是不夠。&lt;/p>
&lt;p>證據來源是受控實驗，形式是數十年的實驗心理學研究，對它測的那些機制強度高。要注意的是其中部分社會促發（priming）相關的研究在後續重複實驗中未能複製，這一塊的結論要保留；判斷與決策的核心部分未受影響。時效上，實驗設計與樣本屬於行為經濟學早期，複製危機之後該領域對效果量的標準已經提高；系統一與系統二的區分與規劃謬誤的機制持續被後續研究沿用。它在本篇是背景而非操作，因此標不出讀它的時機——任何時候讀都拿得到那組名字。書很厚，適合當長期參考而非一次讀完。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555">Amazon（Thinking, Fast and Slow）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010962486">博客來（快思慢想，新版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>怎麼估、估完之後怎麼守、為什麼一開始就會失準——三本各接一段。How Big Things Get Done 給的是跨產業的預測方法，Waltzing with Bears 給的是軟體專案的風險操作，Thinking, Fast and Slow 給的是偏誤的機制來源。&lt;/p>
&lt;p>軟體估算的技術書（功能點分析、故事點校準、蒙地卡羅模擬）數量不少，它們處理的都是第一層——讓估算方法更精細。這個主題不收它們的理由可以從 Flyvbjerg 的資料庫直接讀出來：那批專案的估算方法各異、精細程度差距很大，而超支比例並沒有隨方法精細度下降。方法精細度的提升在誘因結構不變時不改變結果。翻目錄就分得出來：全書的章節都在談怎麼算得更準的，處理的是第一層；有章節在談承諾怎麼被定下來、誰在什麼壓力下改了數字的，才跨到這裡收的那兩層。需要估算技術本身的讀者，那屬於專案管理的操作領域而非本書單的範圍。&lt;/p>
&lt;h2 id="誘因結構由賽局理論承接偏誤那一層由一門哲學課接住一半">誘因結構由賽局理論承接，偏誤那一層由一門哲學課接住一半&lt;/h2>
&lt;p>這是管理線十一個主題裡唯一接得住公開課的一個，兩層各有一門課接。本篇開頭把估算失準分成樂觀偏誤與策略性虛報，並說後者是誘因結構的產物、靠估算方法修不了；分析誘因結構的工具有完整的公開課，就是賽局理論。&lt;/p>
&lt;p>&lt;strong>Yale ECON 159 Game Theory&lt;/strong> 由 Ben Polak 主講、2007 年秋季、24 講，每講約 70 分鐘。跟本篇最直接對得上的是最後一講的 winner&amp;rsquo;s curse：多方競標同一個標的時，得標的是估得最樂觀的那一方，而最樂觀通常就是最錯的那一方——這是策略性虛報以外、同樣不靠任何人說謊就能產生系統性低估的一條機制，而它接得上本篇起點書的樣本——公共基礎建設依法多以競標發包，那正是該書資料庫的主要專案類型。這一條是機制上的接點，不是從書裡讀出來的統計。另外三處各接那條線上的一個環節，而逐講的對應要看過講次內容才下得了，屬於 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「這些判定從哪來」段所說、可信度較低的那一類：第 13 講的道德風險說明看不到對方行動時誘因為什麼會失準，那是估算被交出去之後沒人查證的那一段；第 14 與 15 講的承諾與可信威脅處理「說了會怎樣」要成立需要哪些條件，那是承諾守不守得住的前提；第 23 講的訊號傳遞說明資訊少的一方怎麼從對方願意付出的代價反推真話，對應的是聽估算的人能做什麼。課程自己標了門檻：需要修過個體經濟學導論，會用到微積分（主要是單變數）。&lt;/p>
&lt;p>中文側有對應，而且切得更貼近商管情境。台大開放式課程的&lt;strong>商管研究中的賽局分析&lt;/strong>分兩門：第一門（孔令傑，7 講）從最佳化與賽局基礎走到通路選擇、合約制定與共享經濟平台，課程頁自陳是初學者等級、只需單變數微積分與基本機率；第二門（5 講）整門處理資訊不對稱，講篩選模型與傳訊模型，其中一個應用直接是「篩選零售夥伴的需求預測能力」——那跟「怎麼知道這個估算的人有沒有說實話」是同一個問題換一個場域。&lt;/p>
&lt;p>這兩門課有一個取得上的注意事項，而它剛好示範了平台與載體的差別。兩門同時上架 Coursera，而 Coursera 自 2025 年 8 月起把免費的旁聽改成預覽，只能看第一個單元；同樣的內容在台大開放式課程與 YouTube 上仍然完整免費。走 OCW 或 YouTube 那一邊，不走 Coursera。&lt;/p>
&lt;p>樂觀偏誤那一層由 &lt;strong>Open Yale PHIL 181 Philosophy and the Science of Human Nature&lt;/strong> 接得住一部分。Tamar Gendler（哲學與認知科學）主講、2011 年春季、26 講。它不是偏誤目錄課——全課的骨架是幸福、道德與政治正當性三個哲學問題——但它的指定閱讀直接是本篇第三本書的一手來源：Kahneman 的〈Mapping Bounded Rationality〉與諾貝爾講座、Ariely 的《Predictably Irrational》全本、Evans 的雙系統推理、Sunstein 的道德捷思。讀 Thinking, Fast and Slow 是拿 Kahneman 整理過的版本，走這門課是拿原始論文加一個哲學家的追問。門檻也在那裡：英語授課，而指定閱讀是一手論文而非科普，投入的份量比另外三門重。它跟 ECON 159 一樣是 Open Yale Courses 的課，該站的標準供給含英文逐字稿，讀得慢而聽不動的讀者靠那份稿子搭橋。&lt;/p>
&lt;p>它接不住的是把整批偏誤逐一走完那一面——本篇第三本的用途之一是當長期參考的偏誤地圖，而這門課沒有那個功能。這一輪沒有查到有那個功能的課。&lt;/p>
&lt;p>三門課教的都是推導而非當期材料，時效因此不隨年代改變；ECON 159 錄於 2007 年，它舉的產業例子（外包、教育訊號）屬於當時的情境，推導本身不依賴那些例子。台大那兩門的取得注意事項見上一段。整條線的供給狀況寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://oyc.yale.edu/economics/econ-159">Open Yale Courses（ECON 159 Game Theory，Ben Polak，2007，24 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PL6EF60E1027E1A10B">YouTube 播放清單（ECON 159）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://oyc.yale.edu/philosophy/phil-181">Open Yale Courses（PHIL 181 Philosophy and the Science of Human Nature，Tamar Gendler，2011，26 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PL3F6BC200B2930084">YouTube 播放清單（PHIL 181）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://ocw.aca.ntu.edu.tw/courses/mooc0021">台大開放式課程（mooc0021 商管研究中的賽局分析（一）：通路選擇、合約制定與共享經濟，孔令傑，7 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpD9qxWbXeD7-ucIHKeIVybj">YouTube 播放清單&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://ocw.aca.ntu.edu.tw/courses/mooc0042">台大開放式課程（mooc0042 商管研究中的賽局分析（二）：資訊經濟學，孔令傑，5 講）&lt;/a>、&lt;a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpCL7zokQOh2MbVhQjQtKtVR">YouTube 播放清單&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>策略性虛報無法用估算方法解決，因為它是誘因的產物。要處理那一層，走 &lt;a href="../culture-safety/">組織文化與心理安全感&lt;/a>——講實話會發生什麼事，是那個主題的核心問題。&lt;/p></description><content:encoded><![CDATA[<p>估算失準有兩個來源，需要用完全不同的方法處理。第一個是樂觀偏誤：估算的人真心低估，因為人傾向從內部細節推導，而細節推導系統性地漏掉未知項。第二個是策略性虛報：知道會超支，但講實話案子就過不了，因此低報是理性選擇。前者靠方法修正，後者靠方法修不了——它是誘因結構的產物，要改變它必須先改變「講實話會發生什麼事」。</p>
<p>把這兩者分開是這個主題的核心價值。多數組織的估算改善措施只處理第一層，於是導入了更精細的估算流程、卻得到同樣失準的數字，因為真正在運作的是第二層。</p>
<p>讀不動長篇文字時，本篇文末另標出承接第二層的公開課，收錄門檻與已知限制見 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。</p>
<h2 id="起點是-how-big-things-get-done">起點是 How Big Things Get Done</h2>
<p>Bent Flyvbjerg 與 Dan Gardner 的《How Big Things Get Done》同時涵蓋上述兩層來源並且明確區分兩者，證據規模也是本篇最大的一本，資料庫涵蓋上萬件大型專案的實際成本與時程。</p>
<p>最可直接使用的是參考組預測法：不從內部細節推估，而是找同類專案的歷史實際數字，用分布而非單點來預測。這個方法之所以有效，是因為它繞過了細節推導這個偏誤來源本身，而不是試圖讓細節推導更準。</p>
<p>另一條主線是「慢想快做」：規劃階段盡量長、盡量多次修改設計，執行階段盡量短。理由是規劃階段的修改幾乎免費、執行階段的修改極貴。這條原則與軟體業「盡早交付、快速迭代」的直覺表面衝突，實際處理的是不同性質的專案——可逆的實驗適合快速迭代，不可逆的大型投入適合慢想快做。判斷手上這件事屬於哪一類，是使用這條原則的前提。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是大規模實證，形式是跨產業的歷史成本資料庫，強度足以支持預算與時程的實際決定。時效上，資料庫的專案類型以基建、能源與 IT 大型導入為主，軟體團隊常見的小型迭代不在樣本裡；樂觀偏誤與策略性虛報的區分建立在決策者的資訊與誘因結構上，不依賴專案規模。讀得出價值的前提幾乎沒有，但案例以基建與大型工程為主，軟體的轉譯要自己做。</p>
<ul>
<li><a href="https://www.amazon.com/How-Big-Things-Get-Done/dp/0593239512">Amazon（How Big Things Get Done）</a></li>
<li><a href="https://www.books.com.tw/products/0010986409">博客來（超級專案管理：牛津大學教授揭示計畫成敗的法則）</a></li>
</ul>
<h2 id="要處理軟體專案的風險時讀-waltzing-with-bears">要處理軟體專案的風險時讀 Waltzing with Bears</h2>
<p>Tom DeMarco 與 Timothy Lister 的《Waltzing with Bears》是這個主題唯一針對軟體專案寫的一本。核心主張分兩段：忽視風險在道德上站不住也危及成功，但單純迴避風險在商業上等於放棄競爭力，因此必須接受並管理風險。</p>
<p>書中處理的五類常見風險——時程缺陷、需求膨脹、人員流失、規格崩潰、績效不足——各自附有辨識訊號與應對策略。最實用的是它把風險管理具體化成可執行的動作：把風險列出來、給機率與衝擊、留下對應的緩衝，並且讓緩衝是公開的而非藏在各項估算裡。藏起來的緩衝會在第一次壓力測試時被要求交出來，公開的緩衝才守得住。</p>
<p>它也直接處理了策略性虛報那一層：書中指出組織若懲罰誠實的風險揭露，風險管理制度就只會產出安全的假風險清單。這個觀察把這個主題連回文化問題。</p>
<p>證據來源是跨客戶的顧問經驗加上蒙地卡羅模擬工具，樣本規模有限。時效上，範例的時程單位是多年期大型開發案，與現在的迭代週期不同；五類風險的分類與緩衝要公開這條論證不依賴那個節奏。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，緩衝公開化預設存在一個對外承諾的窗口、而且排程可以攤開討論。承諾由業務單獨對客戶做出、工程只收到日期的組織裡，公開的緩衝沒有地方可以放，那一段要換成對內的風險登記。那五類風險在紙上是一張清單，直到其中一類真的發生過——讀得出價值的前提因此是一次時程失控。</p>
<ul>
<li><a href="https://www.amazon.com/Waltzing-Bears-Managing-Software-Projects/dp/0932633609">Amazon（Waltzing With Bears: Managing Risk on Software Projects）</a></li>
<li><a href="https://www.books.com.tw/products/0010888540">博客來（與熊共舞：軟體專案的風險管理，經典紀念版）</a></li>
</ul>
<h2 id="想理解偏誤的來源時讀-thinking-fast-and-slow">想理解偏誤的來源時讀 Thinking, Fast and Slow</h2>
<p>Daniel Kahneman 的《Thinking, Fast and Slow》提供的是規劃謬誤的心理學源頭，以及一整份認知偏誤地圖——系統一與系統二、錨定、可得性、框架效應。技術決策裡的許多爭論其實是這些偏誤在不同人身上的不同表現，有了名字之後才能在會議中被指認。</p>
<p>它在這個主題的位置是背景而非操作。書中提供的是機制解釋，不提供估算流程；讀完不會讓估算變準，但會解釋為什麼加上緩衝之後還是不夠。</p>
<p>證據來源是受控實驗，形式是數十年的實驗心理學研究，對它測的那些機制強度高。要注意的是其中部分社會促發（priming）相關的研究在後續重複實驗中未能複製，這一塊的結論要保留；判斷與決策的核心部分未受影響。時效上，實驗設計與樣本屬於行為經濟學早期，複製危機之後該領域對效果量的標準已經提高；系統一與系統二的區分與規劃謬誤的機制持續被後續研究沿用。它在本篇是背景而非操作，因此標不出讀它的時機——任何時候讀都拿得到那組名字。書很厚，適合當長期參考而非一次讀完。</p>
<ul>
<li><a href="https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555">Amazon（Thinking, Fast and Slow）</a></li>
<li><a href="https://www.books.com.tw/products/0010962486">博客來（快思慢想，新版）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>怎麼估、估完之後怎麼守、為什麼一開始就會失準——三本各接一段。How Big Things Get Done 給的是跨產業的預測方法，Waltzing with Bears 給的是軟體專案的風險操作，Thinking, Fast and Slow 給的是偏誤的機制來源。</p>
<p>軟體估算的技術書（功能點分析、故事點校準、蒙地卡羅模擬）數量不少，它們處理的都是第一層——讓估算方法更精細。這個主題不收它們的理由可以從 Flyvbjerg 的資料庫直接讀出來：那批專案的估算方法各異、精細程度差距很大，而超支比例並沒有隨方法精細度下降。方法精細度的提升在誘因結構不變時不改變結果。翻目錄就分得出來：全書的章節都在談怎麼算得更準的，處理的是第一層；有章節在談承諾怎麼被定下來、誰在什麼壓力下改了數字的，才跨到這裡收的那兩層。需要估算技術本身的讀者，那屬於專案管理的操作領域而非本書單的範圍。</p>
<h2 id="誘因結構由賽局理論承接偏誤那一層由一門哲學課接住一半">誘因結構由賽局理論承接，偏誤那一層由一門哲學課接住一半</h2>
<p>這是管理線十一個主題裡唯一接得住公開課的一個，兩層各有一門課接。本篇開頭把估算失準分成樂觀偏誤與策略性虛報，並說後者是誘因結構的產物、靠估算方法修不了；分析誘因結構的工具有完整的公開課，就是賽局理論。</p>
<p><strong>Yale ECON 159 Game Theory</strong> 由 Ben Polak 主講、2007 年秋季、24 講，每講約 70 分鐘。跟本篇最直接對得上的是最後一講的 winner&rsquo;s curse：多方競標同一個標的時，得標的是估得最樂觀的那一方，而最樂觀通常就是最錯的那一方——這是策略性虛報以外、同樣不靠任何人說謊就能產生系統性低估的一條機制，而它接得上本篇起點書的樣本——公共基礎建設依法多以競標發包，那正是該書資料庫的主要專案類型。這一條是機制上的接點，不是從書裡讀出來的統計。另外三處各接那條線上的一個環節，而逐講的對應要看過講次內容才下得了，屬於 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「這些判定從哪來」段所說、可信度較低的那一類：第 13 講的道德風險說明看不到對方行動時誘因為什麼會失準，那是估算被交出去之後沒人查證的那一段；第 14 與 15 講的承諾與可信威脅處理「說了會怎樣」要成立需要哪些條件，那是承諾守不守得住的前提；第 23 講的訊號傳遞說明資訊少的一方怎麼從對方願意付出的代價反推真話，對應的是聽估算的人能做什麼。課程自己標了門檻：需要修過個體經濟學導論，會用到微積分（主要是單變數）。</p>
<p>中文側有對應，而且切得更貼近商管情境。台大開放式課程的<strong>商管研究中的賽局分析</strong>分兩門：第一門（孔令傑，7 講）從最佳化與賽局基礎走到通路選擇、合約制定與共享經濟平台，課程頁自陳是初學者等級、只需單變數微積分與基本機率；第二門（5 講）整門處理資訊不對稱，講篩選模型與傳訊模型，其中一個應用直接是「篩選零售夥伴的需求預測能力」——那跟「怎麼知道這個估算的人有沒有說實話」是同一個問題換一個場域。</p>
<p>這兩門課有一個取得上的注意事項，而它剛好示範了平台與載體的差別。兩門同時上架 Coursera，而 Coursera 自 2025 年 8 月起把免費的旁聽改成預覽，只能看第一個單元；同樣的內容在台大開放式課程與 YouTube 上仍然完整免費。走 OCW 或 YouTube 那一邊，不走 Coursera。</p>
<p>樂觀偏誤那一層由 <strong>Open Yale PHIL 181 Philosophy and the Science of Human Nature</strong> 接得住一部分。Tamar Gendler（哲學與認知科學）主講、2011 年春季、26 講。它不是偏誤目錄課——全課的骨架是幸福、道德與政治正當性三個哲學問題——但它的指定閱讀直接是本篇第三本書的一手來源：Kahneman 的〈Mapping Bounded Rationality〉與諾貝爾講座、Ariely 的《Predictably Irrational》全本、Evans 的雙系統推理、Sunstein 的道德捷思。讀 Thinking, Fast and Slow 是拿 Kahneman 整理過的版本，走這門課是拿原始論文加一個哲學家的追問。門檻也在那裡：英語授課，而指定閱讀是一手論文而非科普，投入的份量比另外三門重。它跟 ECON 159 一樣是 Open Yale Courses 的課，該站的標準供給含英文逐字稿，讀得慢而聽不動的讀者靠那份稿子搭橋。</p>
<p>它接不住的是把整批偏誤逐一走完那一面——本篇第三本的用途之一是當長期參考的偏誤地圖，而這門課沒有那個功能。這一輪沒有查到有那個功能的課。</p>
<p>三門課教的都是推導而非當期材料，時效因此不隨年代改變；ECON 159 錄於 2007 年，它舉的產業例子（外包、教育訊號）屬於當時的情境，推導本身不依賴那些例子。台大那兩門的取得注意事項見上一段。整條線的供給狀況寫在 <a href="../">主題書單</a> 的公開課段。</p>
<ul>
<li><a href="https://oyc.yale.edu/economics/econ-159">Open Yale Courses（ECON 159 Game Theory，Ben Polak，2007，24 講）</a>、<a href="https://www.youtube.com/playlist?list=PL6EF60E1027E1A10B">YouTube 播放清單（ECON 159）</a></li>
<li><a href="https://oyc.yale.edu/philosophy/phil-181">Open Yale Courses（PHIL 181 Philosophy and the Science of Human Nature，Tamar Gendler，2011，26 講）</a>、<a href="https://www.youtube.com/playlist?list=PL3F6BC200B2930084">YouTube 播放清單（PHIL 181）</a></li>
<li><a href="https://ocw.aca.ntu.edu.tw/courses/mooc0021">台大開放式課程（mooc0021 商管研究中的賽局分析（一）：通路選擇、合約制定與共享經濟，孔令傑，7 講）</a>、<a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpD9qxWbXeD7-ucIHKeIVybj">YouTube 播放清單</a></li>
<li><a href="https://ocw.aca.ntu.edu.tw/courses/mooc0042">台大開放式課程（mooc0042 商管研究中的賽局分析（二）：資訊經濟學，孔令傑，5 講）</a>、<a href="https://www.youtube.com/playlist?list=PLCX-BLZ1hDpCL7zokQOh2MbVhQjQtKtVR">YouTube 播放清單</a></li>
</ul>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>策略性虛報無法用估算方法解決，因為它是誘因的產物。要處理那一層，走 <a href="../culture-safety/">組織文化與心理安全感</a>——講實話會發生什麼事，是那個主題的核心問題。</p>
<p>當下要把壞消息講出口的技術走 <a href="../influence-conversation/">困難對話與無權限影響力</a>。要用交付資料取代估算辯論，走 <a href="../continuous-delivery/">持續交付與交付效能</a>——變更前置時間的實測分布比估算更能回答「這件事大概要多久」。</p>
<p>偏誤有一部分是在會議室當場被製造出來的：第一個被喊出的數字錨住後面所有人、已投入的成本讓人捨不得改方向。要在流程上擋住這兩件事，走 <a href="../meeting-facilitation/">會議引導與群體決策</a>。</p>
]]></content:encoded></item><item><title>事故、歸因與無指責檢討</title><link>https://tarrragon.github.io/blog/books/software-management/topics/incident-blame/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/incident-blame/</guid><description>&lt;p>事故檢討的品質由一個判斷決定：把「人為疏失」當成調查的起點還是結論。停在結論的檢討會產出加強訓練、加簽核、加提醒這類措施，而這些措施不改變系統允許錯誤發生的條件，因此同類事故會再來。把它當起點的檢討繼續往下問：為什麼這個操作在當時看起來是合理的，於是才會碰到真正可以改的東西。&lt;/p>
&lt;p>這個主題的書大多來自軟體業以外——航空、太空、醫療的安全科學。這些領域比軟體業早三十年面對「事故會死人」的壓力，因此發展出的調查方法與歸因理論成熟得多。Google SRE 的無指責檢討文化就建立在這批研究上，那本是這裡唯一的業內來源。&lt;/p>
&lt;p>受監理環境的讀者要先看這一段再往下。金融、醫療、航空這類有主管機關的組織，事故後的追責與報告是法定義務，不是文化選擇；下面三本處理的是「怎麼問出真正的原因」，不是「可不可以不追究」，而兩者在受監理環境裡最容易被混為一談。把無指責當成免責在這裡有實際的法律風險。這種組織該問的是懲戒界線畫在哪、以及調查報告與法遵報告能不能分開產出，那組問題對應的是 Dekker 的另一本《Just Culture》（見下面的「為什麼只收這幾本」段），而本書單沒有評估過那個脈絡下的適用方式。&lt;/p>
&lt;h2 id="起點是-dekker-的-field-guide">起點是 Dekker 的 Field Guide&lt;/h2>
&lt;p>Sidney Dekker 的《The Field Guide to Understanding &amp;lsquo;Human Error&amp;rsquo;》從歸因理論一路寫到調查程序，而且設計上就是給調查者當工作手冊用——理論與程序同時到位的只有它。核心主張是「人為疏失」這個標籤會阻止真正原因被發現，因為它把調查的終點放在最容易指認的地方。&lt;/p>
&lt;p>最實用的是它對 &lt;a href="https://tarrragon.github.io/blog/til/behavior/hindsight-bias/" data-link-title="後見之明偏誤：事後看得一清二楚的因果，在當下並不存在" data-link-desc="檢討會議裡出現「他當時怎麼會沒注意到」這種問句時，用來理解那個問句本身就建立在錯誤的前提上">後見之明偏誤&lt;/a> 的處理。事後看得一清二楚的因果，在事發當下的當事人視角裡並不存在——當時他看到的是部分的、矛盾的、正在變化的資訊，而且同時有其他事情在進行。因此調查的工作是重建當事人當時看到什麼，而不是列出他應該注意到什麼。書中提供了具體的重建步驟：建立時間軸、標記各時點的可得資訊、找出資訊與判斷之間的合理連結。&lt;/p>
&lt;p>另一組概念是舊觀點與新觀點的對照：舊觀點認為人是系統中不可靠的部分、要用流程約束；新觀點認為人是系統中製造彈性的部分，事故顯示的是系統的條件而非人的品質。這個轉換直接改變檢討會議的提問方式。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨組織案例（航空與醫療的事故調查）加上人因工程研究。時效上，書中的案例來自駕駛艙與手術室，讀者要自行對應到軟體場景；後見之明偏誤與當事人視角重建的論證建立在人類認知的限制上，不依賴任何產業條件。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，全書預設調查的目的是學習，產出是給自己組織看的。有法定通報義務的組織，同一次事故要交出的是兩份東西——一份對內學習、一份對外符合報告格式，而這本書不處理那個分工，開頭那一段講的就是這件事。讀得出價值的前提是：參與過至少一次事故檢討會議。坐過那個房間的人才認得出書中反覆強調的「不要問他為什麼沒注意到」在攔什麼。目前沒有中譯本。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/1472439058">Amazon（The Field Guide to Understanding &amp;lsquo;Human Error&amp;rsquo;）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想理解災難怎麼累積時讀-the-challenger-launch-decision">想理解災難怎麼累積時讀 The Challenger Launch Decision&lt;/h2>
&lt;p>Diane Vaughan 的《The Challenger Launch Decision》是一部社會學的深度個案重建，推翻了挑戰者號失事的通俗解釋。她的結論是 &lt;a href="https://tarrragon.github.io/blog/til/organization/normalization-of-deviance/" data-link-title="偏差正常化：每次放寬都有理由，累積起來走到災難" data-link-desc="回頭看某個決定覺得離譜、但當時所有人都同意時，用來理解標準是怎麼一步步被重新定義的">偏差被逐步正常化&lt;/a>，而非有人違規或隱瞞——每一次小幅放寬標準當下都有合理理由，而且每次都沒出事，於是新標準成為基準，下一次再從新基準往外放一點。&lt;/p>
&lt;p>這個機制解釋了為什麼災難前的每個決定看起來都不算離譜，累積起來卻走到災難。軟體團隊的對應現象很容易辨認：每次跳過測試都有當下的理由、每次手動改生產環境都是特例、每次警報被靜音都因為它最近很吵。偏差正常化這個詞的價值在於它讓這類累積變成可以命名、可以在檢討時指認的東西。&lt;/p>
&lt;p>這是一本八百頁的學術專著，門檻比內容本身更常決定要不要讀它。讀得出價值的前提是待過一個曾經反覆放寬某條標準的組織；缺這個對照，整本會讀成一部太空史。想快速掌握概念的人，偏差正常化這個詞本身已經是主要收穫；想看它怎麼在真實組織裡一步步發生的人，才需要讀完。&lt;/p>
&lt;p>證據來源是單一組織的深度重建，而且深到極少見——內部文件、聽證紀錄、當事人訪談——所以它提供的是一個可以拿來對照自己組織的完整範本，而非可統計的通則。時效上，NASA 在事故後的組織改革使書中描述的決策鏈已不復存在，而偏差正常化的機制與那個組織的具體形態無關。目前沒有中譯本。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Challenger-Launch-Decision-Technology-Deviance/dp/022634682X">Amazon（The Challenger Launch Decision, Enlarged Edition）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要看產業實作版本時回到-google-sre">要看產業實作版本時回到 Google SRE&lt;/h2>
&lt;p>Google 的《Site Reliability Engineering》裡的事後檢討章節，是上述兩本的理論在軟體組織裡的制度化版本：檢討報告該包含什麼、由誰主持、如何確保追蹤項目真的被完成、以及怎麼避免無指責變成無追究。&lt;/p>
&lt;p>它的性質是單一組織的深度重建，形式是制度紀錄，因此提供的是一份可以參照的範本而非通則。這本書的完整描述在 &lt;a href="../continuous-delivery/">持續交付與交付效能&lt;/a>，此處只標出它在事故這條線上的用途。全文免費線上閱讀。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://sre.google/books/">Google SRE 官方免費線上版&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>調查、判讀、制度化是三件不同的工作，各自需要的材料也不同：怎麼問，看 Dekker 的操作指南；怎麼看懂長期累積，看 Vaughan 的深度個案；怎麼把它變成制度，看 Google SRE 的範本。三本不重疊。&lt;/p>
&lt;p>安全科學的文獻量龐大，且多數以學術論文而非書籍形式存在。書籍形式的入門書多半綁定特定產業的法規框架（航空的 SMS、醫療的病安通報），軟體讀者要先學那套法規才讀得懂內容。翻案例來源就看得出來：案例全部出自單一產業的法規通報系統時，那本書的推導依賴那套通報制度，換一個沒有通報義務的環境就少了半邊。&lt;/p>
&lt;p>Dekker 的另一本《Just Culture》處理的是懲戒界線——哪些行為即使在無指責文化下仍需追究。它與這裡的三本不重疊，本書單未評估它對軟體團隊的適用時機，因此暫不列入；團隊已經在爭論「這次到底該不該記過」的話，那本是直接對應的書。&lt;/p>
&lt;p>受監理環境的處理寫在開頭那一段，因為它決定要不要往下讀，而不是讀完之後才調整。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>檢討要有效，前提是當事人願意說出當時真正發生什麼。那個前提屬於 &lt;a href="../culture-safety/">組織文化與心理安全感&lt;/a>——無指責檢討的制度可以照抄，講真話的意願不行。&lt;/p>
&lt;p>偏差累積的另一面是系統層級的回饋延遲：每次放寬標準都沒有立即後果，因此沒有訊號阻止下一次。那個機制走 &lt;a href="../problem-definition/">問題定義與系統思考&lt;/a>。&lt;/p>
&lt;p>事故分級怎麼定、指揮角色怎麼分工、復盤產出怎麼進下一輪演練，這些制度實作看 &lt;a href="https://tarrragon.github.io/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤&lt;/a>。事故的偵測面——客戶端遙測怎麼收、告警怎麼收斂——看 &lt;a href="https://tarrragon.github.io/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系&lt;/a>。服務探活與高可用看 &lt;a href="https://tarrragon.github.io/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>事故檢討的品質由一個判斷決定：把「人為疏失」當成調查的起點還是結論。停在結論的檢討會產出加強訓練、加簽核、加提醒這類措施，而這些措施不改變系統允許錯誤發生的條件，因此同類事故會再來。把它當起點的檢討繼續往下問：為什麼這個操作在當時看起來是合理的，於是才會碰到真正可以改的東西。</p>
<p>這個主題的書大多來自軟體業以外——航空、太空、醫療的安全科學。這些領域比軟體業早三十年面對「事故會死人」的壓力，因此發展出的調查方法與歸因理論成熟得多。Google SRE 的無指責檢討文化就建立在這批研究上，那本是這裡唯一的業內來源。</p>
<p>受監理環境的讀者要先看這一段再往下。金融、醫療、航空這類有主管機關的組織，事故後的追責與報告是法定義務，不是文化選擇；下面三本處理的是「怎麼問出真正的原因」，不是「可不可以不追究」，而兩者在受監理環境裡最容易被混為一談。把無指責當成免責在這裡有實際的法律風險。這種組織該問的是懲戒界線畫在哪、以及調查報告與法遵報告能不能分開產出，那組問題對應的是 Dekker 的另一本《Just Culture》（見下面的「為什麼只收這幾本」段），而本書單沒有評估過那個脈絡下的適用方式。</p>
<h2 id="起點是-dekker-的-field-guide">起點是 Dekker 的 Field Guide</h2>
<p>Sidney Dekker 的《The Field Guide to Understanding &lsquo;Human Error&rsquo;》從歸因理論一路寫到調查程序，而且設計上就是給調查者當工作手冊用——理論與程序同時到位的只有它。核心主張是「人為疏失」這個標籤會阻止真正原因被發現，因為它把調查的終點放在最容易指認的地方。</p>
<p>最實用的是它對 <a href="/blog/til/behavior/hindsight-bias/" data-link-title="後見之明偏誤：事後看得一清二楚的因果，在當下並不存在" data-link-desc="檢討會議裡出現「他當時怎麼會沒注意到」這種問句時，用來理解那個問句本身就建立在錯誤的前提上">後見之明偏誤</a> 的處理。事後看得一清二楚的因果，在事發當下的當事人視角裡並不存在——當時他看到的是部分的、矛盾的、正在變化的資訊，而且同時有其他事情在進行。因此調查的工作是重建當事人當時看到什麼，而不是列出他應該注意到什麼。書中提供了具體的重建步驟：建立時間軸、標記各時點的可得資訊、找出資訊與判斷之間的合理連結。</p>
<p>另一組概念是舊觀點與新觀點的對照：舊觀點認為人是系統中不可靠的部分、要用流程約束；新觀點認為人是系統中製造彈性的部分，事故顯示的是系統的條件而非人的品質。這個轉換直接改變檢討會議的提問方式。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨組織案例（航空與醫療的事故調查）加上人因工程研究。時效上，書中的案例來自駕駛艙與手術室，讀者要自行對應到軟體場景；後見之明偏誤與當事人視角重建的論證建立在人類認知的限制上，不依賴任何產業條件。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，全書預設調查的目的是學習，產出是給自己組織看的。有法定通報義務的組織，同一次事故要交出的是兩份東西——一份對內學習、一份對外符合報告格式，而這本書不處理那個分工，開頭那一段講的就是這件事。讀得出價值的前提是：參與過至少一次事故檢討會議。坐過那個房間的人才認得出書中反覆強調的「不要問他為什麼沒注意到」在攔什麼。目前沒有中譯本。</p>
<ul>
<li><a href="https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/1472439058">Amazon（The Field Guide to Understanding &lsquo;Human Error&rsquo;）</a></li>
</ul>
<h2 id="想理解災難怎麼累積時讀-the-challenger-launch-decision">想理解災難怎麼累積時讀 The Challenger Launch Decision</h2>
<p>Diane Vaughan 的《The Challenger Launch Decision》是一部社會學的深度個案重建，推翻了挑戰者號失事的通俗解釋。她的結論是 <a href="/blog/til/organization/normalization-of-deviance/" data-link-title="偏差正常化：每次放寬都有理由，累積起來走到災難" data-link-desc="回頭看某個決定覺得離譜、但當時所有人都同意時，用來理解標準是怎麼一步步被重新定義的">偏差被逐步正常化</a>，而非有人違規或隱瞞——每一次小幅放寬標準當下都有合理理由，而且每次都沒出事，於是新標準成為基準，下一次再從新基準往外放一點。</p>
<p>這個機制解釋了為什麼災難前的每個決定看起來都不算離譜，累積起來卻走到災難。軟體團隊的對應現象很容易辨認：每次跳過測試都有當下的理由、每次手動改生產環境都是特例、每次警報被靜音都因為它最近很吵。偏差正常化這個詞的價值在於它讓這類累積變成可以命名、可以在檢討時指認的東西。</p>
<p>這是一本八百頁的學術專著，門檻比內容本身更常決定要不要讀它。讀得出價值的前提是待過一個曾經反覆放寬某條標準的組織；缺這個對照，整本會讀成一部太空史。想快速掌握概念的人，偏差正常化這個詞本身已經是主要收穫；想看它怎麼在真實組織裡一步步發生的人，才需要讀完。</p>
<p>證據來源是單一組織的深度重建，而且深到極少見——內部文件、聽證紀錄、當事人訪談——所以它提供的是一個可以拿來對照自己組織的完整範本，而非可統計的通則。時效上，NASA 在事故後的組織改革使書中描述的決策鏈已不復存在，而偏差正常化的機制與那個組織的具體形態無關。目前沒有中譯本。</p>
<ul>
<li><a href="https://www.amazon.com/Challenger-Launch-Decision-Technology-Deviance/dp/022634682X">Amazon（The Challenger Launch Decision, Enlarged Edition）</a></li>
</ul>
<h2 id="要看產業實作版本時回到-google-sre">要看產業實作版本時回到 Google SRE</h2>
<p>Google 的《Site Reliability Engineering》裡的事後檢討章節，是上述兩本的理論在軟體組織裡的制度化版本：檢討報告該包含什麼、由誰主持、如何確保追蹤項目真的被完成、以及怎麼避免無指責變成無追究。</p>
<p>它的性質是單一組織的深度重建，形式是制度紀錄，因此提供的是一份可以參照的範本而非通則。這本書的完整描述在 <a href="../continuous-delivery/">持續交付與交付效能</a>，此處只標出它在事故這條線上的用途。全文免費線上閱讀。</p>
<ul>
<li><a href="https://sre.google/books/">Google SRE 官方免費線上版</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>調查、判讀、制度化是三件不同的工作，各自需要的材料也不同：怎麼問，看 Dekker 的操作指南；怎麼看懂長期累積，看 Vaughan 的深度個案；怎麼把它變成制度，看 Google SRE 的範本。三本不重疊。</p>
<p>安全科學的文獻量龐大，且多數以學術論文而非書籍形式存在。書籍形式的入門書多半綁定特定產業的法規框架（航空的 SMS、醫療的病安通報），軟體讀者要先學那套法規才讀得懂內容。翻案例來源就看得出來：案例全部出自單一產業的法規通報系統時，那本書的推導依賴那套通報制度，換一個沒有通報義務的環境就少了半邊。</p>
<p>Dekker 的另一本《Just Culture》處理的是懲戒界線——哪些行為即使在無指責文化下仍需追究。它與這裡的三本不重疊，本書單未評估它對軟體團隊的適用時機，因此暫不列入；團隊已經在爭論「這次到底該不該記過」的話，那本是直接對應的書。</p>
<p>受監理環境的處理寫在開頭那一段，因為它決定要不要往下讀，而不是讀完之後才調整。</p>
<p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>檢討要有效，前提是當事人願意說出當時真正發生什麼。那個前提屬於 <a href="../culture-safety/">組織文化與心理安全感</a>——無指責檢討的制度可以照抄，講真話的意願不行。</p>
<p>偏差累積的另一面是系統層級的回饋延遲：每次放寬標準都沒有立即後果，因此沒有訊號阻止下一次。那個機制走 <a href="../problem-definition/">問題定義與系統思考</a>。</p>
<p>事故分級怎麼定、指揮角色怎麼分工、復盤產出怎麼進下一輪演練，這些制度實作看 <a href="/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤</a>。事故的偵測面——客戶端遙測怎麼收、告警怎麼收斂——看 <a href="/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系</a>。服務探活與高可用看 <a href="/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運</a>。</p>
]]></content:encoded></item><item><title>困難對話與無權限影響力</title><link>https://tarrragon.github.io/blog/books/software-management/topics/influence-conversation/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/influence-conversation/</guid><description>&lt;p>這個主題處理其他主題留下的執行缺口。理解了心理安全感的機制、知道了估算為什麼失準、看清了組織的回饋迴路，這些都不會告訴一個人：當主管在會議上盯著他問「到底行不行」的時候，接下來三十秒該說什麼。這裡的書處理的正是那三十秒，以及沒有指揮權時怎麼讓別人照著做。&lt;/p>
&lt;p>無權限的影響力在現在的組織裡比職權更常見。Staff 工程師、平台團隊、SRE、架構師都在影響自己管不到的團隊，而多數管理書預設讀者有直接權限。這使得這個主題對技術路線的人特別重要——技術決策要推得動，靠的是方案能不能講進別人的約束裡，光是論證正確並不足夠。&lt;/p>
&lt;h2 id="起點是-difficult-conversations">起點是 Difficult Conversations&lt;/h2>
&lt;p>哈佛談判專案的《Difficult Conversations》把一場難談的對話從準備、診斷走到收尾，整條都在書裡，而且它提供的診斷可以在對話進行中當場用。它把困難對話拆成三層同時進行的對話：關於事實的（發生了什麼、誰對誰錯）、關於感受的（各方的情緒與在意的事）、關於身分認同的（這件事說明了我是什麼樣的人）。&lt;/p>
&lt;p>多數對話失敗的原因是只處理第一層。爭論誰記錯了時程細節，實際上卡住的是第三層——承認自己漏估等於承認自己不夠專業。有了三層的區分，可以在對話中判斷自己卡在哪一層，然後改談那一層。&lt;/p>
&lt;p>書中另一個直接可用的工具是把意圖與影響分開陳述。多數指控來自把觀察到的影響直接推論成對方的意圖，而這個推論幾乎總是錯的，並且一旦說出口就會讓對方轉入防衛。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨客戶的顧問經驗，來自哈佛談判專案近三十年的案例與訓練現場，書中自述如此。時效上，案例場景涵蓋職場、家庭與法律協商，沒有綁定特定的溝通媒介；三層對話的區分建立在人如何處理自我形象受威脅的情境上，遠距與文字溝通普及不影響這個論證。任何位置都用得上，不必先累積什麼才讀得懂。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Difficult-Conversations-Discuss-What-Matters/dp/014313759X">Amazon（Difficult Conversations: How to Discuss What Matters Most）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010650242">博客來（再也沒有難談的事：哈佛法學院教你如何開口）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="情緒已經升溫時讀-crucial-conversations">情緒已經升溫時讀 Crucial Conversations&lt;/h2>
&lt;p>《Crucial Conversations》處理同一件事的另一個切面：高風險、意見相左、情緒正在升溫的時刻。它與前一本的分工是時間點——《Difficult Conversations》用於準備與診斷，這一本處理對話已經開始失控時怎麼拉回來。&lt;/p>
&lt;p>核心工具是維持安全感。書中主張當對方進入沉默或攻擊，內容上的爭辯已經無效，要先修復對話的安全條件（說明共同目的、澄清自己不是什麼意思），再回到內容。這個順序很反直覺——多數人在對方翻臉時會加強論證，而那會加速崩壞。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗，內容是作者群的訓練公司累積的案例與自辦調查。時效上，目前找不到已經失效的前提。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，第三版補上了遠距與跨文化情境，繁體中文版譯自第二版、沒有那一部分。讀得出價值的前提是：有過一次談到一半對方沉默或翻臉的經驗。先修復安全感再回到內容這個順序違反直覺，通常要自己吃過一次虧才照做得下去。繁體中文版《開口就說對話》對應原文第二版、2012 年底出版；第三版目前只有簡體中文版。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Crucial-Conversations-Tools-Talking-Stakes/dp/1260474186">Amazon（Crucial Conversations, Third Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010570731">博客來（開口就說對話，繁體中文舊版）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/CN11836522">博客來（關鍵對話：如何高效能溝通，原書第 3 版，簡體中文版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="問不出真話時讀-humble-inquiry">問不出真話時讀 Humble Inquiry&lt;/h2>
&lt;p>Edgar Schein 的《Humble Inquiry》主題單一：管理者總在說而不在問，而問法本身決定能不能問出真話。它區分幾種提問——謙遜提問、診斷式提問、引導式提問——並指出後兩者會在不知不覺中把答案塞給對方，於是拿回來的是自己的假設被覆述一遍。&lt;/p>
&lt;p>它在這個主題的位置是最小工具。前面兩本處理已經浮上檯面的衝突，這一本處理更早的階段：對方還沒說出真正的問題，而提問方式正在決定他會不會說。對想把心理安全感落到單次互動的人，這是最短的路徑。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗，樣本是質性的。時效上，提問方式決定拿不拿得到真話這個機制沒有發現過時的部分。處境上，第三版加入遠距工作情境；繁體中文版譯自較早的版本，沒有那一章，非同步為主（&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>）的團隊要自己折算。它的前提是一次自我察覺：問完一輪之後發現，拿回來的答案剛好是自己想聽的版本。繁體中文版由天下文化出版，譯名《MIT 最打動人心的溝通課》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Humble-Inquiry-3rd-Instead-Telling/dp/B0DJCSXNMK">Amazon（Humble Inquiry, 3rd Edition，含遠距工作專章）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Humble-Inquiry-Second-Instead-Leadership/dp/1523092629">Amazon（Humble Inquiry, Second Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010660316">博客來（MIT 最打動人心的溝通課：組織心理學大師教你謙遜提問的藝術）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="沒有職權要推動改變時讀-the-secrets-of-consulting">沒有職權要推動改變時讀 The Secrets of Consulting&lt;/h2>
&lt;p>Gerald Weinberg 的《The Secrets of Consulting》處理的是在沒有指揮權的位置上推動改變。這個處境在現在的組織裡很普遍，而多數管理書預設讀者有直接權限，因此這本承擔的角色在這條線上少有其他書填補。&lt;/p>
&lt;p>書中的法則多半以格言形式出現，篇幅短、可以脫離原文脈絡引用。第一法則是「不管客戶怎麼說，一定有問題」；第二法則是「無論問題乍看之下如何，問題一定出在人身上」。定價、拒絕、處理抗拒、判斷什麼時候該退出，這些主題在技術書架上幾乎找不到對應。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗。時效上，影響力的機制部分處理的是被求助者與求助者的關係位置，沒有發現依賴時代條件的部分。處境上，全書預設的僱傭關係是獨立顧問對客戶——收費、合約、什麼時候退出這幾章，對組織內部的技術影響者不適用，因為他退不掉也不收費。試過一次「我明明是對的但沒人動」的人，讀這些法則會覺得精準；沒試過的，會覺得玩世不恭——讀得出價值的前提就在那一次。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Secrets-Consulting-Giving-Getting-Successfully/dp/0932633013">Amazon（The Secrets of Consulting）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010711585">博客來（顧問成功的祕密：有效建議、促成改變的工作智慧，10 週年智慧紀念版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想看自己在壓力下的反應時讀溫伯格第-3-卷">想看自己在壓力下的反應時讀溫伯格第 3 卷&lt;/h2>
&lt;p>Weinberg 的《Quality Software Management, Vol. 3: Congruent Action》處理的是管理者在壓力下的即時反應：被高層質問時為什麼會撒謊、為什麼明知進度不可能還是點頭、為什麼團隊裡沒人敢說壞消息。這是他四卷本裡在這條線的其他書中沒有對應的一卷。&lt;/p>
&lt;p>核心工具是從家族治療師 Virginia Satir 借來的 &lt;a href="https://tarrragon.github.io/blog/til/behavior/satir-coping-stances/" data-link-title="Satir 四種不一致姿態：人在壓力下會丟掉自己、他人或情境其中一項" data-link-desc="被質問的當下說出了自己也不同意的話時，用來標定剛才丟掉了什麼——這是自我觀察的檢查表，不是人格分類">四種不一致姿態&lt;/a>——指責、討好、超理智、打岔。它們的用途是標定「我剛剛是哪一種」，屬於自我觀察的檢查表而非理論。這也是它與這個主題其他書的差別：那些書處理對別人說什麼，這一卷處理自己當下正在做什麼。&lt;/p>
&lt;p>四卷本的標準順序讓不少讀者卡在第一卷，因為那卷整卷在鋪陳看事情的方式、沒有可照抄的步驟。從第 3 卷進入比較有畫面感，讀完再回頭看第 1 卷會比較清楚整套在建立什麼。&lt;/p>
&lt;p>證據來源是跨客戶的顧問經驗加上理論建構（Satir 的治療模型）。時效上，書中的專案是以年為單位的節奏，會議形式已經不同；四種姿態處理的是人在被質問時的自我保護反應，不依賴那個節奏。處境上，它預設的組織形態是階層式匯報——被質問的壓力來自上一層，而扁平組織與非同步協作裡那個壓力換了形狀，姿態本身仍在。這四個姿態要在自己身上認出來才有用，當成人格分類就白讀了。認得出來的前提是經歷過一次「我知道該說什麼但沒說出口」。中文翻譯偏直譯，作者愛用寓言與迂迴的講法，讀起來需要耐心。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Quality-Software-Management-Vol-Congruent/dp/0932633285">Amazon（Quality Software Management, Vol. 3: Congruent Action）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010444273">博客來（溫伯格的軟體管理學：關照全局的管理作為，第 3 卷）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>這個主題的五本按對話的時間軸與位置排：準備與診斷（Difficult Conversations）、失控時的復原（Crucial Conversations）、還沒開口前的提問（Humble Inquiry）、沒有職權的長期影響力（Secrets of Consulting）、自己當下的反應（溫伯格第 3 卷）。前三本處理對別人，後兩本處理對自己與對關係。&lt;/p>
&lt;p>溝通與說服的書是書市數量最龐大的類別之一，多數建立在單一技巧的推廣（談判話術、非暴力溝通、影響力原則）。技巧層的書共同的限制是它們假設讀者已經知道自己想達成什麼，而困難對話卡住的原因通常是還沒弄清楚自己真正在乎什麼——翻目錄先找「我到底為什麼不敢講」這一層有沒有被處理，只給句型的表示它跳過了。&lt;/p>
&lt;p>Robert Cialdini 的《Influence》常被列進這類書單。本書單未評估它在組織內部長期關係中的適用性——它的六個原則來自消費決策與陌生人之間的說服實驗，用在每天要再見面的同事身上會不會反噬，需要另外的證據才能判斷，這裡沒有做。要處理的是對外簡報或一次性的說服場合時，那本是直接對應的書。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而缺的不是數量：以它為名的課很多，內容集中在技巧演練與商業培訓，跨不過本質恆定那一條。它要的機制（承諾可信度與訊號傳遞）在鄰近學科有課，只是這一輪沒有拿那組詞去搜。整條線的供給狀況與那個換法寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>對話技術解決不了結構性的沉默——當講真話會被懲罰，再好的問法也拿不到真話。那條路徑走 &lt;a href="../culture-safety/">組織文化與心理安全感&lt;/a>。&lt;/p>
&lt;p>要推動的具體改變若是團隊怎麼切、交接面誰負責，走 &lt;a href="../team-design/">組織結構與團隊設計&lt;/a>。若要推動的是交付做法，先取得證據會比取得共識容易，走 &lt;a href="../continuous-delivery/">持續交付與交付效能&lt;/a>。&lt;/p>
&lt;p>同一件事發生在一群人身上時要換工具：這裡處理的是兩個人與對話當下的幾十秒，一整場討論怎麼發散與收斂是流程設計的問題，走 &lt;a href="../meeting-facilitation/">會議引導與群體決策&lt;/a>。&lt;/p>
&lt;p>想知道無職權影響力在職涯路徑上對應哪個位置，走 &lt;a href="../role-transitions/">角色轉換與職涯路徑&lt;/a>。&lt;/p>
&lt;p>這個主題有一類讀者在組織之外：替家人管理資產、或要跟不熟悉市場的人談一個財務決定的人，卡住的位置同樣在對話而不在方案。起點書的案例本來就涵蓋家庭，直接用得上；哪幾本的移植成本比較高，以及那個處境還要多留下什麼紀錄，寫在 &lt;a href="https://tarrragon.github.io/blog/books/finance/positions/" data-link-title="依資本責任選書" data-link-desc="手上這筆錢對誰負責決定了同一個主題該從哪一本開始，用來定位自己在哪一格、以及移動前該預習什麼">依資本責任選書&lt;/a> 的最後一節。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理其他主題留下的執行缺口。理解了心理安全感的機制、知道了估算為什麼失準、看清了組織的回饋迴路，這些都不會告訴一個人：當主管在會議上盯著他問「到底行不行」的時候，接下來三十秒該說什麼。這裡的書處理的正是那三十秒，以及沒有指揮權時怎麼讓別人照著做。</p>
<p>無權限的影響力在現在的組織裡比職權更常見。Staff 工程師、平台團隊、SRE、架構師都在影響自己管不到的團隊，而多數管理書預設讀者有直接權限。這使得這個主題對技術路線的人特別重要——技術決策要推得動，靠的是方案能不能講進別人的約束裡，光是論證正確並不足夠。</p>
<h2 id="起點是-difficult-conversations">起點是 Difficult Conversations</h2>
<p>哈佛談判專案的《Difficult Conversations》把一場難談的對話從準備、診斷走到收尾，整條都在書裡，而且它提供的診斷可以在對話進行中當場用。它把困難對話拆成三層同時進行的對話：關於事實的（發生了什麼、誰對誰錯）、關於感受的（各方的情緒與在意的事）、關於身分認同的（這件事說明了我是什麼樣的人）。</p>
<p>多數對話失敗的原因是只處理第一層。爭論誰記錯了時程細節，實際上卡住的是第三層——承認自己漏估等於承認自己不夠專業。有了三層的區分，可以在對話中判斷自己卡在哪一層，然後改談那一層。</p>
<p>書中另一個直接可用的工具是把意圖與影響分開陳述。多數指控來自把觀察到的影響直接推論成對方的意圖，而這個推論幾乎總是錯的，並且一旦說出口就會讓對方轉入防衛。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨客戶的顧問經驗，來自哈佛談判專案近三十年的案例與訓練現場，書中自述如此。時效上，案例場景涵蓋職場、家庭與法律協商，沒有綁定特定的溝通媒介；三層對話的區分建立在人如何處理自我形象受威脅的情境上，遠距與文字溝通普及不影響這個論證。任何位置都用得上，不必先累積什麼才讀得懂。</p>
<ul>
<li><a href="https://www.amazon.com/Difficult-Conversations-Discuss-What-Matters/dp/014313759X">Amazon（Difficult Conversations: How to Discuss What Matters Most）</a></li>
<li><a href="https://www.books.com.tw/products/0010650242">博客來（再也沒有難談的事：哈佛法學院教你如何開口）</a></li>
</ul>
<h2 id="情緒已經升溫時讀-crucial-conversations">情緒已經升溫時讀 Crucial Conversations</h2>
<p>《Crucial Conversations》處理同一件事的另一個切面：高風險、意見相左、情緒正在升溫的時刻。它與前一本的分工是時間點——《Difficult Conversations》用於準備與診斷，這一本處理對話已經開始失控時怎麼拉回來。</p>
<p>核心工具是維持安全感。書中主張當對方進入沉默或攻擊，內容上的爭辯已經無效，要先修復對話的安全條件（說明共同目的、澄清自己不是什麼意思），再回到內容。這個順序很反直覺——多數人在對方翻臉時會加強論證，而那會加速崩壞。</p>
<p>證據來源是跨客戶的顧問經驗，內容是作者群的訓練公司累積的案例與自辦調查。時效上，目前找不到已經失效的前提。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，第三版補上了遠距與跨文化情境，繁體中文版譯自第二版、沒有那一部分。讀得出價值的前提是：有過一次談到一半對方沉默或翻臉的經驗。先修復安全感再回到內容這個順序違反直覺，通常要自己吃過一次虧才照做得下去。繁體中文版《開口就說對話》對應原文第二版、2012 年底出版；第三版目前只有簡體中文版。</p>
<ul>
<li><a href="https://www.amazon.com/Crucial-Conversations-Tools-Talking-Stakes/dp/1260474186">Amazon（Crucial Conversations, Third Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010570731">博客來（開口就說對話，繁體中文舊版）</a></li>
<li><a href="https://www.books.com.tw/products/CN11836522">博客來（關鍵對話：如何高效能溝通，原書第 3 版，簡體中文版）</a></li>
</ul>
<h2 id="問不出真話時讀-humble-inquiry">問不出真話時讀 Humble Inquiry</h2>
<p>Edgar Schein 的《Humble Inquiry》主題單一：管理者總在說而不在問，而問法本身決定能不能問出真話。它區分幾種提問——謙遜提問、診斷式提問、引導式提問——並指出後兩者會在不知不覺中把答案塞給對方，於是拿回來的是自己的假設被覆述一遍。</p>
<p>它在這個主題的位置是最小工具。前面兩本處理已經浮上檯面的衝突，這一本處理更早的階段：對方還沒說出真正的問題，而提問方式正在決定他會不會說。對想把心理安全感落到單次互動的人，這是最短的路徑。</p>
<p>證據來源是跨客戶的顧問經驗，樣本是質性的。時效上，提問方式決定拿不拿得到真話這個機制沒有發現過時的部分。處境上，第三版加入遠距工作情境；繁體中文版譯自較早的版本，沒有那一章，非同步為主（<a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a>）的團隊要自己折算。它的前提是一次自我察覺：問完一輪之後發現，拿回來的答案剛好是自己想聽的版本。繁體中文版由天下文化出版，譯名《MIT 最打動人心的溝通課》。</p>
<ul>
<li><a href="https://www.amazon.com/Humble-Inquiry-3rd-Instead-Telling/dp/B0DJCSXNMK">Amazon（Humble Inquiry, 3rd Edition，含遠距工作專章）</a></li>
<li><a href="https://www.amazon.com/Humble-Inquiry-Second-Instead-Leadership/dp/1523092629">Amazon（Humble Inquiry, Second Edition）</a></li>
<li><a href="https://www.books.com.tw/products/0010660316">博客來（MIT 最打動人心的溝通課：組織心理學大師教你謙遜提問的藝術）</a></li>
</ul>
<h2 id="沒有職權要推動改變時讀-the-secrets-of-consulting">沒有職權要推動改變時讀 The Secrets of Consulting</h2>
<p>Gerald Weinberg 的《The Secrets of Consulting》處理的是在沒有指揮權的位置上推動改變。這個處境在現在的組織裡很普遍，而多數管理書預設讀者有直接權限，因此這本承擔的角色在這條線上少有其他書填補。</p>
<p>書中的法則多半以格言形式出現，篇幅短、可以脫離原文脈絡引用。第一法則是「不管客戶怎麼說，一定有問題」；第二法則是「無論問題乍看之下如何，問題一定出在人身上」。定價、拒絕、處理抗拒、判斷什麼時候該退出，這些主題在技術書架上幾乎找不到對應。</p>
<p>證據來源是跨客戶的顧問經驗。時效上，影響力的機制部分處理的是被求助者與求助者的關係位置，沒有發現依賴時代條件的部分。處境上，全書預設的僱傭關係是獨立顧問對客戶——收費、合約、什麼時候退出這幾章，對組織內部的技術影響者不適用，因為他退不掉也不收費。試過一次「我明明是對的但沒人動」的人，讀這些法則會覺得精準；沒試過的，會覺得玩世不恭——讀得出價值的前提就在那一次。</p>
<ul>
<li><a href="https://www.amazon.com/Secrets-Consulting-Giving-Getting-Successfully/dp/0932633013">Amazon（The Secrets of Consulting）</a></li>
<li><a href="https://www.books.com.tw/products/0010711585">博客來（顧問成功的祕密：有效建議、促成改變的工作智慧，10 週年智慧紀念版）</a></li>
</ul>
<h2 id="想看自己在壓力下的反應時讀溫伯格第-3-卷">想看自己在壓力下的反應時讀溫伯格第 3 卷</h2>
<p>Weinberg 的《Quality Software Management, Vol. 3: Congruent Action》處理的是管理者在壓力下的即時反應：被高層質問時為什麼會撒謊、為什麼明知進度不可能還是點頭、為什麼團隊裡沒人敢說壞消息。這是他四卷本裡在這條線的其他書中沒有對應的一卷。</p>
<p>核心工具是從家族治療師 Virginia Satir 借來的 <a href="/blog/til/behavior/satir-coping-stances/" data-link-title="Satir 四種不一致姿態：人在壓力下會丟掉自己、他人或情境其中一項" data-link-desc="被質問的當下說出了自己也不同意的話時，用來標定剛才丟掉了什麼——這是自我觀察的檢查表，不是人格分類">四種不一致姿態</a>——指責、討好、超理智、打岔。它們的用途是標定「我剛剛是哪一種」，屬於自我觀察的檢查表而非理論。這也是它與這個主題其他書的差別：那些書處理對別人說什麼，這一卷處理自己當下正在做什麼。</p>
<p>四卷本的標準順序讓不少讀者卡在第一卷，因為那卷整卷在鋪陳看事情的方式、沒有可照抄的步驟。從第 3 卷進入比較有畫面感，讀完再回頭看第 1 卷會比較清楚整套在建立什麼。</p>
<p>證據來源是跨客戶的顧問經驗加上理論建構（Satir 的治療模型）。時效上，書中的專案是以年為單位的節奏，會議形式已經不同；四種姿態處理的是人在被質問時的自我保護反應，不依賴那個節奏。處境上，它預設的組織形態是階層式匯報——被質問的壓力來自上一層，而扁平組織與非同步協作裡那個壓力換了形狀，姿態本身仍在。這四個姿態要在自己身上認出來才有用，當成人格分類就白讀了。認得出來的前提是經歷過一次「我知道該說什麼但沒說出口」。中文翻譯偏直譯，作者愛用寓言與迂迴的講法，讀起來需要耐心。</p>
<ul>
<li><a href="https://www.amazon.com/Quality-Software-Management-Vol-Congruent/dp/0932633285">Amazon（Quality Software Management, Vol. 3: Congruent Action）</a></li>
<li><a href="https://www.books.com.tw/products/0010444273">博客來（溫伯格的軟體管理學：關照全局的管理作為，第 3 卷）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>這個主題的五本按對話的時間軸與位置排：準備與診斷（Difficult Conversations）、失控時的復原（Crucial Conversations）、還沒開口前的提問（Humble Inquiry）、沒有職權的長期影響力（Secrets of Consulting）、自己當下的反應（溫伯格第 3 卷）。前三本處理對別人，後兩本處理對自己與對關係。</p>
<p>溝通與說服的書是書市數量最龐大的類別之一，多數建立在單一技巧的推廣（談判話術、非暴力溝通、影響力原則）。技巧層的書共同的限制是它們假設讀者已經知道自己想達成什麼，而困難對話卡住的原因通常是還沒弄清楚自己真正在乎什麼——翻目錄先找「我到底為什麼不敢講」這一層有沒有被處理，只給句型的表示它跳過了。</p>
<p>Robert Cialdini 的《Influence》常被列進這類書單。本書單未評估它在組織內部長期關係中的適用性——它的六個原則來自消費決策與陌生人之間的說服實驗，用在每天要再見面的同事身上會不會反噬，需要另外的證據才能判斷，這裡沒有做。要處理的是對外簡報或一次性的說服場合時，那本是直接對應的書。</p>
<p>這個主題沒查到可以收的公開課，而缺的不是數量：以它為名的課很多，內容集中在技巧演練與商業培訓，跨不過本質恆定那一條。它要的機制（承諾可信度與訊號傳遞）在鄰近學科有課，只是這一輪沒有拿那組詞去搜。整條線的供給狀況與那個換法寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>對話技術解決不了結構性的沉默——當講真話會被懲罰，再好的問法也拿不到真話。那條路徑走 <a href="../culture-safety/">組織文化與心理安全感</a>。</p>
<p>要推動的具體改變若是團隊怎麼切、交接面誰負責，走 <a href="../team-design/">組織結構與團隊設計</a>。若要推動的是交付做法，先取得證據會比取得共識容易，走 <a href="../continuous-delivery/">持續交付與交付效能</a>。</p>
<p>同一件事發生在一群人身上時要換工具：這裡處理的是兩個人與對話當下的幾十秒，一整場討論怎麼發散與收斂是流程設計的問題，走 <a href="../meeting-facilitation/">會議引導與群體決策</a>。</p>
<p>想知道無職權影響力在職涯路徑上對應哪個位置，走 <a href="../role-transitions/">角色轉換與職涯路徑</a>。</p>
<p>這個主題有一類讀者在組織之外：替家人管理資產、或要跟不熟悉市場的人談一個財務決定的人，卡住的位置同樣在對話而不在方案。起點書的案例本來就涵蓋家庭，直接用得上；哪幾本的移植成本比較高，以及那個處境還要多留下什麼紀錄，寫在 <a href="/blog/books/finance/positions/" data-link-title="依資本責任選書" data-link-desc="手上這筆錢對誰負責決定了同一個主題該從哪一本開始，用來定位自己在哪一格、以及移動前該預習什麼">依資本責任選書</a> 的最後一節。</p>
]]></content:encoded></item><item><title>會議引導與群體決策</title><link>https://tarrragon.github.io/blog/books/software-management/topics/meeting-facilitation/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/meeting-facilitation/</guid><description>&lt;p>這個主題處理一群人在同一段時間裡怎麼一起產生想法、並收斂到一個決定。它跟 &lt;a href="../influence-conversation/">困難對話與無權限影響力&lt;/a> 的分界在單位：那邊是兩個人與對話當下的幾十秒，這邊是一群人與整場流程的設計。分開的理由是失敗的形態不同——一對一談崩了當事人知道，而一場沒有真正收斂的會議會以「大家都同意了」的形式結束，問題要到執行時才浮出來。&lt;/p>
&lt;p>三本書對「把人聚在一起想事情」的信任度不同，而那條線是選書的主軸。Kaner 的整套設計建立在群體能一起想；de Bono 認為可以，但要先規定所有人在同一時間只用一種模式；Knapp 的流程把產出環節退回個人，只把評估與收斂留給群體。常見的會議格式各自預設了這條線上的某一點，而那個預設很少被說出來過。&lt;/p>
&lt;h2 id="起點是-facilitators-guide-to-participatory-decision-making">起點是 Facilitator&amp;rsquo;s Guide to Participatory Decision-Making&lt;/h2>
&lt;p>Sam Kaner 這本從發散到收斂的每一段都給得出對應的做法，而不只處理其中一個環節——本篇最完整的一本因此是它。它的骨架是鑽石模型：發散期把選項攤開、中間一段混亂、收斂期做出決定。&lt;/p>
&lt;p>中間那一段是 Kaner 給了名字的部分——groan zone（簡體中文版譯為動盪期）。他的觀察是會議正是在這裡崩掉：意見已經攤開、彼此不相容、氣氛開始難受，而在場的人把這個難受讀成討論出了問題。主持人於是提早收斂，收出來的通常是最早被提出、最少人反對的那個選項。Kaner 的主張是這段難受是把各自的參考框架換成共有框架的必經過程，主持人的任務是讓它持續下去、不提早收斂。這個命名之所以有用，在於它讓那段時間變得可以指認——會議進行到一半有人說「我們現在在 groan zone」，跟有人說「大家好像談不攏」，導出的下一步完全不同。&lt;/p>
&lt;p>書的形式是操作手冊：兩百多項工具、大量圖解與可直接印出來的講義，每一項標明用在哪個階段。這使它的用法偏向隨手查，而非從頭讀完。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是跨客戶的顧問經驗，來自 Kaner 所屬的引導顧問機構 Community at Work 數十年的現場累積。時效上，通路上另列了一個預告補上虛擬環境工具與案例的新版，出版日期以通路頁為準，現在買得到的仍是第 3 版。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，第 3 版的兩百多項工具預設實體會議室、掛圖與便利貼——這是全篇與&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>耦合最緊的一本，遠距與非同步的引導要自己折算，而書中的工具多數以「大家看得到同一張紙」為前提。讀得出價值的前提是主持過會議，而且遇過那種討論了兩小時、最後照最早提的方案做的收場。繁體中文版查不到；簡體中文版《結構化研討：參與式決策操作手冊》第 3 版由電子工業出版社出版。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Facilitators-Participatory-Decision-Making-Jossey-bass-Management/dp/1118404955">Amazon（Facilitator&amp;rsquo;s Guide to Participatory Decision-Making, 3rd Edition）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Facilitators-Guide-Participatory-Decision-Making-Kaner/dp/1119789060">Amazon（Facilitator&amp;rsquo;s Guide to Participatory Decision-Making，新版）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/CN11339885">博客來（結構化研討：參與式決策操作手冊，第 3 版，簡體中文版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要一個當天就能導入的協議時讀六頂思考帽">要一個當天就能導入的協議時讀六頂思考帽&lt;/h2>
&lt;p>Edward de Bono 這本是本篇門檻最低的一本：一個下午讀得完，隔天的會議就能用。它推的是平行思考——全場在同一時間處於同一個思考模式，由主持決定順序與切換時機。白帽查事實、紅帽講直覺與情緒、黑帽找風險、黃帽找好處、綠帽產生替代方案、藍帽管理流程本身。&lt;/p>
&lt;p>它要解的失敗很具體：有人提案、有人立刻挑洞，提案者轉入防守，接下來的討論變成立場攻防而非問題探索。de Bono 的診斷是這種會議裡每個人的模式不同步，而不同模式的輸出無法互相回應——正在給事實的人跟正在挑風險的人不是在討論同一件事。把模式在時間上切開之後，衝突從人與人之間移到議題的不同面向之間。&lt;/p>
&lt;p>紅帽在這六頂裡承擔的功能其他五頂都沒有：它給情緒一個合法的發言時段，而且不要求說明理由。用途是把原本會偽裝成技術論證的反對攤開——「我對這個方案不安但說不出為什麼」在一般會議裡只能包裝成挑技術毛病，而包裝過的反對無法被處理。&lt;/p>
&lt;p>&lt;strong>證據來源是這本書最需要先知道的一項。&lt;/strong> 證據來源是作者自建的方法：這套理論由 de Bono 提出，效果宣稱來自企業訓練的自陳而沒有獨立驗證。目前找得到的獨立系統性評估是 Moseley 等人的《Frameworks for Thinking》（劍橋大學出版社），結論是沒有足夠研究證據支持這類訓練帶來可推廣的思考能力提升；同一份評述也指出 de Bono 關心的是點子怎麼發展得更好，而不是證明這套做法可靠或有效。這個取向本身是判讀這本書時最該先知道的一件事。&lt;/p>
&lt;p>這一項導出的閱讀決定很明確：拿它當自己團隊的實驗協議可行，拿它去支持組織層級的做法改變則需要另外找依據。它拿不到起點書則是更前面一層的事——&lt;a href="../">起點書判準&lt;/a>第一項是涵蓋面，而它只處理討論進行中的模式切換，發散與收斂的整段流程不在它的範圍。本篇因此是門檻最低的書與起點書分開的一個例子。&lt;/p>
&lt;p>時效上，1985 年出版，機制不綁時代。處境上，它預設一間會議室裡的同步討論——全場同時處於同一個模式這個執行前提在非同步協作下要重新設計，書裡沒有處理。讀得出價值的前提是主持過那種全場在互相防守、而不是在想事情的會議。繁體中文版《六頂思考帽（全新修訂版）：思考大師狄波諾改變全世界的創新思維工具》，商業周刊出版、劉慧玉譯。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Six-Thinking-Hats-Edward-Bono/dp/0241257530">Amazon（Six Thinking Hats）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010962021">博客來（六頂思考帽 全新修訂版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="對一群人一起發想存疑時讀-sprint">對「一群人一起發想」存疑時讀 Sprint&lt;/h2>
&lt;p>Jake Knapp 與另兩位 GV 設計合夥人這本給的是一份五天的逐時腳本：週一收斂問題、週二各自畫方案、週三選一個、週四做原型、週五交給真實使用者測。&lt;/p>
&lt;p>它在這個主題的位置是對前兩本的實務保留。產出環節在這套流程裡是各自安靜工作——所有人同時在紙上畫自己的方案，畫完才一起看。決策也不求共識，由一位事先指定的 Decider 定案。這跟 Kaner 的參與式決策是相反的設計：那邊要的是全員共有、因而執行時不會有人陽奉陰違的決定，這邊要的是快到可以在同一週被真實使用者否決的決定。&lt;/p>
&lt;p>這個分歧有第三方證據可以裁判其中一段。Diehl 與 Stroebe 1987 年在《Journal of Personality and Social Psychology》發表的四個實驗指出，一起發想的群體，產出比同人數各自作業再合併的產出少，主因是輪流發言造成的阻塞——等待發言的人一邊記住自己的點子一邊聽別人講，兩件事互相干擾。這支持 Knapp 在產出環節的做法。但它裁判的只有產出這一段；收斂該不該全員參與，那組實驗不回答，而那正是 Kaner 那本的主場。&lt;/p>
&lt;p>證據來源是單一組織的深度重建，內容是 GV 一百多次 sprint 的自陳，形式是逐日逐時的操作腳本。時效上，2016 年出版，流程本身沒有發現過時的部分。處境上，它預設五個工作天全員實體集中，那個前提在分散團隊裡難以滿足，書裡沒有處理替代做法。讀得出價值的前提是權限而非經驗：這本書的讀者是能清空一組人整整一週行事曆的人。繁體中文版《Google 衝刺工作法（暢銷新裝版）》，時報出版、許瑞宋譯。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Sprint-Solve-Problems-Test-Ideas/dp/150112174X">Amazon（Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010986138">博客來（Google 衝刺工作法，暢銷新裝版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>三本按對群體同步的信任度排：完整流程與全員共有的決定（Kaner）、當天可導入的模式切換協議（de Bono）、把產出退回個人而只讓群體評估（Knapp）。起點書在判準的第一項就定案：這個主題問的是一群人的想法怎麼產生並收斂，而 Kaner 覆蓋從發散到收斂的整段流程、不綁定特定場合；de Bono 只處理討論中的模式切換，Knapp 給的是一個綁定五天與全員到齊的特定格式。涵蓋面在第一項就分出勝負，證據那一項因此沒有被走到。它們可以疊用——用鑽石模型判斷現在在哪個階段、用六頂思考帽處理某一段的模式混雜、用 Sprint 的獨立產出取代發散階段的口頭腦力激盪。&lt;/p>
&lt;p>會議與引導的書市有一大類是單一格式的推廣書（世界咖啡館、開放空間、各種工作坊配方）。那類的共同限制是格式預設了適用條件而不寫出來，分辨方法跟架構風格的推廣書一樣：看它有沒有寫什麼情況下不要用這個格式。會議格式的邊界通常落在參與者之間的權力落差上——多數格式預設在場的人開口的代價相同，那個假設不成立時，格式會放大落差而不是抵銷它。&lt;/p>
&lt;p>Dave Gray 等人的《Gamestorming》是工作坊活動的目錄，這裡按不同軸排除：它的性質接近參考書而非流程設計，而這三本要回答的是一群人的想法怎麼產生並收斂。&lt;/p>
&lt;p>Ed Catmull 的《Creativity, Inc.》常被列進這類討論，本書單未評估它。皮克斯的 Braintrust 是這個主題的重要案例，但要判斷那套做法能不能脫離皮克斯的組織條件被複製，需要的證據不在書裡，這裡沒有做。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而缺的不是數量：以它為名的課很多，內容集中在技巧演練與商業培訓，跨不過本質恆定那一條。它要的機制（集體決策與資訊聚合）在鄰近學科有課，只是這一輪沒有拿那組詞去搜。整條線的供給狀況與那個換法寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>流程設計解決不了「講真話會被懲罰」。會議格式再好，當說出真實顧慮的人事後被記上一筆，紅帽時段也只會收到安全的答案，那條路徑走 &lt;a href="../culture-safety/">組織文化與心理安全感&lt;/a>。&lt;/p>
&lt;p>會議上做出的決定本身會被偏誤帶走——錨定在第一個被提出的數字、對已投入的成本捨不得放，那些走 &lt;a href="../estimation-decision/">估算、承諾與決策偏誤&lt;/a>。要處理的是一對一而非一群人，走 &lt;a href="../influence-conversation/">困難對話與無權限影響力&lt;/a>。如果每次會議都在重新定義要解的是什麼問題，那是問題陳述的缺口而非引導技巧的缺口，走 &lt;a href="../problem-definition/">問題定義與系統思考&lt;/a>。&lt;/p>
&lt;p>把思考模式切開分批處理這個做法，站內有兩個實作可以對照：&lt;a href="https://tarrragon.github.io/blog/skills/wrap-decision/" data-link-title="WRAP 決策框架 — 認知偏誤防護與決策品質" data-link-desc="WRAP 決策框架的 blog 好讀版：用錨點確認、資料充足度、選項擴增、現實檢驗、機會成本、行前預想與絆腳索防止自動駕駛式決策。">WRAP 決策法&lt;/a> 把擴增選項、現實檢驗、拉開距離、準備好犯錯排成順序；多輪審查則規定每一輪換一個檢查框架，理由記在 &lt;a href="https://tarrragon.github.io/blog/report/writing-multi-pass-review/" data-link-title="Writing 的 multi-pass review：N 輪 review、每輪換 frame" data-link-desc="寫文章 / 註解 / 文件 / prompt 的「寫」不是單次動作 — 是 N 輪 review。第 1 輪生成、第 2 輪對意圖（#67）、第 3 輪檢查機會成本語氣、第 4 輪 grep-ability、第 5 輪反例 / 邊界。每輪不同 frame、單輪寫不出全部維度。本卡是 #82 在「寫」這個 output 動作的具體實例。">N 輪 review、每輪換 frame&lt;/a>。兩者跟平行思考是同一個原理換載體——同時做多件事會讓每一件都做不好。&lt;/p></description><content:encoded><![CDATA[<p>這個主題處理一群人在同一段時間裡怎麼一起產生想法、並收斂到一個決定。它跟 <a href="../influence-conversation/">困難對話與無權限影響力</a> 的分界在單位：那邊是兩個人與對話當下的幾十秒，這邊是一群人與整場流程的設計。分開的理由是失敗的形態不同——一對一談崩了當事人知道，而一場沒有真正收斂的會議會以「大家都同意了」的形式結束，問題要到執行時才浮出來。</p>
<p>三本書對「把人聚在一起想事情」的信任度不同，而那條線是選書的主軸。Kaner 的整套設計建立在群體能一起想；de Bono 認為可以，但要先規定所有人在同一時間只用一種模式；Knapp 的流程把產出環節退回個人，只把評估與收斂留給群體。常見的會議格式各自預設了這條線上的某一點，而那個預設很少被說出來過。</p>
<h2 id="起點是-facilitators-guide-to-participatory-decision-making">起點是 Facilitator&rsquo;s Guide to Participatory Decision-Making</h2>
<p>Sam Kaner 這本從發散到收斂的每一段都給得出對應的做法，而不只處理其中一個環節——本篇最完整的一本因此是它。它的骨架是鑽石模型：發散期把選項攤開、中間一段混亂、收斂期做出決定。</p>
<p>中間那一段是 Kaner 給了名字的部分——groan zone（簡體中文版譯為動盪期）。他的觀察是會議正是在這裡崩掉：意見已經攤開、彼此不相容、氣氛開始難受，而在場的人把這個難受讀成討論出了問題。主持人於是提早收斂，收出來的通常是最早被提出、最少人反對的那個選項。Kaner 的主張是這段難受是把各自的參考框架換成共有框架的必經過程，主持人的任務是讓它持續下去、不提早收斂。這個命名之所以有用，在於它讓那段時間變得可以指認——會議進行到一半有人說「我們現在在 groan zone」，跟有人說「大家好像談不攏」，導出的下一步完全不同。</p>
<p>書的形式是操作手冊：兩百多項工具、大量圖解與可直接印出來的講義，每一項標明用在哪個階段。這使它的用法偏向隨手查，而非從頭讀完。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是跨客戶的顧問經驗，來自 Kaner 所屬的引導顧問機構 Community at Work 數十年的現場累積。時效上，通路上另列了一個預告補上虛擬環境工具與案例的新版，出版日期以通路頁為準，現在買得到的仍是第 3 版。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，第 3 版的兩百多項工具預設實體會議室、掛圖與便利貼——這是全篇與<a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a>耦合最緊的一本，遠距與非同步的引導要自己折算，而書中的工具多數以「大家看得到同一張紙」為前提。讀得出價值的前提是主持過會議，而且遇過那種討論了兩小時、最後照最早提的方案做的收場。繁體中文版查不到；簡體中文版《結構化研討：參與式決策操作手冊》第 3 版由電子工業出版社出版。</p>
<ul>
<li><a href="https://www.amazon.com/Facilitators-Participatory-Decision-Making-Jossey-bass-Management/dp/1118404955">Amazon（Facilitator&rsquo;s Guide to Participatory Decision-Making, 3rd Edition）</a></li>
<li><a href="https://www.amazon.com/Facilitators-Guide-Participatory-Decision-Making-Kaner/dp/1119789060">Amazon（Facilitator&rsquo;s Guide to Participatory Decision-Making，新版）</a></li>
<li><a href="https://www.books.com.tw/products/CN11339885">博客來（結構化研討：參與式決策操作手冊，第 3 版，簡體中文版）</a></li>
</ul>
<h2 id="要一個當天就能導入的協議時讀六頂思考帽">要一個當天就能導入的協議時讀六頂思考帽</h2>
<p>Edward de Bono 這本是本篇門檻最低的一本：一個下午讀得完，隔天的會議就能用。它推的是平行思考——全場在同一時間處於同一個思考模式，由主持決定順序與切換時機。白帽查事實、紅帽講直覺與情緒、黑帽找風險、黃帽找好處、綠帽產生替代方案、藍帽管理流程本身。</p>
<p>它要解的失敗很具體：有人提案、有人立刻挑洞，提案者轉入防守，接下來的討論變成立場攻防而非問題探索。de Bono 的診斷是這種會議裡每個人的模式不同步，而不同模式的輸出無法互相回應——正在給事實的人跟正在挑風險的人不是在討論同一件事。把模式在時間上切開之後，衝突從人與人之間移到議題的不同面向之間。</p>
<p>紅帽在這六頂裡承擔的功能其他五頂都沒有：它給情緒一個合法的發言時段，而且不要求說明理由。用途是把原本會偽裝成技術論證的反對攤開——「我對這個方案不安但說不出為什麼」在一般會議裡只能包裝成挑技術毛病，而包裝過的反對無法被處理。</p>
<p><strong>證據來源是這本書最需要先知道的一項。</strong> 證據來源是作者自建的方法：這套理論由 de Bono 提出，效果宣稱來自企業訓練的自陳而沒有獨立驗證。目前找得到的獨立系統性評估是 Moseley 等人的《Frameworks for Thinking》（劍橋大學出版社），結論是沒有足夠研究證據支持這類訓練帶來可推廣的思考能力提升；同一份評述也指出 de Bono 關心的是點子怎麼發展得更好，而不是證明這套做法可靠或有效。這個取向本身是判讀這本書時最該先知道的一件事。</p>
<p>這一項導出的閱讀決定很明確：拿它當自己團隊的實驗協議可行，拿它去支持組織層級的做法改變則需要另外找依據。它拿不到起點書則是更前面一層的事——<a href="../">起點書判準</a>第一項是涵蓋面，而它只處理討論進行中的模式切換，發散與收斂的整段流程不在它的範圍。本篇因此是門檻最低的書與起點書分開的一個例子。</p>
<p>時效上，1985 年出版，機制不綁時代。處境上，它預設一間會議室裡的同步討論——全場同時處於同一個模式這個執行前提在非同步協作下要重新設計，書裡沒有處理。讀得出價值的前提是主持過那種全場在互相防守、而不是在想事情的會議。繁體中文版《六頂思考帽（全新修訂版）：思考大師狄波諾改變全世界的創新思維工具》，商業周刊出版、劉慧玉譯。</p>
<ul>
<li><a href="https://www.amazon.com/Six-Thinking-Hats-Edward-Bono/dp/0241257530">Amazon（Six Thinking Hats）</a></li>
<li><a href="https://www.books.com.tw/products/0010962021">博客來（六頂思考帽 全新修訂版）</a></li>
</ul>
<h2 id="對一群人一起發想存疑時讀-sprint">對「一群人一起發想」存疑時讀 Sprint</h2>
<p>Jake Knapp 與另兩位 GV 設計合夥人這本給的是一份五天的逐時腳本：週一收斂問題、週二各自畫方案、週三選一個、週四做原型、週五交給真實使用者測。</p>
<p>它在這個主題的位置是對前兩本的實務保留。產出環節在這套流程裡是各自安靜工作——所有人同時在紙上畫自己的方案，畫完才一起看。決策也不求共識，由一位事先指定的 Decider 定案。這跟 Kaner 的參與式決策是相反的設計：那邊要的是全員共有、因而執行時不會有人陽奉陰違的決定，這邊要的是快到可以在同一週被真實使用者否決的決定。</p>
<p>這個分歧有第三方證據可以裁判其中一段。Diehl 與 Stroebe 1987 年在《Journal of Personality and Social Psychology》發表的四個實驗指出，一起發想的群體，產出比同人數各自作業再合併的產出少，主因是輪流發言造成的阻塞——等待發言的人一邊記住自己的點子一邊聽別人講，兩件事互相干擾。這支持 Knapp 在產出環節的做法。但它裁判的只有產出這一段；收斂該不該全員參與，那組實驗不回答，而那正是 Kaner 那本的主場。</p>
<p>證據來源是單一組織的深度重建，內容是 GV 一百多次 sprint 的自陳，形式是逐日逐時的操作腳本。時效上，2016 年出版，流程本身沒有發現過時的部分。處境上，它預設五個工作天全員實體集中，那個前提在分散團隊裡難以滿足，書裡沒有處理替代做法。讀得出價值的前提是權限而非經驗：這本書的讀者是能清空一組人整整一週行事曆的人。繁體中文版《Google 衝刺工作法（暢銷新裝版）》，時報出版、許瑞宋譯。</p>
<ul>
<li><a href="https://www.amazon.com/Sprint-Solve-Problems-Test-Ideas/dp/150112174X">Amazon（Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days）</a></li>
<li><a href="https://www.books.com.tw/products/0010986138">博客來（Google 衝刺工作法，暢銷新裝版）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>三本按對群體同步的信任度排：完整流程與全員共有的決定（Kaner）、當天可導入的模式切換協議（de Bono）、把產出退回個人而只讓群體評估（Knapp）。起點書在判準的第一項就定案：這個主題問的是一群人的想法怎麼產生並收斂，而 Kaner 覆蓋從發散到收斂的整段流程、不綁定特定場合；de Bono 只處理討論中的模式切換，Knapp 給的是一個綁定五天與全員到齊的特定格式。涵蓋面在第一項就分出勝負，證據那一項因此沒有被走到。它們可以疊用——用鑽石模型判斷現在在哪個階段、用六頂思考帽處理某一段的模式混雜、用 Sprint 的獨立產出取代發散階段的口頭腦力激盪。</p>
<p>會議與引導的書市有一大類是單一格式的推廣書（世界咖啡館、開放空間、各種工作坊配方）。那類的共同限制是格式預設了適用條件而不寫出來，分辨方法跟架構風格的推廣書一樣：看它有沒有寫什麼情況下不要用這個格式。會議格式的邊界通常落在參與者之間的權力落差上——多數格式預設在場的人開口的代價相同，那個假設不成立時，格式會放大落差而不是抵銷它。</p>
<p>Dave Gray 等人的《Gamestorming》是工作坊活動的目錄，這裡按不同軸排除：它的性質接近參考書而非流程設計，而這三本要回答的是一群人的想法怎麼產生並收斂。</p>
<p>Ed Catmull 的《Creativity, Inc.》常被列進這類討論，本書單未評估它。皮克斯的 Braintrust 是這個主題的重要案例，但要判斷那套做法能不能脫離皮克斯的組織條件被複製，需要的證據不在書裡，這裡沒有做。</p>
<p>這個主題沒查到可以收的公開課，而缺的不是數量：以它為名的課很多，內容集中在技巧演練與商業培訓，跨不過本質恆定那一條。它要的機制（集體決策與資訊聚合）在鄰近學科有課，只是這一輪沒有拿那組詞去搜。整條線的供給狀況與那個換法寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>流程設計解決不了「講真話會被懲罰」。會議格式再好，當說出真實顧慮的人事後被記上一筆，紅帽時段也只會收到安全的答案，那條路徑走 <a href="../culture-safety/">組織文化與心理安全感</a>。</p>
<p>會議上做出的決定本身會被偏誤帶走——錨定在第一個被提出的數字、對已投入的成本捨不得放，那些走 <a href="../estimation-decision/">估算、承諾與決策偏誤</a>。要處理的是一對一而非一群人，走 <a href="../influence-conversation/">困難對話與無權限影響力</a>。如果每次會議都在重新定義要解的是什麼問題，那是問題陳述的缺口而非引導技巧的缺口，走 <a href="../problem-definition/">問題定義與系統思考</a>。</p>
<p>把思考模式切開分批處理這個做法，站內有兩個實作可以對照：<a href="/blog/skills/wrap-decision/" data-link-title="WRAP 決策框架 — 認知偏誤防護與決策品質" data-link-desc="WRAP 決策框架的 blog 好讀版：用錨點確認、資料充足度、選項擴增、現實檢驗、機會成本、行前預想與絆腳索防止自動駕駛式決策。">WRAP 決策法</a> 把擴增選項、現實檢驗、拉開距離、準備好犯錯排成順序；多輪審查則規定每一輪換一個檢查框架，理由記在 <a href="/blog/report/writing-multi-pass-review/" data-link-title="Writing 的 multi-pass review：N 輪 review、每輪換 frame" data-link-desc="寫文章 / 註解 / 文件 / prompt 的「寫」不是單次動作 — 是 N 輪 review。第 1 輪生成、第 2 輪對意圖（#67）、第 3 輪檢查機會成本語氣、第 4 輪 grep-ability、第 5 輪反例 / 邊界。每輪不同 frame、單輪寫不出全部維度。本卡是 #82 在「寫」這個 output 動作的具體實例。">N 輪 review、每輪換 frame</a>。兩者跟平行思考是同一個原理換載體——同時做多件事會讓每一件都做不好。</p>
]]></content:encoded></item><item><title>角色轉換與職涯路徑</title><link>https://tarrragon.github.io/blog/books/software-management/topics/role-transitions/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/role-transitions/</guid><description>&lt;p>這個主題的書按角色而非按問題組織，在管理線裡只有這一篇這樣切。其他主題篇問「這個問題該讀什麼」，這一篇問「這個位置的人整天在做什麼」。之所以需要這個落點，是因為有一整類書本身就按角色寫成，內容橫跨多個主題而不屬於其中任何一個——把它們拆進各主題會失去「這個位置的全貌」，而全貌正是要換位置的人需要的東西。&lt;/p>
&lt;p>這類書的價值有兩種用法：在自己的位置上用來確認哪些事該做而自己沒在做，以及在轉換之前用來預習。後者尤其重要，因為多數位置轉換的失敗來自不知道新位置的成功長什麼樣，而不是能力不足。&lt;/p>
&lt;p>預習有一個時間差要注意。位置轉換前讀這些書，能讀到的是地圖；真正的判準要等到承擔了責任才長出來。因此比較有效的用法是轉換前讀一次建立預期，等到自己獨立走完一輪那個位置的完整循環（帶完一次績效週期、獨立處理過一次人的問題、或主導完一次跨團隊的交付）之後再讀一次，兩次讀到的東西不同。&lt;/p>
&lt;h2 id="起點是-the-managers-path">起點是 The Manager&amp;rsquo;s Path&lt;/h2>
&lt;p>Camille Fournier 的《The Manager&amp;rsquo;s Path》一本鋪完整條路徑，涵蓋面在本篇最廣。它從「怎麼被管理」開始，接著是 mentor、tech lead、管理個人、管理團隊、管理多個團隊、管理管理者，最後到資深領導。每章結構相似：這個角色實際在做什麼、常見的失敗模式、怎麼判斷自己準備好進下一層。&lt;/p>
&lt;p>它最實用的部分是把模糊的角色講具體。tech lead 與 manager 的差別、什麼時候該停止自己寫程式、一對一該由誰決定議程、績效不佳的人該怎麼處理，這些問題書裡有明確立場而非兩面兼顧的說法。&lt;/p>
&lt;p>&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>是單一路徑的個人經驗（作者在 Rent the Runway 擔任 CTO 及先前的任職）。例子多來自中型組織，對多數團隊的規模比大廠案例貼近。&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>上，那道階梯預設組織大到每一層都有專人——tech lead、EM、總監各自是一個人的工作。三十人以下的公司這幾層會壓在同一個人身上，那時它的用途是預覽下一階，而不是對照當下。時效上，書中的職級與晉升描述反映 2010 年代中期的美國科技業，遠距團隊的管理不在討論範圍；各層角色的職責劃分與一對一的用法不依賴那個時空。它的前提是位置而非經驗：正處在書中某一層、或即將進入下一層——建議只讀自己這一層加上一層，整本讀完的人通常記不住用不到的部分，升層時還是要回頭重讀。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897">Amazon（The Manager&amp;rsquo;s Path）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010890612">博客來（經理人之道：技術領袖航向成長與改變的參考指南）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="還在個人貢獻者階段時讀-the-software-engineers-guidebook">還在個人貢獻者階段時讀 The Software Engineer&amp;rsquo;s Guidebook&lt;/h2>
&lt;p>Gergely Orosz 的《The Software Engineer&amp;rsquo;s Guidebook》涵蓋從入門工程師到 principal 以上的各個級別，並且針對每個級別分別處理軟體工程、協作、把事情做完這幾組能力。&lt;/p>
&lt;p>它對只對自己產出負責的位置特別有用，因為它明確回答了一個在那個位置上最難自己看清的問題：下一級別的人跟我的差別具體在哪。多數公司的職級描述寫得抽象（影響範圍、獨立性、複雜度），這本書把它翻成可觀察的行為。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗（作者在 Uber、Skyscanner、Microsoft、Skype 的任職），加上長期經營的產業電子報累積的跨公司觀察，後者讓它比純粹的單一路徑多一層廣度。處境上，整本書的骨架是職級制度：能力被翻成級別、級別對應可觀察的行為。沒有職級的組織——新創、接案、共同創辦人之間——讀它拿得到那份能力清單，拿不到把清單排序的那根軸，而排序正是它最有用的部分。時效上是本篇最新的一本，對現在的大廠職級制度與遠距工作型態有直接處理。它的內容綁在職級制度上，那套制度改版時這本書會跟著失準，目前還沒有。讀得出價值的前提幾乎沒有——它是本篇門檻最低的一本，剛入行就可以讀，只是後半的高階級別章節要等到用得上時再回頭看。繁體中文版由碁峰資訊出版，沈佩誼譯，譯名《軟體工程師的晉升之路》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Software-Engineers-Guidebook-Navigating-positions/dp/908338182X">Amazon（The Software Engineer&amp;rsquo;s Guidebook）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0011030029">博客來（軟體工程師的晉升之路：全方位升遷攻略）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="要走技術路線而非管理路線時讀-staff-工程師的兩本">要走技術路線而非管理路線時讀 Staff 工程師的兩本&lt;/h2>
&lt;p>Tanya Reilly 的《The Staff Engineer&amp;rsquo;s Path》處理的是不帶人但要對技術品質負責的位置。它把這個角色拆成三根支柱：用寬廣的視角看自己的工作、把專案實際推成功的戰術、以及決定在自己的組織裡「好的工程」是什麼意思。第三根支柱是這本書在這條線上少有其他書處理的部分——沒有職權的人如何設定標準。&lt;/p>
&lt;p>Will Larson 的《Staff Engineer》（Tanya Reilly 作序）是另一種形式：它包含 Larson 的框架加上多位 staff 工程師的訪談，因此提供的是多條路徑的樣本而非單一敘事。想知道這個位置在不同公司長什麼樣的人，訪談的部分價值較高。&lt;/p>
&lt;p>兩本與這個主題的其他書承擔同一個角色（技術路線的位置說明），彼此的差別在形式而非層級：Reilly 那本提供系統性的能力拆解，Larson 那本提供路徑的多樣性。只讀一本的話讀 Reilly 那本，因為它的三支柱結構可以拿來自我對照，而訪談讀起來是別人的故事。&lt;/p>
&lt;p>證據來源都是單一路徑的個人經驗，Larson 那本另加訪談樣本。時效上，兩本都出版於 2021-2022 年，描述的職級階梯與現在的大廠制度接近，沒有明顯過時的部分。讀得出價值的前提是：已經是資深工程師、且開始被要求處理跨團隊的技術問題——工作範圍還限在自己的模組裡時讀，三支柱會讀成空話。Reilly 那本有繁體中文版，譯名《Staff 工程師之路》；Larson 那本沒有正式出版的中譯本，網路上有社群自譯的版本。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Staff-Engineers-Path-Individual-Contributors/dp/1098118731">Amazon（The Staff Engineer&amp;rsquo;s Path: A Guide for Individual Contributors）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010980200">博客來（Staff 工程師之路：獻給個人貢獻者成長與改變的導航指南）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.amazon.com/Staff-Engineer-Leadership-beyond-management/dp/1736417916">Amazon（Staff Engineer: Leadership beyond the management track）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="第一次帶人時讀-the-making-of-a-manager">第一次帶人時讀 The Making of a Manager&lt;/h2>
&lt;p>Julie Zhuo 的《The Making of a Manager》聚焦在第一年。它處理的是新手管理者實際會遇到的具體場景：第一次一對一該說什麼、面試該問什麼、什麼時候該讓表現不佳的人離開、怎麼在自己也不確定的時候給團隊方向。&lt;/p>
&lt;p>它與《The Manager&amp;rsquo;s Path》的差別是範圍與深度的取捨。Fournier 鋪完整條階梯、每層淺一點；Zhuo 只寫第一段路、但把那段寫得細。第一次帶人的當下，後者的可執行性較高。&lt;/p>
&lt;p>證據來源是單一路徑的個人經驗（作者在 Facebook 從第一位實習生做到產品設計副總），且集中在產品設計而非工程管理。時效上，書中的組織規模與遠距前的辦公型態是背景設定；第一年管理者面對的具體場景（第一次一對一、第一次給負評）不依賴那個背景。工程特有的問題（技術決策、輪值、技術債）需要另尋來源。這本有讀它的時間窗：即將帶人或剛開始帶人的那段。已經帶了兩年的人讀它會覺得都知道。繁體中文版由時報出版，譯名《當上主管後，難道只能默默崩潰？》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/Making-Manager-What-Everyone-Looks/dp/0735219567">Amazon（The Making of a Manager: What to Do When Everyone Looks to You）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010855700">博客來（當上主管後，難道只能默默崩潰？）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="想要管理工作的通用定義時讀-high-output-management">想要管理工作的通用定義時讀 High Output Management&lt;/h2>
&lt;p>Andrew Grove 的《High Output Management》提供的是管理這件事的操作定義而非某個角色的指南。核心是把管理者的產出定義成他所轄組織的產出加上他影響所及組織的產出——這個定義把「我今天很忙」與「我今天有產出」分開，並且讓槓桿變成可以計算的東西。&lt;/p>
&lt;p>書中對一對一、決策會議、績效評估、訓練的處理都建立在同一個槓桿邏輯上：這個動作影響多少人的產出、影響多久。這使它跟其他按角色寫的書層級不同——它給的是判斷任何管理動作值不值得做的尺，因此在任何位置都適用。&lt;/p>
&lt;p>1983 年的書，書中的製造業類比、當時的辦公型態與人事制度都需要折算；槓桿邏輯與會議的分類處理的是管理動作與產出之間的關係，不依賴那些條件，因此是折算後留下來的部分。證據來源是單一路徑的個人經驗（作者在 Intel 從創始成員做到執行長）。讀得出價值的前提是已經在分配自己以外的時間——只管自己的行程時，槓桿計算沒有可以套用的對象。繁體中文版譯名《葛洛夫給經理人的第一課》。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884">Amazon（High Output Management）&lt;/a>&lt;/li>
&lt;li>&lt;a href="https://www.books.com.tw/products/0010816790">博客來（葛洛夫給經理人的第一課：從煮蛋、賣咖啡的早餐店談高效能管理之道，3 版）&lt;/a>&lt;/li>
&lt;/ul>
&lt;h2 id="為什麼只收這幾本">為什麼只收這幾本&lt;/h2>
&lt;p>這六本承擔五個角色：整條階梯的地圖（Manager&amp;rsquo;s Path）、個人貢獻者各級別的能力拆解（SE Guidebook）、技術路線的位置說明（Staff 兩本共同承擔）、第一年帶人的具體場景（Making of a Manager）、管理動作的通用尺（High Output Management）。Staff 兩本合佔一個角色，兩本的差別在形式而非涵蓋範圍。&lt;/p>
&lt;p>分佈刻意偏向個人貢獻者與初階管理。理由是位置越高，同一個職稱在不同公司對應的實際工作差異越大，書能提供的通用部分就越少——到了管理管理者這一層，組織的規模、產業與治理結構決定的比書多。&lt;/p>
&lt;p>職涯類的書在技術書市成長很快，多數落在兩個已被承擔的角色：重述大廠職級制度的升等指南，以及個人成功敘事。前者被《The Software Engineer&amp;rsquo;s Guidebook》以更廣的跨公司觀察覆蓋，後者的證據來源無法回答「這在我的公司也成立嗎」——一個快速的過濾條件是問它：換一間制度不同的公司，這條建議會怎麼變。答不出來的是敘事而非分析。&lt;/p>
&lt;p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 &lt;a href="../">主題書單&lt;/a> 的公開課段。&lt;/p>
&lt;h2 id="這個主題接到哪裡">這個主題接到哪裡&lt;/h2>
&lt;p>確定了位置之後，各項具體能力回到對應主題：交付效能走 &lt;a href="../continuous-delivery/">持續交付與交付效能&lt;/a>，團隊切分走 &lt;a href="../team-design/">組織結構與團隊設計&lt;/a>，人留不留得住走 &lt;a href="../retention-motivation/">留任、動機與工作環境&lt;/a>，該講的話講不出口走 &lt;a href="../influence-conversation/">困難對話與無權限影響力&lt;/a>。&lt;/p>
&lt;p>要判斷自己現在站在哪個位置、以及位置對應的起點書，回到 &lt;a href="../../">軟體管理與組織書單&lt;/a> 的位置表。&lt;/p></description><content:encoded><![CDATA[<p>這個主題的書按角色而非按問題組織，在管理線裡只有這一篇這樣切。其他主題篇問「這個問題該讀什麼」，這一篇問「這個位置的人整天在做什麼」。之所以需要這個落點，是因為有一整類書本身就按角色寫成，內容橫跨多個主題而不屬於其中任何一個——把它們拆進各主題會失去「這個位置的全貌」，而全貌正是要換位置的人需要的東西。</p>
<p>這類書的價值有兩種用法：在自己的位置上用來確認哪些事該做而自己沒在做，以及在轉換之前用來預習。後者尤其重要，因為多數位置轉換的失敗來自不知道新位置的成功長什麼樣，而不是能力不足。</p>
<p>預習有一個時間差要注意。位置轉換前讀這些書，能讀到的是地圖；真正的判準要等到承擔了責任才長出來。因此比較有效的用法是轉換前讀一次建立預期，等到自己獨立走完一輪那個位置的完整循環（帶完一次績效週期、獨立處理過一次人的問題、或主導完一次跨團隊的交付）之後再讀一次，兩次讀到的東西不同。</p>
<h2 id="起點是-the-managers-path">起點是 The Manager&rsquo;s Path</h2>
<p>Camille Fournier 的《The Manager&rsquo;s Path》一本鋪完整條路徑，涵蓋面在本篇最廣。它從「怎麼被管理」開始，接著是 mentor、tech lead、管理個人、管理團隊、管理多個團隊、管理管理者，最後到資深領導。每章結構相似：這個角色實際在做什麼、常見的失敗模式、怎麼判斷自己準備好進下一層。</p>
<p>它最實用的部分是把模糊的角色講具體。tech lead 與 manager 的差別、什麼時候該停止自己寫程式、一對一該由誰決定議程、績效不佳的人該怎麼處理，這些問題書裡有明確立場而非兩面兼顧的說法。</p>
<p><a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>是單一路徑的個人經驗（作者在 Rent the Runway 擔任 CTO 及先前的任職）。例子多來自中型組織，對多數團隊的規模比大廠案例貼近。<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>上，那道階梯預設組織大到每一層都有專人——tech lead、EM、總監各自是一個人的工作。三十人以下的公司這幾層會壓在同一個人身上，那時它的用途是預覽下一階，而不是對照當下。時效上，書中的職級與晉升描述反映 2010 年代中期的美國科技業，遠距團隊的管理不在討論範圍；各層角色的職責劃分與一對一的用法不依賴那個時空。它的前提是位置而非經驗：正處在書中某一層、或即將進入下一層——建議只讀自己這一層加上一層，整本讀完的人通常記不住用不到的部分，升層時還是要回頭重讀。</p>
<ul>
<li><a href="https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897">Amazon（The Manager&rsquo;s Path）</a></li>
<li><a href="https://www.books.com.tw/products/0010890612">博客來（經理人之道：技術領袖航向成長與改變的參考指南）</a></li>
</ul>
<h2 id="還在個人貢獻者階段時讀-the-software-engineers-guidebook">還在個人貢獻者階段時讀 The Software Engineer&rsquo;s Guidebook</h2>
<p>Gergely Orosz 的《The Software Engineer&rsquo;s Guidebook》涵蓋從入門工程師到 principal 以上的各個級別，並且針對每個級別分別處理軟體工程、協作、把事情做完這幾組能力。</p>
<p>它對只對自己產出負責的位置特別有用，因為它明確回答了一個在那個位置上最難自己看清的問題：下一級別的人跟我的差別具體在哪。多數公司的職級描述寫得抽象（影響範圍、獨立性、複雜度），這本書把它翻成可觀察的行為。</p>
<p>證據來源是單一路徑的個人經驗（作者在 Uber、Skyscanner、Microsoft、Skype 的任職），加上長期經營的產業電子報累積的跨公司觀察，後者讓它比純粹的單一路徑多一層廣度。處境上，整本書的骨架是職級制度：能力被翻成級別、級別對應可觀察的行為。沒有職級的組織——新創、接案、共同創辦人之間——讀它拿得到那份能力清單，拿不到把清單排序的那根軸，而排序正是它最有用的部分。時效上是本篇最新的一本，對現在的大廠職級制度與遠距工作型態有直接處理。它的內容綁在職級制度上，那套制度改版時這本書會跟著失準，目前還沒有。讀得出價值的前提幾乎沒有——它是本篇門檻最低的一本，剛入行就可以讀，只是後半的高階級別章節要等到用得上時再回頭看。繁體中文版由碁峰資訊出版，沈佩誼譯，譯名《軟體工程師的晉升之路》。</p>
<ul>
<li><a href="https://www.amazon.com/Software-Engineers-Guidebook-Navigating-positions/dp/908338182X">Amazon（The Software Engineer&rsquo;s Guidebook）</a></li>
<li><a href="https://www.books.com.tw/products/0011030029">博客來（軟體工程師的晉升之路：全方位升遷攻略）</a></li>
</ul>
<h2 id="要走技術路線而非管理路線時讀-staff-工程師的兩本">要走技術路線而非管理路線時讀 Staff 工程師的兩本</h2>
<p>Tanya Reilly 的《The Staff Engineer&rsquo;s Path》處理的是不帶人但要對技術品質負責的位置。它把這個角色拆成三根支柱：用寬廣的視角看自己的工作、把專案實際推成功的戰術、以及決定在自己的組織裡「好的工程」是什麼意思。第三根支柱是這本書在這條線上少有其他書處理的部分——沒有職權的人如何設定標準。</p>
<p>Will Larson 的《Staff Engineer》（Tanya Reilly 作序）是另一種形式：它包含 Larson 的框架加上多位 staff 工程師的訪談，因此提供的是多條路徑的樣本而非單一敘事。想知道這個位置在不同公司長什麼樣的人，訪談的部分價值較高。</p>
<p>兩本與這個主題的其他書承擔同一個角色（技術路線的位置說明），彼此的差別在形式而非層級：Reilly 那本提供系統性的能力拆解，Larson 那本提供路徑的多樣性。只讀一本的話讀 Reilly 那本，因為它的三支柱結構可以拿來自我對照，而訪談讀起來是別人的故事。</p>
<p>證據來源都是單一路徑的個人經驗，Larson 那本另加訪談樣本。時效上，兩本都出版於 2021-2022 年，描述的職級階梯與現在的大廠制度接近，沒有明顯過時的部分。讀得出價值的前提是：已經是資深工程師、且開始被要求處理跨團隊的技術問題——工作範圍還限在自己的模組裡時讀，三支柱會讀成空話。Reilly 那本有繁體中文版，譯名《Staff 工程師之路》；Larson 那本沒有正式出版的中譯本，網路上有社群自譯的版本。</p>
<ul>
<li><a href="https://www.amazon.com/Staff-Engineers-Path-Individual-Contributors/dp/1098118731">Amazon（The Staff Engineer&rsquo;s Path: A Guide for Individual Contributors）</a></li>
<li><a href="https://www.books.com.tw/products/0010980200">博客來（Staff 工程師之路：獻給個人貢獻者成長與改變的導航指南）</a></li>
<li><a href="https://www.amazon.com/Staff-Engineer-Leadership-beyond-management/dp/1736417916">Amazon（Staff Engineer: Leadership beyond the management track）</a></li>
</ul>
<h2 id="第一次帶人時讀-the-making-of-a-manager">第一次帶人時讀 The Making of a Manager</h2>
<p>Julie Zhuo 的《The Making of a Manager》聚焦在第一年。它處理的是新手管理者實際會遇到的具體場景：第一次一對一該說什麼、面試該問什麼、什麼時候該讓表現不佳的人離開、怎麼在自己也不確定的時候給團隊方向。</p>
<p>它與《The Manager&rsquo;s Path》的差別是範圍與深度的取捨。Fournier 鋪完整條階梯、每層淺一點；Zhuo 只寫第一段路、但把那段寫得細。第一次帶人的當下，後者的可執行性較高。</p>
<p>證據來源是單一路徑的個人經驗（作者在 Facebook 從第一位實習生做到產品設計副總），且集中在產品設計而非工程管理。時效上，書中的組織規模與遠距前的辦公型態是背景設定；第一年管理者面對的具體場景（第一次一對一、第一次給負評）不依賴那個背景。工程特有的問題（技術決策、輪值、技術債）需要另尋來源。這本有讀它的時間窗：即將帶人或剛開始帶人的那段。已經帶了兩年的人讀它會覺得都知道。繁體中文版由時報出版，譯名《當上主管後，難道只能默默崩潰？》。</p>
<ul>
<li><a href="https://www.amazon.com/Making-Manager-What-Everyone-Looks/dp/0735219567">Amazon（The Making of a Manager: What to Do When Everyone Looks to You）</a></li>
<li><a href="https://www.books.com.tw/products/0010855700">博客來（當上主管後，難道只能默默崩潰？）</a></li>
</ul>
<h2 id="想要管理工作的通用定義時讀-high-output-management">想要管理工作的通用定義時讀 High Output Management</h2>
<p>Andrew Grove 的《High Output Management》提供的是管理這件事的操作定義而非某個角色的指南。核心是把管理者的產出定義成他所轄組織的產出加上他影響所及組織的產出——這個定義把「我今天很忙」與「我今天有產出」分開，並且讓槓桿變成可以計算的東西。</p>
<p>書中對一對一、決策會議、績效評估、訓練的處理都建立在同一個槓桿邏輯上：這個動作影響多少人的產出、影響多久。這使它跟其他按角色寫的書層級不同——它給的是判斷任何管理動作值不值得做的尺，因此在任何位置都適用。</p>
<p>1983 年的書，書中的製造業類比、當時的辦公型態與人事制度都需要折算；槓桿邏輯與會議的分類處理的是管理動作與產出之間的關係，不依賴那些條件，因此是折算後留下來的部分。證據來源是單一路徑的個人經驗（作者在 Intel 從創始成員做到執行長）。讀得出價值的前提是已經在分配自己以外的時間——只管自己的行程時，槓桿計算沒有可以套用的對象。繁體中文版譯名《葛洛夫給經理人的第一課》。</p>
<ul>
<li><a href="https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884">Amazon（High Output Management）</a></li>
<li><a href="https://www.books.com.tw/products/0010816790">博客來（葛洛夫給經理人的第一課：從煮蛋、賣咖啡的早餐店談高效能管理之道，3 版）</a></li>
</ul>
<h2 id="為什麼只收這幾本">為什麼只收這幾本</h2>
<p>這六本承擔五個角色：整條階梯的地圖（Manager&rsquo;s Path）、個人貢獻者各級別的能力拆解（SE Guidebook）、技術路線的位置說明（Staff 兩本共同承擔）、第一年帶人的具體場景（Making of a Manager）、管理動作的通用尺（High Output Management）。Staff 兩本合佔一個角色，兩本的差別在形式而非涵蓋範圍。</p>
<p>分佈刻意偏向個人貢獻者與初階管理。理由是位置越高，同一個職稱在不同公司對應的實際工作差異越大，書能提供的通用部分就越少——到了管理管理者這一層，組織的規模、產業與治理結構決定的比書多。</p>
<p>職涯類的書在技術書市成長很快，多數落在兩個已被承擔的角色：重述大廠職級制度的升等指南，以及個人成功敘事。前者被《The Software Engineer&rsquo;s Guidebook》以更廣的跨公司觀察覆蓋，後者的證據來源無法回答「這在我的公司也成立嗎」——一個快速的過濾條件是問它：換一間制度不同的公司，這條建議會怎麼變。答不出來的是敘事而非分析。</p>
<p>這個主題沒查到可以收的公開課，而成因跟它在哪裡被教有關：組織類題材主要在商學院，而商學院的課最少免費全釋出。這個說法可以被推翻的方式、以及整條線的供給狀況，寫在 <a href="../">主題書單</a> 的公開課段。</p>
<h2 id="這個主題接到哪裡">這個主題接到哪裡</h2>
<p>確定了位置之後，各項具體能力回到對應主題：交付效能走 <a href="../continuous-delivery/">持續交付與交付效能</a>，團隊切分走 <a href="../team-design/">組織結構與團隊設計</a>，人留不留得住走 <a href="../retention-motivation/">留任、動機與工作環境</a>，該講的話講不出口走 <a href="../influence-conversation/">困難對話與無權限影響力</a>。</p>
<p>要判斷自己現在站在哪個位置、以及位置對應的起點書，回到 <a href="../../">軟體管理與組織書單</a> 的位置表。</p>
]]></content:encoded></item></channel></rss>