<?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>Management on Tarragon</title><link>https://tarrragon.github.io/blog/tags/management/</link><description>Recent content in Management on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Wed, 19 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/management/index.xml" rel="self" type="application/rss+xml"/><item><title>依位置選書</title><link>https://tarrragon.github.io/blog/books/software-management/roles/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/roles/</guid><description>&lt;p>位置篇按責任範圍組織，不按職稱。同一個職稱在不同組織對應的責任差很多——三十人公司的「資深工程師」經常同時對別人的產出與技術品質負責，五百人公司的同一個職稱可能只對自己的產出負責。職稱與實際責任一致時兩者等價，不一致時以責任為準；責任軸的代價是它要自我診斷；職稱則是外部給定、查得到的。下一段的判準就是為了讓這個診斷有可操作的做法。&lt;/p>
&lt;p>每篇處理三件事：這個位置一天實際在處理什麼、同一個責任範圍在制度成文與不成文的組織裡問題差在哪、以及往相鄰位置移動前該預習什麼。制度化程度才是那一段的軸，人數只是粗略訊號——三百人的家族企業可能沒有職級帶，八十人的新創可能整套沿用大廠的 ladder。判的方法是逐項確認四樣東西寫不寫得出來：晉升的條件、績效評估的流程、薪資帶的範圍、以及調動要經過誰。四樣都有文件、而且文件跟實際發生的事一致，是成文；四樣都靠個案決定，是不成文；最常見的是中間態——文件存在但實際決定不照它走，那種情況照不成文處理，因為位置篇談的是這個位置真正能用的工具。另外一個訊號在預算側：headcount 綁在年度預算裡、增補要跨部門核准的，制度化程度通常已經很高。&lt;/p>
&lt;p>遠距、跨國、公部門這三種情境會再疊上各自的變形（可見度、單一薪資市場的假設、法定薪級），那些差異這批內容沒有處理——跨時區非同步團隊尤其要先看&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態&lt;/a>。書的完整描述都在 &lt;a href="../topics/">主題書單&lt;/a>，這裡只說「哪種處境對應哪本」與為什麼。&lt;/p>
&lt;h2 id="五個位置">五個位置&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>位置&lt;/th>
 &lt;th>對什麼負責&lt;/th>
 &lt;th>最常見的失敗&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="own-output/">只對自己的產出負責&lt;/a>&lt;/td>
 &lt;td>交出去的東西本身&lt;/td>
 &lt;td>做完了但沒人知道它做完了&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="technical-quality/">對技術品質負責、不帶人&lt;/a>&lt;/td>
 &lt;td>跨越多人的技術決策與標準&lt;/td>
 &lt;td>方案是對的，但推不動&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="others-output/">對別人的產出負責&lt;/a>&lt;/td>
 &lt;td>團隊交出去的東西&lt;/td>
 &lt;td>自己重寫比教會別人快，於是永遠自己重寫&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="people/">對人負責&lt;/a>&lt;/td>
 &lt;td>這些人留不留得住、成不成長&lt;/td>
 &lt;td>把「管理」做成「更大範圍的自己動手」&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="org-structure/">對組織結構負責&lt;/a>&lt;/td>
 &lt;td>團隊怎麼切、交接面誰負責&lt;/td>
 &lt;td>改組織圖而沒有改任何人的實際約束&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;h2 id="怎麼判斷自己在哪一格">怎麼判斷自己在哪一格&lt;/h2>
