<?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>主題書單 on Tarragon</title><link>https://tarrragon.github.io/blog/books/software-management/topics/</link><description>Recent content in 主題書單 on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Tue, 18 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/books/software-management/topics/index.xml" rel="self" type="application/rss+xml"/><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/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/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/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/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>