<?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/tags/%E7%A4%BE%E6%9C%83%E5%AD%B8/</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>Wed, 19 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E7%A4%BE%E6%9C%83%E5%AD%B8/index.xml" rel="self" type="application/rss+xml"/><item><title>偏差正常化：每次放寬都有理由，累積起來走到災難</title><link>https://tarrragon.github.io/blog/til/organization/normalization-of-deviance/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/til/organization/normalization-of-deviance/</guid><description>&lt;p>偏差正常化（normalization of deviance）指的是&lt;strong>一個群體反覆接受某個超出規格的狀況而沒有出事，於是那個狀況逐漸被重新定義成正常&lt;/strong>。它的關鍵性質是每一步都在當下是合理的：這一次的放寬有具體理由、也確實沒有造成後果，於是新的狀態成為下一次判斷的基準，下一次再從新基準往外放一點。&lt;/p>
&lt;p>這個概念由社會學家 Diane Vaughan 在《The Challenger Launch Decision》（1996）提出。她重建挑戰者號失事的決策鏈之後，推翻了當時的通俗解釋——&lt;strong>那不是有人違規或隱瞞&lt;/strong>。O 型環的侵蝕在先前多次飛行就出現過，每一次都沒有導致失敗，於是「有侵蝕」從異常訊號變成預期現象、再變成可接受風險的一部分。發射前那場著名的爭論裡，工程師拿不出「這次會出事」的證據，因為判斷基準早就移動過了。&lt;/p>
&lt;h2 id="它跟隱瞞的差別在哪裡">它跟隱瞞的差別在哪裡&lt;/h2>
&lt;p>這個區分是整個概念的重點。隱瞞有一個知道真相的人；偏差正常化沒有——參與者不是壓下了警訊，是他們真心不再認為那是警訊。所以事後追查「誰知道而沒說」會落空，而落空之後常見的結論是「大家都盡力了、只是運氣不好」，那同樣錯過了真正可改的東西。&lt;/p>
&lt;p>可改的東西是&lt;strong>判斷基準怎麼被移動的&lt;/strong>：哪一次的例外沒有被記錄成例外、哪一個「這次先這樣」沒有設回收期限、哪個原本要簽核的動作變成口頭同意。這些是可以留下痕跡、也可以設計制度去攔的。&lt;/p>
&lt;p>哥倫比亞號 2003 年失事後，調查委員會的報告直接引用了 Vaughan，並指出同一個模式在同一個組織裡再次完整發生——這也說明偏差正常化不是可以靠一次事故教訓「學會」的東西。&lt;/p>
&lt;h2 id="軟體團隊的對應形態">軟體團隊的對應形態&lt;/h2>
&lt;p>同一個機制在軟體組織裡很容易辨認，因為每一步都有當下的理由：&lt;/p>
&lt;ul>
&lt;li>這次先跳過測試，因為要趕修這個線上問題&lt;/li>
&lt;li>這次手動改生產環境，因為改設定比走流程快&lt;/li>
&lt;li>這個警報先靜音，因為它最近一直誤報&lt;/li>
&lt;li>這次先不寫檢討，因為影響範圍很小&lt;/li>
&lt;/ul>
&lt;p>單看每一條都不算離譜，而問題在於&lt;strong>沒出事本身被當成了做法沒問題的證據&lt;/strong>。跑十次沒事的手動改機，跟跑十次沒事之後第十一次改錯，是同一個做法。&lt;/p>
&lt;p>辨識訊號是「上次也是這樣」開始被用來當理由——那句話在說的正是基準已經移動。&lt;/p>
&lt;h2 id="跟相鄰概念的關係">跟相鄰概念的關係&lt;/h2>
&lt;p>它跟 &lt;a href="../psychological-safety/">心理安全感&lt;/a> 都會讓組織收不到壞消息，但機制不同：心理安全感低的組織裡有人看見了而不敢講，偏差正常化的組織裡沒有人覺得那件事需要講。修法因此也不同——前者要改組織對壞消息的反應，後者要在制度上讓例外留下痕跡並強制回收。兩者疊在一起時最難救，因為既沒有人認為要講、就算有人想講也沒有安全的說法。&lt;/p>
&lt;p>它跟 &lt;a href="../../behavior/hindsight-bias/">後見之明偏誤&lt;/a> 是事故調查裡的一對：後見之明偏誤讓調查者以為當時的訊號很明顯，而偏差正常化解釋了那些訊號當時為什麼真的不明顯——它們已經被納入正常範圍了。忽略後者的調查會停在「他們怎麼會沒發現」，而那個問句無法產出任何改動。&lt;/p>
&lt;h2 id="要往下讀">要往下讀&lt;/h2>
&lt;p>完整的個案重建看 Vaughan 的原書，它是八百頁的學術專著；選讀判斷與較輕的替代路徑在 &lt;a href="https://tarrragon.github.io/blog/books/software-management/topics/incident-blame/" data-link-title="事故、歸因與無指責檢討" 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;/p></description><content:encoded><![CDATA[<p>偏差正常化（normalization of deviance）指的是<strong>一個群體反覆接受某個超出規格的狀況而沒有出事，於是那個狀況逐漸被重新定義成正常</strong>。它的關鍵性質是每一步都在當下是合理的：這一次的放寬有具體理由、也確實沒有造成後果，於是新的狀態成為下一次判斷的基準，下一次再從新基準往外放一點。</p>
<p>這個概念由社會學家 Diane Vaughan 在《The Challenger Launch Decision》（1996）提出。她重建挑戰者號失事的決策鏈之後，推翻了當時的通俗解釋——<strong>那不是有人違規或隱瞞</strong>。O 型環的侵蝕在先前多次飛行就出現過，每一次都沒有導致失敗，於是「有侵蝕」從異常訊號變成預期現象、再變成可接受風險的一部分。發射前那場著名的爭論裡，工程師拿不出「這次會出事」的證據，因為判斷基準早就移動過了。</p>
<h2 id="它跟隱瞞的差別在哪裡">它跟隱瞞的差別在哪裡</h2>
<p>這個區分是整個概念的重點。隱瞞有一個知道真相的人；偏差正常化沒有——參與者不是壓下了警訊，是他們真心不再認為那是警訊。所以事後追查「誰知道而沒說」會落空，而落空之後常見的結論是「大家都盡力了、只是運氣不好」，那同樣錯過了真正可改的東西。</p>
<p>可改的東西是<strong>判斷基準怎麼被移動的</strong>：哪一次的例外沒有被記錄成例外、哪一個「這次先這樣」沒有設回收期限、哪個原本要簽核的動作變成口頭同意。這些是可以留下痕跡、也可以設計制度去攔的。</p>
<p>哥倫比亞號 2003 年失事後，調查委員會的報告直接引用了 Vaughan，並指出同一個模式在同一個組織裡再次完整發生——這也說明偏差正常化不是可以靠一次事故教訓「學會」的東西。</p>
<h2 id="軟體團隊的對應形態">軟體團隊的對應形態</h2>
<p>同一個機制在軟體組織裡很容易辨認，因為每一步都有當下的理由：</p>
<ul>
<li>這次先跳過測試，因為要趕修這個線上問題</li>
<li>這次手動改生產環境，因為改設定比走流程快</li>
<li>這個警報先靜音，因為它最近一直誤報</li>
<li>這次先不寫檢討，因為影響範圍很小</li>
</ul>
<p>單看每一條都不算離譜，而問題在於<strong>沒出事本身被當成了做法沒問題的證據</strong>。跑十次沒事的手動改機，跟跑十次沒事之後第十一次改錯，是同一個做法。</p>
<p>辨識訊號是「上次也是這樣」開始被用來當理由——那句話在說的正是基準已經移動。</p>
<h2 id="跟相鄰概念的關係">跟相鄰概念的關係</h2>
<p>它跟 <a href="../psychological-safety/">心理安全感</a> 都會讓組織收不到壞消息，但機制不同：心理安全感低的組織裡有人看見了而不敢講，偏差正常化的組織裡沒有人覺得那件事需要講。修法因此也不同——前者要改組織對壞消息的反應，後者要在制度上讓例外留下痕跡並強制回收。兩者疊在一起時最難救，因為既沒有人認為要講、就算有人想講也沒有安全的說法。</p>
<p>它跟 <a href="../../behavior/hindsight-bias/">後見之明偏誤</a> 是事故調查裡的一對：後見之明偏誤讓調查者以為當時的訊號很明顯，而偏差正常化解釋了那些訊號當時為什麼真的不明顯——它們已經被納入正常範圍了。忽略後者的調查會停在「他們怎麼會沒發現」，而那個問句無法產出任何改動。</p>
<h2 id="要往下讀">要往下讀</h2>
<p>完整的個案重建看 Vaughan 的原書，它是八百頁的學術專著；選讀判斷與較輕的替代路徑在 <a href="/blog/books/software-management/topics/incident-blame/" data-link-title="事故、歸因與無指責檢討" data-link-desc="事故檢討停在人為疏失、同類事故一再發生時，用來重建當事人視角與辨認偏差累積的安全科學">事故、歸因與無指責檢討書單</a>。把例外留下痕跡、設定回收期限這類制度實作，看 <a href="/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤</a>。</p>
]]></content:encoded></item></channel></rss>