&lt;p>判準是&lt;strong>交不出來的時候，誰會被問&lt;/strong>：&lt;/p>
&lt;ul>
&lt;li>只有自己被問 → &lt;a href="own-output/">只對自己的產出負責&lt;/a>&lt;/li>
&lt;li>沒有人交不出來、但技術決策錯了會問到自己 → &lt;a href="technical-quality/">對技術品質負責&lt;/a>&lt;/li>
&lt;li>別人交不出來而問到自己 → &lt;a href="others-output/">對別人的產出負責&lt;/a>&lt;/li>
&lt;li>人走了會問到自己 → &lt;a href="people/">對人負責&lt;/a>&lt;/li>
&lt;li>團隊之間卡住而沒有人特別該負責時會問到自己 → &lt;a href="org-structure/">對組織結構負責&lt;/a>&lt;/li>
&lt;/ul>
&lt;p>這張清單判不出來的三種處境，答案都在本節後半，依出現順序是：還沒被指派而想先評估下一格（本節第五段）、好幾格同時成立（倒數第二段）、團隊人數不到一個團隊（最後一段）。夾在中間的兩段講的是判準本身在哪些組織會失準，跟這三種處境無關。&lt;/p>
&lt;p>另外有五種組織會讓判準本身失準。前三種是「被問」這件事在組織裡的分佈出了問題：什麼都問同一個人的、集體負責而沒有人被特別問的、以及被問的人不是有槓桿的人。第四種是&lt;strong>沒有人在看&lt;/strong>——沒有人來問不一定表示做得好，也可能是這件事還沒有人在追，這種情況下判準收不到任何訊號。第五種是&lt;strong>問責發生在組織外&lt;/strong>：受主管機關監理的組織，事故後由稽核與監理單位問責，組織內部可能沒有任何人被問，而責任是真實存在的。&lt;/p>
&lt;p>什麼都問同一個人的、集體負責的、以及沒有人在看的這三種，改看&lt;strong>手上能動的槓桿&lt;/strong>——能不能改變別人的優先序、能不能動人事、能不能改變交接面怎麼定，能動到哪一層就讀哪一篇。被問的人沒有槓桿那一種不適用這個處方（它的定義就是槓桿不存在），那種處境照被問的位置選書，同時把 &lt;a href="../topics/influence-conversation/">困難對話與無權限影響力&lt;/a> 排在前面。問責發生在組織外那一種照法定的責任歸屬判，那通常比組織內部的分工更明確。責任大於權限的處境不必因此退出選書：技術品質與別人的產出這兩格的定義本來就是責任大於權限，照被問的位置選書仍然對，只是要先補 &lt;a href="../topics/influence-conversation/">困難對話與無權限影響力&lt;/a>，否則選對了書也推不動。&lt;/p>
&lt;p>這個判準問的是現在。換位置的人需要的卻是下一格。&lt;strong>下一格不是現在這一格的人，照現況判都會落在舊的那一格&lt;/strong>——已經確定要轉換的（下個月開始帶人、下一季接下平台團隊）是一種，還在評估要不要轉換、連機會都還沒出現的是另一種。那不是判錯，只是判準只看得到當下。兩種處境讀兩篇：現在這個位置的「想往哪裡走」段說明該預習什麼，目標那一格的前兩段說明即將接手的問題長什麼樣。還在評估的人另外先看 &lt;a href="../topics/role-transitions/">角色轉換與職涯路徑&lt;/a>——那裡的書逐層寫出每個位置整天實際在處理什麼，而「值不值得走過去」要先看得到那個才答得出來。轉換之後再讀一次目標那篇，讀出來的東西會跟轉換前不同——這是刻意的，判準要等到承擔責任才長得出來。&lt;/p>
&lt;p>這五格是有僱傭關係、責任由組織分配的處境。獨立接案者、開源維護者、DevRel、研究型工程師、技術寫作者的責任來源不同——對客戶、對社群、對外部讀者——那些處境不在這條線的範圍內，套進五格會失真。五格之間也不是階梯：檔案的排序是責任範圍由小到大，不是該走的順序，橫向移動與留在原地都是正常路徑，每篇的「想往哪裡走」段有標出哪些方向存在。&lt;/p>
&lt;p>同時符合兩處時取當下解不掉的那一處——已經在解的那些問題不需要一本書指出怎麼開始。完全對不上的情況也存在——小公司的技術負責人可能同時負責技術品質、別人的產出、人與組織結構，那種處境的建議是照急迫度挑一篇開始，而不是四篇一起讀。&lt;/p>
&lt;p>有一個規模下限要先確認：&lt;a href="org-structure/">對組織結構負責&lt;/a> 那篇的書預設組織裡至少有三個團隊（這個數字的推導在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的約束段）。人數在一個團隊以內時，那些內容是為不存在的問題做設計，先看 &lt;a href="others-output/">對別人的產出負責&lt;/a>。&lt;a href="people/">對人負責&lt;/a> 那一格照樣成立——兩個人的去留一樣決定得了公司能不能活，只是那一格的書預設組織已經有分級、調薪與績效制度可用，沒有制度時讀到的是那些工具背後的判斷，而不是照著把制度建起來。這個規模真正該補的另一半在 &lt;a href="../../craft/">工程技藝&lt;/a>。&lt;/p>
&lt;p>其他會改變答案的約束（人員流動率、協作形態、法規義務、預算）見 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「哪些約束會改變答案」段。&lt;/p>
&lt;h2 id="這幾篇跟主題篇的分工">這幾篇跟主題篇的分工&lt;/h2>
&lt;p>主題篇按問題組織，回答「這個問題該讀什麼」；位置篇按人組織，回答「我現在該讀什麼」。同一本書會出現在多個位置的建議裡，用法不同——&lt;a href="../topics/retention-motivation/">Peopleware&lt;/a> 給只對自己產出負責的人的是「原來我的環境是這樣壞掉的」，給對人負責的人的是「我可以動哪些槓桿」。&lt;/p>
&lt;p>書的性質判定（&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>、時效狀態、&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>、讀得出價值的前提）一律在主題篇，位置篇不重複，避免同一本書的多份說明各自漂移。位置篇寫的是「哪種處境對應哪本、在這裡怎麼用」，而同一本書在多個位置各有一句用法時，那幾句也會漂移——防這一層的做法是各句只講該位置獨有的用途，不重述書的主張本身，書是什麼以主題篇為準。同一條規則也適用於主題篇之間：一本書的性質判定住在它的主場那一篇，別篇引用時只指路、不重述。&lt;/p></description><content:encoded><![CDATA[<p>位置篇按責任範圍組織，不按職稱。同一個職稱在不同組織對應的責任差很多——三十人公司的「資深工程師」經常同時對別人的產出與技術品質負責，五百人公司的同一個職稱可能只對自己的產出負責。職稱與實際責任一致時兩者等價，不一致時以責任為準；責任軸的代價是它要自我診斷；職稱則是外部給定、查得到的。下一段的判準就是為了讓這個診斷有可操作的做法。</p>
<p>每篇處理三件事：這個位置一天實際在處理什麼、同一個責任範圍在制度成文與不成文的組織裡問題差在哪、以及往相鄰位置移動前該預習什麼。制度化程度才是那一段的軸，人數只是粗略訊號——三百人的家族企業可能沒有職級帶，八十人的新創可能整套沿用大廠的 ladder。判的方法是逐項確認四樣東西寫不寫得出來：晉升的條件、績效評估的流程、薪資帶的範圍、以及調動要經過誰。四樣都有文件、而且文件跟實際發生的事一致，是成文；四樣都靠個案決定，是不成文；最常見的是中間態——文件存在但實際決定不照它走，那種情況照不成文處理，因為位置篇談的是這個位置真正能用的工具。另外一個訊號在預算側：headcount 綁在年度預算裡、增補要跨部門核准的，制度化程度通常已經很高。</p>
<p>遠距、跨國、公部門這三種情境會再疊上各自的變形（可見度、單一薪資市場的假設、法定薪級），那些差異這批內容沒有處理——跨時區非同步團隊尤其要先看<a href="/blog/books/knowledge-cards/collaboration-mode/" data-link-title="協作形態（collaboration mode）" data-link-desc="團隊管理的建議逐條檢查都沒有明顯衝突、換算到跨時區團隊卻一條都落不了地時，用來定位失效的是哪一批論證">協作形態</a>。書的完整描述都在 <a href="../topics/">主題書單</a>，這裡只說「哪種處境對應哪本」與為什麼。</p>
<h2 id="五個位置">五個位置</h2>
<table>
  <thead>
      <tr>
          <th>位置</th>
          <th>對什麼負責</th>
          <th>最常見的失敗</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="own-output/">只對自己的產出負責</a></td>
          <td>交出去的東西本身</td>
          <td>做完了但沒人知道它做完了</td>
      </tr>
      <tr>
          <td><a href="technical-quality/">對技術品質負責、不帶人</a></td>
          <td>跨越多人的技術決策與標準</td>
          <td>方案是對的，但推不動</td>
      </tr>
      <tr>
          <td><a href="others-output/">對別人的產出負責</a></td>
          <td>團隊交出去的東西</td>
          <td>自己重寫比教會別人快，於是永遠自己重寫</td>
      </tr>
      <tr>
          <td><a href="people/">對人負責</a></td>
          <td>這些人留不留得住、成不成長</td>
          <td>把「管理」做成「更大範圍的自己動手」</td>
      </tr>
      <tr>
          <td><a href="org-structure/">對組織結構負責</a></td>
          <td>團隊怎麼切、交接面誰負責</td>
          <td>改組織圖而沒有改任何人的實際約束</td>
      </tr>
  </tbody>
</table>
<h2 id="怎麼判斷自己在哪一格">怎麼判斷自己在哪一格</h2>
<p>判準是<strong>交不出來的時候，誰會被問</strong>：</p>
<ul>
<li>只有自己被問 → <a href="own-output/">只對自己的產出負責</a></li>
<li>沒有人交不出來、但技術決策錯了會問到自己 → <a href="technical-quality/">對技術品質負責</a></li>
<li>別人交不出來而問到自己 → <a href="others-output/">對別人的產出負責</a></li>
<li>人走了會問到自己 → <a href="people/">對人負責</a></li>
<li>團隊之間卡住而沒有人特別該負責時會問到自己 → <a href="org-structure/">對組織結構負責</a></li>
</ul>
<p>這張清單判不出來的三種處境，答案都在本節後半，依出現順序是：還沒被指派而想先評估下一格（本節第五段）、好幾格同時成立（倒數第二段）、團隊人數不到一個團隊（最後一段）。夾在中間的兩段講的是判準本身在哪些組織會失準，跟這三種處境無關。</p>
<p>另外有五種組織會讓判準本身失準。前三種是「被問」這件事在組織裡的分佈出了問題：什麼都問同一個人的、集體負責而沒有人被特別問的、以及被問的人不是有槓桿的人。第四種是<strong>沒有人在看</strong>——沒有人來問不一定表示做得好，也可能是這件事還沒有人在追，這種情況下判準收不到任何訊號。第五種是<strong>問責發生在組織外</strong>：受主管機關監理的組織，事故後由稽核與監理單位問責，組織內部可能沒有任何人被問，而責任是真實存在的。</p>
<p>什麼都問同一個人的、集體負責的、以及沒有人在看的這三種，改看<strong>手上能動的槓桿</strong>——能不能改變別人的優先序、能不能動人事、能不能改變交接面怎麼定，能動到哪一層就讀哪一篇。被問的人沒有槓桿那一種不適用這個處方（它的定義就是槓桿不存在），那種處境照被問的位置選書，同時把 <a href="../topics/influence-conversation/">困難對話與無權限影響力</a> 排在前面。問責發生在組織外那一種照法定的責任歸屬判，那通常比組織內部的分工更明確。責任大於權限的處境不必因此退出選書：技術品質與別人的產出這兩格的定義本來就是責任大於權限，照被問的位置選書仍然對，只是要先補 <a href="../topics/influence-conversation/">困難對話與無權限影響力</a>，否則選對了書也推不動。</p>
<p>這個判準問的是現在。換位置的人需要的卻是下一格。<strong>下一格不是現在這一格的人，照現況判都會落在舊的那一格</strong>——已經確定要轉換的（下個月開始帶人、下一季接下平台團隊）是一種，還在評估要不要轉換、連機會都還沒出現的是另一種。那不是判錯，只是判準只看得到當下。兩種處境讀兩篇：現在這個位置的「想往哪裡走」段說明該預習什麼，目標那一格的前兩段說明即將接手的問題長什麼樣。還在評估的人另外先看 <a href="../topics/role-transitions/">角色轉換與職涯路徑</a>——那裡的書逐層寫出每個位置整天實際在處理什麼，而「值不值得走過去」要先看得到那個才答得出來。轉換之後再讀一次目標那篇，讀出來的東西會跟轉換前不同——這是刻意的，判準要等到承擔責任才長得出來。</p>
<p>這五格是有僱傭關係、責任由組織分配的處境。獨立接案者、開源維護者、DevRel、研究型工程師、技術寫作者的責任來源不同——對客戶、對社群、對外部讀者——那些處境不在這條線的範圍內，套進五格會失真。五格之間也不是階梯：檔案的排序是責任範圍由小到大，不是該走的順序，橫向移動與留在原地都是正常路徑，每篇的「想往哪裡走」段有標出哪些方向存在。</p>
<p>同時符合兩處時取當下解不掉的那一處——已經在解的那些問題不需要一本書指出怎麼開始。完全對不上的情況也存在——小公司的技術負責人可能同時負責技術品質、別人的產出、人與組織結構，那種處境的建議是照急迫度挑一篇開始，而不是四篇一起讀。</p>
<p>有一個規模下限要先確認：<a href="org-structure/">對組織結構負責</a> 那篇的書預設組織裡至少有三個團隊（這個數字的推導在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的約束段）。人數在一個團隊以內時，那些內容是為不存在的問題做設計，先看 <a href="others-output/">對別人的產出負責</a>。<a href="people/">對人負責</a> 那一格照樣成立——兩個人的去留一樣決定得了公司能不能活，只是那一格的書預設組織已經有分級、調薪與績效制度可用，沒有制度時讀到的是那些工具背後的判斷，而不是照著把制度建起來。這個規模真正該補的另一半在 <a href="../../craft/">工程技藝</a>。</p>
<p>其他會改變答案的約束（人員流動率、協作形態、法規義務、預算）見 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「哪些約束會改變答案」段。</p>
<h2 id="這幾篇跟主題篇的分工">這幾篇跟主題篇的分工</h2>
<p>主題篇按問題組織，回答「這個問題該讀什麼」；位置篇按人組織，回答「我現在該讀什麼」。同一本書會出現在多個位置的建議裡，用法不同——<a href="../topics/retention-motivation/">Peopleware</a> 給只對自己產出負責的人的是「原來我的環境是這樣壞掉的」，給對人負責的人的是「我可以動哪些槓桿」。</p>
<p>書的性質判定（<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>、時效狀態、<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>、讀得出價值的前提）一律在主題篇，位置篇不重複，避免同一本書的多份說明各自漂移。位置篇寫的是「哪種處境對應哪本、在這裡怎麼用」，而同一本書在多個位置各有一句用法時，那幾句也會漂移——防這一層的做法是各句只講該位置獨有的用途，不重述書的主張本身，書是什麼以主題篇為準。同一條規則也適用於主題篇之間：一本書的性質判定住在它的主場那一篇，別篇引用時只指路、不重述。</p>
]]></content:encoded></item><item><title>主題書單</title><link>https://tarrragon.github.io/blog/books/software-management/topics/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/topics/</guid><description>&lt;p>主題篇是每本書的完整描述所在，位置路由指過來。每篇先給一本起點書，接著依讀者的經驗與處境分出其他選項，最後說明為什麼這個主題只收這幾本。&lt;/p>
&lt;p>書的描述依四個維度——&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源&lt;/a>、時效狀態、&lt;a href="https://tarrragon.github.io/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性&lt;/a>、讀得出價值的前提，定義與這些判定的來源說明在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a>。&lt;/p>
&lt;p>帶著具體症狀來的，直接看下面的主題表：「承擔的問題」欄寫的是症狀而不是術語，對得上哪一列就走哪一篇。中間那一段講的是起點書怎麼被選出來，那是選書方法、不是選書入口。&lt;/p>
&lt;p>從這裡直接進主題篇的話，有一組檢查會被跳過：&lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「哪些約束會改變答案」段列出組織規模、人員流動率、協作形態、法規與稽核義務、取得成本，踩到其中任何一項時同一個主題的正確答案會不同。受主管機關監理的組織、以及跨時區的非同步團隊，尤其要先看那一段再選書。&lt;/p>
&lt;h2 id="起點書怎麼選出來的">起點書怎麼選出來的&lt;/h2>
&lt;p>每篇的起點書用同一組判準，且判準之間有優先序，衝突時往下讓：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>涵蓋面&lt;/strong>：一本書能涵蓋該主題多少個面向（面向＝該篇「為什麼只收這幾本」段開頭列出的那組分工）。優先，因為起點書的任務是建立座標，涵蓋面窄的書會讓讀者以為主題就這麼大。&lt;/li>
&lt;li>&lt;strong>證據夠不夠支持這個用途&lt;/strong>：涵蓋面相當（差一個面向以內）時，取證據來源足以支持「被拿去佐證實際決定」這個用途的那本。這裡排的不是書的好壞，是它的結論可以支持多大範圍的主張——起點書的說法最容易被讀者引用出去，所以這一層看的是引用出去之後對方追問依據時答不答得出來。&lt;/li>
&lt;li>&lt;strong>可操作性&lt;/strong>：前兩項相當時取能直接照著做的那本。&lt;/li>
&lt;/ol>
&lt;p>「相當」指涵蓋的面向差一個以內，而面向不是憑感覺數的：各篇「為什麼只收這幾本」段開頭寫出的那組分工就是該主題的面向清單——事故檢討那篇開頭列的調查、判讀、制度化就是它的三個面向，起點書覆蓋其中幾個直接可數。&lt;/p>
&lt;p>這個定義有一個循環要知道：那段分工是收錄結果的說明，於是「覆蓋幾個面向」有一部分由收了哪幾本反推，第一層判準因此不容易被反駁。要讓它可反駁，面向清單得先於選書寫出來——目前十九篇都不是這樣做的，那是這套判準已知的弱點。&lt;/p>
&lt;p>這組判準同時適用管理線十一篇、技藝線四篇與財務線四篇。十九篇裡有十六篇的起點書在第一層就定案——涵蓋面拉開差距時，後兩層不會被走到，用它們解釋落選是把判準倒過來套。這十六篇的起點書段裡若還提到證據強度或可操作性也是本篇最高，那是附帶說明它的性質，不是它勝出的理由。&lt;/p>
&lt;p>第二層在財務線的三篇被實際走到：個人理財、會計與財報、總體經濟各有兩本涵蓋面差在一個面向以內，取的是證據來源足以支持「被拿去佐證實際決定」這個用途的那本。落選的三本分別是作者自建的九步驟、從一批公司歸納出的比率門檻、以及作者自建並用自己的操作驗證的模板，共同點是追問依據時指回作者本人；勝出的三本各自指回可以重做的計算、公開的準則、以及其他研究者的紀錄。第三層目前仍未被走到。&lt;/p>
&lt;p>判準本身的例外目前登記三條。技藝線的驗證那篇取 Beck，理由是後面兩本都在跟它對話，那條「歷史先行性」不在這三層裡。財務線有兩條，都跟該線的三層分法綁在一起：解釋層（總體經濟）不比預測準不準、改判「寫不寫得出自己的失效條件」，讀懂層（會計與財報）不把可操作性算進加分，因為給一組可以照抄的比率屬於決定層的事。要新增例外的篇章在這裡登記一列，理由寫在該篇。&lt;/p>
&lt;p>五個位置的起點書用的是另一組判準：哪一本最直接對應該位置當下的主要問題，不看涵蓋面。位置起點書的任務是讓人今天就有東西可讀，不是建立主題座標。&lt;/p>
&lt;p>起點書與「門檻最低的那本」經常不是同一本，這是刻意的——起點書服務的是建立主題座標，門檻最低的書服務的是完全沒有相關經驗的讀者。兩者不同時，主題篇會分別點出來。&lt;/p>
&lt;p>要挑給一群程度不一的人共讀時，取門檻最低的那本而非起點書：共讀的瓶頸是讀得最吃力的那個人，而涵蓋面可以靠討論補，讀不下去不行。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>主題&lt;/th>
 &lt;th>承擔的問題&lt;/th>
 &lt;th>起點書&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="problem-definition/">問題定義與系統思考&lt;/a>&lt;/td>
 &lt;td>同一種問題重複發生、每次解法看起來都合理&lt;/td>
 &lt;td>Thinking in Systems&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="continuous-delivery/">持續交付與交付效能&lt;/a>&lt;/td>
 &lt;td>怎麼知道一個工程做法真的有效、該追什麼指標&lt;/td>
 &lt;td>Accelerate&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="team-design/">組織結構與團隊設計&lt;/a>&lt;/td>
 &lt;td>團隊怎麼切、交接面誰負責、這個團隊還能不能再接一個服務&lt;/td>
 &lt;td>Team Topologies&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="culture-safety/">組織文化與心理安全感&lt;/a>&lt;/td>
 &lt;td>沒人講壞消息、錯誤被藏起來、檢討變成表演&lt;/td>
 &lt;td>The Fearless Organization&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="retention-motivation/">留任、動機與工作環境&lt;/a>&lt;/td>
 &lt;td>人為什麼走、環境怎麼影響產出、回饋怎麼給&lt;/td>
 &lt;td>Peopleware&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="personal-workflow/">個人工作流與工作負荷&lt;/a>&lt;/td>
 &lt;td>事情永遠做不完、清單越來越長、換過幾套方法都維持不久&lt;/td>
 &lt;td>Getting Things Done&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="estimation-decision/">估算、承諾與決策偏誤&lt;/a>&lt;/td>
 &lt;td>估算永遠樂觀、明知做不完還是承諾、風險沒人願意講&lt;/td>
 &lt;td>How Big Things Get Done&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="incident-blame/">事故、歸因與無指責檢討&lt;/a>&lt;/td>
 &lt;td>事故檢討變成找戰犯、同類事故一再發生&lt;/td>
 &lt;td>The Field Guide to Understanding &amp;lsquo;Human Error&amp;rsquo;&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="influence-conversation/">困難對話與無權限影響力&lt;/a>&lt;/td>
 &lt;td>該講的話講不出口、沒有職權時怎麼推動改變&lt;/td>
 &lt;td>Difficult Conversations&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="meeting-facilitation/">會議引導與群體決策&lt;/a>&lt;/td>
 &lt;td>討論收斂不了、提案一出口就變成攻防&lt;/td>
 &lt;td>Facilitator&amp;rsquo;s Guide to Participatory Decision-Making&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="role-transitions/">角色轉換與職涯路徑&lt;/a>&lt;/td>
 &lt;td>不知道 tech lead、EM、staff 一天在做什麼、該不該轉過去&lt;/td>
 &lt;td>The Manager&amp;rsquo;s Path&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>依位置而非依主題選書時，回到 &lt;a href="../">軟體管理與組織書單&lt;/a> 的位置表。&lt;/p>
&lt;h2 id="沒查到課的那十個主題理由分三種">沒查到課的那十個主題，理由分三種&lt;/h2>
&lt;p>十一個主題套用公開課的收錄門檻之後，接得住的只有 &lt;a href="estimation-decision/">估算、承諾與決策偏誤&lt;/a> 一個，課程列在該篇文末；其餘十個沒查到。門檻與這件事為什麼要做，寫在 &lt;a href="https://tarrragon.github.io/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦&lt;/a> 的「公開課怎麼收」段。&lt;/p>
&lt;p>先講這個結果的權重，因為它決定下面那三組該被讀得多重。這一輪是拿主題名去找同名的課，而估算那個主題接得住，靠的是改用該主題底下的&lt;strong>機制&lt;/strong>去找鄰近學科（誘因結構 → 賽局理論）。那個換法只在那一個主題上跑過，其餘十個一個也沒跑。所以「沒查到」目前的意思是「用主題名沒查到」，而下面的三組是照著各個主題為什麼空歸納出來的整理方式，不是獨立成立的規律——拿它回頭解釋同一批主題當然都通，那不算驗證。&lt;/p>
&lt;p>&lt;strong>學院有對應的課，只是沒有影片&lt;/strong>。這一類離收得進來只差影音這一項。問題定義與系統思考這個主題對應到 MIT Sloan 的 15.871 Introduction to System Dynamics（John Sterman 與 Hazhir Rahmandad），它教的正是該篇起點書那套因果回路與存量流量的建模方法，而它在 OpenCourseWare 上提供的是 readings、recitations 與作業，沒有影片。同樣的形態在技藝線出現過一次，寫在 &lt;a href="../../craft/">工程技藝書單&lt;/a> 的公開課段。&lt;/p>
&lt;p>&lt;strong>市場供給充足而形態不對&lt;/strong>。困難對話、會議引導、個人工作流這三個主題搜得到大量課程，內容集中在技巧演練與商業培訓，跨不過本質恆定這一條——它們的教材綁在當期的工具與流程上。持續交付也暫時放在這一組：以 CI/CD 為題的課程幾乎都是特定工具的操作教學，而該篇起點書要交付的是怎麼判斷一個工程做法確實有效。&lt;strong>這一個最可能被改判&lt;/strong>——它要的機制是研究設計與因果推論，而那個領域的公開課多得很，只是這一輪沒有拿那組詞去搜。困難對話與會議引導同理，它們要的承諾可信度、訊號傳遞與集體決策，正是估算那一篇已經收了的 ECON 159 第 14、15、23 講在講的事。&lt;/p>
&lt;p>&lt;strong>主要在商學院教，而商學院的課最少免費全釋出&lt;/strong>。組織結構、心理安全感、留任動機、事故歸因、角色轉換這五個主題共用這一點。這一組是三組裡最經得起追問的，因為它給得出一個可以拿去核對的規律：三條線裡接得住的六個主題，全部是被經濟系或資訊系的課接住的——Yale 的三門 ECON、台大的經濟與財金、MIT 6.824、劍橋的分散式系統——沒有一個是被管理學院的課接住的。經濟與資工的大學部講堂課是開放式課程錄製計畫的核心，組織行為與談判則是商學院的收入產品。&lt;/p>
&lt;p>它也給得出推翻自己的方式：它預測大學部科目不空缺、商學院科目普遍空缺。目前兩邊都對得上——社會學是大學部科目，Open Yale 的 SOCY 151 有完整影片；組織行為是商學院科目，MIT Sloan 的 15.668 People and Organizations 只有講義與書面作業。重掃時找到一門商學院自己完整釋出的組織類課程，這一條就要改寫。&lt;/p>
&lt;p>要自己去找的話，兩個方向現在就走得了。一是照上面那個換法自己搜：把手上的主題換成它底下的機制再去找鄰近學科，上面每一組都寫出了那些機制詞（研究設計與因果推論、承諾可信度、訊號傳遞、集體決策、因果回路與存量流量），拿它們去搜比拿主題名去搜命中率高。二是本輪盤點刻意排除的那一類——單場演講、研討會錄影、以及沒有課程頁只有播放清單的教學系列——組織與事故這幾個題材的供給正好集中在那裡，它們進不了這個書單是因為收錄門檻要的是課，不是因為它們沒用。&lt;/p>
&lt;p>重掃的第一件事是把這十個主題各跑一次機制式搜尋，觸發條件登記在 &lt;a href="../">軟體管理與組織書單&lt;/a> 的 Backlog。上面的判定做於 2026 年 8 月。&lt;/p></description><content:encoded><![CDATA[<p>主題篇是每本書的完整描述所在，位置路由指過來。每篇先給一本起點書，接著依讀者的經驗與處境分出其他選項，最後說明為什麼這個主題只收這幾本。</p>
<p>書的描述依四個維度——<a href="/blog/books/knowledge-cards/evidence-provenance/" data-link-title="證據來源分類（evidence provenance）" data-link-desc="手上兩本書講同一件事而結論不同、或要拿一本書去支持一個實際決定時，用來判斷它支持得了多大範圍的決定">證據來源</a>、時效狀態、<a href="/blog/books/knowledge-cards/context-compatibility/" data-link-title="處境相容性（context compatibility）" data-link-desc="一本書或一套做法讀起來都對、換算到自己的組織卻沒有一條動得了時，用來定位缺的是哪一個環境條件">處境相容性</a>、讀得出價值的前提，定義與這些判定的來源說明在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a>。</p>
<p>帶著具體症狀來的，直接看下面的主題表：「承擔的問題」欄寫的是症狀而不是術語，對得上哪一列就走哪一篇。中間那一段講的是起點書怎麼被選出來，那是選書方法、不是選書入口。</p>
<p>從這裡直接進主題篇的話，有一組檢查會被跳過：<a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「哪些約束會改變答案」段列出組織規模、人員流動率、協作形態、法規與稽核義務、取得成本，踩到其中任何一項時同一個主題的正確答案會不同。受主管機關監理的組織、以及跨時區的非同步團隊，尤其要先看那一段再選書。</p>
<h2 id="起點書怎麼選出來的">起點書怎麼選出來的</h2>
<p>每篇的起點書用同一組判準，且判準之間有優先序，衝突時往下讓：</p>
<ol>
<li><strong>涵蓋面</strong>：一本書能涵蓋該主題多少個面向（面向＝該篇「為什麼只收這幾本」段開頭列出的那組分工）。優先，因為起點書的任務是建立座標，涵蓋面窄的書會讓讀者以為主題就這麼大。</li>
<li><strong>證據夠不夠支持這個用途</strong>：涵蓋面相當（差一個面向以內）時，取證據來源足以支持「被拿去佐證實際決定」這個用途的那本。這裡排的不是書的好壞，是它的結論可以支持多大範圍的主張——起點書的說法最容易被讀者引用出去，所以這一層看的是引用出去之後對方追問依據時答不答得出來。</li>
<li><strong>可操作性</strong>：前兩項相當時取能直接照著做的那本。</li>
</ol>
<p>「相當」指涵蓋的面向差一個以內，而面向不是憑感覺數的：各篇「為什麼只收這幾本」段開頭寫出的那組分工就是該主題的面向清單——事故檢討那篇開頭列的調查、判讀、制度化就是它的三個面向，起點書覆蓋其中幾個直接可數。</p>
<p>這個定義有一個循環要知道：那段分工是收錄結果的說明，於是「覆蓋幾個面向」有一部分由收了哪幾本反推，第一層判準因此不容易被反駁。要讓它可反駁，面向清單得先於選書寫出來——目前十九篇都不是這樣做的，那是這套判準已知的弱點。</p>
<p>這組判準同時適用管理線十一篇、技藝線四篇與財務線四篇。十九篇裡有十六篇的起點書在第一層就定案——涵蓋面拉開差距時，後兩層不會被走到，用它們解釋落選是把判準倒過來套。這十六篇的起點書段裡若還提到證據強度或可操作性也是本篇最高，那是附帶說明它的性質，不是它勝出的理由。</p>
<p>第二層在財務線的三篇被實際走到：個人理財、會計與財報、總體經濟各有兩本涵蓋面差在一個面向以內，取的是證據來源足以支持「被拿去佐證實際決定」這個用途的那本。落選的三本分別是作者自建的九步驟、從一批公司歸納出的比率門檻、以及作者自建並用自己的操作驗證的模板，共同點是追問依據時指回作者本人；勝出的三本各自指回可以重做的計算、公開的準則、以及其他研究者的紀錄。第三層目前仍未被走到。</p>
<p>判準本身的例外目前登記三條。技藝線的驗證那篇取 Beck，理由是後面兩本都在跟它對話，那條「歷史先行性」不在這三層裡。財務線有兩條，都跟該線的三層分法綁在一起：解釋層（總體經濟）不比預測準不準、改判「寫不寫得出自己的失效條件」，讀懂層（會計與財報）不把可操作性算進加分，因為給一組可以照抄的比率屬於決定層的事。要新增例外的篇章在這裡登記一列，理由寫在該篇。</p>
<p>五個位置的起點書用的是另一組判準：哪一本最直接對應該位置當下的主要問題，不看涵蓋面。位置起點書的任務是讓人今天就有東西可讀，不是建立主題座標。</p>
<p>起點書與「門檻最低的那本」經常不是同一本，這是刻意的——起點書服務的是建立主題座標，門檻最低的書服務的是完全沒有相關經驗的讀者。兩者不同時，主題篇會分別點出來。</p>
<p>要挑給一群程度不一的人共讀時，取門檻最低的那本而非起點書：共讀的瓶頸是讀得最吃力的那個人，而涵蓋面可以靠討論補，讀不下去不行。</p>
<table>
  <thead>
      <tr>
          <th>主題</th>
          <th>承擔的問題</th>
          <th>起點書</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="problem-definition/">問題定義與系統思考</a></td>
          <td>同一種問題重複發生、每次解法看起來都合理</td>
          <td>Thinking in Systems</td>
      </tr>
      <tr>
          <td><a href="continuous-delivery/">持續交付與交付效能</a></td>
          <td>怎麼知道一個工程做法真的有效、該追什麼指標</td>
          <td>Accelerate</td>
      </tr>
      <tr>
          <td><a href="team-design/">組織結構與團隊設計</a></td>
          <td>團隊怎麼切、交接面誰負責、這個團隊還能不能再接一個服務</td>
          <td>Team Topologies</td>
      </tr>
      <tr>
          <td><a href="culture-safety/">組織文化與心理安全感</a></td>
          <td>沒人講壞消息、錯誤被藏起來、檢討變成表演</td>
          <td>The Fearless Organization</td>
      </tr>
      <tr>
          <td><a href="retention-motivation/">留任、動機與工作環境</a></td>
          <td>人為什麼走、環境怎麼影響產出、回饋怎麼給</td>
          <td>Peopleware</td>
      </tr>
      <tr>
          <td><a href="personal-workflow/">個人工作流與工作負荷</a></td>
          <td>事情永遠做不完、清單越來越長、換過幾套方法都維持不久</td>
          <td>Getting Things Done</td>
      </tr>
      <tr>
          <td><a href="estimation-decision/">估算、承諾與決策偏誤</a></td>
          <td>估算永遠樂觀、明知做不完還是承諾、風險沒人願意講</td>
          <td>How Big Things Get Done</td>
      </tr>
      <tr>
          <td><a href="incident-blame/">事故、歸因與無指責檢討</a></td>
          <td>事故檢討變成找戰犯、同類事故一再發生</td>
          <td>The Field Guide to Understanding &lsquo;Human Error&rsquo;</td>
      </tr>
      <tr>
          <td><a href="influence-conversation/">困難對話與無權限影響力</a></td>
          <td>該講的話講不出口、沒有職權時怎麼推動改變</td>
          <td>Difficult Conversations</td>
      </tr>
      <tr>
          <td><a href="meeting-facilitation/">會議引導與群體決策</a></td>
          <td>討論收斂不了、提案一出口就變成攻防</td>
          <td>Facilitator&rsquo;s Guide to Participatory Decision-Making</td>
      </tr>
      <tr>
          <td><a href="role-transitions/">角色轉換與職涯路徑</a></td>
          <td>不知道 tech lead、EM、staff 一天在做什麼、該不該轉過去</td>
          <td>The Manager&rsquo;s Path</td>
      </tr>
  </tbody>
</table>
<p>依位置而非依主題選書時，回到 <a href="../">軟體管理與組織書單</a> 的位置表。</p>
<h2 id="沒查到課的那十個主題理由分三種">沒查到課的那十個主題，理由分三種</h2>
<p>十一個主題套用公開課的收錄門檻之後，接得住的只有 <a href="estimation-decision/">估算、承諾與決策偏誤</a> 一個，課程列在該篇文末；其餘十個沒查到。門檻與這件事為什麼要做，寫在 <a href="/blog/books/" data-link-title="書單推薦" data-link-desc="站在某個職涯位置、想知道該讀哪本工具書，想往別的位置移動而不知道該預習什麼，或因為閱讀障礙與外語閱讀速度而需要同一份知識換成用聽的時看這裡">書單推薦</a> 的「公開課怎麼收」段。</p>
<p>先講這個結果的權重，因為它決定下面那三組該被讀得多重。這一輪是拿主題名去找同名的課，而估算那個主題接得住，靠的是改用該主題底下的<strong>機制</strong>去找鄰近學科（誘因結構 → 賽局理論）。那個換法只在那一個主題上跑過，其餘十個一個也沒跑。所以「沒查到」目前的意思是「用主題名沒查到」，而下面的三組是照著各個主題為什麼空歸納出來的整理方式，不是獨立成立的規律——拿它回頭解釋同一批主題當然都通，那不算驗證。</p>
<p><strong>學院有對應的課，只是沒有影片</strong>。這一類離收得進來只差影音這一項。問題定義與系統思考這個主題對應到 MIT Sloan 的 15.871 Introduction to System Dynamics（John Sterman 與 Hazhir Rahmandad），它教的正是該篇起點書那套因果回路與存量流量的建模方法，而它在 OpenCourseWare 上提供的是 readings、recitations 與作業，沒有影片。同樣的形態在技藝線出現過一次，寫在 <a href="../../craft/">工程技藝書單</a> 的公開課段。</p>
<p><strong>市場供給充足而形態不對</strong>。困難對話、會議引導、個人工作流這三個主題搜得到大量課程，內容集中在技巧演練與商業培訓，跨不過本質恆定這一條——它們的教材綁在當期的工具與流程上。持續交付也暫時放在這一組：以 CI/CD 為題的課程幾乎都是特定工具的操作教學，而該篇起點書要交付的是怎麼判斷一個工程做法確實有效。<strong>這一個最可能被改判</strong>——它要的機制是研究設計與因果推論，而那個領域的公開課多得很，只是這一輪沒有拿那組詞去搜。困難對話與會議引導同理，它們要的承諾可信度、訊號傳遞與集體決策，正是估算那一篇已經收了的 ECON 159 第 14、15、23 講在講的事。</p>
<p><strong>主要在商學院教，而商學院的課最少免費全釋出</strong>。組織結構、心理安全感、留任動機、事故歸因、角色轉換這五個主題共用這一點。這一組是三組裡最經得起追問的，因為它給得出一個可以拿去核對的規律：三條線裡接得住的六個主題，全部是被經濟系或資訊系的課接住的——Yale 的三門 ECON、台大的經濟與財金、MIT 6.824、劍橋的分散式系統——沒有一個是被管理學院的課接住的。經濟與資工的大學部講堂課是開放式課程錄製計畫的核心，組織行為與談判則是商學院的收入產品。</p>
<p>它也給得出推翻自己的方式：它預測大學部科目不空缺、商學院科目普遍空缺。目前兩邊都對得上——社會學是大學部科目，Open Yale 的 SOCY 151 有完整影片；組織行為是商學院科目，MIT Sloan 的 15.668 People and Organizations 只有講義與書面作業。重掃時找到一門商學院自己完整釋出的組織類課程，這一條就要改寫。</p>
<p>要自己去找的話，兩個方向現在就走得了。一是照上面那個換法自己搜：把手上的主題換成它底下的機制再去找鄰近學科，上面每一組都寫出了那些機制詞（研究設計與因果推論、承諾可信度、訊號傳遞、集體決策、因果回路與存量流量），拿它們去搜比拿主題名去搜命中率高。二是本輪盤點刻意排除的那一類——單場演講、研討會錄影、以及沒有課程頁只有播放清單的教學系列——組織與事故這幾個題材的供給正好集中在那裡，它們進不了這個書單是因為收錄門檻要的是課，不是因為它們沒用。</p>
<p>重掃的第一件事是把這十個主題各跑一次機制式搜尋，觸發條件登記在 <a href="../">軟體管理與組織書單</a> 的 Backlog。上面的判定做於 2026 年 8 月。</p>
]]></content:encoded></item><item><title>軟體管理與組織書單</title><link>https://tarrragon.github.io/blog/books/software-management/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/books/software-management/</guid><description>&lt;p>這條線涵蓋受僱於某個組織、責任範圍從只對自己的產出到對整個組織結構的五種位置。位置決定當下煩惱什麼：初中級工程師煩惱怎麼讓自己的產出被信任，Tech Lead 煩惱怎麼讓別人的產出達標，EM 煩惱人留不留得住，管理管理者煩惱組織切法對不對。這些煩惱各自對應不同的書，但涵蓋的知識領域大量重疊——同一本談心理安全感的書，四個位置都用得到，用法完全不同。&lt;/p>
&lt;p>這條線不處理技藝——程式怎麼寫、怎麼改得動、怎麼驗證，那些在 &lt;a href="../craft/">工程技藝&lt;/a>。兩條線的失敗互相看不見，因此分開。另有一條線 &lt;a href="../finance/">財務與投資&lt;/a> 處理的是自己的資本與現金流，跟這裡的分界不是同一個軸：那條線的決定不在工作場域裡發生，本篇的位置表與規模、流動率這些約束在那裡都不適用。&lt;/p>
&lt;p>書的完整描述住在主題篇，位置與主題兩張路由表只給書名與連結。這個分工的理由是同一本書會出現在多個位置的建議清單裡，若每個位置各寫一份說明，幾份說明會隨時間漂移成幾種不同的講法。&lt;/p>
&lt;h2 id="完全不熟悉這個領域時先讀這一本">完全不熟悉這個領域時先讀這一本&lt;/h2>
&lt;p>&lt;a href="topics/continuous-delivery/">Accelerate&lt;/a> 是這條線的單一起點。選它的理由是它同時滿足兩個條件，而與品質排名無關：結論建立在數萬份跨組織調查上，因此可以拿來支持實際決定；而且它的四項指標已經是業界共同語言，讀完之後其他書的討論才有共同座標。&lt;/p>
&lt;p>它的限制要先知道：它談的是組織層級的交付效能，不談個人怎麼寫程式、也不談怎麼跟人相處。如果目前的困擾是「我下個月開始要帶人」「我想知道管理職實際在做什麼」「我不知道怎麼跟主管講壞消息」或「我不知道自己夠不夠格升等」，這本書不會回答，直接往下面的位置表走。&lt;/p>
&lt;h2 id="依當下的位置選書">依當下的位置選書&lt;/h2>
&lt;p>位置的判準是對什麼負責，不是職稱——同一個職稱在大企業與小公司對應的責任範圍經常不同。判準的操作版本是：&lt;strong>交不出來的時候，誰會被問&lt;/strong>。下表給每個位置的起點書；那個位置一天實際在處理什麼、在有階梯與沒階梯的組織裡問題差在哪、往相鄰位置移動前該預習什麼，在 &lt;a href="roles/">依位置選書&lt;/a> 的五篇裡。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>位置&lt;/th>
 &lt;th>當下的主要問題&lt;/th>
 &lt;th>起點&lt;/th>
 &lt;th>主要主題&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="roles/own-output/">只對自己的產出負責&lt;/a>&lt;/td>
 &lt;td>怎麼讓產出被信任、怎麼知道自己下一步該補什麼&lt;/td>
 &lt;td>The Software Engineer&amp;rsquo;s Guidebook&lt;/td>
 &lt;td>&lt;a href="topics/role-transitions/">角色轉換與職涯路徑&lt;/a>、&lt;a href="topics/problem-definition/">問題定義與系統思考&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/technical-quality/">對技術品質負責、不帶人&lt;/a>&lt;/td>
 &lt;td>沒有指揮權時怎麼讓別人照著做、技術決策怎麼被採納&lt;/td>
 &lt;td>The Staff Engineer&amp;rsquo;s Path&lt;/td>
 &lt;td>&lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a>、&lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/others-output/">對別人的產出負責（Tech Lead）&lt;/a>&lt;/td>
 &lt;td>怎麼讓團隊的產出達標而不變成自己重寫&lt;/td>
 &lt;td>The Manager&amp;rsquo;s Path&lt;/td>
 &lt;td>&lt;a href="topics/continuous-delivery/">持續交付與交付效能&lt;/a>、&lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/people/">對人負責（EM）&lt;/a>&lt;/td>
 &lt;td>人留不留得住、回饋怎麼給、壞消息為什麼傳不上來&lt;/td>
 &lt;td>Peopleware&lt;/td>
 &lt;td>&lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a>、&lt;a href="topics/culture-safety/">組織文化與心理安全感&lt;/a>、&lt;a href="topics/personal-workflow/">個人工作流與工作負荷&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="roles/org-structure/">對組織結構負責（管理管理者）&lt;/a>&lt;/td>
 &lt;td>團隊怎麼切、交接面誰負責、承諾為什麼總是跳票&lt;/td>
 &lt;td>Team Topologies&lt;/td>
 &lt;td>&lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>、&lt;a href="topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>起點書的完整描述與購書連結在對應的主題篇：前三本在 &lt;a href="topics/role-transitions/">角色轉換與職涯路徑&lt;/a>，Peopleware 在 &lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a>，Team Topologies 在 &lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>。&lt;/p>
&lt;p>有三種處境這張表判不出來：好幾格同時成立、還沒被指派而想先評估下一格、以及團隊人數不到一個團隊。三種各自的做法在 &lt;a href="roles/">依位置選書&lt;/a> 的「怎麼判斷自己在哪一格」段，該段開頭就標出三者分別在哪一小段。&lt;/p>
&lt;p>想往上或往旁邊移動時，預習的方向跟當下的問題不同。純個人貢獻者想走管理，第一站是 &lt;a href="topics/role-transitions/">角色轉換與職涯路徑&lt;/a>：那裡的書逐層寫出管理位置整天在處理什麼，而「值不值得走過去」得先看得到那個。決定要走之後才輪到 &lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a> 與 &lt;a href="topics/culture-safety/">組織文化與心理安全感&lt;/a>——這兩塊在只對自己負責的位置上完全用不到，因此也最沒有機會自然累積。想走 Staff+ 技術路線的人，預習的是 &lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a> 與 &lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>，因為技術決策要能推得動，靠的是能不能把方案講進別人的約束裡，職權在這條路線上幫不上忙。&lt;/p>
&lt;h2 id="依主題選書">依主題選書&lt;/h2>
&lt;p>十一個主題與各自的首選書在 &lt;a href="topics/">主題書單目錄&lt;/a>。那一頁是主題與首選的唯一清單，這裡不重複列，避免兩份清單各自漂移。&lt;/p>
&lt;h2 id="經典套書怎麼買">經典套書怎麼買&lt;/h2>
&lt;p>各主題篇按問題組織，因此同一套書會分散在不同篇。實際購買時面對的是套書決定，這一段只處理那個決定，每本書的性質判定回各主題篇看。&lt;/p>
&lt;p>Gerald Weinberg 的《溫伯格的軟體管理學》四卷分別對應四個主題：第 1 卷系統化思考在 &lt;a href="topics/problem-definition/">問題定義與系統思考&lt;/a>，第 2 卷第一級評量在 &lt;a href="topics/continuous-delivery/">持續交付與交付效能&lt;/a>，第 3 卷關照全局的管理作為在 &lt;a href="topics/influence-conversation/">困難對話與無權限影響力&lt;/a>，第 4 卷擁抱變革在 &lt;a href="topics/team-design/">組織結構與團隊設計&lt;/a>。第 1、2 卷處理的問題現在有大規模實證的書可以對照，第 3 卷處理的管理者即時反應在這條線的其他書裡沒有對應。只買一卷買第 3 卷；買套書適合想看完整論述的讀者。四卷合購頁在&lt;a href="https://www.books.com.tw/products/0010553999">博客來&lt;/a>。&lt;/p>
&lt;p>Tom DeMarco 與 Timothy Lister 的兩本分屬不同主題：《Peopleware》在 &lt;a href="topics/retention-motivation/">留任、動機與工作環境&lt;/a>，《Waltzing with Bears》（繁中《與熊共舞》）在 &lt;a href="topics/estimation-decision/">估算、承諾與決策偏誤&lt;/a>。兩本沒有合購版本，分開買。&lt;/p>
&lt;h2 id="相關的實作內容">相關的實作內容&lt;/h2>
&lt;p>書單處理選讀判斷，技術實作在教學系列：交付管線與部署 gate 看 &lt;a href="https://tarrragon.github.io/blog/ci/" data-link-title="CI/CD 教學" data-link-desc="整理 CI/CD 的驗證、建置、發布 gate 與不同部署場域的流程差異，讓每次變更都能被穩定驗證與交付">CI/CD 教學&lt;/a>，服務探活、容量規劃與高可用看 &lt;a href="https://tarrragon.github.io/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運&lt;/a>，事故分級、指揮角色與復盤制度看 &lt;a href="https://tarrragon.github.io/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤&lt;/a>，客戶端遙測的四類事件與收集鏈路看 &lt;a href="https://tarrragon.github.io/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系&lt;/a>，交付生命週期全景看 &lt;a href="https://tarrragon.github.io/blog/devops/" data-link-title="DevOps 全景：軟體交付生命週期" data-link-desc="想釐清 infra、CI/CD、運行期維運怎麼串成一條軟體交付生命週期、或不確定手上的問題該進哪個系列時回來讀">DevOps 全景&lt;/a>。既有團隊的結構評估協議看 &lt;a href="https://tarrragon.github.io/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計&lt;/a>。&lt;/p>
&lt;h2 id="backlog">Backlog&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>項目&lt;/th>
 &lt;th>類型&lt;/th>
 &lt;th>前置條件&lt;/th>
 &lt;th>規模&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>十個主題各跑一次機制式搜尋&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>機制詞候選事前寫死在主題書單的公開課段（研究設計與因果推論 / 承諾可信度 / 訊號傳遞 / 集體決策 / 因果回路與存量流量），產物是十組詞各查到什麼，可重跑&lt;/td>
 &lt;td>1 次&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>沒查到課的十個主題重掃一次&lt;/td>
 &lt;td>案例&lt;/td>
 &lt;td>2027 年 8 月之後重跑，判準是本質恆定加實際有影音；是哪十個主題與各自為什麼空，見 &lt;a href="topics/">主題書單&lt;/a> 的公開課段&lt;/td>
 &lt;td>1 次&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>系統思考這個主題改判&lt;/td>
 &lt;td>主章&lt;/td>
 &lt;td>MIT 15.871 補上影片，或找到另一門教因果回路與存量流量而有影音的課；沒有人會主動去看，實際觸發點是 2027 年那次重掃&lt;/td>
 &lt;td>1 段&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table></description><content:encoded><![CDATA[<p>這條線涵蓋受僱於某個組織、責任範圍從只對自己的產出到對整個組織結構的五種位置。位置決定當下煩惱什麼：初中級工程師煩惱怎麼讓自己的產出被信任，Tech Lead 煩惱怎麼讓別人的產出達標，EM 煩惱人留不留得住，管理管理者煩惱組織切法對不對。這些煩惱各自對應不同的書，但涵蓋的知識領域大量重疊——同一本談心理安全感的書，四個位置都用得到，用法完全不同。</p>
<p>這條線不處理技藝——程式怎麼寫、怎麼改得動、怎麼驗證，那些在 <a href="../craft/">工程技藝</a>。兩條線的失敗互相看不見，因此分開。另有一條線 <a href="../finance/">財務與投資</a> 處理的是自己的資本與現金流，跟這裡的分界不是同一個軸：那條線的決定不在工作場域裡發生，本篇的位置表與規模、流動率這些約束在那裡都不適用。</p>
<p>書的完整描述住在主題篇，位置與主題兩張路由表只給書名與連結。這個分工的理由是同一本書會出現在多個位置的建議清單裡，若每個位置各寫一份說明，幾份說明會隨時間漂移成幾種不同的講法。</p>
<h2 id="完全不熟悉這個領域時先讀這一本">完全不熟悉這個領域時先讀這一本</h2>
<p><a href="topics/continuous-delivery/">Accelerate</a> 是這條線的單一起點。選它的理由是它同時滿足兩個條件，而與品質排名無關：結論建立在數萬份跨組織調查上，因此可以拿來支持實際決定；而且它的四項指標已經是業界共同語言，讀完之後其他書的討論才有共同座標。</p>
<p>它的限制要先知道：它談的是組織層級的交付效能，不談個人怎麼寫程式、也不談怎麼跟人相處。如果目前的困擾是「我下個月開始要帶人」「我想知道管理職實際在做什麼」「我不知道怎麼跟主管講壞消息」或「我不知道自己夠不夠格升等」，這本書不會回答，直接往下面的位置表走。</p>
<h2 id="依當下的位置選書">依當下的位置選書</h2>
<p>位置的判準是對什麼負責，不是職稱——同一個職稱在大企業與小公司對應的責任範圍經常不同。判準的操作版本是：<strong>交不出來的時候，誰會被問</strong>。下表給每個位置的起點書；那個位置一天實際在處理什麼、在有階梯與沒階梯的組織裡問題差在哪、往相鄰位置移動前該預習什麼，在 <a href="roles/">依位置選書</a> 的五篇裡。</p>
<table>
  <thead>
      <tr>
          <th>位置</th>
          <th>當下的主要問題</th>
          <th>起點</th>
          <th>主要主題</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="roles/own-output/">只對自己的產出負責</a></td>
          <td>怎麼讓產出被信任、怎麼知道自己下一步該補什麼</td>
          <td>The Software Engineer&rsquo;s Guidebook</td>
          <td><a href="topics/role-transitions/">角色轉換與職涯路徑</a>、<a href="topics/problem-definition/">問題定義與系統思考</a></td>
      </tr>
      <tr>
          <td><a href="roles/technical-quality/">對技術品質負責、不帶人</a></td>
          <td>沒有指揮權時怎麼讓別人照著做、技術決策怎麼被採納</td>
          <td>The Staff Engineer&rsquo;s Path</td>
          <td><a href="topics/influence-conversation/">困難對話與無權限影響力</a>、<a href="topics/team-design/">組織結構與團隊設計</a></td>
      </tr>
      <tr>
          <td><a href="roles/others-output/">對別人的產出負責（Tech Lead）</a></td>
          <td>怎麼讓團隊的產出達標而不變成自己重寫</td>
          <td>The Manager&rsquo;s Path</td>
          <td><a href="topics/continuous-delivery/">持續交付與交付效能</a>、<a href="topics/influence-conversation/">困難對話與無權限影響力</a></td>
      </tr>
      <tr>
          <td><a href="roles/people/">對人負責（EM）</a></td>
          <td>人留不留得住、回饋怎麼給、壞消息為什麼傳不上來</td>
          <td>Peopleware</td>
          <td><a href="topics/retention-motivation/">留任、動機與工作環境</a>、<a href="topics/culture-safety/">組織文化與心理安全感</a>、<a href="topics/personal-workflow/">個人工作流與工作負荷</a></td>
      </tr>
      <tr>
          <td><a href="roles/org-structure/">對組織結構負責（管理管理者）</a></td>
          <td>團隊怎麼切、交接面誰負責、承諾為什麼總是跳票</td>
          <td>Team Topologies</td>
          <td><a href="topics/team-design/">組織結構與團隊設計</a>、<a href="topics/estimation-decision/">估算、承諾與決策偏誤</a></td>
      </tr>
  </tbody>
</table>
<p>起點書的完整描述與購書連結在對應的主題篇：前三本在 <a href="topics/role-transitions/">角色轉換與職涯路徑</a>，Peopleware 在 <a href="topics/retention-motivation/">留任、動機與工作環境</a>，Team Topologies 在 <a href="topics/team-design/">組織結構與團隊設計</a>。</p>
<p>有三種處境這張表判不出來：好幾格同時成立、還沒被指派而想先評估下一格、以及團隊人數不到一個團隊。三種各自的做法在 <a href="roles/">依位置選書</a> 的「怎麼判斷自己在哪一格」段，該段開頭就標出三者分別在哪一小段。</p>
<p>想往上或往旁邊移動時，預習的方向跟當下的問題不同。純個人貢獻者想走管理，第一站是 <a href="topics/role-transitions/">角色轉換與職涯路徑</a>：那裡的書逐層寫出管理位置整天在處理什麼，而「值不值得走過去」得先看得到那個。決定要走之後才輪到 <a href="topics/retention-motivation/">留任、動機與工作環境</a> 與 <a href="topics/culture-safety/">組織文化與心理安全感</a>——這兩塊在只對自己負責的位置上完全用不到，因此也最沒有機會自然累積。想走 Staff+ 技術路線的人，預習的是 <a href="topics/influence-conversation/">困難對話與無權限影響力</a> 與 <a href="topics/team-design/">組織結構與團隊設計</a>，因為技術決策要能推得動，靠的是能不能把方案講進別人的約束裡，職權在這條路線上幫不上忙。</p>
<h2 id="依主題選書">依主題選書</h2>
<p>十一個主題與各自的首選書在 <a href="topics/">主題書單目錄</a>。那一頁是主題與首選的唯一清單，這裡不重複列，避免兩份清單各自漂移。</p>
<h2 id="經典套書怎麼買">經典套書怎麼買</h2>
<p>各主題篇按問題組織，因此同一套書會分散在不同篇。實際購買時面對的是套書決定，這一段只處理那個決定，每本書的性質判定回各主題篇看。</p>
<p>Gerald Weinberg 的《溫伯格的軟體管理學》四卷分別對應四個主題：第 1 卷系統化思考在 <a href="topics/problem-definition/">問題定義與系統思考</a>，第 2 卷第一級評量在 <a href="topics/continuous-delivery/">持續交付與交付效能</a>，第 3 卷關照全局的管理作為在 <a href="topics/influence-conversation/">困難對話與無權限影響力</a>，第 4 卷擁抱變革在 <a href="topics/team-design/">組織結構與團隊設計</a>。第 1、2 卷處理的問題現在有大規模實證的書可以對照，第 3 卷處理的管理者即時反應在這條線的其他書裡沒有對應。只買一卷買第 3 卷；買套書適合想看完整論述的讀者。四卷合購頁在<a href="https://www.books.com.tw/products/0010553999">博客來</a>。</p>
<p>Tom DeMarco 與 Timothy Lister 的兩本分屬不同主題：《Peopleware》在 <a href="topics/retention-motivation/">留任、動機與工作環境</a>，《Waltzing with Bears》（繁中《與熊共舞》）在 <a href="topics/estimation-decision/">估算、承諾與決策偏誤</a>。兩本沒有合購版本，分開買。</p>
<h2 id="相關的實作內容">相關的實作內容</h2>
<p>書單處理選讀判斷，技術實作在教學系列：交付管線與部署 gate 看 <a href="/blog/ci/" data-link-title="CI/CD 教學" data-link-desc="整理 CI/CD 的驗證、建置、發布 gate 與不同部署場域的流程差異，讓每次變更都能被穩定驗證與交付">CI/CD 教學</a>，服務探活、容量規劃與高可用看 <a href="/blog/operations/" data-link-title="運行期維運 — 服務在 production 怎麼活下來" data-link-desc="負載平衡、水平擴展、流量管控、服務探活、容量規劃、高可用、突發流量、成本管理 — 服務上線後運行期的工程基礎">運行期維運</a>，事故分級、指揮角色與復盤制度看 <a href="/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤</a>，客戶端遙測的四類事件與收集鏈路看 <a href="/blog/monitoring/" data-link-title="監控實務指南" data-link-desc="整理非伺服器端運行時的監控體系 — 行為蒐集、錯誤回報、效能指標、生命週期追蹤，從自架方案到商業方案的完整知識路線">Monitoring 監控體系</a>，交付生命週期全景看 <a href="/blog/devops/" data-link-title="DevOps 全景：軟體交付生命週期" data-link-desc="想釐清 infra、CI/CD、運行期維運怎麼串成一條軟體交付生命週期、或不確定手上的問題該進哪個系列時回來讀">DevOps 全景</a>。既有團隊的結構評估協議看 <a href="/blog/record/launch-control-team-lens-methodology/" data-link-title="發射管制隊視角：評估工作團隊設計的判讀方法" data-link-desc="設計或檢視團隊分組、agent 編制、審查角色歸屬時，用發射管制隊的組織概念逐項判讀結構選擇的正當性：任務編組、安全分線、業務與編組之分等判讀 lens">發射管制隊視角：評估工作團隊設計</a>。</p>
<h2 id="backlog">Backlog</h2>
<table>
  <thead>
      <tr>
          <th>項目</th>
          <th>類型</th>
          <th>前置條件</th>
          <th>規模</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>十個主題各跑一次機制式搜尋</td>
          <td>案例</td>
          <td>機制詞候選事前寫死在主題書單的公開課段（研究設計與因果推論 / 承諾可信度 / 訊號傳遞 / 集體決策 / 因果回路與存量流量），產物是十組詞各查到什麼，可重跑</td>
          <td>1 次</td>
      </tr>
      <tr>
          <td>沒查到課的十個主題重掃一次</td>
          <td>案例</td>
          <td>2027 年 8 月之後重跑，判準是本質恆定加實際有影音；是哪十個主題與各自為什麼空，見 <a href="topics/">主題書單</a> 的公開課段</td>
          <td>1 次</td>
      </tr>
      <tr>
          <td>系統思考這個主題改判</td>
          <td>主章</td>
          <td>MIT 15.871 補上影片，或找到另一門教因果回路與存量流量而有影音的課；沒有人會主動去看，實際觸發點是 2027 年那次重掃</td>
          <td>1 段</td>
      </tr>
  </tbody>
</table>
]]></content:encoded></item></channel></rss>